Dos Subsystem

[oiaohm]

http://freedos-32.sourceforge.net/ I would say that it is the nearest thing to a 32 bit dos around 16 bit dos app been run in protected mode. Next after is dosemu on Linux. Then Wine. Then dosbox lifts out the pit.

[Blazkowicz]

Limit direct access to system hardware by DOS programs (especially IO).

i think DOS programs should have NO direct hardware access at all, since then they could eventually crash the system / make it unstable (at least no unattended access).

maybe some sort of supervising could take place, or, much better, emulate the direct access....

or have some direct access when requested by the user.
there are people who after upgrade from win98 to 2000/XP find out that their old DOS business app cannot print anymore (yes, really)

it's not like direct LPT1 access hurts Windows. I also have that flash cartridge for original game boy with a reader that connects on LPT1, the only good app I found to write to the flash is a DOS one.
Also I was very pissed off that XP doesn't support IPX for DOS games, I had two win98 PC, a DOS PC and a XP PC in the same room and only Windows XP wouldn't play networked doom 2..

[logan_V8]

Hi!,
It's very nice to see that there is some sort of interest of implementing this in ReactOS.
I was thinking before in this and i got the conclusion that implementing the original NTVDM of Windows is pretty bad. Many security problems arise in Windows because the original design of the VDM. I think that we should go with emulation instead of running the code in V86 mode, or use a completely new implementation of the V86 mode calls in the kernel instead of the NtVdmXXX functions. I was thinking about implementing a emulator based in QEMU with a modified FreeDOS kernel or a system driver that provides virtualization and access to V86 mode to a userspace program so that if we don't need the DOS machine we could disable it easily. It is an important property that this subsystem should be implemented securily because in order to execute code in V86 mode we must act at ring0 priviledged level, creating posible security holes. Another thing that could be done is virtualization of priviledged instructions in user mode, so we don't access or touch the kernel. Projects such as GDE or the BSD DOS emulator could be used to implement the basis of this project. I already have GDE compiled under win32, but it doesn't work very well. In fact it can only run a demo DOS .com program .

regards,
Logan_V8

[Coviti]

That's possible, except that Qemu's slow as heck, and their so-called "Accelerator" isn't even open-source, which means it can't be used in this project. I think the NTVDM is good enough, but if you all are really serious I'm sure there's a way to implement a FreeDOS VM into ReactOS somehow, without the dreadful slowness of Qemu or Bochs.

[logan_V8]

Hi!,
there is a open source qemu accelerator module: qvm86 but its not very well tested (i think). And i missed to say that i was trying to benchmark qemu before, but i didn't succeeded .

regards,
Logan_V8

[Jaix]

Hi!,
there is a open source qemu accelerator module: qvm86 but its not very well tested (i think). And i missed to say that i was trying to benchmark qemu before, but i didn't succeeded .

regards,
Logan_V8

Philip Navara one of the devs here is actually working on qemu project, so if we will have an emulated/virtualized part it will probably be qemu I think.

And this is quotes from the QEmu homepage:

QEMU is a generic and open source processor emulator which achieves a good emulation speed by using dynamic translation.

With the QEMU Accelerator Module, QEMU can be compared to other commercial or free PC Virtualizers. It has the advantage of being free and to achieve good performances while necessitating no specific guest Operating System modifications. No other product has such advantages.

[oiaohm]

Ok please read some basic bits about V86. It requires ring 0 to setup. Programs running inside V86 are not at ring 0. All hardware interfaces are fake. If the setup does not provide it a V86 does not have access to it.

ring 1 2 and 3 cannot be started without going threw ring 0. Ie V86 is just a special ring with special memory setup. Note V86 is lower than ring 3 on access rights. Only problem with V86 is that some chips are defective and provided ways of getting out of lock down. Same chips you can break out of ring 1 2 and 3 anyhow. Ie the chip is a security problem. Ms NTVDM has contruction problems far to much in ring 0 when it does not need to be. Linux VM used by dosemu is a better. Ring 0 is used to start VM86 all interfacing is passed to ring 1,2 or 3. I don't know NTVDM well enough to say if the interface could not be twised on top of better code or not.

V86 has to be used on most processors. New pent D could use Xen hyberviser like tech. Amd with get this in time too. A stronger version of V86 that allows traped processors think they have real mode. When all access is controled by the hyperviser.

Freedos32 bit has VM86 software to run old dos programs in theory not compad with freedos32 because freedos32 is multi process. Best option find some way of puting freedos32 bit inside reactos.

[Floyd]

having old sub-systems for older programs is a nice feature, but i think we shouldn't try to be compatible with everything under the sun. the primary focus i think, should be to get and keep compatibility with Win32 and on. besides just because we want binary compatibility with windows doesn't mean we should recreate the same flaws. (windows is such a friggin' mess underneath the hood--they even managed to screw up NT4)

[Harteex]

having old sub-systems for older programs is a nice feature, but i think we shouldn't try to be compatible with everything under the sun. the primary focus i think, should be to get and keep compatibility with Win32 and on. besides just because we want binary compatibility with windows doesn't mean we should recreate the same flaws. (windows is such a friggin' mess underneath the hood--they even managed to screw up NT4)

I don't think it'll create a mess... I guess you can include just the subsystems you want and leave out those you don't want to use if you compile yourself.

[abshoy]

we need an under dos installation for old machines that does not boot from cd.
installation from *.cab files will be faster if they were stored on hard disk and have a setup program that run under dos.
i suggest that the *.cab file be les than 1.44 megabyte floppy size.
in this case, the importance of dos appear to set up the system again while it is running "as windows does" .set up will fix errors made by user.
user will not need to insert cd each time he makes the setup, simply, he will set up ROS from inside dos emulator in few minutes.
when dos run under emulator, it become faster !.

[Wierd]

having old sub-systems for older programs is a nice feature, but i think we shouldn't try to be compatible with everything under the sun. the primary focus i think, should be to get and keep compatibility with Win32 and on. besides just because we want binary compatibility with windows doesn't mean we should recreate the same flaws. (windows is such a friggin' mess underneath the hood--they even managed to screw up NT4)

I don't think it'll create a mess... I guess you can include just the subsystems you want and leave out those you don't want to use if you compile yourself.

The problem is that NTVDM works with WINOLDAP to do WOW.

This means that if you switch to say-- an Itanium, and ROS is compiled for 64bits (A possible reality once GCC is stable on 64bits)--- It means that you are suddenly going to *NEED* a virtualised 32bit world, just like you need a virtualized 16bit world right now. The foundation of NTVDM could be expanded to provide those services.

People need to stop looking at NTVDM as "DOS only."

*edit--

Additionally, should an intelligent design in NTVDM be implemented, it would help with the portability of the OS. EG:

On AMD64, there would be a native 32bits mode that code could be executed in, even if the CPU was in 64bits mode. NTVDM would then just be emulating the v86 modes. On an Itanium, it would have to do both--- and on PPC it could provide an execution environment for win32 apps, simmilar to ROSSETTA for MacOSX.

All you really would have to do (besides the gruntwork inside of building the WOW components) would be to determine what system arch ROS was being run under, and then read the executable header and start WOW(16/32) accordingly to service it's needs.

[PUOjACKz]

BTW, scuse me if I'm off topic, but why do we need a dos subsystem?
I don't know why a user would be interested in running old dos programs made 10-15 years ago...

Dos is like a dinosaur, isn't it?

A lot of particular firm application are still under DOS.
Lose the backward compatibility with DOS has no sense.

[PUOjACKz]

having old sub-systems for older programs is a nice feature, but i think we shouldn't try to be compatible with everything under the sun. the primary focus i think, should be to get and keep compatibility with Win32 and on. besides just because we want binary compatibility with windows doesn't mean we should recreate the same flaws. (windows is such a friggin' mess underneath the hood--they even managed to screw up NT4)

The problems of Win9x are related only for the OS. Those bugs are application-indipendent.

[Blackcrack]

Hy,

humm, realy Hot theme DOS

Oky, i had a idea.. the VSM (Virtual System Manager) this one can have a own running mashin..

read again.. :
[ Poll ] Idea: and way not a Virtual System Manager.. integrated ?
http://www.reactos.org/forum/viewtopic.php?t=2436

there can installed all Systems if supportet..
the Driverconstellation is support emulations how i hear from Matthias..
and in the VSM can say if only emulated or a realtime-room (sorry for my english*s*)
and it's can be more as only a VDM, and.. the network it's on and can run ipx, the lp1
can run and .. if programed, can tutch the bios.. to flashing.. in the running reactos
Read my Post and the Tread again and make you own ideas..
http://www.reactos.org/forum/viewtopic.php?t=2436

there can be running, freedos and freedos32 by side..if you whant a c64-system as 3th system
and.. other Systems if wrote a system/emu-bios for them systems.. you are now what i mean,
you are programmers... and it's funtion.. if correcktly prgramming... but it's a hard work..and
behind manny fun and manny other systems and Reactos as Head-System...

greetings
Blacky

[Floyd]

having old sub-systems for older programs is a nice feature, but i think we shouldn't try to be compatible with everything under the sun. the primary focus i think, should be to get and keep compatibility with Win32 and on. besides just because we want binary compatibility with windows doesn't mean we should recreate the same flaws. (windows is such a friggin' mess underneath the hood--they even managed to screw up NT4)

The problems of Win9x are related only for the OS. Those bugs are application-indipendent.

i'm not sure what point i was driving at in my original post, but i was specifically thinking of the NT line (that is NT4, 2000 and XP/2003).