So you want OpenGEM 5 to replace DosShell?
On 11/28/05, Jerry crashfourit@gmail.com wrote:
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 http://gem.shaneland.co.uk/ GUI API Support. Bios and Video ROM virtualization.
Additions, subtractions, modifications, or comments anyone? _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- David Johnson http://www.davefilms.us
Ausome! Lets do it!
On 11/28/05, Jerry crashfourit@gmail.com wrote:
I want it to be one of many possible options. The idea is that when you run a Open Gem program in ReactOS it will look like a Windows program. I.E. The Open Gem part of the Dos subsytem would translate the GEM GUI calls to Win32 or Win-NT API calls, making it look like a windows program.
David Johnson wrote:
So you want OpenGEM 5 to replace DosShell?
On 11/28/05, Jerry crashfourit@gmail.com wrote:
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 http://gem.shaneland.co.uk/ GUI API Support. Bios and Video ROM virtualization.
Additions, subtractions, modifications, or comments anyone? _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- David Johnson http://www.davefilms.us
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- David Johnson http://www.davefilms.us
Here is a Design proposal. Have the DOS Subsystem registered as an NT Service. That way, you can automatically limit on a per-program basis, whether direct access to the hardware is granted.
What you need is a service that intercepts any MS-DOS executable, or batch file, and and handles any API calls made to the program, and translates any data sent and recieved between the actual hardware, and the DOS program itself.
This service could then maintain a registry-based list of accessed DOS programs, that would hold all the key settings, such as RAM Allocated, etc.
And, IIRC, Long File Name support came from the VFAT driver that debuted in Windows 95. Internally, most, if not all Win16 and DOS programs are still restricted from saving and accessing filenames that exceed the 8.3 file length format.
On 11/28/05, Jerry crashfourit@gmail.com wrote:
I'll start working on it when my semester at college ends. What I need help on is how to register a subsystem, how to register software interrupts in ReactOS/NT, how does ReactOS/NT handle V86 prossess, and a few other things -- not to forget volunteers to help me. ;) However, I am familiar with DOS programing.
David Johnson wrote:
Ausome! Lets do it!
On 11/28/05, Jerry crashfourit@gmail.com wrote:
I want it to be one of many possible options. The idea is that when you run a Open Gem program in ReactOS it will look
like a Windows program. I.E. The Open Gem part of the Dos subsytem would translate the GEM GUI calls to Win32 or Win-NT API calls, making it look like a windows program.
David Johnson wrote:
So you want OpenGEM 5 to replace DosShell?
On 11/28/05, Jerry <crashfourit@gmail.com > wrote:
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? _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- David Johnson http://www.davefilms.us ________________________________
Ros-dev mailing list
Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- David Johnson http://www.davefilms.us ________________________________
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- "I had a handle on life, but then it broke"
Jerry wrote:
I know that. I have a copy of Ralf Brown's Interrupt List http://www.ctyme.com/rbrown.htm for the x86 platform. I also know there are some DOS specific structures that I have to duplicate for compatibility. My problem is that I need to know how to program a NT System Service.
NTVDM/VDM is nor a service nor a subsytem. The only "hack" for it is in CreateProcess which launches ntvdm.exe with the application name suffixed (this code is already in trunk).
The rest depends on: 1) ABIOS implementation in ntoskrnl 2) GUI calls in Win32K 3) NTVDM 4) VDM support in CSRSS 5) BIOS, io.sys, config.sys, etc files
Best regards, Alex Ionescu
If NTVDM/VDM is neither a service, nor a Subsystem, then what precisely is it?
On 11/29/05, Alex Ionescu ionucu@videotron.ca wrote:
Jerry wrote:
I know that. I have a copy of Ralf Brown's Interrupt List http://www.ctyme.com/rbrown.htm for the x86 platform. I also know there are some DOS specific structures that I have to duplicate for compatibility. My problem is that I need to know how to program a NT System Service.
NTVDM/VDM is nor a service nor a subsytem. The only "hack" for it is in CreateProcess which launches ntvdm.exe with the application name suffixed (this code is already in trunk).
The rest depends on:
- ABIOS implementation in ntoskrnl
- GUI calls in Win32K
- NTVDM
- VDM support in CSRSS
- BIOS, io.sys, config.sys, etc files
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- "I had a handle on life, but then it broke"
TwoTailedFox wrote:
If NTVDM/VDM is neither a service, nor a Subsystem, then what precisely is it?
a hack. A hack we don't have to support, since the VDM concept sucks, it has been used as a backdoor in the past and it remains a backdoor by design (direct hardware access for VGA, standard system calls bypassed in certain cases, own fault handling and other such niceties).
And intelligent emulation has worked much better despite theory would suggest a VDM to perform better - for one, most DOS applications are busy-waiting and when run in a VDM will continuously cause expensive context switches in a tight loop, as they raise interrupts, faulting into the kernel, bounced back to user mode, handled by the emulation layer which finally resumes the DOS code with another call into the kernel which switches back the CPU into V86 mode, give or take a context switch... this usually kills both the DOS application and the host system making both unusable. As opposed to an emulator that can simply recompile the DOS code into native code and execute it directly, with interrupts not being much more expensive than regular function calls, and with the chance to behave a lot more like real hardware, unlike V86 mode.
And this doesn't even take VGA emulation in account - Windows support for full-screen DOS applications is especially gruesome, adding a couple more context switches of the ugliest kind (TSS switching) to call into the real-mode 16-bit VGA BIOS. Again, emulation would be not only simpler, but also much faster, as the VGA BIOS virtually is dead code with performance that cannot even remotely be compared with what today's GPUs can do (more or less easily available through DirectX), and it's real-mode 16-bit code on top of that.
Also, Windows has successfully employed software emulation for DOS support, and the actual implementation of the user-mode VDM doesn't affect Win32 components relying on it, but it has a huge impact on kernel complexity and even security - software emulation is painless, has no special kernel requirements and is perfectly compatible. And makes for a self-contained implementation that can be easily customized, or completely removed from an installation or distribution without the need of a separate kernel build.
Finally, V86 support in the Windows kernel is virtually unused outside of the VDM, and completely inadequate for any kind of serious work if compared with V86 support on other operating systems.
In short, it's just ballast
KJKHyperion wrote:
TwoTailedFox wrote:
If NTVDM/VDM is neither a service, nor a Subsystem, then what precisely is it?
a hack. A hack we don't have to support, since the VDM concept sucks, it has been used as a backdoor in the past and it remains a backdoor by design (direct hardware access for VGA, standard system calls bypassed in certain cases, own fault handling and other such niceties).
And intelligent emulation has worked much better despite theory would suggest a VDM to perform better - for one, most DOS applications are busy-waiting and when run in a VDM will continuously cause expensive context switches in a tight loop, as they raise interrupts, faulting into the kernel, bounced back to user mode, handled by the emulation layer which finally resumes the DOS code with another call into the kernel which switches back the CPU into V86 mode, give or take a context switch... this usually kills both the DOS application and the host system making both unusable. As opposed to an emulator that can simply recompile the DOS code into native code and execute it directly, with interrupts not being much more expensive than regular function calls, and with the chance to behave a lot more like real hardware, unlike V86 mode.
And this doesn't even take VGA emulation in account - Windows support for full-screen DOS applications is especially gruesome, adding a couple more context switches of the ugliest kind (TSS switching) to call into the real-mode 16-bit VGA BIOS. Again, emulation would be not only simpler, but also much faster, as the VGA BIOS virtually is dead code with performance that cannot even remotely be compared with what today's GPUs can do (more or less easily available through DirectX), and it's real-mode 16-bit code on top of that.
Also, Windows has successfully employed software emulation for DOS support, and the actual implementation of the user-mode VDM doesn't affect Win32 components relying on it, but it has a huge impact on kernel complexity and even security - software emulation is painless, has no special kernel requirements and is perfectly compatible. And makes for a self-contained implementation that can be easily customized, or completely removed from an installation or distribution without the need of a separate kernel build.
Finally, V86 support in the Windows kernel is virtually unused outside of the VDM, and completely inadequate for any kind of serious work if compared with V86 support on other operating systems.
In short, it's just ballast
It seems to me another benefit of going the emulation route is easy 16-bit support in x64 version of ReactOS - something MS isn't offering.
Hi,
On 11/29/05, Royce Mitchell III royce3@ev1.net wrote:
It seems to me another benefit of going the emulation route is easy 16-bit support in x64 version of ReactOS - something MS isn't offering.
Right now dosbox is far enough along that it can run Win3.1. It would be cool if we could rip out the dosbox gui and write a wrapper or something that made dosbox send and recive input via cmd.exe. That still does not solve the Win16 problem though. Building the Wine Win16 stuff as Win32 dlls, porting winedos.dll and developing a thunking system like they have is a option for that.
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
My "vote" is for integrating DosBox into ReactOS. Maybe it isn't as fast as execution of progs on real processor but it offers many great extensions like sound card emulation.
Sebastian
I am for emulation, no V86, full standard LFN support, support for DOSAPP to give up the timeslices, native DOS network redirector support, standard ints for clippboard access, VESA textmodes ;).
On some setups I think even on WinNT when IPX protocol driver is used, Novells IPX ints are emulated for DOS programs. Maybe even full M$ DOS network stack would be cool. It was hyper huge in DOS 120-300 kb of conventional but I was able to talk to my WinXP machine through TCP/IP happily. Only problem was with DOS acting as server for WinXP. If this is dependent on VDM Ditch that.
And known and documented interrupt compatible with undocumented one from M$ to allow DOS program to switch to fullscreen. Thats what I want. Hehe
What I was thinking was to emulate the VGA bios/VESA by using DirectX or OpenGL calls (or possibly the Allegro Game Library).
I was more or less thinking of how to implement the VDM with security and stability in mind with a mininum set of things that the OS has to do.
Have you heard or read about the VIF (bit 19) and VIP (bit 20) flags in the EFLAGS register?
x86-64 in Long Mode does not have V86 mode. It probibly would be best to emulate the legacy x86 machine in x86-64 Long Mode
(maybe a bit off topic) Hummm....... maybe "x86-128" in "full mode" would loose 32 bit support and drop 16 bit mode all together. If this does happen then I see a trend comming.
KJKHyperion wrote:
TwoTailedFox wrote:
If NTVDM/VDM is neither a service, nor a Subsystem, then what precisely is it?
a hack. A hack we don't have to support, since the VDM concept sucks, it has been used as a backdoor in the past and it remains a backdoor by design (direct hardware access for VGA, standard system calls bypassed in certain cases, own fault handling and other such niceties).
And intelligent emulation has worked much better despite theory would suggest a VDM to perform better - for one, most DOS applications are busy-waiting and when run in a VDM will continuously cause expensive context switches in a tight loop, as they raise interrupts, faulting into the kernel, bounced back to user mode, handled by the emulation layer which finally resumes the DOS code with another call into the kernel which switches back the CPU into V86 mode, give or take a context switch... this usually kills both the DOS application and the host system making both unusable. As opposed to an emulator that can simply recompile the DOS code into native code and execute it directly, with interrupts not being much more expensive than regular function calls, and with the chance to behave a lot more like real hardware, unlike V86 mode.
And this doesn't even take VGA emulation in account - Windows support for full-screen DOS applications is especially gruesome, adding a couple more context switches of the ugliest kind (TSS switching) to call into the real-mode 16-bit VGA BIOS. Again, emulation would be not only simpler, but also much faster, as the VGA BIOS virtually is dead code with performance that cannot even remotely be compared with what today's GPUs can do (more or less easily available through DirectX), and it's real-mode 16-bit code on top of that.
Also, Windows has successfully employed software emulation for DOS support, and the actual implementation of the user-mode VDM doesn't affect Win32 components relying on it, but it has a huge impact on kernel complexity and even security - software emulation is painless, has no special kernel requirements and is perfectly compatible. And makes for a self-contained implementation that can be easily customized, or completely removed from an installation or distribution without the need of a separate kernel build.
Finally, V86 support in the Windows kernel is virtually unused outside of the VDM, and completely inadequate for any kind of serious work if compared with V86 support on other operating systems.
In short, it's just ballast _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Alex Ionescu -
David Hinz -
David Johnson -
Ge van Geldorp -
Jerry -
KJKHyperion -
Maritn "E.T." Misuth -
Royce Mitchell III -
Sebastian Gasiorek -
Steven Edwards -
TwoTailedFox