[ros-dev] DOS Subsystem.

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


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