DOS ain't dead

In case you missed it, DOS Subsystem for Linux [0][1] was announced on HackerNews.  Think of it something like WINE, or, something like DPMILD32/HXRT/HXGUI Japeth's HX DOS Extender, but for Linux on top of DOS.  A couple interesting things to note: 1) It needs to run w/o XMS [2], 2) It seems to actually boot Linux's bzImage kernel image [3].

I think DINE (DINE Is Not an Emulator), LID (Linux in DOS) might have been more descriptive names for the project.  Reminiscent of the old UMSDOS Linux Distros but maybe not full fledged boot into Linux.  Interesting nonetheless.

[0] https://news.ycombinator.com/item?id=24555689
[1] https://github.com/charliesome/doslinux
[2] https://github.com/charliesome/doslinux/blob/master/doslinux.asm#L5-L15
[3] https://github.com/charliesome/doslinux/blob/master/doslinux.asm#L45-L220

Oh....and it runs in UnReal Mode?!?! [0][1] Super interesting.


[0] https://github.com/charliesome/doslinux/blob/master/doslinux.asm#L239-L247
[1] https://en.wikipedia.org/wiki/Unreal_mode

How should it work? You say it's booting linux kernel so isn't it just yet another linux loader for dos (like loadlin, linld)? Does it use DosEmu? Or it use some magic trick to boot linux on background, then switch back to DOS and in case of running linux binary it switched to linux again? It may have a sense as you say it doesn't work with XMS - so it use only low memory for DOS while linux use mostly the memory above 1MB so they may live together and swapping between. No time to play with it now...

---
DOS gives me freedom to unlimited HW access.

> How should it work? You say it's booting linux kernel so isn't it just yet
> another linux loader for dos (like loadlin, linld)? Does it use DosEmu? Or
> it use some magic trick to boot linux on background, then switch back to
> DOS and in case of running linux binary it switched to linux again? It may
> have a sense as you say it doesn't work with XMS - so it use only low
> memory for DOS while linux use mostly the memory above 1MB so they may live
> together and swapping between. No time to play with it now...

It seems like it is the functional part of a VM executor. Enough to create a new context, boot/switch to Linux, run a binary, and then have Linux return to DOS in VM86 mode, per the author [0]. So yes, you assumption about the architecture seems to be right.

Sounds VERY interesting, but I see only the source is available, no compiled binaries. I am a little confused as to just what kernel version of Linux loads, and how big the binaries are supposed to be. I suppose one could choose just how robust the .iso image is, but my goal would be get it as small as possible, so as to load very quickly.

I'm also wondering to what interesting tasks this could be put. I've often thought of using video card RAM as a RAMDRIVE, which Linux does allow, as I understand it. That might be a great idea, swap in and out of Linux for a 2 or 4 GB ramdrive, courtesy of your modern video card with fast VRAM. Are there any other ideas for Linux-specific applications which have not been ported to DOS, and / or will run better in Linux commandline? I'm thinking modern soundcard support is better in Linux, but this is probably well beyond the scope of what this program is supposed to do. How about the latest Mplayer and / or FFmpeg Linux ports?

Has anyone built this, and can share the binaries?

> Sounds VERY interesting, but I see only the source is available, no
> compiled binaries. I am a little confused as to just what kernel version of
> Linux loads, and how big the binaries are supposed to be. I suppose one
> could choose just how robust the .iso image is, but my goal would be get it
> as small as possible, so as to load very quickly.
>
> I'm also wondering to what interesting tasks this could be put. I've often
> thought of using video card RAM as a RAMDRIVE, which Linux does allow, as I
> understand it. That might be a great idea, swap in and out of Linux for a 2
> or 4 GB ramdrive, courtesy of your modern video card with fast VRAM. Are
> there any other ideas for Linux-specific applications which have not been
> ported to DOS, and / or will run better in Linux commandline? I'm thinking
> modern soundcard support is better in Linux, but this is probably well
> beyond the scope of what this program is supposed to do. How about the
> latest Mplayer and / or FFmpeg Linux ports?
>
> Has anyone built this, and can share the binaries?

I think the intent is to have a modern version of nasm [0], to build a custom
kernel for the bzImage, a custom busybox, and a build of i386-gcc & i386-binutils. See the Makefile.

Yes, I readed the author post...

But such DOS system is quite limited to realmode-only programs that must also behave nicely to the hardware to not destroy the linux in backgroud or they have HW restricted access by VM. So i think it's less usable than having a linux with running DosEmu that can also run p-mode dos programs + e.g. the SB emulation. I can imagine that DosEmu could be patched so you could call linux commands from dos prompt and would be passed to running linux. But he turned it upside down where I see more drawbacks than advantages. He also wrote there that he may include DPMI support so it could be then possible to run some p-mode programs in dos. But it will be still limited compared to normal dos (with ability of XMS and extenders). Maybe if he run the linux on 2nd core, maybe with aid of VT-x it could have better separation and robustness...

---
DOS gives me freedom to unlimited HW access.

> Yes, I readed the author post...
>
> But such DOS system is quite limited to realmode-only programs that must
> also behave nicely to the hardware to not destroy the linux in backgroud or
> they have HW restricted access by VM. So i think it's less usable than
> having a linux with running DosEmu that can also run p-mode dos programs +
> e.g. the SB emulation. I can imagine that DosEmu could be patched so you
> could call linux commands from dos prompt and would be passed to running
> linux. But he turned it upside down where I see more drawbacks than
> advantages. He also wrote there that he may include DPMI support so it
> could be then possible to run some p-mode programs in dos. But it will be
> still limited compared to normal dos (with ability of XMS and extenders).
> Maybe if he run the linux on 2nd core, maybe with aid of VT-x it could have
> better separation and robustness...

Maybe there's more drawbacks. Good VM separation would be fun.

I put in some work to build doslinux. It wasn't so hard. I think I could find some uses for this for my old 32-bit CPUs given some network drivers.

Well thanks for testing and making binaries but I cannot download them, you probaly didn't set the public flag on your Gdrive. But still see no advantage of this over booting linux with dosemu, I see it just as a technical curiosity...

---
DOS gives me freedom to unlimited HW access.

> Well thanks for testing and making binaries but I cannot download them, you
> probaly didn't set the public flag on your Gdrive. But still see no
> advantage of this over booting linux with dosemu, I see it just as a
> technical curiosity...


Hopefully I just fixed that.

Yes, DL worx now

---
DOS gives me freedom to unlimited HW access.

Unfortunatelly after some ACPI errors cannot mount ramfs :(

http://www.rayer.g6.cz/1tmp/dsl.jpg

---
DOS gives me freedom to unlimited HW access.

> Unfortunatelly after some ACPI errors cannot mount ramfs :(
>
> http://www.rayer.g6.cz/1tmp/dsl.jpg

Interesting. What hardware? Are you booting from an IDE or SATA HDD? I had somewhat similar kernel panic when booting off FD 1.2 Full USB drive.

> > Well thanks for testing and making binaries but I cannot download them,
> you
> > probaly didn't set the public flag on your Gdrive. But still see no
> > advantage of this over booting linux with dosemu, I see it just as a
> > technical curiosity...
>
> y> Hopefully I just fixed that.

I also tried your binaries (thanks for compiling) and could not boot. It couldn't mount ACPI drivers either, like in RayeR's case, and I got kernel panic after a few seconds, with keyboard LEDS still going crazy (blinking). Nothing but a hard reboot would get the system functional again. My hardware, which was detected by the Linux loader was Lenovo G50-80 laptop, and I was running dos in real mode, booted from a USB memory stick (in FAT32), native AHCI mode. Perhaps I should try another system, where DOS is loaded directly onto a SATA hard drive (in AHCI mode). Also will it help to try again from a SATA drive, in IDE emulation mode?

It's my main core i7-2600k machine. I put the DSL on sata disk 0 - IDE emulation as primary master, FAT16 formatted partition C: along my DOS. I will check what device name is used in my debian linux for this disk but it might changed as kernel drivers changed. I saw that dsl.com contains some hardcoded paths and parameter, it' not good idea, better to have a separate config file. Now I just tried to boot it on my compaq notebook with standard ide hdd C: and it rebooted my system immediatelly so I couldn't read any error mesage if there was any. To start dsl I just booted to bare msdos 6.22 without config cd to dsllinux and run dsl.com

---
DOS gives me freedom to unlimited HW access.

[SNIP]
RayeR wrote:
> might changed as kernel drivers changed. I saw that dsl.com contains some
> hardcoded paths and parameter, it' not good idea, better to have a separate
> config file. Now I just tried to boot it on my compaq notebook with
> standard ide hdd C: and it rebooted my system immediatelly so I couldn't
> read any error mesage if there was any. To start dsl I just booted to bare
> msdos 6.22 without config cd to dsllinux and run dsl.com

I agree. There are things to improve for sure. I've started compiling a list in the original repo's Issues. Some are simple changes, some are not.

Zyzzle wrote:
> I also tried your binaries (thanks for compiling) and could not boot. It
> couldn't mount ACPI drivers either, like in RayeR's case, and I got kernel
> panic after a few seconds, with keyboard LEDS still going crazy (blinking).
> Nothing but a hard reboot would get the system functional again. My
> hardware, which was detected by the Linux loader was Lenovo G50-80 laptop,
> and I was running dos in real mode, booted from a USB memory stick (in
> FAT32), native AHCI mode. Perhaps I should try another system, where DOS is
> loaded directly onto a SATA hard drive (in AHCI mode). Also will it help to
> try again from a SATA drive, in IDE emulation mode?

Interesting. I've only tested on my 32-bit Intel Atom N280. The i7-2600K and the i5-5200U (not sure what is in RayeR's Compaq) are 64-bit capable chips. Maybe that is the difference? I could pull out a Core i5-4690 and burn a CD for an Athlon64 3000+ I have. I think I have a Pentium Gxx too that would be easier to USB boot. Hmm. I suppose recompiling with so that dsl.com doesn't boot the Linux kernel in `quiet` mode would help debugging.

I very doubt that CPU 64-bit support matters. My NTB have Pentium-M Dothan (no 64bit). My debian (kernel 4.3) boots from standard device /dev/sda (sata 0). What kernel version is used in DSL? Enabling some debug messages could tell us more...

---
DOS gives me freedom to unlimited HW access.

> I very doubt that CPU 64-bit support matters. My NTB have Pentium-M Dothan
> (no 64bit). My debian (kernel 4.3) boots from standard device /dev/sda
> (sata 0). What kernel version is used in DSL? Enabling some debug messages
> could tell us more...

Kernel is fairly recent, 5.8.9.

OK, but maybe it's stripped of important components/modules/drivers to make the image small...

---
DOS gives me freedom to unlimited HW access.

> OK, but maybe it's stripped of important components/modules/drivers to make
> the image small...

I've been rebuilding & rebuilding the doslinux kernel over and over today. ATA subsystem was turned off (makes sense since it's deprecated). Much of PATA and SATA subsystem was turned off too. Statically building the kernel now makes it way about 18MB (3x bigger), compressed. I haven't tried it on my HW yet but I'm trying to get to a point where a lot more network cards, video card framebuffers, and sound cards are built-in, plus some other niceties like NFS, EXT2/3/4, NTFS, parallel, serial, PS/2 and USB ports supported, SMP, PII.

> > OK, but maybe it's stripped of important components/modules/drivers to
> make
> > the image small...
>
> I've been rebuilding & rebuilding the doslinux kernel over and over today.
> ATA subsystem was turned off (makes sense since it's deprecated). Much of
> PATA and SATA subsystem was turned off too. Statically building the kernel
> now makes it way about 18MB (3x bigger), compressed. I haven't tried it on
> my HW yet but I'm trying to get to a point where a lot more network cards,
> video card framebuffers, and sound cards are built-in, plus some other
> niceties like NFS, EXT2/3/4, NTFS, parallel, serial, PS/2 and USB ports
> supported, SMP, PII.

Got a little further. You can find the progress here until I'm able to write it up. I've removed some of the drivers I originally added and `/dev` is nearly empty. Lots of devices need to be added to make it more usable.

In my case I saw a quick waterfall of kernel messages but stopped very soon (cca 0.6s) on found 11 ACPI functions and then frozen...

---
DOS gives me freedom to unlimited HW access.

> In my case I saw a quick waterfall of kernel messages but stopped very soon
> (cca 0.6s) on found 11 ACPI functions and then frozen...

I got much further than in older version. It booted quite a long time 8.06 seconds, and I saw the four penguin at the top of the screen along with many scrolled messages. Finally, after 8.06 seconds elapsed, I got a total freeze and a Kernel panic: "VPS: unable to mount filesystem fs (8,1)"

This is on the same i5-5200 Lenovo laptop with nothing changed from the above.

I tried adain and here's my kernel error message:
http://www.rayer.g6.cz/1tmp/dsl.jpg

---
DOS gives me freedom to unlimited HW access.

Don't know if there is any interest in testing this further. I made a cleaner Makefile for Fedora & Ubuntu, fix compilation & ensured things are actually built with a cross-compiler, documented dependencies and produced a simpler to install on real hardware, 6.5MB zip file. I have ideas on what this could be used for but getting a clean shell with C:\DOSLINUX\dsl sh is a good place to check what I have for now.

https://github.com/lpsantil/doslinux/releases/tag/20230930
https://github.com/lpsantil/doslinux/releases/download/20230930/DSL002B.ZIP