Pagin 1 din 17

Development Guide
Submitted by Z98 on Sat, 11/12/2011 - 22:00
This guide is intended to help new developers setup and familiarize themselves with the tools
needed to obtain, compile, and work with the ReactOS source code, along with a few tips and best
practices for the required tools if new developers are unsure what is the best approach to use. This
guide does not provide a walkthrough of the ReactOS code base nor does it present an introduction to
the NT architecture.
Source Control
Build Environment
Installation
Debugging Overview
Virtual Machines
Translation
Source Control
Submitted by Anonymous on Sat, 11/12/2011 - 23:07
Revision control for the ReactOS source code is managed using Subversion. As such, users
will need a SVN client. Developers working on Windows are encouraged to useTortoiseSVN as it
helps simplify many of the tasks associated with managing source code.
Source Code
The ReactOS project's source code is split into several different folders.
ReactOS: The operating system itself with required base components.
svn://svn.reactos.org/reactos/trunk/reactos/
Applications: Additional applications developed for use with ReactOS and bundled with each point
release. svn://svn.reactos.org/reactos/trunk/rosapps/
Documentation: Documentation on various ReactOS components.
svn://svn.reactos.org/reactos/trunk/documentation/
Media: Graphical media used by the project. svn://svn.reactos.org/press-media/trunk/
Tools: Additional tools used to assist the project. svn://svn.reactos.org/project-tools/trunk/
Wallpapers: Wallpapers bundled with each point release.
svn://svn.reactos.org/reactos/trunk/wallpaper/
Website: Modules and other website scripts used on the ReactOS site.
svn://svn.reactos.org/web/trunk/
Pagin 2 din 17

A variety of branches also exist for the purpose of implementing new functionality without
introducing major regressions during the development process.
Checking Out with Command-line SVN
In the folder where one wishes to checkout the ReactOS source code, execute the following
command on the terminal, replacing MODULE_NAME with the name of the ReactOS component one
wishes to check out:
svn co svn://svn.reactos.org/reactos/trunk/MODULE_NAME/
The follow example will check out the ReactOS operating system and required base components:
svn co svn://svn.reactos.org/reactos/trunk/reactos/
Checking out branches from the ReactOS repository is done as follows, replacing BRANCH with the
name of the desired branch:
svn co svn://svn.reactos.org/reactos/branches/BRANCH/
The checked out copy of ReactOS is called the working copy. To update one's local working copy, the
following command is used:
svn up
Checking Out with TortoiseSVN
Checking out with TortoiseSVN is trivially simple. Simply right-click on the directory you want
to save the checkout to and select SVN Checkout from the menu.
Then fill out the repository URL to point to ReactOS' SVN server.
Hit OK and wait a bit for the checkout to complete.
Patches and Commits
Developers with commit access can submit their changes directly to the ReactOS repository.
Developers who do not have permission to commit to the ReactOS repository must generate patches
to submit to the project for review if they wish to contribute code.
Creating Patches with Commandline SVN
Change into the directory where your changes are and run the following command, replacing
PATCHFILE with a name of your choosing that describes the changes:
Pagin 3 din 17

svn diff > PATCHFILE.patch
Creating Patches with TortoiseSVN
Right-click on the directory with the source checkout and navigate to the Create patch option in the
TortoiseSVN menu.

Clicking on it will bring up a window asking you to select all the changed files to include in the patch.

Select the files you want included and click OK. Save the patch somewhere and give it a meaningful
name.
Commit Messages
Code commits made to the ReactOS repository should follow the below format.
[Component Name] * Description of Change (Ticket number of bugzilla ticket exists)
An example of this is the follow commit by Johannes Anderwald:
[KERNEL32] * Don't access freed memory in GetVolumeNameForVolumeMountPointW
Past commits can be viewed in the ros-diffs mailing list archive.
Committing with Commandline SVN
The following command is executed to commit changes, replacing directory_with_changes to point to
the folder one wishes to commit:
svn ci -m "Commit message" directory_with_changes
The first time a commit is made, the SVN client will ask for a username and password. Both can also
be passed in using the commandline arguments --username and --password.
Committing with TortoiseSVN
Right-click on the directory with the source checkout and click on the SVN Commit option.

Pagin 4 din 17

This will bring up a window where you can type in the commit message and select the changed files
you want as part of the commit.

Merging with TortoiseSVN
Build Environment
Submitted by Z98 on Sat, 11/12/2011 - 23:44
The Project provides a package of customized compilers and tools to help quickly set up everything
needed to build ReactOS called the ReactOS Build Environment (RosBE) for bothWindows and Unix.
The BE includes:
CMake 2.8.10.2
MinGW GCC 4.7.2
ninja
Commandline SVN Client
Note that the build environment on Windows should only be installed if one wants to use the MinGW
toolchain to build ReactOS. If one wishes to use Microsoft's toolchain either from the command line or
Visual Studio, the project provides an installer for a standalone, customized version of CMake and
ninja. After installation, simply make sure the bin directory of CMake is in the path.
Build Procedure
When building using the MinGW toolchain, one must have started the command prompt using the
shortcut created by the build environment. This shortcut helps set up the necessary paths and
environment variables to make sure all of the necessary compilers and tools are found. It is highly
recommended that compilation be done in a separate directory from the source checkout. This keeps
the checkout clean and makes it easier to blow away the compiled objects for a truly clean build. The
following instructions all assume a separate build directory has been created and is the build
environment terminal's current working directory. For the commandline build, execute:
pathtocheckout/configure
NOTE: By default, ninja is used for generating the build files. If you want to use makefiles instead, just
use the following command:
pathtocheckout/configure Makefiles
This creates several directories and files in the build directory, the two most important being the host-
tools and reactos directories. Before ReactOS can be compiled, some helper tools need to be
Pagin 5 din 17

compiled first. To do this, enter the following commands to move into the host-tools directory and
build.
cd host-tools && ninja
Once the host tools have been compiled, move into the reactos directory next to the host-tools
directory to build ReactOS.
cd ../reactos && ninja
The final step is to build an image for installation or testing. The following are the different types of
images currently available.
bootcd: An image that can be used to install ReactOS onto a computer, real or virtual.
bootcdregtest: An unattended installation image that automatically runs through a series of
regression tests.
livecd: An image that can be run on a computer from the CD-ROM.
For example, to build a bootcd, use the following command.
ninja bootcd
Note that this command can be issued even before ReactOS has been built. If the object files have
not been generated yet, the build system will simply start a build from scratch before building the
image.
NOTE: When using makefiles, use make (or makex) instead of ninja.

On Windows systems, it is also possible to build ReactOS using Microsoft's toolchain. ReactOS
currently supports using Visual Studio 2010 and 2012. One however needs to execute the configure
script from the Visual Studio command prompt instead of the build environment tool prompt. The
cmake version bundled with the ReactOS Build Environment must however be in the path
somewhere. Generating the command line build is effectively the same as the above instructions.
Generating a Visual Studio solution file requires a different argument to be passed to configure like so:
pathtocheckout/configure VSSolution
Pagin 6 din 17

Two separate solutions are created, one for the host tools and the other for ReactOS proper. Once
again, the host tools must be built first before attempting to build ReactOS. Please note however that
while the Visual Studio build boots, it is not entirely working yet.
Installation
Submitted by Z98 on Sun, 02/10/2013 - 22:08
Installing ReactOS is very much like installing Windows XP. However, due to it still undergoing heavy
development, a few pointers are helpful when first getting started.
Installation Platform
ReactOS currently supports running on x86 processors with x64 support still in development. In
additional to real hardware, ReactOS also supports running on a variety of virtual machine platforms.
More details on setting up ReactOS can be found on the virtual machines page. Several caveats exist
regarding what hardware ReactOS will work with and the following sections seek to document the
more prominent issues.
Minimum System Requirement
Pentium I processor or later
32 MB of RAM (Debug builds may require 48MB of RAM)
IDE/SATA hard disk drive with at least 350MB of space
VGA compatible video card (VESA BIOS version 2.0 or later)
PS/2 keyboard
PS/2 compatible mouse or Microsoft Mouse compatible serial mouse
Drives
ReactOS has uneven support for SATA drives. It is recommended that IDE compatibility mode be
used for best results
The boot partition must be the first FAT16 or FAT32 partition on the disk.
The setup utility cannot check the integrity of file systems.
USB
USB support is still in development and not all devices are yet supported. Generally it is advised to set
USB keyboard and mice to legacy mode in the BIOS when installing ReactOS.
Boot Options
A variety of options can be added to the freeldr.ini file to change the configuration that ReactOS will
boot into. The following is an example of an entry for booting ReactOS in a specific configuration.
[ReactOS]
BootType=ReactOS
Pagin 7 din 17

SystemPath=multi(0)disk(0)rdisk(0)partition(1)\reactos
Options=/DEBUGPORT=SCREEN
DEBUG
Turn on debugging output. This option is automatically turned on when running a debug build of
ReactOS.
To specify output device use DEBUGPORT option. If DEBUGPORT is not specified output by default
goes to COM1.
Format: DEBUG
DEBUGPORT
Specifying DEBUGPORT as a boot option will enable certain debugging features.
Format: DEBUGPORT=[SCREEN|BOCHS|GDB|PICE|COM1|COM2|COM3|COM4|COM:|FILE|MDA]
Any one of the following values may set:
SCREEN: Send debug output to the screen.
BOCHS: Send debug output to bochs.
GDB: Enable the GNU debugger (GDB) stub so remote debugging using GDB is possible.
PICE: Enable the Private ICE driver so debugging using Private ICE is possible.
COM#: Send debug output to COM port #.
COM:[hex address]: Specifies the COM port address. (Example: /DEBUGPORT=COM:0xCC00 )
FILE: Send debug output to a file %systemroot%/reactos/debug.log
MDA: Send debug output to MDA (The old text graphics card from IBM).
It is permitted to use several DEBUGPORT options, but for ports of the same class, for example,
COM ports, only the last one will be used for output.
BAUDRATE
Specifies baudrate of the serial port to be [baudrate] bps. Used in conjunction with COM1-4 or GDB.
Format: BAUDRATE=[baudrate]
IRQ
Specifies the IRQ number of the serial port to be [irq-number]. Used in conjunction with COM1-4 or
GDB.
Format: IRQ=[irq-number]
Pagin 8 din 17

PROFILE
Enables profiling. Profiling information will be written in %windir%\profiler.log. This will slow down the
system quite a bit.
Format: PROFILE
MAXMEM
Will restrict ReactOS to use only the first [maxmem] MB of physical memory.
Format: MAXMEM=[maxmem]
NOGUIBOOT
Disables the bitmap that displays the progress bar at ReactOS startup.
Format: NOGUIBOOT
FIRSTCHANCE
Set up exceptions to be passed to debugger on its occurrence, before being handled by regular
exception handling code.
Format: FIRSTCHANCE
MININT
Loads the Registry SYSTEM hive as a volatile hive, such, that changes made to it in memory are not
saved back to the hive image, into registry file. Useful for running ReactOS from a liveCD.
Format: MININT
Debugging Overview
Submitted by Z98 on Sun, 11/13/2011 - 01:01
Debugging is an important skill to have when developing large, complex pieces of software. The
ReactOS project has a variety of resources and tools to help its developers identify problems. Several
different debuggers are supported by the project and the operating system also generates debug
messages that can be captured and viewed using a variety of methods. The below guides will show
you how to set up ReactOS and the platform it is installed on to receive debug output as well as how
to use a debugger to examine the executing code.
Debug Verbosity
One of the most basic ways of acquiring debug information about the operating system is from the
debug messages sent over serial. These debug messages have varying levels of verbosity, with
Pagin 9 din 17

DPRINT1 messages always being printed and DPRINT messages only showing when NDEBUG is
not defined. This define tends to be at the top of source files and commenting it out will increase the
verbosity for that file. Changing this define of course requires recompilation of the operating system.
Verbosity can also be increased at runtime by setting the environment variable DEBUGCHANNEL to
include the desired application or component. The following example shows how this is done on the
command line for a few components.
set DEBUGCHANNEL=+msi,+rpc,+ole
This can also be done using the registry, though would require a reboot. Simply add the following line
to the boot/bootdata/hivesys.inf file.
HKLM,"SYSTEM\CurrentControlSet\Control\Session
Manager\Environment","DEBUGCHANNEL",0x00020000,"+ole,+rpc"
Finally, developers and testers can add in their own debug messages by inserting DPRINT or
DPRINT1 calls in the operating system. These in principle work like printf, but have different
formatting codes.
Capturing Debug Output
Debug messages can be captured and viewed in a variety of methods. The most common is over a
serial connection, but messages can also be written to a file or even an application in ReactOS. The
latter two can be somewhat more problematic if there is a major problem that causes the system to
crash so serial output is the preferred method for capturing debug output.
Debug to File
It is possible to have debug output written to a file in ReactOS. By default they will be saved in the file
debug.log in the root directory. This can be overridden by changing the following line in freeldr.ini:
Options=/DEBUG /DEBUGPORT=FILE:\Device\Harddisk0\Partition1\debug.log /SOS
or
Options=/DEBUG /DEBUGPORT=FILE:\ArchName\multi(0)disk(0)fdisk(0)\debug.log /SOS
Note that this method is fairly limited and fatal system errors will not be recorded.
Pagin 10 din 17

Debug to Screen
Sending debug messages to the screen is also possible, but comes with a major limitation. The
messages are not actually displayed to the output display until a user breaks into the kernel debugger.
A separate application would need to be written to receive and display these messages. Turning on
this feature requires adding or modifying the DEBUGPORT option in freeldr.ini as follows:
Options=/DEBUG /DEBUGPORT=SCREEN
Debug to Serial
By far the most useful of the debug output options, this option works out of the box on ReactOS' side
but requires additional setup in order to receive messages. This will be covered in the next section.
Debugger Break-In
Bugchecks occur when the operating system can no longer continue running without risking data
corruption. This normally results in a blue screen of death, but when a kernel debugger is attached the
system will instead drop into a command prompt. ReactOS debug builds have the integrated kernel
debugger enabled and will do this, whereas release builds will simply blue screen. To enter the kernel
debugger, simply hit TAB-K on the keyboard attached to the system running ReactOS. To exit the
debugger, type in cont and hit enter.
Generating a Backtrace
Backtraces help determine what the operating system was doing before a bugcheck occurred. This is
done from inside the kernel debugger.
Enter 'bt' and hit enter to produce output. The following is the example that will be used for this guide.
(drivers\filesystems\vfat\rw.c:809) <\ReactOS\system32\kernel32.dll> Entered debugger on
embedded INT3 at 0x0008:0x800935f2.
kdb:> bt
Eip:
<ntoskrnl.exe:935f3 (lib\rtl\i386\debug_asm.S:31 (DbgBreakPoint@0))\>
Frames:
<vfatfs.sys:97de (drivers/filesystems/vfat/misc.c:111 (VfatDispatchRequest))>
<vfatfs.sys:9b25 (drivers/filesystems/vfat/misc.c:167 (VfatBuildRequest))>
<ntoskrnl.exe:3ab23 (ntoskrnl/io/iomgr/irp.c:1088 (IofCallDriver))>
<ntoskrnl.exe:36206 (ntoskrnl/io/iomgr/iofunc.c:686 (IoSynchronousPageWrite))>
<ntoskrnl.exe:59daa (ntoskrnl/mm/section.c:6330 (MmspWriteDataSectionPages))>
<ntoskrnl.exe:244c6 (ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint))>
<ntoskrnl.exe:70e90 (ntoskrnl/ps/thread.c:134 (PspSystemThreadStartup))>
Pagin 11 din 17

<ntoskrnl.exe:7b142 (ntoskrnl\ke\i386\ctxswitch.S:258 (KiThreadStartup@156))>
kdb:>
The debugger already displays that the bugcheck occurred during an INT3 operation and it specifies
the address at which it happened. The following lines indicate the chain of operations that ultimately
led up to the bugcheck.
Serial Configuration
Submitted by Z98 on Sat, 02/09/2013 - 23:02
Debugging ReactOS over serial tends to be the most reliable methodology as it minimizes the risk of
losing debug output when ReactOS crashes compared to directing output to a file or application in
ReactOS. It however takes a bit more setup on the receiving side and some extra hardware if
attempting to debug a physical machine. The following provides basic instructions for setting up serial
on both the sending and receiving side. For more detailed instructions on configuring serial output for
virtual machines, please refer to the virtual machine section of this guide.
Serial Configuration
When debugging a physical machine with ReactOS installed, the machine must have a serial port
installed. While many motherboards do have such an interface, most do not expose it to the end user
and require an extra ribbon cable to connect the serial pins to a port. The receiving machine does not
necessarily need a serial interface installed, as USB adapters do exist. Please be aware however that
such adapters can be somewhat temperamental and it is generally more reliable to use an actual
serial device. These adapters also cannot be used on the machine with ReactOS installed, as
ReactOS is not capable of using USB to output debug messages. If a motherboard does not have a
serial port or serial pins that can be easily hooked up to a port, serial PCI cards also exist.
By default, the debug build of ReactOS has its serial baud rate set at 115200. This can however be
changed if there is a reliability issue at that speed. To do so, simply modify the BAUDRATE line in
freeldr.ini like so:
/BAUDRATE=921600
Another value that might need to be changed is the serial port to use to send output. To do so, simply
modify the DEBUGPORT to an appropriate port like so:
/DEBUGPORT=COM1
Pagin 12 din 17

Serial Terminals on Linux/Unix Platforms
There are a wide range of programs that people can use to capture data from a serial port on Unix
based platforms. The following lists a few options that should be easy to use and instructions on how
to get started. For more detailed information, it is advised that interested readers look up the
respective man pages for these utilities.
cu
Assuming that a serial port is installed on the receiving computer, users can use the cu program to
receive messages over serial. This program is installed by default on FreeBSD and is known as uucp
on RPM-based Linux distros. The following command shows how to start up cu to listen on a serial
port.
sudo cu -s 115200 -e -o -t -l /dev/ttyS0
-l specifies the device being connected, which in this case is /dev/ttyS0. This name can be
determined by using dmesg
-e -o means there is no parity. An alternative way of specifying this is -parity=none.
-s specifies the baud rate at which output is transmitted. 115200 is a conservative value. Most
systems can probably handle a speed of 9600.
A useful script for storing debug output to a file is as follows:
DATE=`date +"%F_%H%M%S"` screen -dmS ROSlogger script MyMachine1-ROS-debug-$DATE.log
sudo cu -s 115200 -e -o -t -l /dev/ttyS0
This script will output the debug log to a file incorporating the date and time.
minicom
To capture serial output using minicom, simply type in the following command:
minicom -D /dev/ttyS0
The -D option specifies the device one wants to capture output from. Inside of minicom, hit Ctrl+A to
access the configuration menu to set things like parity and baud rate.
Serial Terminals on Windows
Capturing serial output on Windows is a bit trickier. Windows used to have a built in serial console
before in versions of NT before Vista, but does not any longer. There are however many third party
programs that work just as well. In actuality, any telnet client should be suitable for use as a serial
reader.
Pagin 13 din 17

Putty
Putty is likely better known as a SSH client for Windows, but can also act as a telnet client and
capture serial output. It can be acquired here. To configure it to capture serial data, select the Serial
option for Connection type and enter the Serial path. The path \\.\pipe\ros_pipe is used in many
examples in this guide. Speed is also commonly set to 115200.
TeraTerm
TeraTerm is an open source terminal emulator that supports both SSH and telnet and can be
acquired here. It too can be configured to capture input to serial ports and might actually be more
intuitive to set up for such connections.
Other Tools
A few other utilities and tools exist to help in dealing with serial devices.
com0com
Com0com is an open source utility to create virtual serial port bridges which can be used to capture
the debug output of ReactOS and direct it to a terminal program. It can be acquiredhere.
Virtual Machines
Submitted by Z98 on Sun, 02/10/2013 - 06:15
Virtual machines provide a stable and known configuration for ReactOS to run on, reducing the
chances that misbehaving hardware could destabilize the operating system. They are especially
helpful when developing and testing higher level components of ReactOS. Several virtual machine
platforms are supported and a basic guide to getting ReactOS running on them and configuring for
debug support. Suggested resource allocation for all of the following virtual machine platforms is a
minimum of 128MB of RAM and 2GB of storage space. As ReactOS currently does not support
utilizing multiple processors, it is best to assign only a single processor to the virtual machine.
QEMU
The QEMU project does not provide Windows builds directly, but several individuals have compiled
Windows versions themselves and the project has linked to them here. Please bear in mind that
QEMU by default does not include a graphical frontend for setting options. People not comfortable
working from the command line may wish to consider VirtualBox or VMWare Player instead.
Installation
1. Move the ReactOS installation image to the same directory as QEMU for convenience purposes.
2. Create a virtual disk image using the qemu-img utility like so:
qemu-img create -f vmdk reactos.vmdk 1GB
Pagin 14 din 17

Size the image as needed.
3. Run QEMU with the virtual image and installation image attached like so:
qemu -L . -m 128 -hda reactos.vmdk -cdrom ReactOS.iso -boot d
4. Follow the directions of the ReactOS installer. Make sure you choose Install bootloader on the
harddisk (MBR).
5. Once the system is done installing and reboots, close QEMU to shut down the VM.
6. Run QEMU with the following arguments to mount just the virtual disk image and not the
installation image:
qemu -L . -m 128 -hda reactos.vmdk
7. At the boot menu select your desired boot option. The first option selected is suitable for poking
around but the DEBUG option is required if you wish to debug crashes.
Serial Configuration
By default, ReactOS will send debug output to the COM1 serial port. You can however use the -serial
option to direct debug messages to other locations. The following are several examples of where
serial output can be redirected.
To redirect serial output to a file:
-serial file:"pathtofile"
To redirect serial output to a named pipe:
-serial pipe:"\\.\pipename\"
To redirect serial output to the console on Windows:
-serial file:CON
To redirect serial output to the console on Unix:
-serial stdio
To redirect serial output to another serial port on Windows:
-serial COM#
Pagin 15 din 17

VirtualBox
VirtualBox can be acquired at this location.
1. Create a new virtual machine with the recommended amount of memory and storage. The new VM
wizard will prompt you to either create or select a virtual harddrive. It is recommended you select
the dynamically expanding image to help conserve space on the host machine.
2. Go into the VM settings and enable the CD-ROM. Select to mount an ISO image and choose the
ReactOS installation image.
3. Set the boot order to be CD-ROM first, then harddrive.
4. Run the VM and follow the directions of the ReactOS installer. Make sure you choose Install
bootloader on the harddisk (MBR)
5. Once installation is done and the virtual machine is shut off, remove the ReactOS installation
image from the CD-ROM and swap the boot order back to harddisk first.
6. Boot the VM again and select your desired boot option. The first option selected is suitable for
poking around but the DEBUG option is required if you wish to debug crashes.
VMWare Player
VMWare Player is the free, non-commercial version of VMWare available for free download at
the VMWare site. Note that once an OS has been installed on a virtual machine, VMWare Player does
not support booting into a CD to install another OS.
Installation
1. Create a new virtual machine and choose to install an operating system later when prompted for
the installation disk.
2. Select Other when asked for the Guest Operating System.
3. Select the size of the virtual disk. It is recommended to store the virtual disk as a single file when
prompted.
4. Once the virtual machine is created, choose 'Edit virtual machine settings' and set the system
resources to the recommend values.
5. Under the CD/DVD section, choose 'Use ISO image file' and select the ReactOS installation image.
6. Run the VM and follow the directions of the ReactOS installer. Make sure you choose Install
bootloader on the harddisk (MBR)
7. Boot the VM again and select your desired boot option. The first option selected is suitable for
poking around but the DEBUG option is required if you wish to debug crashes.
Serial Configuration
VMWare Player's graphical user interface does not provide a way to configure serial ports. You will
have to edit the .vmx file that describes your virtual machine. Adding the following lines will create a
port and connect it to a port on the host machine.
Pagin 16 din 17

serial0.present = "TRUE"
serial0.fileName = "COM1"
Translation
Submitted by Z98 on Sun, 02/10/2013 - 23:03
ReactOS uses resource files to hold translations. These must be encoded using UTF-8 so
take care the text editor used on these files does not accidentally change the encoding. Each
language's resource file must be included in the rsrc.rc or application.rc file of the respective
component being translated. Please keep in mind that some components are imported from WINE
and as such translations of those components should be sent upstream instead.
The first thing to do is to make a copy of the english rc-file, usually called en-US.rc, and name
it after the target language. If you do not know the code for your language, check the two-letter codes
of the ISO 639 standard. Microsoft also maintains a list of language identifiers here. Please note that a
few files may differ from this list, for example files originally from Wine. As such, make sure to confirm
a translation does not already exist before starting a new one.
When translating, following the guidelines below.
Change LANG_ENGLISH into your language (Example: LANG_SWEDISH). Depending on your
language and location, you might also have to change the Sublang from SUBLANG_NEUTRAL or
SUBLANG_DEFAULT.
Translate the strings in quotes. There are a few exceptions but they are fairly obvious. For example
you should not translate "MS Shell Dlg" (which is a font, as you can see in the beginning of the
line) or "SysListView32".
Leave an end of file line (a blank line) at the end of your rc file for ease of building.
Common Characters
&
The ampersand denotes the letter that comes after it as a hotkey. A hotkey is a key you can use to
quickly access different menus and options. The hotkey is shown with an underline.
%
The percent sign is followed by another character, like the %1 you see in the .rc file above. This
should not be changed as it is usually a text string or a value being printed.
\n
This is a line break.
/* text */
This is commented text. You may consider leaving the source language text in order to facilitate
future work.
Pagin 17 din 17

Size
The size of fields and labels can be changed if they are too small or big for the translation. In
the following line,
PUSHBUTTON "&Some text", IDC_ACELIST_REMOVE, 170, 87, 50, 14
the numbers 170, 87, 50, 14 stand for LEFT, TOP, WIDTH, HEIGHT. Changing 50 to 60 will result in a
longer pushbutton.
Below is an example rc-file from ReactOS Access Control List Editor (aclui).
Note that in a few lines some things irrelevant to translation have been removed.

<source lang="c">
include <reactos/resource.h>
include <defines.h>
include "resource.h"
LANGUAGE LANG_ENGLISH, SUBLANG_NEUTRAL
IDD_SECPAGE DIALOGEX 0, 0, 227, 215 STYLE WS_CHILD | WS_VISIBLE | WS_CAPTION
CAPTION "Security" FONT 8, "MS Shell Dlg", 0, 0, 0x0 BEGIN
LTEXT "&Group or user names:", -1, 7, 7, 105, 8
CONTROL "", IDC_ACELIST, "SysListView32", LVS_REPORT
PUSHBUTTON "A&dd...", IDC_ACELIST_ADD, 116, 87, 50, 14
PUSHBUTTON "&Remove", IDC_ACELIST_REMOVE, 170, 87, 50, 14
LTEXT "Allow", -1, 135, 107, 32, 8, SS_CENTER
LTEXT "Deny", -1, 176, 107, 32, 8, SS_CENTER
END
STRINGTABLE DISCARDABLE {
IDS_PSP_TITLE "Permissions for %1"
} </source>