From: muta...@gmail.com   
      
   On Saturday, November 19, 2022 at 3:06:53 PM UTC+8, JJ wrote:   
   > On Fri, 18 Nov 2022 13:37:57 -0800 (PST), muta...@gmail.com wrote:   
   > >   
   > > A C-generated executable normally doesn't manipulate   
   > > segment registers/selectors. That's what I'm interested   
   > > in. Large memory model is the main thing I want. I assume   
   > > lds still works to load a selector instead of a segment.   
      
   > It depends on which platform it's compiled for. The memory management   
   > functions from the runtime library would treat segment registers   
   > differently.   
      
   I will freshly compile it for whatever works. I provide my own   
   runtime library.   
      
   > > I only used OS/2 2.0, and I could do this:   
   > >   
   > > unsigned long hfile; /* OS/2 file handle */   
   > >   
   > > rc = DosWrite(stream->hfile, (VOID *)ptr, towrite, &tempWritten);   
   > >   
   > > Did this function not exist in 1.0?   
   > >   
   > > If it did exist, that's all I need, isn't it?   
   > >   
   > > Windows 12/13 could support a 16-bit DosWrite that writes   
   > > to a console and supports ANSI controls for both input and   
   > > output, couldn't it?   
   > >   
   > > Any other existing option besides DosWrite? Did 16-bit   
   > > Windows have nothing the equivalent of that?   
      
   > Since there's no 16-bit Windows application which is a console type, there's   
   > no equivalent function in Windows. 16-bit Windows application can not have   
   > its own console. In 16-bit Windows, consoles only belong to DOS   
   > applications.   
      
   Do you now agree that 16-bit OS/2 supported a console   
   at least?   
      
   If so, that might be my target API.   
      
   > > My desire is to run an unkludged executable on that CM16   
   > > at native speed.   
   > >   
   > > I'm just wondering what sort of things I can stick on that.   
   > > Is anyone currently using it for anything?   
   > >   
   > > Some people climb mountains because they exist.   
   > >   
   > > I want to exercise CM16 because it exists.   
      
   > CM16 is not quite useful. CM16 only exist for backward compatibility. It's   
   > only useful for existing softwares. It's not useful for a new 64-bit OS   
   > since there's no advantage of creating 16-bit applications for 64-bit OS.   
      
   Backward compatibility with ... what?   
      
   What API can I use in CM16 and can I create a new API if I want?   
      
   I have no comment on whether it will be useful or not.   
      
   When I started writing PDPCLIB, someone asked me why   
   I was going to so much effort to create something that   
   came free with every compiler. I didn't have a particularly   
   good answer at the time.   
      
   About a decade later, gccmvs and MVS/380 were born   
   as a result.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)