Hi Jim, everybody,
> I get a lot of the emails you described. People email me to ask why > FreeDOS doesn't run on their Raspberry Pi like Linux does .. or why > FreeDOS can't take advantage of multiple CPUs and cores like Linux > does .. or why FreeDOS can't run on their UEFI-only system (no > "Legacy" mode) like Windows can .. or why FreeDOS doesn't have a > default GUI like Windows .. or the one [...] from the Facebook > group asking how to run an Apache/MySQL/PHP stack on [...] FreeDOS Actually I have been some of this as part of a long discussion with Stas this week. As you may know, support for BIOS and even for VGA and VESA VBE seems to have declined significantly 2020. And for various reasons, Stas has spent a lot of work to pull most of the FreeDOS kernel over into the protected mode space in context of dosemu2. That module is now called fdpp. It lacks the init-text and the hma-text part runs on the Linux side, with dosemu-specific connectors residing on the DOS side. This makes it somewhat convoluted to "package" the heavily updated fdpp kernel back into a classic "kernel.sys loaded by a boot sector" infrastructure again and of course some things are now optimized for protected mode. So it can be frustrating that many updates for the kernel have ended up somewhat out of reach, backporting them would require tedious cherry picking. But exactly that would allow an interesting scenario: You may remember that VMware has their ESXi "operating system", actually hypervisor, which boots on raw hardware and lets you start and manage instances of VMware virtual machines. Now imagine that you have a minimal protected mode "operating system" which boots on UEFI hardware and loads one task which simulates a BIOS, similar to what normal CSM for UEFI do. It also loads other tasks which simulate VGA hardware with the appropriate BIOS and VESA VBE, or a Sound Blaster 16 hardware with yet another task pipelining the audio to some HDA driver. The next task runs the fdpp kernel and yet another opens some vm8086 task where all of the other stuff is used to create a virtual environment where you can pretend that you are running the normal rest of your FreeDOS installation on hardware while in fact having just the right amount of virtualization layers between you and the hardware :-) This might be more feasible than it sounds (Stas had been told that pulling the kernel into Linux space would be impossible as well - it took a LOT of work, but it worked) and might be yet another interesting idea for future hardware use along the lines of for example: - https://github.com/Baron-von-Riedesel Japheth's 64-bit HIMEM (also his JLM system for drivers in protected mode realm) - http://ndn.muxe.com/download/ Necromancer's DOS Navigator, which has a 64-bit DPMI edition - some libraries and proof of concept things for multi-core or multi-threading inside DOS applications - https://dosbox-x.com/ which includes a version which lets you run DOSBOX inside DOS with Japheth's HX RT extender, so you can run DOS inside DOS and get emulated hardware - http://mpxplay.sourceforge.net/ which plays audio and video even in DOS and even with modern sound hardware and network - VSB https://www.dosforum.de/viewtopic.php?t=1188 (which I have mirrored, too) is an ancient Sound Blaster 1 simulation with I/O trapping to pipeline sound to Covox printer port D/A either by MS EMM386 I/O trap API or creates vm86 task itself - https://cmaiolino.wordpress.com/dosbian/ which boots a minimal Linux to open Dosbox so you can use DOS on Raspberry Pi and other ARM-based hardware which is not DOS compatible at all So I think tricks and modules which connect the DOS world to new hardware and firmware worlds and help DOS apps to use the abilities of hardware which has not existed in MS DOS times are something which are getting increasingly interesting. For people with REALLY old hardware (before 386) it is great that our classic kernel can be compiled for 8086 and I would like to remind everybody that FreeCOM command.com has a KSSF special helper version to save RAM on 8086 where no XMS is available for the XMS SWAP which is the "default" for us in spite of not working on 8086. That makes the default FreeCOM binary a memory hog until you load some HIMEM. But even for something as "humble" as a Live CD which needs at least a 486 to boot (simply because older BIOS rarely is able to boot from CD, although you can use a loader floppy) we COULD actually decide to be a lot more modern regarding system requirements. And if a protected mode kernel can be part of a FreeDOS CD which boots from UEFI-only hardware? Well, why not. The thing is that writing some hypervisor is going to require serious experts. Not available? Then how about making a clone of DOSBIAN, but for, say, PC compatible computers with at least a Pentium and maybe 32 MB RAM? That would still be totally FreeDOS related :-) In spite of always keeping support for ALL reasonably IBM PC compatible hardware available, it is good to keep watching the adventurous people who are tinkering with novel ways to use novel hardware for all things DOS. And be ready to give them some momentum at the right time. Right now, my Linux PC has no problems to first boot a heavy Linux and then open dosemu2. But right now, DOSBIAN also exists and makes ARM users happy. Right now, I have no idea why I would use DPMI64 or 64 GB XMS, but years ago somebody on the mailing list has mentioned how they were using 2 or 3 GB of RAM for their DOS checkers game. Who knows what will happen :-) Already now, we can for example recommend Linux GPARTED for people who need a DOS partition. It does not make their DOS less DOS to have used Linux a bit. DOS is not an island and interesting things happen next door :-) Cheers, Eric _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
