Projects‎ > ‎Reactos‎ > ‎

Developer FAQ

Contents

  1. 1 General
    1. 1.1 How will you avoid the inevitable "Microsoft" text throughout ReactOS?
    2. 1.2 Will drivers designed for Windows work on ReactOS?
    3. 1.3 What do I need to compile ReactOS from sources?
    4. 1.4 Why don't you help the Wine project instead?
    5. 1.5 What IDE should I use to develop for ReactOS?
    6. 1.6 What about so-called SEH-problem?
  2. 2 Graphics Subsystem
    1. 2.1 Why is the graphics subsystem not in Ring 3 but in Ring 0?
    2. 2.2 Why did Microsoft put the GUI in Ring 0?
    3. 2.3 Does ReactOS have the same security problems as Microsoft(R) Windows(R)?
    4. 2.4 Which GUI can I use?
  3. 3 File Systems
    1. 3.1 Can we implement the FreeDOS version of the FAT32 filesystem?
    2. 3.2 Does ReactOS support VFAT and long names?
    3. 3.3 Why don't you implement Ext2/3 instead of focusing on NTFS?
    4. 3.4 Where can I find the Ext2/3-IFS for NT?
    5. 3.5 Can I help programming installable file system drivers?
    6. 3.6 Can we use Ext2/3 instead of poking around in NTFS?
    7. 3.7 Why do you not make use of the Linux-NTFS project's sources?
    8. 3.8 How critical is NTFS support for ReactOS to be successful?
    9. 3.9 The JFS sources (also for OS/2) are free to download. Why not make JFS the standard filesystem in ReactOS?
    10. 3.10 How do you deal with case sensitivity (i.e. ext2) ?
    11. 3.11 Does a 64-bit file system run on a 32-bit machine?
    12. 3.12 What file systems does ReactOS support, now?
    13. 3.13 What file systems will ReactOS support?
    14. 3.14 I have an idea: Why not throw away these odd drive letters?
    15. 3.15 What is a Redirector?
    16. 3.16 What is a filesystem recognizer?
    17. 3.17 SEH-Problem
  4. 4 Debugging
    1. 4.1 How do I trace an unhandled exception in user mode?



General

How will you avoid the inevitable "Microsoft" text throughout ReactOS?

We believe that this falls under fair use. It is also not needed except in the registry.

Will drivers designed for Windows work on ReactOS?

Some drivers have been known to work, but at this point there is no definitive answer as some facilities in kernel land that are unimplemented.

What do I need to compile ReactOS from sources?

Refer to our Build Environment page for information on how to compile ReactOS from the source.

Why don't you help the Wine project instead?

Actually we work very closely with the Wine project. Wine probably has a lot more in common with ReactOS than with Linux. The Wine project has the goal of implementing the entire windows API on top of WineServer. There are only a few WINE dlls that cannot be used in ReactOS. These are NTDLL, USER32, KERNEL32, GDI32, and ADVAPI. The rest of WINE's DLLs can be shared with ReactOS. We have several developers in both the WINE and ReactOS projects that work on cross-compatibility issues between the two projects. It is our view that Linux + Wine can never be a full replacement for Microsoft(R) Windows(R). ReactOS has the potential for a much higher degree of compatibility - especially for Microsoft(R) Windows(R) drivers - which WINE does not address.

What IDE should I use to develop for ReactOS?

See using an IDE for information on supported code editors.

What about so-called SEH-problem?

Structured exception handling (SEH) is used in programming ReactOS as it is used in programming for OS/2 or Microsoft(R) Windows(R) NT. SEH is a game wich is played between OS and Compiler (Keywords: __try, __except, __finally). ReactOS itself is SEH-aware and provides the infrastructure. However up till now, the used GNU-compiler is not capable of generating SEH aware code. So one can't compile a driver or program which uses SEH with the GNU-Compiler.

 

Graphics Subsystem

Why is the graphics subsystem not in Ring 3 but in Ring 0?

The short answer is that because Microsoft has done it this way, and we aim for driver compatibility, we have to do it the same way.

Why did Microsoft put the GUI in Ring 0?

Because this gives quite an advantage in speed. Contrary to a GUI-server, which will run in its own process, there are no context changes necessary when performing GUI operations. This does make the architecture less clean of course, and when the GUI crashes, the whole system crashes. The same discussion took place in Redmond, when the GUI went into the kernel in Microsoft(R) Windows(R) NT 4.0. They came to the conclusion that the GUI has matured, so that nothing will go wrong unless a faulty driver is present, and that the consequences are similar to when something goes wrong in user mode.

Does ReactOS have the same security problems as Microsoft(R) Windows(R)?

Microsoft(R) Windows(R) NT and successors aren't really inherently insecure systems. We believe that Microsoft made a secure system insecure as a result of some poor decisions. For example, Windows XP gives every user Administrator rights by default. Some services are poorly implemented and ease of use often takes priority over security. We can, however, rearrange these priorities in ReactOS. What will be problematic is that Microsoft hasn't pressured software creators to let their products run with normal user rights.

Which GUI can I use?

To answer this, one must understand how the GUI functions in ReactOS/Microsoft(R) Windows(R):
- The DIB Engine (in the graphics subsystem), along with your video card's driver, provide rendering primitives, such as rectangles, lines and BitBlit operations.
- Then there is the Win32 subsystem (CSRSS), which provides the windowing functionality, including console windows.
- The USER32.DLL library provides slightly more complex windows, such as buttons and checkboxes.
- The library COMCTL32 provides even more sophisticated windows, such as file open dialogs.
- The shell (for instance Explorer) is an ordinary program, which is started upon bootup. It creates the desktop with its icons, and the start menu. It is this last component which can be changed out with another shell. There are many popular open source "Explorer replacements" like LiteStep and BlackBox available, which we intend to support.

 

File Systems

ReactOS uses filesystem drivers just as Microsoft(R) Windows(R) NT does. For that reason it implements the IFS-interface which stands for Installable File System. Therefore ReactOS will be able to load and use IFS-drivers. At the time of writing ReactOS was still unable to load Microsoft(R) Windows(R) NT-native IFS-drivers. But some time, ReactOS will be able to load even native NTFS-drivers.

Can we implement the FreeDOS version of the FAT32 filesystem?

ReactOS has had support for FAT32 for ages. There's no need to implement another one.

Does ReactOS support VFAT and long names?

ReactOS natively supports long and unicode filenames. It is up to the file system driver how it deals with it. The FAT-driver delivered with ReactOS supports VFAT (=long names on FAT).

Why don't you implement Ext2/3 instead of focusing on NTFS?

Because NTFS is a major feature which must be supported at some time. Ext2/3 is of course a topic for us, however there are already projects whose goal it is to implement Ext2/3 for NT. We will utilize these drivers when they are good enough.

Where can I find the Ext2/3-IFS for NT?

You can find it here: http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm http://sys.xiloo.com/projects/projects.htm#ext2fsd http://ashedel.chat.ru/ext2fsnt/.

Can I help programming installable file system drivers?

Yes, there's lots of work to do around IFS-drivers. It is, however, very hard to program. It could be said that programming drivers is hard but programming file system drivers is the king's discipline. If you are a real kernel hacker, come to our maling list and announce yourself.

Can we use Ext2/3 instead of poking around in NTFS?

Yes, it's up to you which file system you want to use. For now, however, neither the Ext2/3-IFS nor the our NTFS-IFS is ready to use for read and write. So there's still lots of work to do and so the only option is the FAT-IFS.

Why do you not make use of the Linux-NTFS project's sources?

These sources are useful, but as with all NTFS implementations (except the one from Microsoft) it lacks writing support. And there are still big areas of NTFS which are undocumented/unknown. We are working together with them - or for now - just using their code. At the moment, there is no priority for NTFS, so active contribution in this area is still dormant.

How critical is NTFS support for ReactOS to be successful?

The ReactOS Project will eventually see NTFS support as a priority, but for now, there is no critical reason to have it. NTFS is primarily a hard disk filesystem, so the only reason one would absolutely need it would be is if you wanted to access an NTFS-formatted physical partition on an installed hard disk when using ReactOS. Other file systems will be able to provide the advanced features of NTFS (journalling, ACLs, compression, hard links, etc.) if strict NTFS compatibility is not a requirement. All software comes on CD or DVD media (ISO-9660 or UDFS), or possibly on floppies (FAT). External media (compact flash, memory sticks, etc.) tend to be formatted FAT.

The JFS sources (also for OS/2) are free to download. Why not make JFS the standard filesystem in ReactOS?

Yes, at least an IFS is already planned. Since JFS is still a state-of-the-art file system with journalling, big file and partition sizes, ACLs and extended attributes and hard links, it would well suit ReactOS. We are working on it but you are welcome to help.

How do you deal with case sensitivity (i.e. ext2) ?

Case sensitivity is not a problem of the file system itself. It's an aspect of the corresponding driver. The object manager which provides the whole namespace supports case sensitivity natively. So IFS-drivers get a special case flag which they must handle accordingly. A ported file system driver must therefore be able to handle both, case (in)sensitivity.

Does a 64-bit file system run on a 32-bit machine?

Yes. The 64-bit part is just the addressing on the disk. It has nothing to do with the executable which contains the driver. That executable has as many bits as the whole operating system has.

What file systems does ReactOS support, now?

FAT(12/16/32) plus VFAT, ISO-9660 - CD-ROM, NPFS - named pipe file system (internal FS), MSFS - mailslot file system (internal FS)

What file systems will ReactOS support?

Our goal is to support as many filesystems as possible. IFS-drivers can be developed for at least these disk file systems which are available with Linux. It is, however, very hard to program a compliant/working filesystem driver. So it will take some time. There will be at least: FAT(12/16/32) plus VFAT, ISO-9660 - CD-ROM, A Higher FS like ext3, NTFS or JFS, NPFS - named pipe file system (internal FS), MSFS - mailslot file system (internal FS)

I have an idea: Why not throw away these odd drive letters?

This is an old idea. Microsoft has probably had this idea, but they have not implemented it yet. In the ReactOS team there are also thoughts about this issue. But up to now there has not been a sufficient conclusion on this topic. There are ideas such as having a memory based mount file system or uncovering the object manager's name space to win32 apps or drive words, but each approach has disadvantages. Note: The ReactOS/Microsoft(R) Windows(R) NT Kernel doesn't work with drive letters. These are a relic of DOS (or should I say CP/M) in Win32.

What is a Redirector?

This is a special form of an IFS driver. It doesn't implement an on-disk filesystem. Instead it relies on the kernel's network stack and provides most times a remote file system (i.e. SMB shares).

What is a filesystem recognizer?

A real filesystem driver is a heavy weight. Loading it just for it to see that there is no partition it could mount is a waste of time. For this reason Dave Cutler invented the so called recognizer driver. They are more or less an integral part of the driver architecture. This driver gets loaded and searches partitions for filesystems its companion IFS is capable of reading. If it finds such a partition it loads its companion IFS to mount it.

SEH-Problem

Structured exception handling (SEH) is used in programming ReactOS as it is used in programming for OS/2 or Microsoft(R) Windows(R) NT. SEH is a game wich is played between OS and Compiler (Keywords: __try, __except, __finally). ReactOS itself is SEH-aware and provides the infrastructure. However up till now, the used GNU-compiler is not capable of generating SEH aware code. So one can't compile a driver or program which uses SEH with the GNU-Compiler.

 

Debugging

How do I trace an unhandled exception in user mode?

The trace looks something like this: (KERNEL32:process/create.c:328) Process terminated abnormally due to unhandled exception (KERNEL32:process/create.c:329) Address: 761a13e0 (KERNEL32:process/create.c:334) Frames: (KERNEL32:process/create.c:338) 761a2be9 Look at reactos/baseaddress.cfg, find the nearest lower address that matches the address you're trying to trace. Open the .map file for the corresponding DLL in viewer and search for the offset.

Comments