Siccome siamo in un forum di informatica, è giusto che le idee vengano per bene chiarite in un post in cui l'argomento non è OT. Altrimenti l'idea ERRATA esposta in altri topic potrebbe influenzare gente credulona o che comunque non sa e che vuole informarsi.
ReactOS è nato per EMULARE windows e riproporlo sotto una veste open source (ovviamente è a lungo termine essendo windows forse il sistema operativo la cui struttura è più complessa e astratta).
Circa l'80% del kernel di ReactOS è coincidente con quello di windows l'altro 20% non è tale perché non ancora implementato - ad esempio il cache manager o l'se mgr (per la sicurezza del file system, gli access check etc).
Ciò che coincide con windows, almeno nel kernel (settore che io conosco, il resto è buio) è:
cm, dbgk, ex, io, ke, lpc, ob, ps, mm/arm3 manager; vdm handling, l'hal quasi totalmente (alcune parti sono appunto non ancora implementate) ed in particolare l'interrupt request level - per privilege check - e bus handling.
Detto ciò ci tengo a chiarire che quando si dice COINCIDENTE CON WINDOWS non si intende perfettamente identico, ovviamente chi ci assicura che le variabili hanno lo stesso nome o che alcuni controlli vengono fatti con ASSERT e non manualmente? (ovviamente le funzioni dell'internal hanno li stessi nomi di quelle NT, ma questo è un dato che si evince dal debugging). Ma si intende che la logica ed il funzionamento sono li stessi. Questo rende reactOS la miglior referenza per il source del kernel di windows NT. Vi faccio un esempio, tempo addietro trovai un bug nella
Quindi quando avete dubbi sul funzionamento del kernel NT, consultate doxygen o la repo di ntoskrnl di ReactOS per chiarire i vostri dubbi
ReactOS è nato per EMULARE windows e riproporlo sotto una veste open source (ovviamente è a lungo termine essendo windows forse il sistema operativo la cui struttura è più complessa e astratta).
Circa l'80% del kernel di ReactOS è coincidente con quello di windows l'altro 20% non è tale perché non ancora implementato - ad esempio il cache manager o l'se mgr (per la sicurezza del file system, gli access check etc).
Ciò che coincide con windows, almeno nel kernel (settore che io conosco, il resto è buio) è:
cm, dbgk, ex, io, ke, lpc, ob, ps, mm/arm3 manager; vdm handling, l'hal quasi totalmente (alcune parti sono appunto non ancora implementate) ed in particolare l'interrupt request level - per privilege check - e bus handling.
Detto ciò ci tengo a chiarire che quando si dice COINCIDENTE CON WINDOWS non si intende perfettamente identico, ovviamente chi ci assicura che le variabili hanno lo stesso nome o che alcuni controlli vengono fatti con ASSERT e non manualmente? (ovviamente le funzioni dell'internal hanno li stessi nomi di quelle NT, ma questo è un dato che si evince dal debugging). Ma si intende che la logica ed il funzionamento sono li stessi. Questo rende reactOS la miglior referenza per il source del kernel di windows NT. Vi faccio un esempio, tempo addietro trovai un bug nella
ExfAcquireRundownProtection, funzione privata degli internal di Windows. Necessita di reversing accanito? No, basta
Doxygen - ReactOS WebsiteQuindi quando avete dubbi sul funzionamento del kernel NT, consultate doxygen o la repo di ntoskrnl di ReactOS per chiarire i vostri dubbi