DOS ain't dead

[post split due to unaccepted word]

I recently noticed that the MSDOS 2.0 API is very
close to Unix with INT 21H APIs like open, read,
write, seek, close.

I know that various C compilers for MSDOS came with
functions like open() but I never used them so I'm
not sure of the details.

I'm wondering whether Microsoft effectively introduced
something similar to POSIX with their C compiler,
providing wrappers for each of their system calls, or
at least the most important ones.

In which case, a true 32-bit successor to MSDOS would
be something that provides a 32-bit open() with the
same parameters as MSDOS 2.0. Win32 should not
be considered the successor.

Is there a possibility of a rival to POSIX here?
I never liked POSIX when they made fork() a requirement.

> Is there a possibility of a rival to POSIX here?
> I never liked POSIX when they made fork() a requirement.

Note that I don't expect a C library to directly call
open() and pol*lute the namespace.

Probably Microsoft failed to provide a suitable
GetCommandLine() and spawn() function though (that
would work on both 16-bit and 32-bit).

What would an MSDOS-inspired rival to POSIX be called?

Hello kerravon,

> I recently noticed that the MSDOS 2.0 API is very
> close to Unix with INT 21H APIs like open, read,
> write, seek, close.

This is almost certainly by design. The recently published DOS 2.x source code referred to the new system calls as XENIX CALLS.

Also, while syscall 0x4b is named $EXEC, it actually starts a child process, so it is really more akin to POSIX's posix_spawn. There is actually no MS-DOS execve-like syscall that lets a running process replace itself with another program. The MS-DOS syscall ABI is also kind of deficient in other ways.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> to the new system calls as XENIX CALLS.

Thanks for that interesting link.

I did some more reading on Xenix and it looks like
Gates wanted to use Unix eventually, but couldn't
do it immediately due to limitations of PC hardware.

I am interested in an OS that CAN be implemented on
limited hardware. MSDOS is known to be able to be
implemented on limited hardware, so I'm interested
in that API.

As far as the core API is concerned, the only things
I notice are:

1. A GetCommandLine() function is needed to mask the
different ways that command lines are accessible to
an application.

2. posix_spawn or similar needs to be available, forget
about fork and exec.

3. Memory allocation needs to be provided - some sort
of allocmem() function - which should take a number
of bytes and return a far pointer.

And then we have a set of syscalls that are viable for
small computers with 64k memory or whatever, and still
be viable for more powerful computers.

> > to the new system calls as XENIX CALLS.
>
> Thanks for that interesting link.
>
> I did some more reading on Xenix and it looks like
> Gates wanted to use Unix eventually, but couldn't
> do it immediately due to limitations of PC hardware.


I'll add that Unix compatibility was a huge, HUGE thing in the 1980s. Even Apple tried to go there with MacOS at the time. Having Unix compatibility could open doors for lucrative government contracts.

Of course, DOS took over anyway and ruled the PC market for the duration of the 1980s and into the 1990s. So in the end, Microsoft didn't need Unix anyway, and came up with Windows NT as a commercial alternative, which won the day for them.

> I recently noticed that the MSDOS 2.0 API is very
> close to Unix with INT 21H APIs like open, read,
> write, seek, close.

Hmmm... which one? Do you mean working via FCB or something else ?
(FCB = File Control Block)

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > I recently noticed that the MSDOS 2.0 API is very
> > close to Unix with INT 21H APIs like open, read,
> > write, seek, close.
>
> Hmmm... which one? Do you mean working via FCB or something else ?
> (FCB = File Control Block)

No. Using handles.

Like "open" is INT 21H AH=3DH

http://www.ctyme.com/intr/rb-2779.htm

It's just something that hadn't registered in
my brain before.

BFN. Paul.