The README for 2.0 contains an interesting apology to OEMs:
> The user manual contains some significant errors. Most of these are
due to last minute changes to achieve a greater degree of compatibility
with IBM's implementation of MS-DOS (PC DOS). This includes the use
of "\" instead of "/" as the path separator, and "/" instead of "-"
as the switch character. For transporting of batch files across
machines, Microsoft encourages the use of "\" and "/" respectively
in the U.S. market. (See DOSPATCH.TXT for how you can overide this.
The user guide explains how the end-user can override this in CONFIG.SYS).
Both the printer echo keys and insert mode keys have now been made to
toggle. The default prompt (this may also be changed by the user
with the PROMPT command) has been changed from "A:" to "A>".
We apologize for any inconveniences these changes may have caused
your technical publications staff.
So MS-DOS almost had Unix-style file separators and argument switches!
That'd be really cool. Upgrades to QuickBasic would come out pretty fast I'll bet.
In case it doesn't happen, I have to say FreeBASIC is pretty nice...I was happy with how easy it was to make a little simulation game and compile it. Also I haven't tried it out for very long, but Gambas seems pretty neat and does some kind of web app creation thing now too.
FreeBASIC is pretty cool, qb64 isn't bad either -and might be a shade closer to the original quickbasic? (I'm not sure as I don't know enough QB arcana to test).
There’s also a guy from Finland that wrote his own QuickBasic compiler and is doing some pretty cool videos on YouTube under the handle Bisqwit, with some of the videos talking about things he wrote or prototyped using QuickBasic.
It looks like git uses the standard Unix epoch for its internal timestamp format, and not e.g. a format unable to represent dates before its creation, but that still means it can't really handle pre-Unix dates:
I didn't downvote you, but what you say doesn't make much sense.
git is distributed and works offline, this means that nothing could prevent you from making commit with a "fake" date, you always can change time on your machine. So there's nothing really hackish in that, and that has nothing to do with format in which time stored in git internally. And you can have legitimate uses for "faking" commit date. I'd say repository above is an example of such a legitimate use.
The format Git uses determines the range of dates it can store. If it uses the normal Unix epoch system 0 means 1-1-1970 so you can’t represent dates before that.
It’s more a formality I think. Since recording of atomic time started in the early 1970s it’s accepted that an atomic second is an actual second back as far as 1970. No assertion of accuracy is made beyond that. Of course otherwise you can negative offset as much as you like beyond that but because of physics and stuff it can’t be treated with the same level of certainty or something.
Shocking to think this is where PCs got started. On my first encounters with MS-DOS I was underwhelmed, the Acorn BBC Micro came with better software and it was all in ROM. I could not believe that this was serious software.
If Cringley is to be believed, the original incarnation was called QDOS, Quick & Dirty DOS done up by some guy in the valley that didn’t want to pay for CP/M. Gates licensed it outright for $50k cause he needed something to go to IBM with ...
I bet at least until the whole .com .exe stuff was sorted out. After .exe was created they finally got more than a single segment in a binary, so they probably we're using C by then for some things at least. I imagine all the .com files were ask even at 6.22 though, because of the 64kb limit of them
There's at least support in 1.0, but the api changed in 2.0. Though I believe the few bits of software I've seen from that era, there were fewer .exes (I suspect for the same language distinction I postulated earlier).
My beta web app probably has more source code than that..
That has me thinking though. I have always wanted to try OS dev but all the stuff I have read says it will take years to get a system that can print hello world but surely it can't take that long to write 12k lines.
An "OS" that just boots and prints hello world would be on the order of tens to hundreds of lines depending how fancy you want to be and how much you want to lean on legacy bios support still being a thing.
There are a lot of tutorials out there that'll walk you through quite a bit more than that in a weekend.
There are many tutorials for creating a Raspberry Pi OS[0]. Running in a VM like qemu is the easiest and cheapest way to start (setting up a bootable SDcard is more involved).
A "something that boots" kernel is very small although obviously it doesn't do much. By the time you get to "hello world" the program will have grown but it's still relatively small.
Messing with SET BLASTER (port 220 IRQ 5 DMA 1) to get sound to work in "Rise of the Triad" was probably the defining moment of my early PC misadventures. That and making a boot disk for Dark Forces, and labelling it "boot dick" by accident (thanks for kicking me in the nuts, mum)
I'd name "Farting around with config.sys and autoexec.bat" among the things I enjoyed the most in my life. That's a pity you can't find a job to be paid for this nowadays...
Same here. Tweaking FILES= and BUFFERS= etc. in CONFIG.SYS and discovering DEVICE=ANSI.SYS enabled me to create custom DOS prompts with positioning and colours was a game changer and really what started me on the road to programming decades ago!
I loved tweaking AUTOEXEC.BAT so much that I created a front end menu shell which could be end user customised that at one stage became the de-facto program launcher for an entire state government here in Australia for a couple of years in the '80s.
Once you started moving up the chain with Win3, etc, throw in config.ini and program.ini amongst others. So many painful memories or is that nostalgia.
Did you install qemm (https://en.wikipedia.org/wiki/QEMM) and use loadhi to try to move software into 'high memory' (where that would only work for some programs)?
I spent so many hours of my youth messing with that :) and this is one of those things where built up experience became completely irrelevant over time.
I'd like to see tiny 80x86 boards (about the size of the Pi Zero) that you could boot DOS on, with full access to GPIO/SERIAL/PARALLEL etc. I know arduino exists in this space, but for DOS lovers, little hobbyist boards like this would be great, and ideal for bootstrapping single purpose apps written in C.
Wonder if and when we will get closer to seeing existing windows apps open sourced. It looks like they may be doing clean up of old codebases to release
I'm a bit ambivalent about this (and all the "open sourcing" MS has been doing recently.) On the one hand, it's great to see source code. On the other hand, everything can be reverse-engineered anyway and it feels like this is a sign of a "shedding" (for lack of better term) MS --- one that doesn't see software as having intrinsic commercial value anymore, but instead is turning to services like Azure and stuffing telemetry in everything to eventually turn into another adware company for profit, while at the same time hiding that behind the "but we're open-source too" marketing.
I can see Microsoft using open source to attract developers & retain its userbase and platform dominance, then using that to make money from the surrounding ecosystem.
I see Windows Kernel as a possible candidate. Or At least some sort of strategy based around having Open Kernel for Servers / Mobile, and expand .Net Toolset in Server Space as well as Gaming in Mobile.
I'd be pretty surprised. To be sure that there's no 3rd party crap in it they'd probably need to re-write it the way they rewrote their C# compiler which would be both pointless and difficult to justify (to put it mildly) from a business perspective.
Ohh, that screenshot brought back memories of Win 3.1
I remember developing real world apps using MS Access on Win 3.1. It was a great RAD platform, you didn't even had to know all of SQL and VB right away, you could add it bit by bit as needs arose. All the while I was learning C and C++ with the Borland compiler and playing around with Corel Draw. Fun times. I was in high school.
Oh, VB6 was the most productive language I have ever used I think. It really was about rapid development and getting stuff done by non experts, which was very powerful. Wonder if we'll see something like this again in upcoming years.
Does anyone remember a particular DOS programming guide that dove deep into the internals, distributed as textfiles written by a single author on contract from (I believe) the US Navy?
I would love to see the sources of MS DOS 7.1 (the version included with Windows 98 that supports FAT32) actually. And Novel DOS 7 (that supports multitasking) if possible. Also these could make an amazing contribution to the FreeDOS project and possibly add some steam to what the world of DOS is nowadays. I love DOS.
I love it nostalgically (and I actually enjoyed using it back in the days), many people still use some flavor of DOS e.g. in supermarkets and post offices. I believe there is a lot of old hardware that is only compatible with DOS still in use.
In 2006 I worked at a dry-cleaner/laundromat that had its computer system all running on DOS. I remember when the computer died one day, my boss went to the local thrift store and found a computer old enough to just move the drive over and keep things running. I thought it was odd, but it worked great! Kept us from using it to play games :)
Up until about 10 years ago the ordering system at all the Domino's pizza stores was running either on a DOS or a Win95 machine in a dos window. They manage to patch it to the point it could take internet orders over, what I think was, a virtual modem controlled by a helper windows program.
Not speaking from any authority, but I'd imagine because 6.22 can still be useful in certain applications and Microsoft would still want to exploit that.
Then again, there's FreeDOS which happens to be used in a ton of places that MS-DOS otherwise would be (BIOS update disks, car radios, etc)
Glad someone else started the whole "Not speaking from any authority", so I'll follow your lead... (-:
In addition to said usefulness, it doesn't necessarily have to even be something that Microsoft may consider useful to keep as IP, and -- here it comes -- not speaking from any authority but I recall that there were some components that Microsoft may not have the complete ownership of in these later versions of MS-DOS; I'm not sure if these components are so critical that releasing it without them would make it unusable, or if it would just involve a lot of effort on the code side to do so (and then on the audit side to make sure it was really done[0]). Those companies may not exist any longer to even get the appropriate permission from ... though they have a way of popping out of the woodwork when there's a large corporation that could be sued.
Even if memory serves me wrong, and these later versions of MS-DOS are 100% Microsoft code[1], owned free-and-clear without copyright or patent licensing agreements that included any provisions about publication/re-licensing of source code. You then have the legal team.
Copyright is hard, and while I'd be surprised if Microsoft didn't have a legal team that understood software licensing and all of the fun and turmoil of Copyright (multiplied by every country they operate in), I wouldn't be terribly surprised if the idea of Copyright and 'All Rights Reserved' are indistinguishable to -- at least -- some of these lawyers. However, assuming even that's not a problem, getting everyone in a room to clean all of the guts off of the floor is both a time-consuming and not-at-all-easy task. I've done the 'large multi-national corporation thing'[2] and IP was something you didn't pull an "it's easier to ask for forgiveness..." thing on. I created a security product, software, hardware and all for the company, with direct assistance with Microsoft. My boss made a handi-cam video which Microsoft showed at the MVP summit. I spent weeks trying to get permission to upload the video to YouTube or have it put on our marketing page (made little sense there; but probably the easier path). I didn't give up -- I was told in no uncertain terms that I was forbidden to upload the video and that I should delete all copies of it (which I did) with various IP-related reasons given[3].
Honestly, I'm surprised they bothered with MS-DOS versions of that age. It's really neat, don't get me wrong. I'm guessing they either believe that the historical value, good will generated (marketing), and such is high enough to warrant the effort/time/cost and/or the effort was minimal due to it being a simpler time, smaller team, era of software development[4].
[0] And even then, just because you're right, doesn't mean you won't be sued; nor that said suit won't cost more to win than it would ever possibly be worth.
[1] Honestly don't recall -- I can only remember things I saw, vaguely, from my old PC and while I can't remember specifically seeing a notice about third-parties in the copyright notice that appeared prior to the prompt display, I thought a few of the things it shipped with (very possibly having nothing to do with DOS) having been part of the installed product.
[2] 17,000 employees at its peak, globally (plus many, many contractor/temp), so not 'massive' like the likes of Microsoft, but big enough that several bureaucracy-dances were required for some of the most basic-sounding things when it came to software licensing (and a whole lot of other things). We were in tech, but not software, so there's the artificial barrier of explaining to a lawyer the idea of a GPL-style license. Fun times.
[3] I knew our IP policy and worked in security the year prior, so I knew they weren't screwing around. I also assumed nobody would have the desire (or stones) to upload it. I discovered at a job interview that went really well that the reason I wasn't asked a large number of technical questions was because they found the video of the product I had described on my resume and it demonstrated everything they were looking for. I'm not sure who did it (it wasn't me -- I signed the contract, so I really did delete all of my copies), or when -- years (and one merger) later they were far more lax, too.
[4] And I'm really hopeful this is the God's honest "everything but the license" original code, warts and all, because it'd be fascinating to look at something produced at this time under the pressures that were all around them. I remember seeing videos of Bill Gates where he looks like he's going to outright vomit Microsoft blue -- unshaven, unshowered, and talking to a room full of people and a camera.
I have an irrational attachment to V2.11. For whatever reason, I thought that represented the first mature, finished DOS V2. V2 was massively improved over V1 (V1 didn't have subdirectories), and V3,4,5 etc were much more marginal improvements. For years I kept a version of debug.com from V2.11, patched (with debug.com) so that the initial version check didn't abort for something other than 2.11. It had all the features I expected in debug, yet was positively tiny compared to bloated later versions with no (important) extra features. To me that was V2.11 versus later versions in a nutshell.
3.3 seemed to be a common base for a long time, and a lot of people skipped 4.0. The big feature it brought to market was support for >32Mb disc partitions, but at the cost of using enough conventional memory that you needed bootdiscs to turn off "superfluous" stuff like mouse drivers to play some games.
5.0 brought the ability to load a bunch of stuff high, so you could finally have your cake and eat it too.
I'm with you there -- IIRC, the 3.x series was all about hard disks. I'd lean toward 3.31, though, personally as the "Everything(TM)" item since (I think) that was the version that shipped with FAT16 (had to hit up Wikipedia and this was the version that supported partitions over 32MB). I remember, as a kid, that we had to have 2 partitions on our drive because of the version of DOS not supporting partitions greater than that size and that this was a problem for us for a while (how long, not sure, I was young, could have been years but was probably months), so it seemed like it was a pain point that was overdue for where software was heading, even then[0].
It was also when I started to feel the age of the 8088 I was running it on and was the first version of an OS that I wrote something 'difficult' that I thought was 'really cool' using assembler. I was very young, so cool had a wildly different definition than it has today. What I wrote was a TSR (terminate and stay ready -- something that was almost, but not quite, entirely unlike a background app) that made a ball-like character bounce around the screen after a random number of minutes, really fast* for a second (just long enough for you to maybe question what you saw)[1].
It was a horrible pain of C, some assembler, and -- of course the mess of pirated software that claimed to be something of a compiler and a development environment but I found most of them were designed to simply return indecipherable errors (or -- error codes -- sometimes literally just exit codes), it took me weeks, but it's the reason I stopped begging for a C64, Mac, Amiga or any of the other platforms that had far more fun things to do with them at the time.
[0] Some never forget being told '640K is more than you'll ever need' (yes, partial or misquote, but it's exactly what the guy who sold us that first 8088 told us) -- I'll never forget the incredible controversy that happened when OS/2 2.1 came out and it was something like ~30MB installed! We had a FULL height 350MB SCSI drive at the time (a cool $1,600 controller, cable, terminators, drive and all), so I was a little spoiled. I was still always almost full all the time but, hey, what can you do.
[1] I got the idea from a rumor I had heard about a software virus of the time that did something similar. Mine didn't spread -- it had to be edlin'ed into the AUTOEXEC.BAT. I named it something non-obvious since my dad was proficient enough to go snooping around (it may have even been something in the more l33t CONFIG.SYS).
Honestly, I think I've always referred to it as Terminate and Stay Ready; probably something I read in one of those old books that used to adorn the bookshelf of my parent's office.
Writing it brought back a lot of memories, as well - glad someone enjoyed it! It's amazing to think that we used to write programs in ways other than "I don't know how to do this" (performs google search) "I know how to do this now", but rather had to pour through books, forums (on dial-up BBSes and what qualified as equivalents in the early Internet days) and acquiring that little nugget of knowledge felt like it had so much more value, even though the reality is that the value was the same, it just took a lot more effort.
I wrote a couple of TSR programs too, nothing too advanced, but it was a fun time to be learning and experimenting.
I suspect the most useful thing I wrote was a simple "undeleter" program, for recovering deleted files from floppies and drives. Unmarking the FAT-entry as deleted, then chasing blocks to reassemble the file.
I wasn't a fan of the 6.x series of DOS but I can't remember exactly why. I have fond memories of DOS 5.0, but that's also the first version I ran on my 486 that we built in the 90s (I came from an 8088, so this was an unfathomable upgrade). It was the first version of DOS that I could finally run some interesting games on.
One thing I do recall about the 6.x series that drove me nuts was that the installer progress bar was ... peculiar[0]. It seemed like you could benchmark the 5.0 and 6.22 install from the time the progress bar started and both would go from 0% to 99% in the same time, but where 5.0 would finish with a non-unusual delay after 99%, each version of 6.x spent a while there, with each minor version longer than the prior. By a while, it was something like 3 or 4 times more time spent on that 1% than the entirety of 0-99 (no politics intended). We joked that the entire MS-DOS 5.0 installer must have been copied over and they appended all of the files for 6.x to some post-install script that ran at 99%. No evidence or attempts to gather evidence were ever done, but it was something to talk about while waiting for that last semi-solid 8-bit ASCII block to get filled in.
The 6.x series ended up being one that I ran for the least amount of time -- I ended up on DR-DOS and PC-DOS. But software of that time was really painful to work with. Eventually, I ended up on OS/2 (2.0 through Warp, which I used until just prior to Windows 95) because it felt like the software I depended on ran the same on the platform it was designed for -- Windows 3.x -- as it did on on OS/2's compatibility layer[1].
And the worst part is this is not a compliment of OS/2. Back then, starting an application wasn't as simple as tapping an icon on a touch-screen. Some programs required commitment and following a careful launch sequence if your level of commitment was detected as insufficient. To appease these demonic applications, you followed a careful set of ritualistic actions. Double-click the program icon, wait until the mouse stops moving entirely (or if it starts hopelessly stuttering, that's fine, too). At this point, turn the computer off, wait until it's quiet, turn it back on, tidy your desk, refill the coffee, double-click the application icon (rinse, repeat until you land three 7s). And in the days of co-operative Multitasking or OS/2's 'hold my beer' with a single application's bug taking out the entire system (OS/2 one-upped Microsoft by occasionally causing dumpster fires in the shape of large, metal, PC enclosures). /s
This really wasn't meant to be so ranty, so my apologies. I think fondly of those days. I also tend to think about them a lot more when people say silly things like 'quality of software isn't what it used to be'. It really depends on what 'used to be' means. (-:
[0] Sure, complaining about an installer you run once is weak, but while I mentioned that big computer upgrade, I didn't mention was that it was funded by my father selling PCs which I assembled and configured DOS/Windows/Networking on (we had some corporate clients). It was a side business he set up as a way for me to make enough money to buy a top-of-the-line upgrade. I was 13, or so, and we were ... successful ... just my take in it paid for a car and a 486 that cost as much as a car. I installed ... a lot ... of DOS ... and Windows.
[1] If memory serves, it was actual Win32 API code that they had a license to from past contractual agreements (they still had to pay for the license for each version but they were legally allowed to include it on install media), so it wasn't so much a compatibility layer as it was ... Windows, running on OS/2 with stability as a future feature ... of Windows, and nearly every Windows app of the era. Later they removed the compatibility layer, and released a version where you could provide your Windows installation disks to get the compatibility layer. The two were meant to feel tightly glued together, but someone mixed up glue and lube.
Windows 95 was really annoying in that regard, the progress bar would race to 95%, and then stay there for a long time. We used to joke that the installation routine would only start doing any actual work upon reaching that 95% mark.
If you don't mind doing some searching and the legality (or lack thereof), I believe the sources for 6.22 were leaked a long time ago along with 3.2 (or 3.3, can't remember now --- this was over a decade ago.)
Maybe MS will officially release it someday, but you'll probably see 3.x first.
> If you can get it onto a floppy image, I'm sure it would run it just fine.
There's a bit of a catch-22 there. Technically, you need to be running DOS X.X to create a bootable floppy (real or image) of DOS X.X, as to make a disk bootable you have to type 'SYS A:' from the running DOS to write bootblock onto the floppy and copy over the current IO.SYS MSDOS.SYS and COMMAND.COM.
So, on say.. a modern machine, with no extra third party tools to create the empty bootable floppy image, you'd be hard pushed to do this, as the files in the Repo are just the files and not a floppy image.
It is even more complex than that. This source code (and the compiled binaries) does not contain the PC-specific DOS code, which were supposed to be written by the OEM (in PC case that probably means IBM). In order to build bootable DOS out of this you have to link SYSINIT.OBJ and SYSIMES.OBJ and your hardware interface code into binary (on PC the result of that is IBMIO.COM for PC-DOS and IO.SYS for MS-DOS for PC) and if you want to boot from floppy you also have to provide some kind of bootloader.
Universities and industry groups, esp. security folks, get full source copies of Windows and more... with big bear-trap, PMITAP NDA's. I have/had a NT5/Win2k source CD somewhere in my empire of junk.
I have tons of nostalgia for DOS having first used it in 1992. However, as soon as I used Linux in 1994, it was instantly apparent how backward and hard to use DOS was compared to Unix-like systems. With hardware like Raspberry Pis, not sure why anyone would want to use DOS on x86 for embedded purposes today.
> The user manual contains some significant errors. Most of these are due to last minute changes to achieve a greater degree of compatibility with IBM's implementation of MS-DOS (PC DOS). This includes the use of "\" instead of "/" as the path separator, and "/" instead of "-" as the switch character. For transporting of batch files across machines, Microsoft encourages the use of "\" and "/" respectively in the U.S. market. (See DOSPATCH.TXT for how you can overide this. The user guide explains how the end-user can override this in CONFIG.SYS). Both the printer echo keys and insert mode keys have now been made to toggle. The default prompt (this may also be changed by the user with the PROMPT command) has been changed from "A:" to "A>". We apologize for any inconveniences these changes may have caused your technical publications staff.
So MS-DOS almost had Unix-style file separators and argument switches!