ReactOS Utvikling > Utviklings OSS

Utviklings OSS

Utviklings OSS (ofte stilte spørsmål) om ReactOS. Hvis du har mere spørsmål, les vår OSS (ofte stilte spørsmål).

 

• Generielt
• Grafisk undersystem
• Filsystemer
• Debugging

 

 

Generielt

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.

Vil drivere som er laget for Windows virke med ReactOS?

Noen drivere vil fungere, men dette her har ikke endelig svar siden noen innreninger i kernel har ikke blitt lagt til.

Hva trenger jeg for å kompilere ReactOS fra kildekoden?

Se vår Build Environment side for informasjon på hvordan man kompilerer ReactOS fra kildekoden.

Hvorfor skal du heller ikke hjelpe Wine-prosjektet isteden for?

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.

Hvilken IDE skal jeg bruke for å videre utvikle for ReactOS?

Se using an IDE for informasjon fungerende programmering programmer.

Hva med so-kallet 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.

 

Grafisk Subsystem

Hvorfor er grafisk subsystem ikke i Ring 3 men i 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.

Hvorfor har Microsoft lagt GUI i 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.

Har ReactOS de samme sikkerhet problemer som 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.

Hvilken grafisk brukergrensesnitt kan jeg bruke?

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.

 

Filsystemer

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.

Kan vi implementere FreeDOS versjon av FAT32 filsystem?

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

Vil ReactOS støtte VFAT og lange navn?

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).

Hvorfor vil dere heller ikke implementere Ext2/3 isteden for å fokusere på 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.

Hvor kan jeg finne Ext2/3-IFS for NT?

Du kan finne dette her: http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm http://sys.xiloo.com/projects/projects.htm#ext2fsd http://ashedel.chat.ru/ext2fsnt/.

Kan jeg hjelpe til med å programmerer installerbar filsystem drivere?

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.

Kan vi bruke Ext2/3 isteden for poking rundt i 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.

Hvorfor vil dere ikke lage og bruke Linux-NTFS projekt kilde?

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.

Hvor kritisk er NTFS støtte for ReactOS skal bli vellykket?

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.

JFS kilden (også for OS/2) er gratis å laste ned. Hvorfor ikke lage JFS standard filsystem for 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 (f.eks 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.

Vil 64-bit filsystem fungere på 32-bit maskin?

Ja. 64-bit delen er bare hvordan adressene er på platen. It has nothing to do with the executable which contains the driver. That executable has as many bits as the whole operating system has.

Hvor mange filsystemer støtter ReactOS, nå?

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

Hvilken filsystemer vil ReactOS støtte?

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)

Jeg har en ide: Hvorfor ikke kast bort disse ekstra stasjon bokstavene?

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.