I am a bit fuzzy on the details, but I think I recall Microsoft charging OEMs for selling devices without an OS installed. So some vendors have gotten into the habit of selling devices with FreeDOS preinstalled.
One of my laptops came with FreeDOS preinstalled, and it was about € 50,- cheaper than the version with Windows. Being a Linux person, I gladly took the discount.
I did run into a use case where FreeDOS was insufficient, though - in my last job, our automation people were maintaining an industrial plant whose SCADA software ran on DOS. I have no clue what they did, but apparently it would only run well on MS-DOS. One of our engineers suspected that timing issues regarding the serial port played a role, but in the end, we never found out. I installed MS-DOS 6.22 on two machines, and that was the end of it.
I got a kick out of it, though. Imagine installing an early 1990s OS on late 1990s hardware in ~2016.
On dos you own the machine down to bare metal for better or worse, usually worse, but software only slows things down.
I suspect if you stuck a protocol analyzer on it you'll find one of three situations:
Someone did simplistic polling instead of a windowing protocol so increased latency makes the overall system unusably slow. 0.1 ms vs 10 ms per handshake is not noticeable to humans but if your scada sequentially polls 10000 parameters thats the difference between a poll taking 1 second or about two minutes...
The other scenario is keep alive signaling where the computer needs to assure the CNC machine that its still alive and sane every 10 ms or the controller initiates an emergency shutdown. Can't have a giant lathe or printing press running off wild not under active computer control. So windows wants to multitask and do who knows what for 50 ms, and the scada shuts down.
The final situation is they're doing something "weird" at the hardware level like signaling over the control pins instead of over the serial ports. Like toggling the RS-232 DSR pin turns on the milling machine motor for 10 ms instead of sending a serial RX/TX power command every 10 ms. Windows opinion of DSR, IIRC, is DSR means the serial port driver registered in windows and is not available to end users. Been a long time since I've had to deal with that so I might misremember.
DOS and BIOS had some pretty crappy interrupt calls for Serial port access and as DOS was single threaded and you could hang the PC if not careful. In timing critical cases you were safer accessing the serial controller directly.. Of course strictly verboten under any real OS and one of the reasons a lot of older timing critical software was problematic to move to windows or other hardware.
Not just timing critical stuff. BIOS calls for serial were slow, character at a time. If you wanted to fill a buffer and keep processing you wrote your own interrupt driven serial code or used a good library. No serious software on DOS would use the BIOS serial code.
This sort of thing was just normal. No multitasking so you had full control of the hardware. Third party libraries or custom code for serial, sound, graphics, often keyboard. Drop into assembly for extra speed. DOS was basically a library for filesystem access, process creation and limited memory management!
>This sort of thing was just normal. No multitasking so you had full control of the hardware. Third party libraries or custom code for serial, sound, graphics, often keyboard. Drop into assembly for extra speed. DOS was basically a library for filesystem access, process creation and limited memory management!
I sometimes think if we will one day cycle back to that model. It was at least an era where I thought I had some understand of computer. Now I seriously dont. But it works.
Is there a reason you believe FreeDOS interrupt latency would be inferior to MS-DOS?
(I can certainly imagine virtual 8086 mode / emm386-style shenanigans, varying with configuration and what's loaded in your config.sys, but this is all very hypothetical, and the most straightforwardly hypothetical position of all is that one bare-bones 16-bit DOS should be exactly the same as another in this regard, not necessarily being in the loop at all.)
FWIW, the automation people suspected the problem was timing-related, so you're probably right.
I was just sad that FreeDOS did not work, but installing MS-DOS from floppy disks was fair compensation. 3.5" Floppy disks! We had an USB floppy drive lying around, but actually finding 3 floppy disks was quite the challenge. (-:
My understanding is that it's more a way to sell a computer for people who don't want a bundled OS, but without it really having no OS. This way the new computer will at least start up to something instead of an error message that can potentially imply storage failure.
Edit: Especially since some of these purchasers are not technically-minded Linux users, who can handle a blank disk error, but people who want to use their (ahem) specially-aquired Windows licenses.
My current home computer is an HP EliteBook I custom ordered with FreeDOS to install Linux on. (Also got the matte touchscreen!)
Worked at an OEM and Microsoft charged a license fee for every processor out the door regardless of whether the system had DOS, Novell, or nothing at all installed.
They would force such a licence agreement on every OEM, small or large. There was a lot more dirty tricks involved to monopolize the market. Look up BeOS history, for example. The OEMs installed BeOS on a second partition, and they could not show it in the bootloader, because of these agreements.
Microsoft and Bill Gates built their position on pure evil.
Microsoft was a big player, and certainly had clout, but the word "force" is inaccurate.
To answer the grand-parent-post, they got a license per CPU because the retailers _agreed_ to that model.
MS would argue that every cpu sold ran an MS operating system (legal or illegal) so licensing the CPU made it cheaper for legit users (ie lower price) and pirate users ultimately paid as well.
This left other OSs out in the cold but the number of actual legit users installing something else was a rounding error.
Shops could _choose_ to just sell dos or windows when the customer wanted it, but they paid a higher price via that model, so few (if any) shops went that way.
MS certainly played lots of dirty tricks but OEM pricing is not really dirty, it's just sensible business when you have that sort of market dominance and your software is pirated so heavily.
That's not an unusual business position. You see it everyday with places that sell coke or Pepsi but not both.
That the choice for retailers is an obvious one is neither here nor there. They had a choice and clearly they wanted to sell Windows, so the choice is obvious.
You might not like their choice, you might not like Windows, but this is bog standard business stuff.
Companies in a monopoly position are more limited in what they are allowed to do.
Something that might seem like a usual business practice to a small fish like you or me, might be illegal for a monopoly.
Microsoft's lawyers tried using your argument to get partial summary judgement in Caldera v. Microsoft. They lost, and they lost the appeal. Here's Caldera's claim, quoting the summary in the US District Court judgement:
> In addition to its improper vaporware and FUD campaigns, Caldera alleges that Microsoft also forced OEMs away from DR DOS 5.0 by what plaintiff refers to as the "licensing triple-whammy," which refers to (1) per processor licenses, (2) minimum commitments subject to forfeiture, and (3) increased license duration. Per processor licensing agreements required an OEM to pay Microsoft a royalty on every machine the OEM shipped regardless whether the machine contained MS-DOS or a different operating system. This is in contrast to a per system licensing agreement, which required OEMs to pay a royalty on only those computers shipped with MS-DOS installed. The use of per processor agreements is argued by plaintiff to be Microsoft's most effective single weapon against DR DOS. Plaintiff alleges that DRI had no realistic chance to license DR DOS to OEMs under a per processor license with Microsoft. It would make no sense for an OEM to install DR DOS when it had already paid for MS-DOS on every machine. Microsoft contends that OEMs were free to depart from the per processor licensing scheme, and that price differentials between license types were "relatively minor." However, plaintiff points to the depositions of several OEM executives who testified that even slight price differentials between the per processor and per system licenses meant that only the per processor license was financially viable.
This case was specifically about illegal use of monopoly power, which is why you can read:
> By 1988 Microsoft had obtained a monopoly position in the DOS market. For purposes of the present motions, Microsoft does not dispute the contention that it has such a monopoly in the operating systems market.
Without that assumption they could not have gotten summary judgement.
> This left other OSs out in the cold but the number of actual legit users installing something else was a rounding error.
Isn't that the whole point? They forced the OEMs to drop other OSs by abusing their monopoly position. If this is not dirty I don't know what is. But yes, MS has plenty of other dirty moves in their past. I don't trust them one bit, even with their new clothes on.
Because the reality is that the OEM doesn't want to track OS installations and Microsoft doesn't want to audit that tracking. With per-CPU licensing, the OEM can just say "here's our invoices from Intel".
The "per-CPU" policies were primarily at issue ~20-25 years ago. Most of the big OEMs didn't even offer significant customization unless you were buying for a whole office or organization.
I was reading a book on Microsoft's history and they did that back in the DOS days: any IBM PC clone that was sold had to pay for the MS-DOS license regardless of if the PC would be running MS-DOS or not. So unless someone explicitly asked for DR-DOS (and was fine to pay for both the MS-DOS and the DR-DOS license since the former would need to be paid anyway), manufacturers just used MS-DOS because it was "cheaper" (and with MS-DOS being the "standard" it isn't like they could afford to not license it).
You could be right, but my likewise fuzzy recollection was that the contract that OEMs had with MS said that every PC that was sold had to have an OS on it. Because the implication was that a PC sold without an OS was likely to have a pirated version of windows installed by an end user. The contract didn't say that it had to have a Microsoft OS because they were a little leery of anti-trust accusations at the time. Very few OEMs used the FreeDOS loophole because they would go out of business if MS decided to pull the OEM contract.
I've heard an explanation that they sell laptops with FreeDOS because in some places it's illegal to sell a preassembled computer with no OS. The expectation is that, yes, you would wipe it and install Linux, because most of the hardware in the thing doesn't even have DOS drivers.
Some OEMs don't sell laptops with DOS, but instead have a procedure where you can "return" the Windows license that came with it and get a refund.
I think there’s a carve out for alternate DOS environments due to some litigation over DR-DOS and PC-DOS. IIRC, its a Compaq thing that came over when HP bought them. Also, I don’t think DOS can connect to AD.
Otherwise, Microsoft’s terms are basically anything that isn’t an ATM machine, server or IoT needs a windows license. In enterprise agreements, you need to buy Windows licenses for MacOS devices too.
> In enterprise agreements, you need to buy Windows licenses for MacOS devices too.
Why would you tell Microsoft that you've bought some Macs? It's not like they're the IRS, they're just a company. They have no business to know any of this.
Well, if those devices use Windows server based services, then it makes more sense. But if they do not, Microsoft would have no way to know about their existence.
> Well, if those devices use Windows server based services, then it makes more sense. But if they do not, Microsoft would have no way to know about their existence.
Yes, that's exactly how it works.
Windows Server Client Access Licenses (CALs) are sold either by user or by device. User licenses allow one person to use any Windows Server hosted services in the organization from any device. Device licenses allow any number of people to use any Windows Server hosted services from one specific device.
If you have a bunch of users with their own personal computers and potentially other devices like a normal office the user CAL model usually makes the most sense, but for environments like classrooms or multi-shift businesses where you have significantly more devices than users the device CAL model can sometimes be beneficial. The catch is that almost any use of Windows services requires a CAL and that includes DHCP/DNS. If you host either of those services primarily from Windows the device count suddenly changes significantly.
It's been long since, so I don't remember all the details, but it was a government anti-piracy regulation at that time in some countries that you either ship with another OS or you pay MS because practically all computers sold without an OS were used with some pirated MS OS.
Such laws existed and may still exist, I remember Germany had some tax on CD-RW disc sales because "they were used also for piracy". All it took was "lobby" at the right level of government.
It must be though to be Walter Bright on HN. He wrote the compiler himself. he wrote dlang. He has been in this game for a lifetime. He would know, right?
I don't think he is the boasting type, even though he has enough reasons to boast… being the only person that ever wrote a C++ compiler by himself and all.
One thing people should be aware of, is that C++ exceptions and RTTI are unworkable for a 16 bit target. Those have to be disabled for 16 bit code gen.
The reason is pretty simple - all the support code would exceed 640K. You wouldn't get past a demo program.
Templates work, but you have to be pretty cautious in avoiding template bloat. Probably better off just avoiding them.
I have a lot of respect for Walter Bright. And I agree, he's typically not boastful without good evidence. Walter is also very accomplished. However, DigitalMars compilers on DOS haven't been popular in a very long time. And if there are some good tricks or some sort of advantage to using them for building and maintaining DOS apps and FreeDOS, then there would be a few people interested in exploring & understanding that.
TK Chia and others have been working on adding DOS C/C++ compiler-isms to GCC as well as improving the the codegen to make it more hospitable for DOS apps. So far, the FreeDOS kernel compilable by gcc-ia16.
It's more than that. It's also supporting the 16 bit Windows calling conventions, __ss pointers, __cs pointers, __huge pointers, etc. There's also dealing with chips that don't have an x87 processor.
OSI considers it valid[0]. The issue FSF has[1] is a requirement for publishing source code which IMO is very underspecified (i mean FSF's issue, not the license's which seems to not be anything special). I can't see how exactly that makes the license non-free, if anything it ensures the source will be available. The issues DFSG had can be found here[2] but they're also not something that would be an issue in practice for the compiler itself - the most practical issue would be the requirement to provide the code for a year but in practice OWv2 is published via GitHub anyway (and i doubt if it moved anywhere else anyone involved would say "no" if asked to provide sources in case they somehow become inaccessible to the entire internet before a year passes).
Also none of those are "not free enough" (FSF claims so but it doesn't seem to explain why) and they're really about the license itself, not how it applies in practice to OpenWatcom.
(FWIW: I'm in agreement with you that DMC++ is likely superior, I'm more curious about what OpenWatcom's deficiencies in relation to it are, and I reckon there are probably only a few people as familiar and qualified than yourself to comment)
When i made a small raytracing benchmark a few years ago[0] OpenWatcom produced better code than DMC (note it was C, not C++), though they were both crushed by Visual C++ 6.
Ok, i tried with the latest versions of both (DMC 8.57 - though the compiler advertises itself as 8.42n - and the latest build from OpenWatcom).
DMC version: Elapsed time = 7.593 seconds
OW2 version: Elapsed time = 6.344 seconds
While i'm using a different CPU than the one from the previous benchmark, the relative results are practically identical (OW version is ~1.195 times faster for the old results and ~1.196 with the new results). VC6 is still faster than both.
FWIW i do not think these different matter that much in practice anyway, if anyone is going to target those old machines nowadays it'd be for retrocoding fun and in those cases if performance is a concern you'd most likely just want to use assembly anyway. IMO as long as a compiler does some basic optimizations to get mostly there it is fine. Some years ago i wrote a small maze rasterizer[0] in C to run on an original IBM PC and i tried to compile it with both Turbo C and OpenWatcom... and there was zero difference in performance since the main render loop was done by generated machine code, so OW's optimizer was optimizing stuff that didn't really need optimizing anyway :-P.
Doom was written mainly in C but the important bits like the span rasterization for the DOS version were written in assembly. The released code was for the Linux version that didn't use assembly so the DOS was only as part of a README file[0]. The sound code was licensed (and thus never released to the public) and most likely also used assembly as that was common at the time.
Quake also used assembly for a few bits (also, like Doom, had C versions for portability).
That is what i meant when i wrote "use assembly", not to write the entire game in assembly (which is why i also gave my maze renderer as an example - pretty much all of it was in C except a tiny part).
I used Open Watcom 2 in production, together with JWasm and JWlink, everything worked perfectly. Though I remember a couple issues I had and reported mainstream, they fixed it relatively quickly.
What's interesting is that it seems to still be much less performant on very small systems than "commercial DOS".
I have a kit-built machine with an 8MHz 8088-class CPU, and FreeDOS is much slower to boot than PC DOS 2000 (the final mainstream MS/PC DOS release). When I used it years ago on 486-class machines (distraction0-free laptops) the gap didn't seem so wide.
Pity DR-DOS seems to have disappeared into the ether. It was a competent choice to, and I know there was a point where you could get a source distribution for embedded purposes, so you'd expect that the next logical step would have been crowdfunding a source buyout.
I'm not all that surprised by freedos booting slower actually. It tends to be significantly more feature rich than the DOSes of the day, and as a result tends to be quite heavy for the 16-bit machines.
My main wish for it would be serial console support. I have "old" industrial boards (386EX, 512K of non-expandable RAM, 8-bit bus, but made in '02). It has a BIOS and an in-ROM variant of DOS by a company called General Software. It has no built-in video hardware and uses a serial console by default.
I installed FreeDOS with a video card installed, added the ctty entry in autoexec.bat, powered down, and removed the graphics card.
The FreeDOS kernel messages came out at boot (over serial), but when it got to command.com, it just started printing '.' characters to my serial console. To be fair, I really didn't spend much time debugging.
Just speculating, but I think the reason for this is that MS-DOS was originally written on 4.77Mhz 8088 machines, both the OS itself and the core utilities, in assembly language. I know from my own experience that it's actually a perfectly fine platform, and you can write performant software that does simple things well. But if you take software written 15-20 years later, on much much faster 386/486/Pentium class machines in C and put it on those early boxes... Well, it's unsurprising it's not going to be performant on 8088s unless that was a specific goal that would absorb a lot of special effort.
>But if you take software written 15-20 years later, on much much faster 386/486/Pentium class machines in C and put it on those early boxes...
Just for the sake of perspective:
15 years later, you had NT 3.51 running on pentiums with NT 4.0 coming just around the corner and Windows 95 had already been out for a year.
20 years later Windows XP was released and MS held an event celebrating the end of MS-DOS
Even ten years later, you had Windows 3.1 running on 486s and OS/2 2.0 was a year away from release.
So the 8088 and assembly window was really, really small. And people were over dos by the time Windows 3.0 was released (1990 -nine years after the first IBM PC)
> So the 8088 and assembly window was really, really small
It really wasn't. Ten years later you could walk into a shop and still purchase an XT-class system. It ran WordPerfect (written in asm) just fine. Newer stuff had come out, but it was always more expensive. It wasn't until Windows 3.1 took off circa 1992ish that PC hardware started getting faster and cheaper very rapidly.
> And people were over dos by the time Windows 3.0 was released
As a practical matter, Windows 3.x required a lot of DOS configuration. It really wasn't until Windows 95 you could mostly ignore it.
In the original article the author talks of posting a statement of intent in 1994 (13 years after the IPM-PC's debut) and kind of skips over the the next 12 years in a couple of paragraphs, getting to 2006 (25 years after the IBM-PC debut) and FreeDOS V1.0. I was referring to the time FreeDOS was written vs the time MS-DOS was written so I think my 15-20 years range was reasonably accurate.
It did take a while for the PC revolution to really pick up speed. The 1981 genesis involved a floppy only machine. The 1983 PC-XT was the practical workhorse that changed everything. The 1984 PC-AT was insanely expensive originally and the average knowledge worker could well have skipped straight to a 386 machine in the late 80s at which point the dramatic speed increases year on year became the norm for a while. Many people continued using MS-DOS alone into the 90s, I know I did. Windows prior to V3.1 was impractical and nobody used it. Windows 3.1 was a successful product and a good experience if you had a really powerful machine. Windows 95 in, that's right 1995, was the real beginning of the end of MS-DOS alone as a mass market office workers' operating system. I would put the golden years of MS-DOS software targeted primarily at 8088 8/16 bit CPUs (in some ways the 8088 had 8 bit hardware and the comparitively uncommon 8086 was the real 16 bit CPU) as 1983-1988. By 1988 much more powerful 32 bit machines were affordable and becoming ubiquitous, but for a while they were mainly used to run 16 bit software much faster.
By 1994 when FreeDOS got underway, 8088 machines were not worth targeting and I'm not surprised FreeDOS doesn't work as well as MS-DOS on them, as I already stated.
Correction; Windows 3.1 wasn't released until 1992 -eleven years later. So it would have been Windows 3.0 (probably in Standard or Enhanced mode) people were running in 1991.
Late versions of MS-DOS are also full of assembly langage.
Hell even QBasic and QuickBasic were written in assembly IIRC.
There were a few tools in C though I don't really remember which ones; but the vast majority of the OS stayed written in assembly language.
My "Mainstream" was "It came as a shrink-wrapped bundle that had an instruction manual and CD, when I bought it at a computer swap meet ages ago." :) This makes me think it was actually targeted for some market intending to be used as a standalone OS.
Mine didn't have a box, just the bundle wrapped, so I wonder if the use case was similar to how some OEMs ship FreeDOS for the "it has an OS for contractual reasons" purpose. You don't need a box if it's being slipped in the system packaging.
DR-DOS from Caldera or Lineo made it to v7.03, I think.
Versions 7.04 through to 7.07 were finished, released and sold, but only as OEM products, bundled on bootable floppies containing Ontrack and Seagate hard disk toolkits, in Nero Burning ROM's bootable floppies and so on. (I suspect also in virus scanners, disk-imaging products, backup tools, etc.) Just the boot file(s) and COMMAND.COM.
Given that a bootable diskette containing a disk manager was included with probably hundreds of thousands to millions of EIDE hard disks at the end of the 1990s... it's quite possible that more copies were ever shipped that way than were sold as standalone retail products.
(Arguably, but IMHO: sad to say.)
So by any reasonable definition, the "mainstream" version of DR-DOS might be the one bundled on maybe millions of bootable diskettes, and not the boxed product.
I have no idea how many copied of PC DOS 7.1 IBM has distributed this way, and I bet it hasn't either.
But I take your point, and I accept it. I just have a slightly different definition myself. :-)
It's the EMM Computers board (www.homebrew8088.com). It's a little nicer than the PC-Retro because it has some concessions to modernity (PS/2 compatible keyboard port, ATX power connector and mounting design, uses a USB flash drive as boot medium) but there are some "work in progress" aspects (In the last few months, it's gone through a few hardware changes to make the speaker work and to support DMA) so there may be some compatibility holes.
I prefer DOSBox-X to DOSBox because it's easier to run; but it sounds like neither one is what you want.
Have you heard of or tried "MS-DOS Player"? It seems to convert binaries into a format that Windows can understand. I think you have to do it on a per-file basis so it might be more of a headache than it's worth; but it's out there!
[edit]There's also winevdm which can run 16 bit windows binaries on 64 bit windows. It has DOS support but it's incomplete and it points back to MS-DOS player in it's readme...
The seem to do far more than can work for my case :-(
I wonder how long it would take to write an 8086 emulator and just intercept the file I/O DOS calls. Would anyone else be interested in such a program?
I've used emu2 to run ancient MASM out of a Makefile. It should work under WSL. (Edit: it doesn't propagate exit codes afaict) https://github.com/dmsc/emu2
I was wrong, I looked at the source and forgot all the CP/M-inherited syscalls are supposed to lack an exit code. The MS-DOS 2 exit-with-return-call method works, and it looks like WSL2 can propagate that from its' Linux VM into Win32-land.
FreeDOS is impressive. Had the occasion to use it after I ran DBAN on an old computer before sending it to a recycling shop. FreeDOS was even able to run the driver needed for the non-standard CDROM. It also is small enough to boot from a 3.5" floppy. It was a real trip down memory lane when software was a lot simpler - yet felt more substantial.
It has been a long time since I looked at FreeDOS. When in it's nascent days I tried to get it running for some old DOS Games and couldn't get it to work. It may be a lot better now.
FreeDOS's main problem is that DOSBox can run almost everything in a modern OS backdrop. DOSBox CAN run windows 3.1 as well, and I believe Windows 95. And you can drop out of it to a modern networked OS whenever you need to. Sure it's less efficient, but there's now 100x (maybe 1000x) more power in the CPU.
For FreeDOS to really achieve its goals it likely needs several things:
1) works in a VM (which it appears to do)
2) runs almost all DOS software in a VM, this involves drivers that would enable long term VM compatibility. Do VMs have a "general networking driver" and "general video driver".
3) provide utilities for networking
4) ... this is the hard one:
FreeDOS would need to curate, collect, and provide collections of old DOS software with modern-friendly installers. The challenge here is legality and copyright.
Collections of WordPerfect / etc
Collections of the compilers / interpreters (Turbo Pascal, Turbo C++)
There are ongoing significant work in preserving Games with eXoDOS, but it's noteworthy that eXoDOS and eXoWIN (the 3.X windows preservation project) don't seem to use freedos at all.
As stated, DOSBox handles most DOS software. But one of the biggest emulation/preservation blind spots right now is the Windows 3.1 --> Windows 98 non-NT kernel software that was semi-DOS and semi-not. The programs could run roughshod on the memory space and APIs, but bridged to the gigahertz era of x86 CPUs. And x86 CPUs are a bear to emulate between all the modes and ISA extensions over the years.
For 2) hypervisors usually have compatibility with select older devices such as the E1000 network adapter (and other older ones even) enabling older systems to interface without needing anything special for virtualization on older guests. There is also of course nothing preventing folks from continuing to add drivers for newer/more efficient virtual adapters, after all they already wrote the OS and the virtual adapters have open source implementations to base off of. Between the two of these methods drivers are pretty well covered as is.
3) is already part of the FreeDOS installer.
4) Is best left to some other project(s) both from a scope perspective as well as the legal perspective you mention. Particularly for modernizing the installers. DOS software collections are quite easy to come by, particularly with organizations like Internet Archive.
DOSBox-X can run anything up to 98, I think; not sure about ME. It also runs across multiple operating systems (it's even in NetBSD's pkgsrc).
For number 2, "it depends"; qemu, vmware, etc all have different features. An alternative is to use something like 86Box (https://github.com/86Box/86Box/) which can present the OS with a complete DOS-era computer with video and other peripherals.
For number 3; I think there's a networking set in the freedos distribution. I have no idea how robust it is, though.
Number four -why? Unless I'm very wrong, the aim of freedos isn't to preserve the dos software landscape but to ensure that there's an ms-dos compatible operating system out there if people want to use it. Also, winworldpc has a fair amount of dos software as does archive.org as I remember.
>As stated, DOSBox handles most DOS software. But one of the biggest emulation/preservation blind spots right now is the Windows 3.1 --> Windows 98 non-NT kernel software that was semi-DOS and semi-not.
The software is largely still out there, and 86box covers the emulation. The real blind spot is the early 00's hole where computers were too complex to emulate well but things are just slightly incompatible with modern operating systems.
> 2) runs almost all DOS software in a VM, this involves drivers that would enable long term VM compatibility. Do VMs have a "general networking driver" and "general video driver".
For network, you probably want VirtIO. For video, just VESA? Although honestly I don't know that that's needed; VMs can just provide emulated devices for which drivers already exist.
> FreeDOS's main problem is that DOSBox can run almost everything in a modern OS backdrop.
IMO it's a matter of perspective. I'd say FreeDOS is already a success as a modern, maintained DOS implementation. The fact that most users find DOSBox and its forks more useful doesn't diminish FD. More software isn't a problem.
Does anyone do gamedev using FreeDOS? I'd wager a low power machine running FreeDOS and running "dos-like" games would be pretty niche, kinda like a demoscene thing but building games on FreeDOS always kinda was something I wondered about.
People write games for DOS emulators (especially DOSBox). Mostly mods of existing DOS games (our son loves Commander Keen mods), but more rarely new from scratch games as well.
However, the problem with developing games/mods for an emulator such as DOSBox, is you may find they run fine in the emulator but don't work in real DOS. Some years ago, I had MS-DOS 6.22 running under VirtualBox and our son was using that to play DOS games. He wanted to play this Command Keen mod he saw on YouTube, but it kept on crashing with an "out of memory" error. Eventually we tried it on DOSBox instead, there it worked. I tried to free up memory by tinkering with CONFIG.SYS/etc, but it appears to be impossible to get that much free conventional memory with real MS-DOS, even when making fullest possible use of UMBs and the HMA. I never tried FreeDOS, but it might have the same issue.
I didn't use FreeDOS to make, but there was an MS-DOS game jam a couple of years ago for which i made a 3D platformer/adventure game[0] (it might sound a bit too big for a jam since most are like 2-6 days but that jam lasted for about two months, i made the game in about five weeks spread within those months). Later ported to other platforms too (and made a few minor improvements in terms of fixing bugs and improving performance - though the game itself is basically the same as it was when the jam ended).
But it does run in FreeDOS, in fact there is a video Jim Hall (the author of the article and the FreeDOS maintainer) made where he plays a bit of the game[1]. Note that since that version both performance and some bugs have been improved/fixed (also i'm working on a new update that improves the performance even further (i've actually made a full playthrough on a 133MHz P1 laptop i have here).
The development itself was done on Windows though and i recently ported the editor to Linux[2].
I haven't done anything else since then but the engine was written to be separate from the game and i want to separate it from the source too at some point. I did consider making a game for the dungeon crawler jam last year but i wasn't very motivated as 7 days felt too little for making something interesting (IMO) and only made a small prototype for walking around [3] (that was done before the jam to ensure the engine was usable for making a game like that, but i lost interest before the jam even began :-P). Also it wasn't specifically for DOS or retro machines in general, i just thought of reusing the engine since i had it lying around and was usable enough.
There's a vibrant C64, ZXSpectrum, and Amiga demoscene with even commercial games shipping with physical editions complete with the little knickknacks that games had in the 80s (they usually make the games free to download as well of course). I've had fun playing some of these games too. I know there are some free pascal folks making games that target DOS, but I'm not sure how many.
Few years ago a customer brought me some tiny PC board for embedding that had some clone of 486 for a project. I hooked up monitor and keyboard to it, installed used Free DOS and my old Borland Pascal to write software for that board. It was nostalgic fun.
FreeDOS is able to run Microsoft Windows 1.0 and 2.0 releases. Windows 3.x releases, which had support for i386 processors, cannot fully be run in 386 Enhanced Mode
I wonder why that is. Well, too bad! Windows 3.11 was a fine, usable OS.
It's the virtual 8086 mode that virtualizes multiple DOS instances. Windows 3.x gets very intimate with DOS to implement this feature (maintaining multiple parallel DOS states) and FreeDOS doesn't mirror DOS precisely enough for this to work.
It's because of the undocumented and weird calls MS put into windows in part to thwart DR-DOS back in the day. (see also https://en.wikipedia.org/wiki/AARD_code )
There are I believe issues with the memory manager and there is a sort of protection mechanism that actually prevents running Windows 3.1/3.11 also on newer MS DOS (aka the DOS 7.1/8.0 of Windows 98/Me, whilst the 7.0 from Windows95 should be able to run without patches), there are dedicated patches/programs for some of these (original MS) DOS versions, probably something similar is needed for freedos.
EDIT: for some reasons this post ended up after retrac's one that actually provides a solution
The first screenshot is from Star Wars: Dark Forces. I played a lot of this game as a kid. I remember the Mac version being superior to the DOS version because it ran at double the resolution. I tried running the Mac version on SheepShaver (a MacOS emulator), but it ran too slow. The DOS version runs well and is available on Steam [1]. It uses DOSBox.
Maybe it's just me, but I like the idea of loadlin. You are given a choice between two OS, running on bare metal, without the dual-boot. You can instantly boot up into DOS to do some quick experiment or something, and then you could load Linux when/if you need it.
For a while I had a grub entry with 'init=/bin/bash' for this purpose. Not a great idea for several reasons, but it was handy if my computer was off and I just needed to quickly copy a file onto USB or whatever.
Major French computer store LDLC (and its subsidiary materiel.net) sells modern laptops with FreeDOS preinstalled (so you don't have to buy Windows). I wonder if that's something others do as well.
Yes, some laptop OEMs have (or have had) FreeDOS as an OS option.
Though with a quick glance at current local computer retailer catalogs I found only HP 290 G3, which is not a laptop (https://www8.hp.com/h20195/v2/GetPDF.aspx/c06636833.pdf). Found plenty of discontinued laptops (e.g. HP ProBook 430 G6: https://support.hp.com/lv-en/document/c06179691), though, so maybe it is just not as common anymore. I vaguely remember seeing FreeDOS laptops much more often 5-10 years ago.
Retailers do that to have the big, red font, price cheaper than their competition. Per law they have to include everything in that price, Windows license too. No Windows license, price is cheaper. That's the sole reason retailers include FreeDOS or Linux, not because they are somehow evangelists of Windows alternatives.
I wonder about the future of FreeDOS. How long will 64-bit x86 CPUs support 32-bit code? They'll probably drop support within 10 or so years (just to free up dead silicon to compete with ARM). And then the FreeDOS kernel will have to be rewritten for 64-bit, and contain a (hopefully) accurate 32-bit VM.
PC DOS diverged from MS-DOS from version 6, went to version 7, and then around the turn of the millennium had a final commercial release called PC DOS 2000 which was essentially PC DOS 7 with some y2k fixes and other little modernizations. IBM used it embedded in other products until about 2003 after which it's been dead and buried.
DR-DOS was bought by Novell when Digital Research went under and became Novell DOS, then it was sold again to Caldera (and later its spun-off Lineo division) where it was called Caldera OpenDOS for a while. It was sold off one last time to DRDOS, Inc. which sold it as a commercial product until at least 2011. I think the current status of the ownership and codebase is unclear.
I'm about to find out. I have a 10+ year old Macbook that was given to me, and is a brick if you try to run Snow Leopard that came in the box. So I've been playing with a variety of weird OS distro's on it.
What systems are completely unrelated? DOS led to Windows, Linux led to Linux-like commands in FreeDOS. I appreciate the context and, from my point of view, credibility of the author to bring some history into the development of modern tools.
One of my laptops came with FreeDOS preinstalled, and it was about € 50,- cheaper than the version with Windows. Being a Linux person, I gladly took the discount.
I did run into a use case where FreeDOS was insufficient, though - in my last job, our automation people were maintaining an industrial plant whose SCADA software ran on DOS. I have no clue what they did, but apparently it would only run well on MS-DOS. One of our engineers suspected that timing issues regarding the serial port played a role, but in the end, we never found out. I installed MS-DOS 6.22 on two machines, and that was the end of it.
I got a kick out of it, though. Imagine installing an early 1990s OS on late 1990s hardware in ~2016.