DOS Subsystem.

[David Johnson]

So you want OpenGEM 5 to replace DosShell?

On 11/28/05, Jerry <crashfourit(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  

--
David Johnson
http://www.davefilms.us

[David Johnson]

Ausome! Lets do it!

On 11/28/05, Jerry <crashfourit(a)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(a)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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >  
>
>  --
>  David Johnson
>  http://www.davefilms.us
>
>  ------------------------------
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  

--
David Johnson
http://www.davefilms.us

[TwoTailedFox]

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(a)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(a)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(a)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(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > >
> > >  
> >
> >
> >  --
> >  David Johnson
> >  http://www.davefilms.us ________________________________ 
> >   _______________________________________________
> >  Ros-dev mailing list
> >
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >  
>
>
>   --
>   David Johnson
>   http://www.davefilms.us ________________________________
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  

--
"I had a handle on life, but then it broke"

[Ge van Geldorp]

>   From: Jerry
>
>  I still want to add long file name support for those programs that suport 
it.

MS-DOS 7 (Win95) used INT21/AH=0x71 for long filename support.

GvG

[Alex Ionescu]

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

[TwoTailedFox]

If NTVDM/VDM is neither a service, nor a Subsystem, then what precisely is it?

On 11/29/05, Alex Ionescu <ionucu(a)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:
>  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
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  

--
"I had a handle on life, but then it broke"

[KJKHyperion]

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

[Royce Mitchell III]

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.

[Steven Edwards]

Hi,

On 11/29/05, Royce Mitchell III <royce3(a)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

[Sebastian Gasiorek]

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

[KJKHyperion]

Royce Mitchell III 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. 
granted, but I'm explaining why it'd be better to use emulation on x86 
too and ditch the VDM design

[Maritn "E.T." Misuth]

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

[Jerry]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>