From: bohannonindustriesllc@gmail.com   
      
   On 7/19/2024 11:18 AM, Scott Lurndal wrote:   
   > "Paul Edwards"  writes:   
   >> Sure - but why not make it available anyway?   
   >   
   > MS-DOS is, was, and always will be a toy.  It's not even   
   > a real operating system.   
   >   
   > No mainframe user would ever be interested in something   
   > so simplisticly useless.   
   >   
      
   It has a FAT filesystem, MZ loader, and basic console printing and   
   memory allocation... These cover the main bases for what one needs for   
   an operating system.   
      
      
   Granted, if one wants memory protection and multiple processes/threads,   
   this is no longer sufficient as now the OS needs to be able to do all   
   the other stuff programs might want to be able to do.   
      
   Granted, other types of things one might need to deal with is how   
   programs should be able to interface with OS facilities and device drivers.   
      
      
   Say, for example:   
   Unix style: System calls identified by number, and treated like a   
   function call. Most devices are presented as file-like objects (mostly   
   using file operations or "ioctl()").   
      
   COM style interfaces: An object is given with various methods, and a   
   mechanism exists for mapping these method calls from userspace to kernel   
   space or between processes.   
      
      
   In my project, I used a hybrid approach, where a range of system-call   
   numbers were set aside for method calls. There is a system call used to   
   request an interface object for a given interface.   
      
   In this case, an interface ID is given as a pair of 64-bit numbers,   
   which may be interpreted as FOURCC's, EIGHTCC's, or a UUID/GUID. When   
   needed, it is possible to tell them apart by looking at bit patterns.   
   Current thinking is mostly that OS APIs would use FOURCC or EIGHTCC   
   pairs, whereas private interfaces would use GUIDs.   
      
   The object is presented (to the client application) with its VTable   
   mostly filled up with methods which merely exist to forward their   
   arguments to the corresponding system-call number (for their location   
   within the VTable).   
      
      
   Some other devices could present themselves with a file-like or   
   socket-like interface though.   
      
   Though, say, for things like GUI/audio/etc interfaces, a COM-like   
   interface routed directly over syscalls would have lower overhead, say,   
   than trying to shoe-horn it through message passing over a socket or   
   similar.   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)