Trying out Microsoft's pre-release OS/2 2.0 | Hacker News Reader

Trying out Microsoft's pre-release OS/2 2.0

theregister.com

57 pointslproven48 comments

“If 32-bit OS/2 had launched as planned, Windows 3 would have been the last version before it was absorbed into OS/2 and disappeared.”

I don’t think so - Microsoft would have preferred having 100% control instead of sharing OS/2 with IBM. Windows 3.0 was the technical foundation that allowed things to go the way they went, and its technical capabilities were known, even if it needed time to prove itself in the market. Microsoft would likely have pushed Windows a lot harder than OS/2 even if they had both been concurrently available.

OS/2 was my primary OS for a few years and it was truly awesome - we did things like running a 3-node BBS out of a single 486 with 12 MB RAM and one could format a floppy disk while the system remained responsive (try that with Windows). Fun times.

The only way this would have happened is if Dave Cutler had never left DEC.

Microsoft had already been the biggest commercial UNIX vendor with Xenix, and obtaining the architect of the VMS kernel gave them a brain trust that IBM could not match.

I don't think that Dave Cutler would have been happy as one of several contributors to OS/2 as it slowly grew out of the 286. I think it was dead the moment he walked in the door.

Exactly this, and we should not valorize OS/2 as an operating system foundation. The kernel in NT is far superior.

The "alternate timeline" I'd be more interested in is one where NT had propagated as a more open solution with either open source or more reasonable licensing costs, with a better more VMS and/or Unix-like CLI driven user space and multiple vendors offering systems somehow.

On the one hand, I have no idea why NT chose CMD.EXE as their command shell instead of pdksh; most would ascribe this to the influence of OS/2. NT was built with a POSIX interface, and Korn would have been a much better fit; one objection might be that NT forks processes very slowly, which is a major aspect of Korn.

On the other hand, I don't believe Dave Cutler would have ever allowed /usr/src to ship with the source code to the kernel.

Ill take a stab at that. command.com scripts were very similar to cmd.exe scripts. That was important to get people to actually use the thing. You can see the same thing today with powershell. PS is in many ways better. Except it does not run the old scripts very well. Even something simple like 'dir /s' does not work in powershell you have to do it the powershell way. If they had moved to sh style command eventually they would have been fine. But... their existing base would have been very unhappy with the results in the short term.

At the same time, Xenix had a huge influence on Microsoft.

I can't believe that anyone with taste would want CMD.EXE, and the criticism is deep.

https://blog.nullspace.io/batch.html

Oh no doubt it is a rubish language to program in. The thing is their existing base had a set of scripts that already worked. These are not 5 line scripts either. One place I worked at the thing was probably 20k lines of batch script. To hand them a new shell is akin to saying 'throw everything you did out and redo it'. Those scripts were probably home grown by people who had other things to do (you work with what you have). Or by expensive consultants. They 'must work' or 'why am I upgrading to this?' It is not necessarily hard to do. It just an extra expense most businesses are going to skip if they can.

Some reasons why CMD.EXE is so bad:

(1) COMMAND.COM cut a lot of corners, in significant part due to being written in assembly and designed to run on machines with very low memory (DOS 1.0 would run on machines with only 32KB of RAM)

(2) Backward compatibility meant a lot of the questionable decisions in (1) had to be maintained

(3) At some point Microsoft stopped investing in it, and didn't do anything further to add new features or file off more rough edges

I think (1) and (2) were kind of inevitable, but (3) is a decision Microsoft has made much more recently

I wish they'd open-source CMD.EXE and start accepting PRs for it – I think some of the worst things about it (e.g. the "Terminate batch job (Y/N)?" prompt which is impossible to turn off without patching the executable) would get fixed. But I doubt they'll do that because they just want people to focus on PowerShell instead–and before PowerShell, it was the same thing for VBScript

At this point ConHost.exe is open source [0] so it is maybe not a stretch to expect Microsoft to open source CMD.EXE at some point.

Though with PowerShell being cross-platform and already open source, I personally don't think there's enough to gain in some sort of better open source CMD.EXE fork. I'd be interested in being proved wrong on that, but I'm also happy enough with PowerShell these days I'm not in a hurry to return to CMD.EXE.

[0] https://github.com/microsoft/terminal/tree/main/src/host

PowerShell is rather heavy and takes a lot longer to start than CMD.EXE does

I think there are plenty of little annoyances in CMD.EXE which could be fixed. That prompt I mentioned is the most obvious one, but I'm sure there are more.

Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc. Neither Korn/pdksh nor CMD.EXE can meet such a requirement.

DOS batch compatibility could easily be met with a secondary command shell.

NT's primary command shell could have reworked AWK's grammar into an interactive shell.

It's a shame that the NT command shell did not recieve the attention that it deserved. DCL would have been preferable (if you like FORTRAN).

> Ideally, a command processor would be composed of an LR-parsed language that could easily be represented as a grammar for yacc

There are plenty of parser generators other than yacc, many of which accept different types of grammars from LR (e.g. LL parsers, PEG parsers). I'm not sure why it should matter whether a command processor's grammar is LR or LL or whatever.

The POSIX shell (and its precursors and derivatives) are not LR-parsed languages, and they suffer from ambiguities and inconsistencies. The extent of the distrust is clear in the video and slides below.

I don't know as much about the descent of the COMMAND.COM of MS-DOS with the influence of OS/2 into NT CMD.EXE, but I can say with certainty that it was no better.

We needed something clean and maintainable, and we didn't get it.

https://archive.fosdem.org/2018/schedule/event/code_parsing_...

The problem the slides are raising is that the POSIX shell's grammar is ad hoc: despite the POSIX standard containing an LR yacc grammar, it is annotated with English-language rules which violate the LR formalism.

But not being LR-parsed in particular seems like a red herring – if it had been designed to be cleanly LL-parsed, I don't think anyone would be complaining.

> The problem the slides are raising is that the POSIX shell's grammar is ad hoc...

...and that's the point. A shell language with no inconsistencies or ambiguities is what we needed, and we didn't get it.

A language with a formal yacc grammar would have helped us get it. Neither the POSIX shell nor CMD.EXE are ever going to meet such a requirement.

I don't know if DCL was clean enough to have a yacc grammar. If it was, then it would have been a better choice.

I don't know why you are defending such a precept when the weaknesses are so very well known.

EDIT: A yacc grammar might be preferred as yacc itself is part of POSIX.2, assuring many implementations.

You can find lex and yacc here:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/

However, had any formal grammar been used, it would have been far better than what we have now.

There are languages with perfectly clean grammars which can't be parsed by yacc because they aren't LALR(1).

I agree that a command processor should have a grammar that can be expressed in a well-known formalism, and its parser generated by a parser generator.

I agree that both POSIX shell and CMD.EXE are flawed because that isn't true.

What I'm disagreeing with, is that it is important that the grammar formalism be LALR(1) in particular, and that the parser generator be yacc in particular.

Suppose I have a Packrat parser generator. [0] And my command processor has a nice clean PEG grammar. [1] And I use the Packrat parser generator to generate the parser of my command processor. That grammar quite possibly isn't LALR(1), and hence yacc in particular won't be able to generate a parser for it. But what's the problem with that? If it is a problem at all, it is a very different problem than the problem that CMD.EXE and POSIX shell have

[0] e.g. https://github.com/arithy/packcc

[1] https://en.wikipedia.org/wiki/Parsing_expression_grammar

> I have no idea why NT chose CMD.EXE as their command shell

Because the OS is a sequel and replacement to DOS, and so it has a DOS-like shell.

Speaking as a former professional VMS, DOS, Windows and NT sysadmin:

I preferred CMD to any Unix shell, and I still do. I had boxes to run. I am not a programmer and I don't want programmers' tools.

It is much more use to me to be able to do:

move *.00? oldlogs

And have it pick all files matching the wildcard and move them to the folder -- without needing to be told it's a folder -- than it is for me to be able to write shell scripts.

I think you'll need to provide a better example, since the equivalent in most unix shells is...

  mv *.00? oldlogs

Just sayin'. =)

I see your =) and raise you this:

    ren *.htm *.html

[Author/submitter here]

> we should not valorize OS/2 as an operating system foundation.

I think we should, because we should consider the timing here.

> The kernel in NT is far superior.

Sure it is, but it came along 3 years later, at a time of very rapid industry progress, and it really wanted a Pentium with SCSI disks and 32MB of RAM to work half decently.

I know: I specced, bought, installed and supported the kit, and the OS, in production, in 1993.

Whereas OS/2 2.0 was a perfectly good, capable, multitasking 32-bit OS that ran usefully in 4MB of RAM on an IDE -- not EIDE, plain old sub-504MB IDE -- disk, and it was running in 1990. If MS hadn't killed it, it was nearly ready for launch. Networking and all. That is the point of the article.

> with a better more VMS and/or Unix-like CLI driven user space and multiple vendors offering systems somehow.

DEC could have had that, had it wanted, but it wasn't its business model.

But DEC blew a billion dollars on trying to build the VAX 9000

https://en.wikipedia.org/wiki/VAX_9000

... while ignoring the RISC chip and OS for it that its own OS guru was developing.

https://en.wikipedia.org/wiki/DEC_PRISM

https://en.wikipedia.org/wiki/DEC_MICA

So he went off and built the OS for Microsoft instead.

Somehow it managed to salvage Alpha, turn it into a product and sell it, with its former guy's OS running on it, and it also managed to port its VAX OS to Alpha and sell that for a while.

But it wasn't enough.

Compaq, already a pawn of MS and Intel, bought DEC, handed over the industry's fastest RISC chip to Intel who killed it, and failed to sell the OSes or hardware effectively, because they were just an upmarket PC cloner and didn't know what to do with it.

So HP bought Compaq, and HP also being a pawn of Microsoft, killed one of the remaining competitive bits: HP OpenMail, an Exchange-server compatible groupware server for Unix that was about 2 orders of magnitude more scalable than MS Exchange on NT Server.

https://en.wikipedia.org/wiki/HP_OpenMail

HP traded this for a next-gen sequel to PA RISC -- which turned out to be the dismal Itanium, of course.

Microsoft could still open source some or all of the NT kernel and try to compete for mindset. It's still incredible how much work they put into porting the NT Kernel for some embedded scenarios (you can run it on a Raspberry Pi or things smaller than it) in the Windows 10 lifetime but couldn't seem to understand why more people weren't licensing it more when Linux is cheap as free for embedding. Even when Microsoft went to "free licenses" (still with too many caveats such as type and size of screen attached) the open source appeal was hard to get past.

I'm still somewhat surprised with all of Microsoft's cloud focus and how much of Windows is getting open sourced that the NT Kernel itself hasn't been a priority to win back embedded applications that Microsoft has lost to Linux especially. I certainly understand the massive sunk costs in the NT Kernel that some accountants would see it as too much very expensive proprietary R&D, but it's still interesting to imagine what would happen if Microsoft got over that hump, even if they kept the Win32 userspace and most of the rest of Windows proprietary.

It may be that they can't release it open source. How much of other peoples' proprietary code is in that kernel?

To be clear, I'm not talking illegal theft or anything of the sort -- but it's quite possible that they've licensed things over the years (code, patents, ...) and thus cannot open source it.

Not saying this is or isn't true, just something to consider when trying to figure out the why of things.

Actually, a lot of the kernel code has leaked in the past, so this question can be independently answered.

I know that there were a few leaks at different times. Some of it appears to be here:

https://github.com/0x5bfa/NT5.1

They did finally kick their fork of Adobe's Type 1 Font Manager out of the Kernel in recent years (somewhere in the middle of Windows 10 as I recall), so that's definitely a complication to expect.

[Author/submitter here]

> The only way this would have happened is if Dave Cutler had never left DEC.

Yes and no.

Things happened the way they did because DEC cancelled Prism and Mica and he decamped to MS.

But the point here is that, 3 years before NT, MS had a very capable 386 OS and this shows it, complete with screenshots.

Windows 3.0 was extremely poor by comparison and I speak as someone who deployed and fixed countless copies of Windows 3.0, 3.1, and Windows for Workgroups, all the while running OS/2 2.0 at home.

We're not talking about that alternate history here. What the article is about is that MS had a complete working 386 OS in 1990... but chose to kill it, and it would be another 3 years before its own in-house version was ready, and a decade after that before that in-house 32-bit OS finally replaced DOS-based Windows.

From Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft by Zachary, we learn that Microsoft hired Cutler in October of 1988.

By this time, Microsoft had already maintained a 32-bit kernel with a flat memory model as Xenix. They disposed of it because AT&T was entering the commercial UNIX market and Microsoft would be at a distinct disadvantage.

This means that Cutler had been expounding on his grand kernel plans for two years prior to the 32-bit OS/2 from 1990, and staff at Microsoft could very well grasp the significance.

Chapter 4 of Zachary, Blind Alley, claims that the NT development kernel booted on an i860 PC in July of 1989. This being the case, the knives must have been out for OS/2 for some time.

https://en.wikipedia.org/wiki/Dave_Cutler

From the start, there were 3 planned editions of OS/2.

1.x - 16-bit, for the 80286

2.x - 32-bit, for the 80386

3.x - 32-bit, portable and CPU-independent, aimed at RISC chips.

MS also had a multitasking DOS 4, never fully commercially released.

https://en.wikipedia.org/wiki/MS-DOS_4.0_(multitasking)

http://www.os2museum.com/wp/multitasking-ms-dos-4-0-lives/

What became NT started out as OS/2 3. It was initially developed on the Intel i860 RISC chip, codenamed N10. OS/2 3 was codenamed OS/2 NT for N-Ten.

100% control/ownership was "the Microsoft way", but perhaps there's an alternate universe where they did jointly launch OS/2 due to business needs, with Microsoft intending to claw back control. Would have been interesting to see them fight over ownership!

I ran OS/2 Warp for a couple years as my daily driver and agree, it was a fantastic OS. Stable as heck, preemptive multitasking, just a solid workhorse. I would say Windows got "good enough" with Windows 2000, and pretty decent with the release of XPSP3. Many years later....

[Author/submitter here]

> but perhaps there's an alternate universe where they did jointly launch OS/2 due to business needs

Did you not see the subtitle on my article?

"It fell through a timewarp from an alternate and very different computing universe."

[Author/submitter here]

> Microsoft would have preferred having 100% control instead of sharing OS/2 with IBM.

You seem to forget a few important points.

1. MS willingly entered into the OS/2 partnership with IBM. It even had its own multitasking MS-DOS, the original MS-DOS 4, which it never released.

2. MS wasn't always as rich and powerful as it became much later.

3. It was IBM's PC that made MS rich. That and the success of the PC clones.

> Windows 3.0 was the technical foundation that allowed things to go the way they went

I did not dispute that. The point of the article is that Microsoft's own version of 32-bit OS/2 was nearly ready when Windows 3.0 was released.

> its technical capabilities were known, even if it needed time to prove itself in the market

Hardly. Windows was a flop and an industry laughing stock before Windows 3.0.

I used Windows 2 on my work PC. It was not good. I told my boss that Windows 3.0 was going to be a big hit and that he should get as many copies as he could, and allow me to train all the company's staff on what would very soon be the top-selling product.

He laughed at me.

A couple of months later, the company's 17 copies of Windows 3.0 sold before the office opened for the day, they were on back-order with a waiting time of weeks to months, all our customers wanted Windows 3.0 and he apologised to me saying that he had been wrong and I was right.

It was too late.

I sometimes wonder what the IT world would look like if IBM locked down their IBM PC as hard as Apple currently does with their offerings.

Presumably what you mean is "if IBM locked down their PC as hard as Apple currently does iOS," because MacOS isn't locked down at all.

macOS is pretty hard locked to the hardware which is what OP is describing.

And it’s easy to know how it would have turned out - as a footnote in the computing world as some other clonable system took over

macOS is quite locked down. It's not possible to easily distribute software to macOS users that isn't code-signed and notarized, both of which require a paid Apple Developer account and Apple's participation. This is also true for "side-loaded" apps, not just ones distributed via the app store.

Yes, it's possible to run arcane shell commands to unset extended file system attributes to circumvent quarantine, but this is not "easily".

I know some Linux zealots think that if there's literally ANYTHING preventing a random binary downloaded from DefinitelyNotMalware.com from running, then it's "locked down," but that doesn't make it true. These same people seem to love to describe the Mac environment as a restrictive, nannyware-controlled hellscape, but this, too, is untrue.

The Mac is open, but ships with sensible defaults because MOST PEOPLE HAVE NO BUSINESS RUNNING APPS THAT AREN'T VERIFIED.

Macs ship with an option set in the Privacy & Security pane that limits apps to those from the App store -- but it's a radio button, and the other option is easy to choose ("App store and identified developers").

Yes, this still requires the code be signed, which is a 100% reasonable position in today's world.

And yet: that's not even the end of it. If you do download something from an unsigned source -- either because it's built from source, or because it's from someone who is ideologically opposed to joining the dev program at Apple, or whatever -- all you have to do is right-click the icon and choose to open it. That will save it as an exception, and allow it to be run normally after that point.

See: https://support.apple.com/guide/mac-help/open-a-mac-app-from...

At no point do you need to resort to "arcane shell commands" or "extended file system attributes." In fact, literally ALL of this is absolutely easy.

It'd look exactly the same, because been-there-done-that.

IBM went that way with the PS/2 systems - microchannel, 8514 graphics, supported my IBM PC-DOS (and OS/2, and IBM-OEM'ed Windows).

IBM before that had the BIOS lawsuit against Compaq (https://www.allaboutcircuits.com/news/how-compaqs-clone-comp...) attempting to defend their market ownership; PS/2 came after in the attempt to "re-corner" the market in a way one would today call "Apple style" (walled garden proprietary HW/SW). Too late though. But not for lack of want on IBM's side.

I think the question was if the original IBM PC in 1981 had been locked down such that the BIOS couldn't be cloned.

If the IBM PC hardware (and PC/MS-DOS) was locked down, it would have lost its advantage and would have had equal footing with the alternatives, the Apple Macintosh, the Atari ST, the Commodore Amiga and the Acorn Archimedes, all of which were also locked down.

CP/M (or MP/M) and GEM could run on hardware that wasn't locked down so perhaps some 16-bit version of that could have replaced the 8-bit versions of CP/M and that hardware could have become an open standard.

With or without OS/2, it would be really interesting to see how everything turned out. Windows had such a profound impact on both business and personal computing that we might've been in a completely different place!

More discussion on the os2museum link last week: https://news.ycombinator.com/item?id=39600108

Liam Proven does some stellar work for the Reg: https://www.theregister.com/Author/Liam-Proven

Oh, thank you very much indeed! :-)

Doesn't this rather imply that IBM would have priced OS/2 reasonably and been able to get OEMs to bundle it? There's no way Microsoft would have tolerated OEMs bundling an IBM-only OS/2, they would have pulled all the same illegal tricks they did with DRDOS. And on the first one, have you seen IBM's pricing ...

IBM had, if somewhat limited, success in OEM-bundling OS/2 in Germany. That was not the least Microsoft's own fault (the non-US prices for Windows were ... "high"), and pretty much ended once Win95 got there.

I had a student's license for OS/2 2.x from the 2nd IBM beta to 2.1; with the developer tools and networking, I remember it cost me half of what Win 3.1 plus tools would've set me back. By the time Win95 and OS/2 3.x (Warp) came out though ... Linux had already won for me.

> Doesn't this rather imply that IBM would have priced OS/2 reasonably

When I was around 11 or 12, I had a retail copy of OS/2 2.0 which my dad had bought me at some computer fair. Don't remember exactly how much it cost, but my recollection is it wasn't expensive–he would not have bought it for me if it was.

I was amused by the fact that the box had a "Made in Australia" logo on it–the box and physical floppy disks were made here, but I doubt much of the software on them was.

My understanding of the weird OS/2 marriage was that one early plan (that never happened) was that IBM OS/2 and MS OS/2 would be different SKUs. Microsoft's would be "the cheap SKU" and probably the one most bundled by OEMs because of existing Microsoft relationships with OEMs. (Keep in mind there was a mutual antagonism between IBM and the other OEMs and it would have be weirdly unlikely for IBM to sell OEMs on bundling their OS directly; part of the "marriage of convenience" was directly Microsoft's sway and relationships with the OEMs.) Some IBM accountant would declare some features as too expensive or too "real business" for the MS SKU and Microsoft would have to cut them. In theory Microsoft could have said some Windows things couldn't be in the IBM SKU because IBM OS/2 would be for "real business" and Windows was a "silly toy" for "consumers" (until it wasn't, when 3.1 started to win big). (Though that never seemed to happen either, Microsoft wound up letting IBM OS/2 Warp include the Windows compatibility layers.)

It was expected that despite the shared OS/2 brand name (IBM's dumb insistence) the Microsoft and IBM OS/2's might have wound up feeling surprisingly different.

Microsoft never actually sold an OS/2 SKU so there's all kinds of speculation of what that would have been like and how it would have differed from the IBM OS/2 SKUs we did get. The hard-to-find preview versions like the article talks about are our only glimpses into whatever crazy world that might have been had the weird OS/2 marriage "succeeded". (It's also a weird glimpse, as the article points out, into the insight that Microsoft probably was ahead of IBM on their versions of OS/2 and likely were intentionally sandbagging how much wound up getting sent over to IBM's side of the fence and their SKUs.)

It's definitely a strange fork in the world of computing history, if the "divorce" hadn't happened, if Windows 3.1 hadn't won over everybody, if Microsoft hadn't attracted Dave Cutler to start on the NT Kernel, and so forth: the operating systems we use would have been hugely different (and probably not for the better, given IBM's IBM-ness, the design-by-committee parts of OS/2, and some of the still underappreciated technical marvels of the NT Kernel that we did get in this timeline).

> The cover letter that came with the SDK stressed that Microsoft developers had been using the OS/2 pre-release for day-to-day work.

Back in the day dogfooding was the Microsoft way.

Well, at least as far as I know.

Absolutely, and an excellent idea it is, too.

Whereas I have worked for 2 of the largest 3 Linux vendors, and at both of them, the facilities and site-management people all run Windows. The excuse is "oh but we need to for the interoperability with our suppliers!" Note, this includes server side stuff and groupware. Meanwhile, the marketing and management people all use MacBooks.

It's no wonder their desktop OSes are so poor. Only the techies use their own products, and the management don't listen to the geeks.

Reply on news.ycombinator.com