Dos Subsystem
Moderator: Moderator Team
-
- Posts: 3
- Joined: Sat Oct 01, 2005 5:27 am
Dos Subsystem
I'm interested in starting to code the DOS subsystem.
So I am going to list some possible design principles:
Avoid excessive switching from V86 mode and Protected mode.
Limit direct access to system hardware by DOS programs (especially IO).
Must differentiate CPU exceptions and Software interrupts.
Each DOS process would have its own private first Megabyte of Memory.
At least DPMI v. 0.9 support.
Dos API support (Including Long File Name support.)
Possible design additions:
Native handling of DJGPP DPMI programs (I.E. skip DJGPP stub-loader and jump directly to the DJGPP COFF image).
Open GEM GUI API Support.
Bios and Video ROM virtualization.
Additions, subtractions, modifications, or comments anyone?
So I am going to list some possible design principles:
Avoid excessive switching from V86 mode and Protected mode.
Limit direct access to system hardware by DOS programs (especially IO).
Must differentiate CPU exceptions and Software interrupts.
Each DOS process would have its own private first Megabyte of Memory.
At least DPMI v. 0.9 support.
Dos API support (Including Long File Name support.)
Possible design additions:
Native handling of DJGPP DPMI programs (I.E. skip DJGPP stub-loader and jump directly to the DJGPP COFF image).
Open GEM GUI API Support.
Bios and Video ROM virtualization.
Additions, subtractions, modifications, or comments anyone?
-
- Posts: 483
- Joined: Tue Nov 30, 2004 5:44 pm
- Location: Canada
Said thing is that dos is not dead yet.
Programs from Win9x systems use dos calls in places.
Freedos is still alive and kicking. Its getting harder to kill stuff. Microsoft might think they killed dos but it did not die.
Yes and this is a little off topic from the graphical point of view. Open Gem is a new system not a old one.
Programs from Win9x systems use dos calls in places.
Freedos is still alive and kicking. Its getting harder to kill stuff. Microsoft might think they killed dos but it did not die.
Yes and this is a little off topic from the graphical point of view. Open Gem is a new system not a old one.
ReactOS is NT not 9x. Really I wouldn't care at all for DOS compatibility when I can just install FreeDOS and have compatibility and speed. And btw... DosBox is a neatly designed and self-contained piece of software, and it's performance is just great. Runs very nicely even on a P200, so what's wrong about it?
Re: Dos Subsystem
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).crashfourit wrote:Limit direct access to system hardware by DOS programs (especially IO).
maybe some sort of supervising could take place, or, much better, emulate the direct access....
Can the dos programs think they have full direct hardware access while actualy using the proper api chennels, like the first mb of memory, they think it is the first MB there using but it is not actualy the first MB of ram.
I think a dos subsystem would be an inportant addition to reactos. dos game networking would be good (IPX direct hardware access i think).
I think a dos subsystem would be an inportant addition to reactos. dos game networking would be good (IPX direct hardware access i think).
Our current subsystem is just a stub which does nothing yet. We do not even have the functionality in the kernel. I think the reactos project has other priorities at the moment.GreatLord wrote:We have part of dos system in ros
om NT it call VDM finish it u maybe can run old games
I prefer using dosbox
Where do you want ReactOS to go today ?
Who is online
Users browsing this forum: Ahrefs [Bot] and 11 guests