Re: XMS memory
- To: TCP-Group@ucsd.edu
- Subject: Re: XMS memory
- From: firstname.lastname@example.org
- Date: Sun, 23 Apr 95 00:37:03
- Reply-to: email@example.com
> NOS uses neither XMS nor EMS. What it can use is the EMS page frame. This is
> very different from ordinary EMS-using programs, and is usually incompatible
> with them. EMS does provide for saving and restoring state around task
> switches, even from inside TSRs, but NOS does not implement any of that.
> It is a major piece of work to use paged memory of any kind. EMS is paged
> through a frame window fixed in size and position, while XMS is copied back and
> forth into a settable window.
Mike, you may want to try explaining that in English next time, but perhaps
I can interprete for now (at the risk of starting another Jehad).
xNOS falls into that grey area somewhere between a dos application and a
special purpose operating system. It encompasses most, if not all, of the
functions an operating system needs to provide, ie task control, interval
control, memory management, i/o control etc. However it provides these
services only to a fixed set of tasks, compiled with the 'O/S'. Although it
provides these higher level services to its preset tasks, it does so on top
of an otherwise unfriendly 640k DOS aka file loader. Because the two,
operating services and applications are so tightly integreted, it would be
extremely difficult to provide the required add-ons to DOS to open up memory
or scalability etc. Doing so is not impossible, it would just require
re-writting huge amounts of xNOS. I think, Karl, what you are really asking
for is to have the NOS application functionality on a real operating system.
There are such versions. The problems are not so much with the NOS
applications, its with the lack of an operating system to support it, in the
case of DOS, and therefor Windows. Thats why there came to be an OS/2 or NT.