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 looklike 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 andjump 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" _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev