ReactOS Sviluppo > FAQ dello sviluppatore

FAQ dello sviluppatore

FAQ dello sviluppatore (Frequently Asked Questions) riguardo ReactOS. Se avete più domande comuni, leggete le FAQ dell'utente.

• Generale
• Sottosistema grafico
• I File System
• Debugging

 

Generale

Come eviterete l'inevitabile testo "Microsoft" in ReactOS?

Crediamo che questo rientra nel "fair use". E poi, non è necessario, eccetto nel registro.

Funzioneranno in ReactOS i driver disegnati per Windows?

Alcuni driver si sa che hanno funzionato, ma a questo punto non c'è una risposta definitiva perché ci sono ancora delle cose non implementate nel lato kernel.

Di cosa ho bisogno per compilare ReactOS dai sorgenti?

Fate riferimento alla pagina dell'ambiente di Build per informazioni su come compilare ReactOS dai sorgenti.

Perché non aiutate il progetto Wine invece?

In realtà lavoriamo a stretto contatto con il progetto Wine. Probabilmente Wine ha più cose in comune con ReactOS che con Linux. Il progetto Wine ha lo scopo di implementare le API Windows in cima al WineServer. Ci sono solo alcune dll di WINE che non possiamo usare in ReactOS. Queste sono NTDLL, USER32, KERNEL32, GDI32, and ADVAPI. Il resto delle dll di WINE possono essere condivise con ReactOS. Abbiamo diversi sviluppatori sia in WINE che ReactOS che lavorano su questioni di compatibilità incrociata tra i due progetti. E' nostro avviso che Linux + Wine non potrà essere mai un sostituto pieno di Microsoft(R) Windows(R). ReactOS ha il potenziale per un grado di compatibilità molto più alto - specialmente per i driver Microsoft(R) Windows(R) - che WINE non può gestire.

Che IDE dovrei usare per sviluppare per ReactOS?

Guardate usando un IDE per informazioni sugli editori di codice supportati.

Cosa ne dite riguardo il così chiamato problema SEH?

Structured exception handling (SEH) si usa nella programmazione di ReactOS come lo si usa nella programmazione per OS/2 o Microsoft(R) Windows(R) NT. SEH è un gioco tra il Sistema Operativo e il compilatore (Parole chiave: __try, __except, __finally). ReactOS stesso è consapevole delle SEH e fornisce l'infrastruttura. Tuttavia fino ad adesso, il compilatore GNU usato non è capace di generare codice consapevole delle SEH. Quindi non si può compilare un driver o programma che usa SEH con il compilatore GNU.

 

Sottosistema grafico

Perché il sottosistema grafico non è in Ring 3 ma in Ring 0?

La risposta corta è perché Microsoft l'ha fatto così, e se cerchiamo di avere compatibilità a livello driver, dobbiamo farlo allo stesso modo.

Perché Microsoft ha messo la GUI in Ring 0?

Perché fornisce un grande vantaggio di velocità. Contrariamente a un server GUI, il quale si eseguirà nel suo proprio processo, non sono necessari cambi di contesto quando si eseguono operazioni di GUI. Questo rende l'architettura meno pulita certo, e quando la GUI va in crash, tutto il sistema lo fa. La stessa discussione è avvenuta a Redmond, quando la GUI è andata nel kernel in Microsoft(R) Windows(R) NT 4.0. Sono giunti alla conclusione che la GUI era maturata,e quindi niente poteva andare storto a meno che no ci fosse un driver difettoso, e che le conseguenze sono simili a quelle che avvengono quando qualcosa va storto nello usermode.

ReactOS ha gli stessi problemi di sicurezza che ha Microsoft(R) Windows(R)?

Microsoft(R) Windows(R) NT e successivi non sono in realtà sistemi insicuri. Crediamo che Microsoft ha reso insicuro un sistema che era sicuro come conseguenza di decisioni povere. Ad esempio, Windows XP dà a tutti gli utenti diritti di amministratori di default. Alcuni servizi sono scarsamente implementati, la facilità di uso spesso ha la priorità per sopra la sicurezza. Possiamo, tuttavia, riorganizzare queste priorità in ReactOS. Quello che sarà problematico è che Microsoft non ha premuto i creatori di software perché facessero girare i loro software con diritti di utente normale.

Quale GUI posso usare?

Per rispondere a questa domanda, bisogna sapere come funziona la GUI in ReactOS/Microsoft(R) Windows(R):
- Il motore DIB (nel sottosistema grafico), assieme al vostro driver video, fornisce le primitive per il rendering, come rettangoli, linee e operazioni di BitBlit.
- Dopo c'è il sottosistema Win32 (CSRSS), il quale fornisce la funzionalità di finestre, compresa la finestra di console.
- La libreria USER32.DLL la quale fornisce finestre leggermente più complesse, come bottoni e checkbox.
- La libreria COMCTL32 fornisce finestre ancora più sofisticate, come dialoghi di apertura di file.
- La shell (ad esempio Explorer) è un programma ordinario, che si avvia dopo il boot. Crea il desktop con le sue icone, e il menù start. E' l'ultimo componente che può essere sostituito con un'altra shell. Ci sono diverse alternative open source come LiteStep e BlackBox disponibili, che intendiamo supportare.

 

I File System

ReactOS usa driver per i filesystem come lo fa Microsoft(R) Windows(R) NT. Per questo motivo implementa l'interfaccia IFS che sta per Installable File System. Quindi ReactOS sarà in grado di caricare e usare driver IFS. Al momento della scrittura ReactOS non era ancora in grado di caricare driver IFS nativi di Microsoft(R) Windows(R) NT. Ma a un certo punto, ReactOS riuscirà a caricare addirittura driver nativi NTFS.

Possiamo implementare la versione FreeDOS del filesystem FAT32?

ReactOS supporta FAT32 da secoli. Non c'è bisogno di implementarne un'altra.

ReactOS supporta VFAT e nomi file lunghi?

ReactOS supporta nativamente nomi file lunghi e unicode. Dipende dai driver dei filesystem il come vengono gestiti. Il driver FAT incluso in ReactOS supporta VFAT (=nomi file lunghi in FAT).

Perché non implementate Ext2/3 invece che focalizzarvi su NTFS?

Perché NTFS è una feature importante che dovrà essere supportata prima o poi. Ext2/3 è certamente da considerare anche, tuttavia ci sono già dei progetti la quale meta è implementare Ext2/3 per NT. Useremo questi driver quando saranno abbastanza maturi.

Dove posso trovare i driver Ext2/3-IFS per NT?

Li potete trovare qui: http://www.fs-driver.org/download.html.

Posso aiutare programmando driver installabili per filesystem?

Sì, c'è tanto lavoro da fare attorno ai driver IFS. Tuttavia, sono molto difficili da programmare. Si potrebbe dire che programmare driver è difficile ma programmare driver per filesystem è il re della disciplina. Se sei un hacker vero del kernel, annunciati nella mailing list.

Possiamo usare Ext2/3 invece che NTFS?

Sì, dipende da voi cosa volete usare. Per adesso però, né il driver Ext2/3-IFS né il nostro NTFS-IFS sono pronti per l'uso in lettura e scrittura. Quindi c'è ancora tanto lavoro da fare e quindi l'unica opzione è FAT-IFS.

Perché non usare i sorgenti del progetto Linux-NTFS?

Questi sorgenti sono utili, ma come con tutte le implementazioni NTFS (eccetto per quella Microsoft) non supporta la scrittura. E ci sono ancora aree di NTFS che non sono prive di documentazione/sconosciute. Lavoriamo assieme a loro, o per adesso, usiamo il loro codice. Al momento, NTFS non è una priorità, quindi le contribuzioni in modo attivo in quest'area sono in sospeso.

Quanto è critico il supporto NTFS perché ReactOS abbia successo?

Il progetto ReactOS vedrà eventualmente il supporto NTFS come prioritario, ma per adesso, non ci sono ragioni critiche per averlo. NTFS è primariamente un filessystem per hard disc, quindi l'unica ragione per cui uno ne avrebbe bisogno assolutamente è se volesse accedere una partizione formattata in NTFS su un disco installato quando si usa ReactOS. Alri filesystem saranno in grado di fornire le caratteristiche avanzate di NTFS (journalling, ACLs, compressione, hard links, ecc.) se non è un requisito la compatibilità rigorosa con NTFS. Tutti i software si trovano su supporti CD o DVD (ISO-9660 o UDFS), eventualmente anche su floppy (FAT). Supporti esterni (compact flash, chiavette di memoria, ecc.) che solitamente sono formattati in FAT.

I sorgenti JFS (anche per OS/2) si possono scaricare gratuitamente. Perché non fate JFS il filesystem di default in ReactOS?

Sì, al meno un driver IFS è pianificato. Poiché JFS è ancora un filesystem allo stato dell'arte con journalling, dimensioni grandi dei file e le partizioni, ACLs, attributi estesi e hard links, potrebbe essere adeguato per ReactOS. Ci stiamo lavorando, ma siete i benvenuti per aiutare.

Come gestite la distinzione tra maiuscole e minuscole (ad esempio ext2) ?

La distinzione non è un problema del filesystem in sé. E' un aspetto che spetta al driver. Il gestore degli oggetti che fornisce il namespace supporta la distinzione nativamente. Quindi i driver IFS ottengono una bandiera di caso speciale che devono gestire di conseguenza. Un filesystem portato dovrebbe gestire quindi tutti i due i casi, la distinzione e la non distinzione tra maiuscole e minuscole.

Funziona un filesystem a 64-bit in una macchina a 32-bit?

Sì. La parte a 64-bit è solo l'indirizzamento nel disco. Non ha niente a che fare con l'eseguibile che contiene il driver. Quell'eseguibile contiene tanti bit quanti ne contiene il sistema operativo.

Quali filesystem supporta ReactOS adesso?

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

Quali filesystem supporterà ReactOS?

Il nostro scopo è quello di supportare il più possibile. I driver IFS si possono sviluppare per al meno questi filesystem disponibili con Linux. Tuttavia, è molto difficile programmare un driver per filesystem compatibile/funzionante. Quindi ci vorrà del tempo. Ci saranno al meno: FAT(12/16/32) più VFAT, ISO-9660 - CD-ROM, un sistema più evoluto quale ext3, NTFS oppure JFS, NPFS - named pipe file system (FS interno), MSFS - mailslot file system (FS interno)

Ho un'idea: Perché non buttiamo via le lettere delle unità?

Questa è una vecchia idea. Microsoft probabilmente ce l'ha avuta, ma non l'hanno ancora implementato. Nel team di ReactOS ci sono delle opinioni riguardo l'argomento. Ma fino ad adesso non ci sono state conclusioni. Ci sono idee tipo un sistema di montaggio basato in memoria oppure scoprire il namespace del gestore degli oggetti alle applicazioni win32 o parole dei drive, ma ogni approccio ha svantaggi. Nota: Il kernel di ReactOS/Microsoft(R) Windows(R) NT non lavora con lettere delle unità. Queste sono una reliquia del DOS (oppure dovrei dire CP/M) in Win32.

Cos'è un Redirector?

Questo è un caso particolare di driver IFS. Non implementa un filesystem su disco. Invece si appoggia allo stack di rete del kernel e fornisce la maggior parte delle volte un filesystem remoto (ad esempio condivisioni SMB).

Cos'è un filesystem recognizer?

Un vero driver di filesystem è un peso massimo. Caricarlo solo per vedere che non ci sono partizioni che possa montare è una perdita di tempo. Per questa ragione Dave Cutler ha inventato il così chiamato "riconoscitore di filesystem". Sono più o meno una parte integrale dell'architettura del driver. Questo driver viene caricato e cerca partizioni con filesystems che i suoi compagni IFS siano in grado di leggere. Se le trova allora carica il compagno IFS per montarla.

 

Debugging

Come rintraccio un'eccezione non gestita in user mode?

La traccia assomiglia a questo: (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 Guardate in reactos/baseaddress.cfg, trovate l'indirizzo più basso più vicino che combacia l'indirizzo che state cercando di rintracciare. Aprite il file .map della dll corrispondente nel visualizzatore e cercate l'offset.