home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,462 of 4,255   
   mutazilah@gmail.com to Alexei A. Frounze   
   Re: windows   
   19 Nov 22 05:34:03   
   
   From: muta...@gmail.com   
      
   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.   
      
   > 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.   
      
   > > 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.   
      
   > > 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.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca