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