From: alexfrunews@gmail.com   
      
   On Saturday, November 19, 2022 at 5:34:04 AM UTC-8, muta...@gmail.com wrote:   
   > On Saturday, November 19, 2022 at 11:59:09 AM UTC+8, Alexei A. Frounze wrote:   
   >   
   > > On Friday, November 18, 2022 at 1:59:22 PM UTC-8, muta...@gmail.com wrote:   
   > > > On Friday, November 18, 2022 at 9:19:46 AM UTC+8, Alexei A. Frounze   
   wrote:   
   > > >   
   > > > > You can build your 16-bit support on 64-bit Windows around Hyper-V.   
   > > > I don't want a virtual machine. I want to use the same machine   
   > > > that currently lets me run 32-bit and 64-bit executables from   
   > > > the command prompt.   
   >   
   > > The modern Windows doesn't support your scenario.   
   > > Which is in part because the modern x86 CPU doesn't support it.   
   > It does - CM16.   
      
   Originally you wanted real mode if I remember correctly.   
   Sticking arbitrary selector values into segment registers is going to be   
   problematic in protected mode, unless you restrict everything to a single   
   pre-existing segment.   
   On top of that, the OS needs to know how to properly support processes   
   running in 16-bit compatibility mode. That support is likely absent from the   
   kernel.   
   So you're looking into hacking the system into providing such a support.   
   This goes far beyond your " written "nicely" ".   
      
   > > And the modern PC doesn't necessarily support it either (e.g. there can be   
   no   
   > > BIOS or VGA on whose availability you could rely some 20 years ago,   
   > > now there's EFI).   
   > I don't need either BIOS or VGA for PDOS-generic applications.   
   > Or even the "INT" instruction.   
      
   Then why do you even care about running the code natively on the CPU?   
   How are you going to benefit from it? Do you want to run ancient software   
   at speeds it was never intended for? This would be about the only benefit.   
   Any other I'm missing?   
   Emulating the i80486 instruction set (more than sufficient HW for DOS SW)   
   is a problem that is bound and has been solved many times. You can just   
   do it without hacking Windows. Plenty of CPU cycles, RAM bytes and disk   
   sectors to go around for this nowadays.   
      
   > > > Ideally I would not even know that I am running a 16-bit   
   > > > executable (as was the case with 32-bit Windows   
   > > > command prompt).   
   > > >   
   > > > But if Microsoft is unwilling to provide 16-bit support I   
   > > > am willing to design 16-bit applications that will work   
   > > > under a theoretical PDOS/x64, but while waiting for   
   > > > that, I could instead use a kernel mode 32-bit app to   
   > > > switch to CM16 (or perhaps set the D-bits while staying   
   > > > in CM32), run my 16-bit app (which does no interrupts,   
   > > > since it is PDOS-generic), returns to CM32 and switches   
   > > > the D-bits back without Windows even being aware   
   > > > what happened.   
   >   
   > > Microsoft doesn't want your code running freely in kernel mode.   
   > >   
   > > And that's another blow to your dreams.   
   > They don't stop me installing privileged programs currently,   
   > I believe.   
      
   You may be able to install unsigned drivers, but it's not kosher   
   outside of development of software for Windows.   
   And if not already, there may be limitations associated with it   
   (other than the warning messages).   
      
   > > > I do something similar with MVS/380. The OS is unaware   
   > > > that the app switched to AM31 and back again.   
   > > > > If I understand it correctly (it's been years since I did anything   
   in/with Hyper-V), you'll need to   
   > > > > implement all the necessary x86 devices yourself (PIC, PIT, DMA, VGA,   
   serial port,   
   > > > > keyboard, mouse, FDC, HDC, SB, etc etc) and throw in a BIOS of some   
   kind.   
   > > > I want to avoid all that. I want to switch back to 32-bit   
   > > > mode to service the 16-bit API call.   
   > > >   
   > > > If Microsoft has an official API I would be happy to call   
   > > > a 16-bit interrupt or DLL in that case.   
   >   
   > > There just isn't. Get over it. Run DOSBox or a VM.   
   > > Or stick to old Windows on old PCs while you still can (if you can).   
   > None of those things exercise CM16, which is what I am   
   > interested in.   
      
   Using Hyper-V you get a way to run your 16-bit SW (real mode or   
   protected) as close to native as possible without crippling or hacking   
   Windows.   
      
   Alex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)