On Mon, 23 Jan 2023 at 18:55, Bret Johnson <bretj...@juno.com> wrote:
Hi Bret. Thanks for the long and considered reply. I do not know why you conflated 2 different people's emails into one reply, though, also stripping out the identifying info, but I will only attempt to reply to the part that addressed my email. > **** > > > This is a very sketchy thought, but... > > > > AIUI, the way that 386 memory managers for DOS work is that they put > > the CPU into protect mode, map RAM into upper memory blocks as DOS > > wants, then start a single, non-multitasking V86 mode VM for DOS > > itself. > > > > That basic process would be enough to boot a DOS instance, wouldn't > > it? > > No, not really. Before you can run a Memory Manager you need a BIOS and an > OS to install it on. I am aware of that. :-) I am not proposing that an existing 386 EMM could do this. > > "All" it needs is a memory manager that can start as a 32-bit > > process, set up a few interrupts -- INT 11 for the hard disk, for > > instance -- start a single V86 process, and then kick DOS off in > > that process. Then a stub program for DOS to load in CONFIG.SYS to > > enable the memory manager. > > No, not quite. For example, the way MS Windows worked (back before NT when > Windows was actually a DOS program) was that when Windows started it would > send a special call to EMM386 that told EMM386 to shut itself off. Windows > would transfer a little bit of information from EMM386 (but it would NOT, > e.g., transfer the I/O virtualization information) and then would handle the > EMM386 stuff 'The Windows Way". When Windows exited, it would tell EMM386 to > turn on again. Exactly how that all worked was proprietary to MS which is > why other memory managers are incompatible with Windows. Bob Smith and > Qualitas managed to work through some of those issues, but I'm not sure they > ever figured out the whole thing. I do believe 386MAX was able to work with > Windows, at least partially. BTW, this process was called GEMMIS (if you > want to try and look it up). OK -- good info, and I will look it up. I suppose my first suggestion would be: sod Windows. A suggestion of a justification: If people want a FOSS DOS then they must use a FOSS GUI, and if they want a proprietary GUI then they must accept that also means a proprietary DOS underneath. > > Normally, DOS starts EMM386 or JEMM386 or whatever. This way round, > > JEMM386 starts DOS. > > Nice thought, but I don't think it will work. You need much more than a > memory manager -- you really need a BIOS and an OS also. Let's look at those separately. A BIOS: Well there is already at least one FOSS BIOS out there -- SeaBIOS. https://www.seabios.org/SeaBIOS https://en.wikipedia.org/wiki/SeaBIOS Surely that's a start? The questions become, [1] is it, or can it be made, sufficiently generic? [2] is there any way to softload the thing from a UEFI loader? An OS: Well, the point I was trying to make was that it doesn't need to be very much of an OS. While I am not arguing against your interesting rebuttal, which I appreciate, I feel that you didn't engage with my core point. Perhaps you conflated the 2 different emails from different people when composing a response? My core point was: the way that a 386 memory manager worked was running as a kernel-mode 32-bit binary, running a single 386 hardware V86 session. In other words, from EMM386 to JEMM to QEMM, they were already, 30 years ago, 32-bit code that set up a hardware DOS VM and ran DOS in it. Yes, I know that how they got there was different. They didn't cold boot. What I am saying is that if UEFI can only load 32-bit (or 64-bit but that's irrelevant to DOS) payloads, well, if we're running DOS on a 32-bit machine, we more or less need one of those anyway. So, is there a way to use it? Write a special 32-bit payload that can only do one thing: 1. load into RAM 2. load a generic BIOS emulation which only emulates a few fixed devices that are supported by DOS 3. set up a single V86 session 4. boot FreeDOS into that Then FreeDOS loads some kind of shim that talks to the memory manager that is already resident. The DOS sessions in Windows NT and OS/2 ≥2 both do this already. It is, or was, a thing. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
