kerravon wrote:
Brendan wrote:
Also don't forget that most operating systems are multi-tasking, so if a (single-threaded) process waits for a "write()" to complete then all of the other hardware (devices and CPUs) can still be kept doing useful work for other processes.
MS-DOS was "special" because it didn't provide any way to keep hardware (devices and CPUs) doing useful work in any situation.
The lack of multi-tasking in the actual implementation of 16-bit MS-DOS does not mean that there is a problem with the API itself that forever prevents a new version of MS-DOS (ie PDOS/386) from supporting multi-tasking, does it?
It's not that you can't support multitasking, it's that to do multitasking while retaining compatibility with existing DOS programs, you have to either give up stability or emulate device I/O, in which case you've given up on direct hardware access. For new programs, having (for example) a sound API that abstracts away the details of the sound hardware is easier for you, easier for application developers, and more performant than trying to emulate every single little detail of every sound card that a DOS program might ever have tried direct hardware access to.
Microsoft has already done what you're attempting. The "Allow direct hardware access, at the cost of stability" branch was called Windows 3.x and Windows 9x, and is responsible for the reputation of Windows as a crashy system. The "emulate hardware access" branch is called NTVDM. On 32-bit Windows systems to this day, it encapsulates a DOS instance as a Windows process, but even Microsoft doesn't have the resources to write emulation for every single hardware device that any DOS program ever might try to access directly, so there are a lot of DOS programs that won't run on it, and fewer and fewer with every release of Windows.
Quote:
Regardless, I'm not trying to replace the MS-DOS API with Posix or something else, I'm taking the MS-DOS API *as a given*. What I'm looking for is a minimal set of changes, that still revolve around the MS-DOS API, but allow for 32-bit and maybe one day 64-bit programming. The only thing I would change about the MS-DOS write() API is to allow the 32-bit version to take the number of bytes to write in ECX rather than CX. And to avoid application programmers having to code two different int86x calls, one 16-bit populating cx, and one 32-bit populating ecx, I would instead have a wrapper function called PosWriteFile(int handle, void *data, size_t len);. Or something like that. I'm fairly happy with that one already. It's the allocation of memory that has me going round and round in circles trying to decide whether I need a new AH service and have a flag (register) to say whether I want memory in 20-bit space or 32-bit space, similar to how MVS (mainframe) does things. I'm expecting this one API call will be a necessary divergence from the rest of the API.
As I said, "for new programs, having (for example) a sound API that abstracts away the details of the sound hardware is easier for you, easier for application developers, and more performant than trying to emulate every single little detail of every sound card that a DOS program might ever have tried direct hardware access to".
For existing programs, you don't need any more than the existing DOS APIs, DOS itself, DPMI, Win16, etc.
For new programs, you don't want an API that allows direct hardware access, and you want an API that is defined in terms of a high-level-language, not x86 assembly, so you really don't want to try to extend the DOS API to 64-bits (DPMI already did that for 32 bits).