Well, no... WSL runs Linux inside Windows. DSL runs Linux inside DOS. So there's no stacking that makes sense here.
(I think we're seeing just how confusing the "Subsystem for Linux" naming is. "Foo Subsystem for Linux" sounds like a way to run Foo under Linux, but it's the opposite...)
There was a video where someone was running a firefox browser inside another browser using wasm. It was presented as a wacky "future history" talk... I can't find it in my watch history
So does this run DOS on Windows? Or DOS on Linux? Or Linux on DOS? Or DOS on Linux on Windows? Would be nice if there were an explanation in the README.
Author here. I am planning to do an in depth write up of how this works, but it seems Hacker News found it sooner :)
When DSL is first invoked at the command line it boots up the Linux kernel which takes over control of the computer from DOS.
Now here’s the trick: DSL makes use of a processor feature called VM8086 which allows for a 32 bit operating system to run legacy 16 bit code mostly natively. This feature is how early Windows, DOS extenders, etc worked. The Linux kernel also supports VM86, although it is largely undocumented and not really used these days. I think dosemu is the only major user of VM86 on Linux.
DSL then returns to DOS, which has essentially been flipped inside out and is now unknowingly running inside a VM8086 task. Helpfully Linux does not appear to clobber DOS’s memory during its own boot process.
DSL does just enough emulation of hardware like the keyboard to make things work, allowing DOS raw hardware access for everything else. This situation of running two operating systems at the same time on the same hardware is extremely fragile and unsafe of course, but it does seem to work surprisingly well anyway!
> Helpfully Linux does not appear to clobber DOS’s memory during its own boot process.
Is that just a coincidence or intentional somehow?
I guess DOS can only access the first 1MB (err... plus 65520 HMA bytes?), so if Linux just avoids using that space then DOS can keep running happily... I was curious if there's actually a mechanism to tell Linux to avoid that space.
DOS memory management fascinates me in its absurdity.
With HIMEM.SYS + EMM386.EXE [0][1], you could include or exclude certain memory segments. But, DOS Subsystem for Linux uses non-standard little documented Unreal Mode [2][3] instead of traditional DOS Memory Management.
Have you tried the approach of booting Linux and then creating a normal fullscreen qemu/KVM-based VM initialized with the memory state of the DOS OS, with a configuration so that the transition works correctly?
That would make the whole system fully robust and safe, and also support running XMS/EMS managers, DOS extenders, Windows and other bootloaders from the DOS VM.
I'm not sure however whether you would need to modify qemu to make it work and how hard that would be (also I guess that would have less hacky fun factor).
After not finding much of a README (yet), I poked around the source code a few minutes ago. Thanks for my actually confirming my initial "...he can't be doing it that way, surely..." :)
This is nice. It reminds me of the IPL sequence of some mainframe OS I sadly can't remember right now (might be System/i?) where the bootloader that launched the kernel was a first-class OS process that went from running the entire system to being promoted to an OS task as the kernel started up. Except in this case you're promoting the entire
OS to a kernel task, while the promoted OS continues to run :D
I wonder if you could extend this to turn Linux into a replacement for HIMEM.SYS, to "properly" support the fact that HIMEM has to be disabled. :D
(Immediately after reading that I thought "wait; the two OSes are running independently, of course that won't work..." but then I realized, no, HIMEM works by trapping interrupts... so this is not only possible, but vm86 of course works by handing you interrupts to deal with.)
The extremely-confusing-but-still-positive benefit of this would be to allow you to elevate DOS to have demand-paged virtual memory, complete with swapfile.
It might be interesting to identify the oldest kernel version(s) you're prepared to put up with, to realize the smallest _in-memory_ kernel size possible, and _possibly_ enable running multi-MB applications on real systems with only 640KB of RAM (with the proviso that using an SSD via a SATA-IDE adapter would give the best results - and the rationale that both of those items will soon be cheaper than old DIMMs). The issue suggesting 2.4 is maybe a bit of a stretch, but the early 2.6 trees might be interesting.
Implementing my own extended memory support in the supervisor is indeed an interesting idea, I might try it out :)
Another idea I had after reading the dosemu source is implementing a DPMI server to allow protected mode DOS apps to run. It might even be possible to run an early version of Windows this way too.
It would be cool to do the same using KVM. You can use a magic I/O port instead of an interrupt as the upcall mechanism, on the other hand trapping interrupts has to be done from the DOS side...
- it first, if not yet present, starts Linux, via normal Linux kernel load. It passes over some pointers from DOS into /init arguments so that /init can know about DOS' context when Linux was first loaded
- Linux's /init then uses VM86 [1] to call back into DOS, back to the function that was run in DOS before Linux was loaded (vm86_return). This is a bit of a 'draw the rest of the fucking owl' deal, as it has to actually emulate a lot of DOS/PC behaviour (emulate INB/OUTB, etc). It's basically a small VM, like with KVM, but for 16-bit DOS.
- when DOS wants to run a Linux command, it now uses a special new interrupt (DOSLINUX_INT) to call into the kernel. This in turn triggers a VM86 exit, jumps into the VM86 monitor in /init, executes the command, and pokes the result back into DOS, resuming VM86 emulation.
The GIF's prety much crystal clear: it runs QEMU on Linux. And QEMU runs whatever you want, because it's a machine emulator/virtualiser, in this case it's running as x86 with MS DOS on top.
No.... QEMU is being used to run DOS, since a) who runs DOS on metal these days, and b) how would you record the screen if you were running DOS on metal (I suppose you could use a capture card). Linux is running in a WSL-like environment on the DOS host.
No, qemu is only there to boot DOS. DOS then runs Linux commands via `dsl` (DOS Subsystem for Linux).
You could perhaps argue "inception" since it's Linux running a DOS VM running Linux commands. But the charitable explanation is the author just wanted a convenient environment to do DOS development rather than bare metal (think of it like a Vagrant box).
No, the interesting part is what's happening in DOS. QEMU was probably just used for screenshots and not going through the pain of installing DOS on a new machine.
It is literally DOS, so it executes real mode binaries natively.
Okay, actually, this is more like VMWare ESX in the 4.0 days. It's kind of, uh, inside out.
Basically it's DOS, which launches Linux via DSL, which then runs a task out of init in vm86 mode that uses KVM to _continue_ the DOS that launched it as if it were the only thing running.
The DOS doesn't know anything has happened, even though the rug has been pulled out from under it, and it is now running in a KVM VM guest. You just can't tell anything is different because all the BIOS/real mode stuff is unchanged.
You get your prompt back when a native Linux binary finishes but it's the linux kernel emulating the DOS session after that first command, until you reboot.
If I recall correctly, there was at one time a Linux boot loader that ran from DOS, which could make use of DOS device drivers. I recall using Yggdrasil Linux which had an option to boot this way, which used the DOS driver for my SCSI card and CDROM drive to make it available under Linux.
That was LOADLIN. When coupled with a Linux filesystem called umsdos, it allowed you to boot Linux without repartitioning your disk or clobbering your MBR. Fun times.
Umsdos overlaid a POSIX file system on top of an MS-DOS file system, using a scheme somewhat similar to Windows long filenames (but created before that became a feature of Windows). Basically, every directory would have a magic file called --LINUX-.--- that contained POSIX file data, including full filenames and permissions.
Brings back old memories. My first Linux experience was with PhatLinux and WinLinux2000. We only had one family computer and I didn't want to risk nuking the disk, which I now know would have inevitably happened.
I used to use that when I had a sound card that was not supported in Linux. I would load the drivers from DOS which provided Sound Blaster compatibility, then boot Linux from there.
Hey, could you please stop posting unsubstantive comments to HN? It's not what this site is for, so we ban accounts that do it, and eventually the main account as well.
EDIT: I stand corrected. A closer look at TFA confirmed that it is indeed DSL. I was confused by the screenshot which at first glance just shows DOS running in QEMU on Linux. But it goes deeper!
Yes, that is correct. Windows Subsystem for Linux means it's one of Windows' subsystems which provides linux.
Misunderstandings aside (I am fully up to speed on that), why do this and WSL each use "for" to mean "provides"? In most software contexts, the noun after the word "for" is the thing you already had, like "Word for Windows" et al.
I assume this uses it purely to make fun of Windows.
Windows has the concept of subsystems - technically the Win32 API is also just a subsystem around the NT kernel that provides the "Windows API". Windows NT also had one providing an OS/2 API, and one providing POSIX API - the latter later evolved into/was replaced by "Windows Services for UNIX" - assume there and with WSL the intent is to read it as "for Linux/UNIX applications".
But why specifically this confusion phrasing is unclear, maybe they wanted to keep the "Windows" brand attached to the thing - i.e. treat "Windows Subsystem" and "Windows Services" as one term?
This should come preinstalled on literally any and all Linux flavours. It would remove so many barriers for folks first trying Linux after decades of Windows.
I feel like for most Windows users, using DOS is probably as (or even more) foreign as using Linux. How many times do you think the average Windows user has used a command prompt in the past year?
Counter question: how many times do you think the average Windows user has tried installing Linux? Because it's probably fewer than those who use what they'll invariable call the "dos box" for something, so having something in place to make the transition for those Windows users who DO venture out of their comfort zone to give Linux (yet another?) try easier is great.
There are a ton of comments here that seem to be misunderstanding what this software is. This creates a WSL-like environment on a DOS host system. It does not create a DOS environment on a Linux host. I'm not sure where this misunderstanding even comes from; the name is perfectly analogous to WSL.
Indeed, this confused me as a Linux user who hasn't used Windows in over a decade (and therefore is unfamiliar with the terminology). Thank you. I was reading this as a potential DOS Box alternative to run on Fedora.
If the project maintainer is reading, it would be super helpful to put that at the top of your REMADME.md. I'll even send you a PR. FTR it's not your fault the terminology is confusing :-)
I know what it means and what way round it is now due to repetition, but WSL struck me as a weird name and confused me at first.
Usually, saying "for Linux" or "for Windows" about something means there's a thing that is for (or "to run on") Linux or Windows, not that the thing is "of" Linux or to enable the use of Linux. I appreciate there are two ways to look at the semantics, but the one they picked for WSL seems the least common one to me.
I would imagine it's because WSL is a terribly confusing name itself for a lot of people.
There are two ways to read "Windows Subsystem for Linux":
1. This is a subsystem that runs on Windows that enables Linux binaries.
2. This is a subsystem that runs on Linux that enables Windows binaries.
The confusion comes in the fact that when I write those two sentences, I naturally want to write "This is a subsystem FOR Windows..." or "This is a subsystem FOR Linux... ." I had to consciously avoid using "for" in that sentence to highlight the problem.
So when someone who doesn't know what the thing does reads "Windows Subsystem for Linux" they may walk away with the false impression that the subsystem allows Windows binaries to run on Linux. Likewise, what you're seeing now is that people are seeing "DOS Subsystem for Linux" and thinking that this enables you run DOS on Linux.
The WSL terminology really only makes sense if you are aware that Windows has the concept of subsystems - and which is why swapping other labels makes even less sense. I.e. the run-Windows-on-Linux thing would probably not be called Linux Subsystem for Windows, because what is a "Linux Subsystem"?
And of course WSL2 isn't a subsystem anymore, but is stuck with the product name. ¯\_(ツ)_/¯
A "Linux subsystem" is a Linux system that is a part of a bigger system. And "Linux audio subsystem" is an audio system that is a part of Linux. And if you swap the words, you get "audio Linux subsystem" which doesn't make sense, not really.
So the proper name would be "Windows Linux subsystem", but I concede that it does sound really weird (because both Windows and Linux are the same kind of things, they're OSes).
And of course, if it was named "Windows's Subsystem for Linux", there would be much less confusion, but apparently the English for some reason doesn't use the possessive case here (although that's the perfect place for it) and prefer to use the noun as a possessive adjective.
This is helpful, but the composition rules are weird and confusing.
It's true that a Linux Subsystem is a subsystem of Linux, but an "X for Linux" is a component of Linux or an application for Linux.
When you put them together, it seems that the "for" wins the battle. In parsing terminology, it has lower precedence (though I'm sure the actual rules of English are more complex than that indicates).
I'd love to see an actual linguist comment on why this phrase is so confusing.
I have an English degree and can confidently say the issue is the implicit understood possessive in the correct parsing. As it stands, “for” dominates mentally because the phrase obviously needs a possessive to make sense and “for” denotes possession. If it were “Window’s Subsystem for Linux” or “DOS’s Subsystem for Linux”, explicating the proper possession, the parsing trouble would disappear.
And if you think "Windows Subsystem for Linux" is bad, the subsystem that enables the Win32 API is csrss or "Client/Server Runtime Subsystem" and it makes you think: why does that subsystem not mention Windows but the Linux one does?
> And of course WSL2 isn't a subsystem anymore, but is stuck with the product name
Even WSL1 is not a classic Windows NT subsystem. Its implementation (picoprocesses) is quite different from that of the classic Windows NT subsystems (Win32, OS/2, POSIX/Interix/SFU/SUA). The classic Windows NT subsystems all involve using ntdll.dll to make NT syscalls; WSL1 processes make Linux syscalls and can't actually make NT syscalls or call ntdll. There is nothing technically stopping an OS/2 1.x executable from realising that it is running on NT and start talking to the NT kernel using the normal NT API; by contrast, a Linux executable running under WSL1, even if it detects it is running under WSL1, isn't allowed to talk to the normal NT kernel interfaces.
Windows NT user mode code is divided into programs and subsystems.[1][2] Programs are the actual applications/utilities/etc you run. Subsystems are OS components executing in user mode, generally composed of DLLs and server EXEs which expose LPC services (a little bit like Unix daemons).
There are two types of subsystems – environment subsystems (which provide APIs to programs) and integral subsystems which provide services to the environment subsystems. Integral subsystems include the security subsystem (lsass.exe). (Sources are a bit unclear about whether there is one "integral subsystem" composed of multiple parts, or multiple integral subsystems – e.g. are lsass.exe and smss.exe separate integral subsystems, or two subsystems of the integral subsystem???)
There are three environment subsystems in Windows NT – Win32, POSIX and OS/2, although the latter two have been discontinued in newer versions. The design was always open to adding more (e.g. maybe an OpenVMS subsystem) but that never happened in practice. (Win32, despite its name, doesn't just run Win32, it also runs Win16 and DOS; also, in practice the POSIX and OS/2 subsystems were dependent on the Win32 subsystem and borrowed functionality from it, despite in theory being independent of it. csrss.exe, despite having "subsystem" in its name, is not a separate subsystem, but rather the primary LPC server for the Win32 environment subsystem.)
The term "personality" is sometimes used to describe the environment subsystems, but it is not the term the Windows NT developers used. The term "personality" actually comes from Mach. The idea with Mach was that existing operating systems could be ported to run on top of the Mach microkernel through layers called "personalities" which would map the existing OS API to the underlying Mach API. The original CMU Mach team built such a layer for BSD Unix – the BSD personality – and it actually survives in XNU (macOS/iOS/etc), but they never implemented any other personalities. However, IBM's abortive Workplace OS project actually did implement an OS/2 personality for Mach, which could run alongside an AIX personality, so they actually got closer to delivering on CMU's original vision (albeit the whole project was cancelled before being fully released.) Possibly, NT's environment subsystem idea took some influence from the Mach personality concept; plus, outside observers quickly noticed the similarity between NT environment subsystems and Mach personalities, and started using the term "personality" for the former; but it has never been the officially preferred terminology for Windows.
I've never heard anyone call WSL1 an "environment subsystem". Its method of implementation is very different from the classic NT environment subsystems. You might call WSL1 or WSL2 "personalities", but as I said that's never been official Windows terminology.
It still doesn't even make sense when you know about Windows subsystems though. True, it is a "Windows subsystem" in Windows terminology, but from my native-English speaker point of view, it's not "for" Linux in the way that the word "for" is used in standard English.
It does work if you assume it's a shortening of something like "Windows Subsystem for Running Linux Applications (on Windows)"
But I get that naming it is a tricky problem, because even a technically accurate name like "Windows Linux Subsystem" (after the old 'Microsoft POSIX Subsystem' name) is still confusing.
It's really confusing. Windows Linux Subsystem would be more clear. Windows Subsystem for Linux always hinted me to a Vine competitor. Then I know what it is so I read this DOS Subsystem for Linux in the right way (and right to left!)
I saw a discussion that it was mostly concerns about the Linux trademark when WSL1 didn't actually use a Linux Kernel with the leading part of the name/term.
WSL1 emulated Linux kernel syscalls. GNU was run on top of it unmodified, but could be used without GNU.
on WSL2 the actual kernel is what is being run, in a thin VM wrapped by lots of wrappers to provide a native-like experience.
Yep - the sentence "X subsystem for Y" reads to me like you're adding an X thing to your Y - i.e. you're adding some Windows thing to your Linux, but what Microsoft means by it is the other way around.
My understanding, especially with WSL1, was that there was a concern about the Linux trademark if MS used the name "Linux Subsystem for Windows" which would have been a better name, since WSL1 didn't actually use a Linux kernel. WSL2 does though.
"Windows' Linux Subsystem" might have been better as well (WLS), using it as a posessive statement, or "Windows' Subsystem of/with Linux" which would keep the same WSL abbreviation.
Grammatically, I read the title and thought "yes! finally a way to run those Dell firmware updaters instead of using FreeDOS boot sticks" and then read the comments to find out it's backwards in nature. The phrase is "bad English" in a colloquial sense.
The suffix "for Linux" strongly implies it's software for use on Linux. It's like the "4j" and "4win" suffixes, implying software built for the Java and Windows environments, respectively.
What's more, Windows or DOS as an adjective of subsystem bind more tightly than "for Linux". So if you were to start dropping parts of the name, you'd drop "for Linux" first. Except you can't, because then it's just the Windows Subsystem.
LSW would have been a much more natural name. In a conversation about Windows subsystems, you could refer to it as the Linux Subsystem. If other operating systems picked up on the idea, they would have their own Linux subsystems, e.g. Linux Subsystem for macOS. If you wanted to check if your OS had anything like it, you could search "is there a Linux subsystem for FreeBSD?" Which might turn up results about the Linux ABI in FreeBSD. Speaking of which, imagine if it had been named the FreeBSD ABI for Linux. What an awful pattern! You can't even repeat the pattern unless both modifiers are proper nouns! Could you have called the VFS Subsystem the "FreeBSD Subsystem for VFS"?
Something that should come up early in sentence diagramming but often isn't explained well enough is that sentence diagrams aren't context free, often can be ambiguous, and depend on the context of the speaker to determine referents. Sentence diagrams in the real world are rarely as easy as elementary school examples.
In this case, the context known to the speaker but often missed when trying to "sentence diagram" WSL involves the part "Windows Subsystem". That referent, to which the original author was quite familiar, is invoked in WSL as a single noun in part of the larger noun phrase, and while you could continue to sentence diagram break "Windows Subsystem" into constituent parts here, it is important to remember it as a single connected "atom" to which "for Linux" modifies in the overall noun phrase of "(Windows Subsystem) for Linux". Given that context/referent, the sentence diagram here is unambiguous to the original team/"speaker". It's the audience with much less familiarity with the referent/context in question that has ambiguity problems in trying to "sentence diagram" the noun phrase.
It follows the same naming convention as SFU (Windows Subsystem for Unix) [1] which was equally confusing.
My belief (!!), back then, was that it was intentionally named confusing. Back when it came around, Microsoft was under scrutiny for monopoly behavior. They didn't want Windows to be compatible with Unix in any way; they wanted the world to run Windows (9x, NT) only. That was my belief/theory, as it is now I don't have anything to back it up as it is though. Your theory might equally be viable.
I expect it's branding. I'm having trouble coming up with a name that sounds unambiguous while keeping "Windows" as the first word. And I doubt Microsoft's branding people would be happy if "Linux" appeared in the title before "Windows".
I've been fielding these questions all day. Saying the same thing. It's for "DOS" so you can run _bash_. Ok? People got all excited for Prince of Persia... smh. +1
The poor naming convention goes back ~20 years or so to (at least) "Windows Services for UNIX" (SFU) [0]. The naming was not intuitive then and it still isn't today.
The "problem" is that these products are not what you automatically assume they are!
To illustrate: SFU provided NFS and NIS servers, a cron daemon, a telnet server, and various CLI "utilities" (i.e., standard "services" provided by "UNIX") running on Windows -- not Windows services that run on UNIX!
Once you know that, the "Windows Services for UNIX" name kinda makes sense and helps to understand what the "Windows Subsystem for Linux" and, now, the "DOS Subsystem for Linux" actually are.
It’s because the WSL is confusing and doesn’t follow english naming conventions. “X subsystem for y” reads left to right as X is an adjective describing the subsystem, and for seems to indicate y is the platform that X subsystem is for.
Instead it’s seemingly meant to be parsed inside-out with “subsystem for Linux” as one noun indicating a subsystem that runs Linux apps, and DOS as an adjective describing that noun. Maybe wsl did it to keep the windows brand first? Are there many other “windows subsystems for Y” out there and this is a Microsoft-universe term? I don’t know but it’s very strange.
"WSL" is Windows Subsystem for Linux is obviously from the old Services for Unix used to bait-and-switch people to NT, and the grammar in the latter is irrelevant, the meaning of "SFU" is clear.
This used to be the best way to try Linux before live CDs became a thing. The first Linux distro I ever used (DragonLinux) was 'installed' by unzipping an 8mb zip file and running a BAT file. You could 'uninstall' it by deleting the directory it created next time you booted into DOS.
Slackware had "ZipSlack" which would fit on a 100Mb Zip disk, or could be installed (read: copied) into a DOS directory and run from there: https://en.wikipedia.org/wiki/ZipSlack
Why would someone choose such a stupid name then?
It's "for Linux"... which means you already have Linux, and you want to run DOS in a sub-system (a VM)
DOS Subsystem for Linux means exactly that, you are using a DOS subsystem in Linux. That is why it is confusing. If it is a WSL for DOS, that is what it should be called.
> A WSL alternative for users who prefer an MS-DOS environment.
Very confusing description. Is it made for Linux? So what does it have to do with WSL which is made for Windows? May be it's a Wine analog for running DOS programs on Linux then or it's actually emulating things like DosBox does?
It seems like cropping the QEMU "chrome" from the screenshot would make it clearer that it's a DOS environment, and that the prefix "dsl" allows you to run Linux commands...
A couple comments....this is super interesting to me. It boots into Linux from an HDD image. It also requires and uses Unreal Memory Mode [0][1] (vs. Real Mode or Protected Mode). It makes me wonder how compatible & stable this is with other DOS era software.
181 comments
[ 2.9 ms ] story [ 40.6 ms ] threadOne might almost think we need a Domain-Specific Language to distinguish between all these meanings.
Does it run under WSL?
(I think we're seeing just how confusing the "Subsystem for Linux" naming is. "Foo Subsystem for Linux" sounds like a way to run Foo under Linux, but it's the opposite...)
https://www.destroyallsoftware.com/talks/the-birth-and-death...
at about 13:10.
Indeed.
> a way to run Foo under Linux
"Under" is also confusing since "run X under Y" means the same as "run X on Y" even though it's the opposite analogy.
I suggest everyone stick to "X on Y", e.g. Linux on DOS.
I put inside in quotes because how this actually works is quite amusing (and apparently is actually how Windows 95 also works)
When DSL is first invoked at the command line it boots up the Linux kernel which takes over control of the computer from DOS.
Now here’s the trick: DSL makes use of a processor feature called VM8086 which allows for a 32 bit operating system to run legacy 16 bit code mostly natively. This feature is how early Windows, DOS extenders, etc worked. The Linux kernel also supports VM86, although it is largely undocumented and not really used these days. I think dosemu is the only major user of VM86 on Linux.
DSL then returns to DOS, which has essentially been flipped inside out and is now unknowingly running inside a VM8086 task. Helpfully Linux does not appear to clobber DOS’s memory during its own boot process.
DSL does just enough emulation of hardware like the keyboard to make things work, allowing DOS raw hardware access for everything else. This situation of running two operating systems at the same time on the same hardware is extremely fragile and unsafe of course, but it does seem to work surprisingly well anyway!
Is that just a coincidence or intentional somehow?
I guess DOS can only access the first 1MB (err... plus 65520 HMA bytes?), so if Linux just avoids using that space then DOS can keep running happily... I was curious if there's actually a mechanism to tell Linux to avoid that space.
DOS memory management fascinates me in its absurdity.
[0] http://www.mdgx.com/mem6.htm#6
[1] http://manmrk.net/tutorials/DOS/msdos7/emm386.htm
[2] https://en.m.wikipedia.org/wiki/Unreal_mode
[3] https://github.com/charliesome/doslinux/blob/master/doslinux...
Would be really cool if someone contributed a proper man page, I bet it would be a fascinating read.
That would make the whole system fully robust and safe, and also support running XMS/EMS managers, DOS extenders, Windows and other bootloaders from the DOS VM.
I'm not sure however whether you would need to modify qemu to make it work and how hard that would be (also I guess that would have less hacky fun factor).
This is nice. It reminds me of the IPL sequence of some mainframe OS I sadly can't remember right now (might be System/i?) where the bootloader that launched the kernel was a first-class OS process that went from running the entire system to being promoted to an OS task as the kernel started up. Except in this case you're promoting the entire OS to a kernel task, while the promoted OS continues to run :D
I wonder if you could extend this to turn Linux into a replacement for HIMEM.SYS, to "properly" support the fact that HIMEM has to be disabled. :D
(Immediately after reading that I thought "wait; the two OSes are running independently, of course that won't work..." but then I realized, no, HIMEM works by trapping interrupts... so this is not only possible, but vm86 of course works by handing you interrupts to deal with.)
The extremely-confusing-but-still-positive benefit of this would be to allow you to elevate DOS to have demand-paged virtual memory, complete with swapfile.
It might be interesting to identify the oldest kernel version(s) you're prepared to put up with, to realize the smallest _in-memory_ kernel size possible, and _possibly_ enable running multi-MB applications on real systems with only 640KB of RAM (with the proviso that using an SSD via a SATA-IDE adapter would give the best results - and the rationale that both of those items will soon be cheaper than old DIMMs). The issue suggesting 2.4 is maybe a bit of a stretch, but the early 2.6 trees might be interesting.
Another idea I had after reading the dosemu source is implementing a DPMI server to allow protected mode DOS apps to run. It might even be possible to run an early version of Windows this way too.
- it first, if not yet present, starts Linux, via normal Linux kernel load. It passes over some pointers from DOS into /init arguments so that /init can know about DOS' context when Linux was first loaded
- Linux's /init then uses VM86 [1] to call back into DOS, back to the function that was run in DOS before Linux was loaded (vm86_return). This is a bit of a 'draw the rest of the fucking owl' deal, as it has to actually emulate a lot of DOS/PC behaviour (emulate INB/OUTB, etc). It's basically a small VM, like with KVM, but for 16-bit DOS.
- when DOS wants to run a Linux command, it now uses a special new interrupt (DOSLINUX_INT) to call into the kernel. This in turn triggers a VM86 exit, jumps into the VM86 monitor in /init, executes the command, and pokes the result back into DOS, resuming VM86 emulation.
[1] - https://en.wikipedia.org/wiki/Virtual_8086_mode
freedos developers?
people updating HP bios from bootable media
people using intels ssd firmware update tool
You could perhaps argue "inception" since it's Linux running a DOS VM running Linux commands. But the charitable explanation is the author just wanted a convenient environment to do DOS development rather than bare metal (think of it like a Vagrant box).
-Dr. Ian Malcolm
Okay, actually, this is more like VMWare ESX in the 4.0 days. It's kind of, uh, inside out.
Basically it's DOS, which launches Linux via DSL, which then runs a task out of init in vm86 mode that uses KVM to _continue_ the DOS that launched it as if it were the only thing running.
The DOS doesn't know anything has happened, even though the rug has been pulled out from under it, and it is now running in a KVM VM guest. You just can't tell anything is different because all the BIOS/real mode stuff is unchanged.
You get your prompt back when a native Linux binary finishes but it's the linux kernel emulating the DOS session after that first command, until you reboot.
Umsdos overlaid a POSIX file system on top of an MS-DOS file system, using a scheme somewhat similar to Windows long filenames (but created before that became a feature of Windows). Basically, every directory would have a magic file called --LINUX-.--- that contained POSIX file data, including full filenames and permissions.
I'm using it currently on a 386SX with 8MB of RAM (not to post this, however).
Edit: Ah, this doesn't do the driver bit. But it works pretty well in itself.
https://news.ycombinator.com/newsguidelines.html
What about DOSBox?
Yes, that is correct. Windows Subsystem for Linux means it's one of Windows' subsystems which provides linux.
This should be called Linux Subsystem for DOS.
So what's different?
E: Ah I see, I misinterpreted the comment chain depth. Thanks all.
Windows has the concept of subsystems - technically the Win32 API is also just a subsystem around the NT kernel that provides the "Windows API". Windows NT also had one providing an OS/2 API, and one providing POSIX API - the latter later evolved into/was replaced by "Windows Services for UNIX" - assume there and with WSL the intent is to read it as "for Linux/UNIX applications".
But why specifically this confusion phrasing is unclear, maybe they wanted to keep the "Windows" brand attached to the thing - i.e. treat "Windows Subsystem" and "Windows Services" as one term?
On a more serious note, the hack described by the author [0] is quite ingenious.
[0] https://news.ycombinator.com/item?id=24556801
If the project maintainer is reading, it would be super helpful to put that at the top of your REMADME.md. I'll even send you a PR. FTR it's not your fault the terminology is confusing :-)
Usually, saying "for Linux" or "for Windows" about something means there's a thing that is for (or "to run on") Linux or Windows, not that the thing is "of" Linux or to enable the use of Linux. I appreciate there are two ways to look at the semantics, but the one they picked for WSL seems the least common one to me.
There are two ways to read "Windows Subsystem for Linux":
1. This is a subsystem that runs on Windows that enables Linux binaries.
2. This is a subsystem that runs on Linux that enables Windows binaries.
The confusion comes in the fact that when I write those two sentences, I naturally want to write "This is a subsystem FOR Windows..." or "This is a subsystem FOR Linux... ." I had to consciously avoid using "for" in that sentence to highlight the problem.
So when someone who doesn't know what the thing does reads "Windows Subsystem for Linux" they may walk away with the false impression that the subsystem allows Windows binaries to run on Linux. Likewise, what you're seeing now is that people are seeing "DOS Subsystem for Linux" and thinking that this enables you run DOS on Linux.
And of course WSL2 isn't a subsystem anymore, but is stuck with the product name. ¯\_(ツ)_/¯
https://news.ycombinator.com/item?id=14093517
So the proper name would be "Windows Linux subsystem", but I concede that it does sound really weird (because both Windows and Linux are the same kind of things, they're OSes).
And of course, if it was named "Windows's Subsystem for Linux", there would be much less confusion, but apparently the English for some reason doesn't use the possessive case here (although that's the perfect place for it) and prefer to use the noun as a possessive adjective.
It's true that a Linux Subsystem is a subsystem of Linux, but an "X for Linux" is a component of Linux or an application for Linux.
When you put them together, it seems that the "for" wins the battle. In parsing terminology, it has lower precedence (though I'm sure the actual rules of English are more complex than that indicates).
I'd love to see an actual linguist comment on why this phrase is so confusing.
Which was raised when this name came up but they didn't like that Linux came first so went with gymnastic language instead.
Its even more obvious with this new name.
Its a Linux subsystem for DOS.
[0] https://twitter.com/ericlippert/status/1205372172534874112
The "on Windows" part makes it clear that Windows is the host OS.
Many Microsoft's past products used "for $PLATFORM" in the product name. For example:
Microsoft Word for Windows
Microsoft Word for DOS
Microsoft Word for Mac
It makes it clear that it was the version of the product FOR a given platform.
At first glance "Windows Subsystem for Linux" seems like Microsoft's version of WINE.
Maybe we'll get a real "Windows Subsystem for Linux" when the desktop version of Microsoft Linux arrives.
Even WSL1 is not a classic Windows NT subsystem. Its implementation (picoprocesses) is quite different from that of the classic Windows NT subsystems (Win32, OS/2, POSIX/Interix/SFU/SUA). The classic Windows NT subsystems all involve using ntdll.dll to make NT syscalls; WSL1 processes make Linux syscalls and can't actually make NT syscalls or call ntdll. There is nothing technically stopping an OS/2 1.x executable from realising that it is running on NT and start talking to the NT kernel using the normal NT API; by contrast, a Linux executable running under WSL1, even if it detects it is running under WSL1, isn't allowed to talk to the normal NT kernel interfaces.
There are two types of subsystems – environment subsystems (which provide APIs to programs) and integral subsystems which provide services to the environment subsystems. Integral subsystems include the security subsystem (lsass.exe). (Sources are a bit unclear about whether there is one "integral subsystem" composed of multiple parts, or multiple integral subsystems – e.g. are lsass.exe and smss.exe separate integral subsystems, or two subsystems of the integral subsystem???)
There are three environment subsystems in Windows NT – Win32, POSIX and OS/2, although the latter two have been discontinued in newer versions. The design was always open to adding more (e.g. maybe an OpenVMS subsystem) but that never happened in practice. (Win32, despite its name, doesn't just run Win32, it also runs Win16 and DOS; also, in practice the POSIX and OS/2 subsystems were dependent on the Win32 subsystem and borrowed functionality from it, despite in theory being independent of it. csrss.exe, despite having "subsystem" in its name, is not a separate subsystem, but rather the primary LPC server for the Win32 environment subsystem.)
The term "personality" is sometimes used to describe the environment subsystems, but it is not the term the Windows NT developers used. The term "personality" actually comes from Mach. The idea with Mach was that existing operating systems could be ported to run on top of the Mach microkernel through layers called "personalities" which would map the existing OS API to the underlying Mach API. The original CMU Mach team built such a layer for BSD Unix – the BSD personality – and it actually survives in XNU (macOS/iOS/etc), but they never implemented any other personalities. However, IBM's abortive Workplace OS project actually did implement an OS/2 personality for Mach, which could run alongside an AIX personality, so they actually got closer to delivering on CMU's original vision (albeit the whole project was cancelled before being fully released.) Possibly, NT's environment subsystem idea took some influence from the Mach personality concept; plus, outside observers quickly noticed the similarity between NT environment subsystems and Mach personalities, and started using the term "personality" for the former; but it has never been the officially preferred terminology for Windows.
I've never heard anyone call WSL1 an "environment subsystem". Its method of implementation is very different from the classic NT environment subsystems. You might call WSL1 or WSL2 "personalities", but as I said that's never been official Windows terminology.
[1] https://en.wikipedia.org/wiki/Architecture_of_Windows_NT
[2] http://vig.pearsoned.com/samplechapter/0201791064.pdf
It does work if you assume it's a shortening of something like "Windows Subsystem for Running Linux Applications (on Windows)"
But I get that naming it is a tricky problem, because even a technically accurate name like "Windows Linux Subsystem" (after the old 'Microsoft POSIX Subsystem' name) is still confusing.
- vs -
Windows Subsystem (for Linux)
is probably closest to WSL1’s intent.
It was a Windows subsystem (the first new one in years), and its goal was to let you run Linux apps.
"Windows Subsystem for Linux"
-----
Is the 'windows subsystem' for linux?
or is the 'subsystem for linux' a windows branded feature?
If you asked most people they would probably choose incorrectly.
Linux Subsystem on Windows
Linux Subsystem in Windows
They used to have a product called Windows Services for UNIX [1] which was, you guessed it, UNIX Services for Windows: NFS, Telnet, cron, rsh, etc.
[1] https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
* https://news.ycombinator.com/item?id=11417059
* https://news.ycombinator.com/item?id=18948258
"Windows' Linux Subsystem" might have been better as well (WLS), using it as a posessive statement, or "Windows' Subsystem of/with Linux" which would keep the same WSL abbreviation.
The suffix "for Linux" strongly implies it's software for use on Linux. It's like the "4j" and "4win" suffixes, implying software built for the Java and Windows environments, respectively.
What's more, Windows or DOS as an adjective of subsystem bind more tightly than "for Linux". So if you were to start dropping parts of the name, you'd drop "for Linux" first. Except you can't, because then it's just the Windows Subsystem.
LSW would have been a much more natural name. In a conversation about Windows subsystems, you could refer to it as the Linux Subsystem. If other operating systems picked up on the idea, they would have their own Linux subsystems, e.g. Linux Subsystem for macOS. If you wanted to check if your OS had anything like it, you could search "is there a Linux subsystem for FreeBSD?" Which might turn up results about the Linux ABI in FreeBSD. Speaking of which, imagine if it had been named the FreeBSD ABI for Linux. What an awful pattern! You can't even repeat the pattern unless both modifiers are proper nouns! Could you have called the VFS Subsystem the "FreeBSD Subsystem for VFS"?
This is why we teach sentence diagramming in elementary school.
Maybe the person who came up with "WSL" wasn't a native English-speaker?
In this case, the context known to the speaker but often missed when trying to "sentence diagram" WSL involves the part "Windows Subsystem". That referent, to which the original author was quite familiar, is invoked in WSL as a single noun in part of the larger noun phrase, and while you could continue to sentence diagram break "Windows Subsystem" into constituent parts here, it is important to remember it as a single connected "atom" to which "for Linux" modifies in the overall noun phrase of "(Windows Subsystem) for Linux". Given that context/referent, the sentence diagram here is unambiguous to the original team/"speaker". It's the audience with much less familiarity with the referent/context in question that has ambiguity problems in trying to "sentence diagram" the noun phrase.
My belief (!!), back then, was that it was intentionally named confusing. Back when it came around, Microsoft was under scrutiny for monopoly behavior. They didn't want Windows to be compatible with Unix in any way; they wanted the world to run Windows (9x, NT) only. That was my belief/theory, as it is now I don't have anything to back it up as it is though. Your theory might equally be viable.
[1] https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
Besides, latest WSL is not like that anymore, it's a hypervisor running a VM now.
maybe it could be phrased as "for those who want linux but need to run DOS as their main OS"
[1] https://copy.sh/v86/?profile=windows98
1. It's for Linux (so Linux is the host).
2. It creates some subsystem that runs DOS (either emulated, virtualized or translated like Wine is doing for Windows on Linux).
That can allow running DOS games on Linux for example, instead of using DOSbox for it.
The "problem" is that these products are not what you automatically assume they are!
To illustrate: SFU provided NFS and NIS servers, a cron daemon, a telnet server, and various CLI "utilities" (i.e., standard "services" provided by "UNIX") running on Windows -- not Windows services that run on UNIX!
Once you know that, the "Windows Services for UNIX" name kinda makes sense and helps to understand what the "Windows Subsystem for Linux" and, now, the "DOS Subsystem for Linux" actually are.
---
[0]: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
Instead it’s seemingly meant to be parsed inside-out with “subsystem for Linux” as one noun indicating a subsystem that runs Linux apps, and DOS as an adjective describing that noun. Maybe wsl did it to keep the windows brand first? Are there many other “windows subsystems for Y” out there and this is a Microsoft-universe term? I don’t know but it’s very strange.
Windows Subsystem for Linux -> WSL
Linux Subsystem for DOS -> LSD
I like it!
this project looks really cool. i don't hear a whole lot of people using dos nowadays but for a tinkering around that would be awesome.
hats off to the author. it's amazing one dude could code this.
Windows subsystem for linux for DOS. Sounds right
> A WSL alternative for users who prefer an MS-DOS environment.
Very confusing description. Is it made for Linux? So what does it have to do with WSL which is made for Windows? May be it's a Wine analog for running DOS programs on Linux then or it's actually emulating things like DosBox does?
[0] https://en.m.wikipedia.org/wiki/Unreal_mode
[1] https://github.com/charliesome/doslinux/blob/master/doslinux...