Reading the documentation, "this is a clone of MS-DOS" turns out to be quite a misleading summary of what this is.
The documentation claims things (which I have not verified personally) such as forking, signals, and pipes. Instead of a SUBST command there is a MOUNT command. And there's a convoluted piece of hooplah that stands in place of what MS-DOS could do with the SHELL= line in CONFIG.SYS .
> Reading the documentation, "this is a clone of MS-DOS" turns out to be quite a misleading summary of what this is.
Not a "clone" in the sense of 100% compatible... but a "clone" in the sense of borrowing a significant degree of ideas and APIs/syntax from it, yet also deviating at various points (whether for good reasons or for idiosyncratic ones)
It is a clone more in the sense that the Japanese mainframe operating systems Fujitsu MSP and Hitachi VOS3 are/were clones of IBM MVS: they started out as a direct copy of MVS–due to IBM having released earlier versions into the public domain, and Fujitsu/Hitachi illegally stealing the IP of later ones–but over time diverged in incompatible directions
ST-DOS is a DOS implementation, but it is not meant to be a clone of MS-DOS. It is mostly syscall-compatible with MS-DOS, but the driver API and many other things are completely different. After all the definition of DOS is just "disk operating system".
All real mode programs that are compiled with Watcom C/C++ should work. The most recent versions of Watcom's protected mode runtime don't currently work, because they use some undocumented MS-DOS syscalls that are not implemented in ST-DOS. I intend to create a compatibility TSR that will solve most issues with those MS-DOS programs.
The documentation claims things (which I have not verified personally) such as forking, signals, and pipes. Instead of a SUBST command there is a MOUNT command. And there's a convoluted piece of hooplah that stands in place of what MS-DOS could do with the SHELL= line in CONFIG.SYS .