From: muta...@gmail.com   
      
   On Sunday, November 20, 2022 at 5:57:22 AM UTC+8, Alexei A. Frounze wrote:   
      
   > > > 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.   
      
   Originally when? This is a new thread for a reason.   
   I didn't ask for RM16.   
      
   > 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.   
      
   I was hoping to switch the GDT. But I need to know where   
   to find the old one to be able to switch back.   
      
   > 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.   
      
   It can be either added by Microsoft properly if they want,   
   or I can hack around without their knowledge.   
      
   > So you're looking into hacking the system into providing such a support.   
   > This goes far beyond your " written "nicely" ".   
      
   Sorry for the confusion.   
      
   I want the 16-bit *apps* to be written nicely.   
      
   I don't care about what happens outside of the executable   
   (disabling interrupts so that I can change the GDT, crashing   
   all of Windows on the first bug, or anything else).   
      
   > > > 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?   
      
   Yes, backdated 16-bit software that I write for the 8086.   
      
   I want it to fly on CM16.   
      
   > This would be about the only benefit.   
   > Any other I'm missing?   
      
   Nope. That's it. I want any 16-bit programs I write for   
   MSDOS (or at least 16-bit PDOS-generic) to run in   
   long mode CM16 under 64-bit PDOS-whatever, when   
   it eventually exists, and potentially under Windows   
   sooner than that.   
      
   > 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.   
      
   I don't want to rely on the hardware compensating   
   for poor software implementation.   
      
   > > > > 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.   
      
   I'm not trying to win Miss America, I'm trying to write   
   16-bit applications that work on the 8086 and CM16.   
      
   If Bill Gates has a heart attack I don't care.   
      
   > And if not already, there may be limitations associated with it   
   > (other than the warning messages).   
      
   Ok.   
      
   > > > > 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.   
      
   I don't want to rely on the existence of such a feature.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)