- Overzicht
- Hoe neem ik deel
- Whitepaper
- ReactOS samenstellen
- Ontwikkelaars FAQ
- Intellectueel eigendom
- SVN Server
- Bugzilla
- Doxygen
- RosCMS
- Website Status
- Vertaal de Website
- ReactOS CIA
ReactOS Ontwikkeling > Ontwikkelaars FAQ
Ontwikkelaars FAQ
Ontwikkelaars FAQ (Vaak Gestelde Vragen) over ReactOS. Als je gewone vragen hebt, lees dan de Gebruikers FAQ.
Algemeen
Hoe zal je de onvermijdelijke "Microsoft" tekst doorheen ReactOS vermijden ?
We geloven dat dit onder eerlijk gebruik valt. Het is ook niet nodig, behalve dan in het register.
Zullen drivers die ontworpen zijn voor Windows werken op ReactOS ?
Van sommige drivers weten we dat ze werken, maar op dit moment is er geen definitief antwoord omdat een aantal zaken in de kernel nog niet geïmplementeerd zijn.
Wat heb ik nodig om ReactOS te compileren uit de bronbestanden ?
Raadpleeg onze Build Omgeving pagina voor informatie over hoe je ReactOS opbouwt vanuit de broncode.
Waarom help je niet gewoon met het Wine project ?
We werken eigenlijk heel nauw samen met het Wine project. Wine heeft waarschijnlijk veel meer gemeen met ReactOS dan met Linux. Het Wine project heeft als doel een volledige Windows API te implementeren die bovenop de WineServer draait. Er zijn slechts een paar WINE dll's die niet gebruikt kunnen worden in ReactOS. Deze zijn NTDLL, USER32, KERNEL32, GDI32, en ADVAPI. De rest van de WINE DLL's kunnen gedeeld worden met ReactOS. Er zijn verschillende ontwikkelaars die actief zijn in zowel het WINE als het ReactOS project en werken aan compatibiliteitsproblemen tussen de twee projecten. Volgens ons kunnen Linux + WINE nooit een volledige vervanging vormen voor Microsoft(R) Windows(R). ReactOS heeft de mogelijkheid een veel grotere graad van compatibiliteit te bereiken - vooral voor de Microsoft(R) Windows(R) drivers - welke WINE niet kan bieden.
Welke IDE zou ik gebruiken om aan ReactOS te werken ?
Zie een IDE gebruiken voor informatie op ondersteunde code editors.
Hoe zit het met het zogenaamde SEH-probleem ?
Structured exception handling (SEH) wordt gebruikt bij het programmeren van ReactOS zoals het gebruikt wordt voor programmatie voor OS/2 of Microsoft(R) Windows(R) NT. SEH is een spel dat gespeeld wordt tussen het OS en de compiler (Keywords: __try, __except, __finally). ReactOS is zelf SEH-bewust en voorziet de infrastructuur. Tot nu toe is de gebruikte GNU-compiler echter niet in staat om SEH bewuste code te genereren. Men kan dus geen driver of programma compileren dat SEH gebruikt met deze GNU-Compiler.
Grafisch Subsysteem
Waarom is het grafisch subsysteem niet in Ring 3 maar in Ring 0?
Het korte antwoord is : omdat Microsoft het zo heeft gedaan, en we driver compatibiliteit nastreven. We moeten het dus op dezelfde manier aanpakken.
Waarom plaatste Microsoft de GUI in Ring 0 ?
Omdat dit voordelen geeft naar snelheid toe. In tegenstelling tot een GUI-server, welke in zijn eigen proces draait, zijn er geen veranderingen van context nodig bij het uitvoeren van GUI operaties. Dit maakt de architectuur natuurlijk wel minder proper, en wanneer de GUI crasht, zal het hele systeem crashen. Dezelfde discussie werd al gevoerd in Redmond, wanneer de GUI in de kernel werd geplaatst in Microsoft(R) Windows(R) NT 4.0. Zij kwamen tot de conclusie dat de GUI volwassen geworden is, zodat niets fout zou gaan tenzij er een slechte driver geïnstalleerd is. De consequenties daarvan zijn gelijkaardig aan iets dat misgaat in user mode.
Heeft ReactOS dezelfde beveiligingsproblemen als Microsoft(R) Windows(R)?
Microsoft(R) Windows(R) NT en zijn opvolgers zijn geen echt inherent onveilige systemen. We geloven dat Microsoft een veilig systeem onveilig heeft gemaakt ten gevolge van enkele ongelukkige beslissingen. Zo geeft Windows XP bijvoorbeeld standaard elke gebruiker beheerdersrechten. Sommige services zijn slecht geïmplementeerd en het gebruiksgemak heeft dikwijls de bovenhand over beveiligingen. We kunnen deze prioriteiten echter herschikken in ReactOS. Het probleem zal misschien zijn dat Microsoft de softwarehuizen niet heeft gedwongen hun producten te laten draaien met normale gebruikersrechten.
Welke GUI kan ik gebruiken ?
Om dit te beantwoorden moet je eerst begrijpen hoe de GUI functies in ReactOS/Microsoft(R) Windows(R) werken :
- De DIB Engine (in het graphische subsysteem) voorziet, samen met de driver van je video-kaart, de rendering primitieven, zoals rechthoeken, lijnen en BitBlit operaties.
- Dan heb je het Win32 subsysteem (CSRSS), dat de venster-functionaliteit biedt, alsook de console vensters.
- De USER32.DLL bibliotheek voorziet ietwat complexere vensters, zoals knoppen en aankruisvakjes.
- De bibliotheek COMCTL32 voorziet nog meer gesofisticeerde vensters, zoals "Open bestand" venster.
- De shell (bijvoorbeeld de Verkenner) is een gewoon programma, dat gestart wordt bij het opstarten. Dit programma maakt het bureaublad aan met zijn iconen, en de start menu. Deze laatste component kan verwisseld worden met een andere shell. Er zijn populaire open source "Explorer replacements" beschikbaar, zoals LiteStep en BlackBox, welke we zullen ondersteunen.
Bestandssystemen
ReactOS gebruikt bestandssysteem drivers net zoals Microsoft(R) Windows(R) NT dat doet. Daarom implementeert het de IFS-interface, wat staat voor Installable File System. Bijgevolg zal ReactOS IFS-drivers kunnen laden en gebruiken. Op het moment dat dit geschreven werd was ReactOS nog niet in staat om Microsoft(R) Windows(R) NT-native IFS-drivers te laden. Maar ooit zal ReactOS in staat zijn om zelfs de native NTFS-drivers te gebruiken.
Kunnen we de FreeDOS versie van het FAT32 filesysteem gebruiken ?
ReactOS heeft al lange tijd FAT32 ondersteund. Het is niet nodig om een andere driver te implementeren.
Ondersteunt ReactOS VFAT en lange bestandsnamen ?
ReactOS ondersteund standaard lange bestandsnamen in unicode. Het hangt van de bestandssysteem driver af hoe deze ermee omgaat. De FAT-driver die bij ReactOS zit ondersteund VFAT (=lange namen op FAT).
Waarom implementeer je geen Ext2/3 in plaats van je op NTFS te richten ?
Omdate NTFS een belangrijke functionaliteit is die we ooit moeten ondersteunen. Ext2/3 staat natuurlijk ook op het verlanglijstje, maar er zijn reeds projecten die als doel hebben Ext2/3 te implementeren voor NT. We zullen deze drivers gebruiken als ze goed genoeg zijn.
Waar kan ik de Ext2/3-IFS voor NT vinden ?
Je kan ze hier vinden : http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm http://sys.xiloo.com/projects/projects.htm#ext2fsd http://ashedel.chat.ru/ext2fsnt/.
Kan ik helpen met het programmeren van IFS drivers ?
Jazeker, er is een boel werk te doen rond de IFS-drivers. Het is echter zeer moeilijk om te programmeren. Je zou kunnen zeggen dat het programmeren van drivers moeilijk is, maar het programmeren van bestandssysteem drivers is de topdiscipline. Als je een echte kernel hacker bent, meldt je dan aan op de maling lijst.
Kunnen we Ext2/3 gebruiken in plaats van in NTFS rond te dwalen ?
Jawel, het is aan jou om een bestandssysteem te kiezen. Voorlopig zijn echter nog de Ext2/3-IFS, noch onze NTFS-IFS driver klaar voor lezen en schrijven. Er is dus nogeen boel werk en dus is de enige optie voorlopig de FAT-IFS.
Waarom maak je geen gebruik van de broncode van het Linux-NTFS project ?
Deze broncode is nuttig, maar zoals bij alle NTFS implementaties (behalve die van Microsoft) is er een tekort aan geschreven ondersteuning. En er zijn nog een heleboel gebieden in NTFS die ongedocumenteerd/onbekend zijn. We werken samen met hen of gebruiken - voorlopig - gewoon hun code. Op dit moment is er geen prioriteit voor NTFS, dus actieve medewerking op dit gebied is geboden.
Hoe kritisch is NTFS ondersteuning voor ReactOS om succes te hebben?
Het ReactOS Project zal uiteindelijk de NTFS ondersteuning als een prioriteit beschouwen, maar voorlopig is er geen reden om deze te hebben. NTFS is vooral een hard disk bestandssysteem, dus de enige reden dat iemand dit absoluut zou nodig hebben is dat hij een NTFS-geformatteerde fysische partitie op een geïnstalleerde harde schijf wil gebruiken vanuit ReactOS. Andere bestandssystemen kunnen ook de geavanceerde functies van NTFS bieden (journalling, ACLs, compressie, hard links, enzovoort) als strikte NTFS compatibiliteit geen vereiste is. Alle software komt op een CD of DVD (ISO-9660 or UDFS), of misschien op floppies (FAT). Externe media (compact flash, memory sticks, enzovoort) zijn meestal geformatteerd met FAT.
De JFS broncode (ook voor OS/2) zijn vrij te downloaden. Waaroom maak je van JFS niet het standaard bestandssysteem van ReactOS?
Ja, er is tenminste al een IFS gepland. Vermits JFS nog steeds een state-of-the-art bestandssysteem is met journalling, grote bestanden en partities, ACL's en uitgebreide attributen en hard links, zou het zeker passen bij ReactOS. We werken eraan maar hulp is welkom.
Hoe ga je om met hoofdlettergevoeligheid (i.e. ext2) ?
Hoofdlettergevoeligheid is geen probleem van het bestandssysteem zelf. Het is een aspect van de bijbehorende driver. De object manager die de volledige namespace voorziet ondersteund hoofdlettergevoeligheid standaard. IFS-drivers krijgen dus een speciale case vlag welke ze toepasselijk moeten gebruiken. Een geporteerde bestandssysteem driver moet daarom in staat zijn ze allebei te ondersteunen, hoofdletter(on)gevoelig.
Werkt een 64-bit bestandssysteem op een 32-bit toestel ?
Ja. Het 64-bit gedeelte is enkel de addressering van de schijf. Dit heeft niets te maken met de uitvoerbare code die de driver bevat. Die code heeft evenveel bits als het volledige operating system heeft.
Welke bestandssystemen ondersteunt ReactOS nu ?
FAT(12/16/32) plus VFAT, ISO-9660 - CD-ROM, NPFS - named pipe bestandssysteem (internal FS), MSFS - mailslot bestandssysteem (internal FS)
Welke bestandssystemen zal ReactOS ondersteunen ?
Ons doel is zoveel bestandssystemen als mogelijk te ondersteunen. IFS-drivers kunnen tenminste ontwikkeld worden voor de bestandssystemen die beschikbaar zijn in Linux. Het is echter zeer moeilijk om een compliant/werkende bestandssysteem driver. Het zal even duren. Deze systemen zullen er zeker zijn : FAT(12/16/32) plus VFAT, ISO-9660 - CD-ROM, een hoger FS zoals ext3, NTFS of JFS, NPFS - named pipe bestandssysteem (internal FS), MSFS - mailslot bestandssysteem (internal FS)
Ik heb een idee : Waarom gooi je die oude drive letters niet weg ?
Dit is een oud idee. Microsoft heeft waarschijnlijk ook al dit idee gehad, maar ze hebben het nog niet toegepast. In het ReactOS team wordt hier ook aan gedacht. Maar tot nu toe is er nog geen conclusie bereikt over dit onderwerp. Er zijn ideeën zoals een geheugen-gebaseerd bestandssysteem of het openen van de namespace van de object manager naar win32 applicaties of drive woorden, maar elke benadering heeft zijn nadelen. Opgelet : De ReactOS/Microsoft(R) Windows(R) NT Kernel werkt niet met drive letters. Deze zijn een overblijfsel van DOS (of moet ik zeggen CP/M) in Win32.
Wat is een Redirector?
Dit is een speciale vorm van een IFS driver. Deze implementeert geen schijf-bestandssysteem, maar vertrouwd op de netwerk stack van de kernel en voorziet meestal een remote bestandssysteem (d.w.z. SMB shares).
Wat is een filesystem recognizer?
Een echte bestandssysteem driver is een zwaargewicht. Dit gewoon laden om te zien dat er geen partitie is om toegankelijk te maken is tijdverlies. Daarom vond Dave Cutler de zogenaamde recognizer driver uit. Deze is min of meer een integraal deel van de driver architectuur. Deze driver wordt geladen en zoekt naar partities die door het bijbehorende IFS kunnen gelezen worden. Als het zulke partities vindt wordt de bijbehorende IFS ingeladen om deze toegankelijk te maken.
SEH-Probleem
Gestructureerde fout afhandeling (SEH) wordt gebruikt in de programmatie van ReactOS zoals het gebruikt wordt bij de programmatie voor OS/2 en Microsoft(R) Windows(R) NT. SEH is een spel dat gespeeld wordt tussen het OS en de Compiler (Keywords: __try, __except, __finally). ReactOS is zelf SEH-bewust en voorziet de infrastructuur. Tot nu toe is de gebruikte GNU-compiler echter niet in staat om SEH-bewuste code te genereren. Men kan dus met deze GNU-compiler geen driver compileren die SEH gebruikt.
Foutzoeken
Hoe spoor ik een niet-afgehandelde fout op in user mode?
De trace ziet eruit als volgt : (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 Kijk naar reactos/baseaddress.cfg, vindt het dichtste lagere adres dat overeenkomt met het adres dat je probeert op te sporen. Open het .map bestand om de bijbehorende DLL te bekijken in viewer en zoek de offset.
