Hi Bret, Yep! You said it all much better and in far greater detail than I went into.
Thanks. :-) Jerome > On Jan 23, 2023, at 1:54 PM, Bret Johnson <bretj...@juno.com> wrote: > > >> >> by the way, the 2 programs are the setup stuff and edlin. hardly >> rocket science. > > Even those two "simple" programs would probably be considered "rocket > science", or at least akin to "learning a foreign language", by most students > who are only used to modern technology and web apps. Low-level stuff like > I/O and IRQ and BIOS emulation isn't flamboyant enough for most younger > people to get involved with these days. > > **** > >> Perhaps it could be used to solve one of the most frequent problems >> I hear. Running FreeDOS on modern UEFI hardware. > > I think that is the main point of it all. > >> As we are all well aware, this cannot be directly accomplished and >> would require an abstraction layer between the OS and the actual >> hardware. > > It actually can, at least in certain situations. The fundamental problem, at > least as I see it, is I/O. I know a lot of the talk seems to be around sound > cards, but let's discuss it in terms of something a little simpler: joysticks. > > A regular, old-fashioned joystick uses an I/O port, specifically port 201h. > There is also a BIOS function that lets you access the joystick, INT 15.84. > Over the years as computers got faster and joysticks got more complicated > (more buttons and axes), the INT 15.84 BIOS interface effectively became > useless. Modern programs that want to use a joystick almost never use INT > 15.84 and instead try to talk to I/O port 201h directly. That has caused all > kinds of problems. > > Sound cards have a similar, yet slightly different, problem. There was NEVER > a widely support BIOS-level interface for sound cards. The de facto > "standards" that everyone seemed to base their sound card designs on were Ad > Lib and Sound Blaster which were fundamentally hardware (I/O) based and > proprietary (they also used things like DMA's and IRQ's). > > Now, we're in a world where USB is pretty much the standard port for > everything plugged into the computer (certainly for joysticks and to a large > extent for sound devices). From a hardware perspective, the USB host > controllers are the only things that actually talk to the "real" I/O ports > (sometimes PIO but usually MMIO). DOS programs still expect to see the > joysticks on I/O port 201h and the sound cards at various I/O ports, but > those ports don't exist on the real hardware any more and must somehow be > virtualized. > > The problem is even worse when you're using something like DPMI. DPMI does > allow thunking down to the lower level (the DOS/16-bit "layer") for > interrupts but doesn't provide a standard way to thunk for I/O ports. Since > a way to thunk I/O isn't provided, every single DPMI-based program needs to > understand things like USB and all the different kinds of devices that can be > USB-attached. Of course, none of them understand USB and none of them thunk > the I/O, either. > > It is possible to virtualize I/O in DOS with MS EMM386 and with Quailitas' > 386MAX. JEMM also has a proprietary way to virtualize I/O with JLOAD, and I > am currently trying to add the MS/Qualitas-style capability to JEMM. But > those methods will only work with programs that don't use DPMI or that thunk > the I/O from DPMI. IOW, many old programs would need to be rewritten change > the way they do things to work properly on modern hardware without a VM. > That ain't gonna happen. > > What a Virtual Machine does is provide another level of abstraction between > the real hardware (e.g., the I/O ports associated with the USB hardware) and > the virtualized hardware (e.g., I/O port 201h that a DPMI program is > expecting to see a joystick attached to). With this extra layer of > abstraction, the DPMI program doesn't need to do the "thunking" -- it is > handled "automatically" by the abstraction layer that sits between the real > hardware (real I/O ports) and the virtualized hardware (virtualized I/O > ports). > > That hardware abstraction layer is one of the main things that Virtual > Machines provide. Of course, different VMs virtualize different hardware > devices. I think they all do mice and keyboards and disks, a lot of them do > Ethernet cards and printers, but only some of them will do things like PC > Speakers and joysticks and sound devices. > > One of the main things that Windows has done is to move the BIOS _function_ > (an abstraction layer between the hardware and the software) up into the OS > itself. In fact, Microsoft at least used to call it the "Hardware > Abstraction Layer" or HAL, but I don't know if they still call it that or > not. *nix does something similar -- they have hardware-specific drivers > (that talk to devices at the I/O level) and then have a "layer" that a > program "talks to" when it wants to send or receive data from some particular > device. The program doesn't need to know what kind of hardware port the > device is attached to. > > DOS has always expected that abstraction layer to be provided by the BIOS. > For example, if you use the BIOS INT 13h function for disk access you don't > need to know if the DISK is MFM/RLL, ESDI, SCSI, IDE/ATA, USB, or whatever. > The INT 13h abstraction layer hides all that from you. The Ethernet packet > driver interface is similar -- it provides a standard software interface that > Ethernet programs can talk to and they don't need to understand the nuances > of every different kind of Ethernet card. While the Ethernet packet driver > interface doesn't actually exist in the BIOS, it provides an abstraction > layer similar to what a BIOS would provide if there were one. My DOS USB > drivers provide a similar BIOS-level interface for the USB host controllers > (but a specific USB device, like a joystick, needs an additional layer before > a program can "see" a USB joystick). > > In modern computers the BIOS abstraction layer no longer exists -- it has > been moved up into the (modern) OS itself. From a user perspective, I think > it was a very bad mistake to let that happen but we're way too far down the > road to go back. > >> A project could be created to provide a very thin Linux based system >> (possibly using an RTOS kernel) whose only job is to manage the >> abstraction layer and implement the virtual machine to run FreeDOS. >> >> This could be done almost transparently. Booting straight to DOS >> unless the user pressed a specific key (Like F1) during boot. >> >> Pressing such a key would bring up a BIOS like interface that could >> be used to change the virtual BIOS settings and configure drivers >> and such aspects of the host OS. >> >> Their job would be to create that interface and make it all work >> seemingly. Most of the pieces required exist. But, it would not be a >> small task to implement. > > No, it wouldn't. And I think you're also assuming it would be based on some > existing Linux VM (like QEMU or KVM or something like that). Some existing > VMs provide enough of a BIOS emulation that it may be a partial solution, but > it would need to provide enough specific hardware support that I'm not > exactly sure how "thin" it could actually be. It will still need to include > all the hardware drivers for all the modern hardware that could potentially > need to be virtualized to be used by the DOS VM. One advantage would be > standardization (e.g., all sound devices could be virtualized as one of the > SoundBlaster models). > >> It could yield much better performance and more accurate emulation >> than traditional virtual machines. With todays multi-core systems, >> individual cores could be dedicated to emulating various aspects of >> PC hardware. For example, one core could be dedicated to performing >> the tasks handled by a sound card. > > In theory, yes, but probably not a place to go. Modern systems generally run > too fast to run older programs correctly (especially games). I think such a > VM would still need to accurately emulate various types and speeds of > hardware rather than just running as fast as it can all the time, similar to > what some (but not all) modern VMs do. > >> I think such a project could appeal to many. There is a lot of >> interest in playing old games. Also, since this would be a generic >> legacy PC emulation layer. It could be used to install other >> Operating Systems like MS-DOS, PC-DOS, etc. > > Or even older versions of Windows. > > **** > >> I think I actually proposed a similar idea some time ago except that >> it was *itself* the OS, rather than a stripped-down Linux distro. >> Sort-of a pre-AMD64 PC emulator, virtualizing where possible, >> emulating where not. > > I think a "thin" Linux distro has the best chance of working and also the > best chance of getting volunteers to work on. You still need all the > real-to-virtual I/O port stuff to be handled somewhere/somehow, and I think > Linux would be the best place to find existing resources that could provide > the necessary level of support. You certainly can't expect to get it from MS. > >> As for all the people saying "make FreeDOS more like Linux", they >> don't seem to understand FreeDOS *or* Linux. > > Indeed. > > **** > >> 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. > >> "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). > >> 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. Even though I don't > particularly like Jerome's idea of a "Thin Linux" (I really would like things > to run on real hardware), it may be the most reasonable solution. > > **** > >> There could be a small image containing a thin linux host that is >> booted by system. Possibly in it’s own partition or image file. >> This host then provides an abstraction layer which then boots the >> system like it was a PC with a legacy BIOS. Most likely providing a >> some abstracted and emulated hardware like a SoundBlaster compatible >> audio card. The Client OS (FreeDOS) would be installed to a normal >> partition on the drive. >> >> Providing support to also map things like I/O ports from the host OS >> to the client, to allow the possibility of connecting real legacy >> hardware to the machine (like CNC machines and TTY devices). > > Again, I think the I/O stuff is the real point to emphasize, though I'm not > sure how effective you can be in mapping I/O ports for old hardware. You > don't even have a real ISA bus any more (at least not any ISA card slots) -- > even that is "virtualized" and only exists in the software/firmware. > > **** > > Here's maybe another way to think about it. DOS was originally written to > site "on top" of the BIOS, and the BIOS sat directly "on top" of the > hardware. In DOS you could bypass the BIOS and go directly to the hardware > if you wanted, but it was usually better to go through the BIOS (at least if > the BIOS did what you wanted it to do). The way modern hardware works, > that's not really possible any more. Now, the "BIOS" is simply an > "abstraction layer" in the OS itself. To virtualize a BIOS for DOS to use, > the OS must inject a new "translation layer" between the real hardware and > the BIOS that DOS needs to virtualize the old types of hardware (I/O ports) > that no longer exist. The way this is done on modern machines is to > completely "encircle" DOS in a Virtual Machine rather than simply providing a > "translation layer" between the BIOS and the hardware. > > For awhile, the UEFI manufacturers provided a CSM (Compatibility Support > Module) as the "translation layer" so you didn't need a VM. But they've even > stopped doing that nowadays. So, we'll either need to come up with a > "generic CSM" that doesn't need a VM but still provides the needed level of > hardware support both now and in the future, or we'll need to do some kind of > "thin VM" as Jerome is suggesting. I think the second option has a better > chance of long-term viability even though I would prefer the first. > > I also think the second would be something that might be more interesting to > Google aficionados but it is FAR from trivial. > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
