[ros-dev] ReactOS: Execute Natively or Virtually?

[Bernd Blaauw]

Op 19-1-2013 18:46, J. C. Jones schreef:
> Hi,

Per email thread subject, I'd say it would be nice if ReactOS loads at 
all, critically only depending on a minimum set of requirements and 
having everything else loaded/working if possible, without ever hanging 
or stalling the loading process.

All that's necessary is system memory and finding ReactOS files. Having 
output devices like screen/printer is usefull ofcourse, but not critical 
for loading ReactOS. Same for input devices (mouse/keyboard) and the 
subsystem they are on (USB).

However, currently ReactOS is stalling easily when certain system 
hardware or external (USB) devices are present. Not even working on x86 
in a general way, might not encourage going beyond x86.

> I had forgotten all about BOCHS. It is amazing how many emulators there are on the market these days.

Each ReactOS LiveCD ISO-file is inside a 7z-archive, such an archive 
supports including multiple files (unlike XZ for example) so adding 
Bochs would be easy and limited overhead (bochs.exe + vgabios + bios 
together below 1MB, if Bochs.exe gets UPX-compressed).
Doubleclicking bochs.exe or a batchfile to run the LiveCD inside Windows 
would be most convenient.

> I think that, for mass appeal, we should try to get ReactOS to run natively. The problem is that there are basically two types of users of ReactOS:

Would you require proof of ROS working as good as possible inside 
emulators first? Or try anyway on native x86/x64 and other architectures?

> http://www.reactos.org/forum/viewtopic.php?f=9&t=12262

Linux/Android have the advantage of source-level drivers that can be 
compiled/ported for multiple architectures. Windows seems to have 
x86/x64 closed-source drivers, on which ReactOS would also depend. Thus, 
porting to other architectures is impossible. That is, unless ReactOS is 
intended to develop their own (accelerated) drivers for hardware on 
multiple architectures.

Anyway, if you manage to get ReactOS on mobile (ARM?) devices, all the 
better ofcourse. It can only benefit the project.

Bernd