Keep in mind that this isn't an isolated case: Microsoft used this as a tactic with Quicktime amongst others. Their tactics were numerous, either bringing spurious error messages, stealing associations to bring error messages/dodge the invocation of the competitor software or simply altering windows code to produce legitimate errors in competitor software.
That's on top of plain old threatening other companies if they dared use technology that they were trying to suffocate.
True, this is one case that isn't mentioned much, but this gave Excel and Word its massive market share.
When Windows 95 was being developed, MS kept telling Lotus (and maybe Word Perfect) that OS/2 was the real future, so Lotus was focusing on a GUI version of their main product for OS/2. And Notes was originally developed on OS/2.
So Lotus had a nice version of 123 for OS/2 about to go, but the had to shift gears to Windows when W95 was released. Also there were rumors that MS was keeping some APIs secret to make it appear their products were faster than competitors.
When W95 came out, by magic, MS had a GUI version of Excel and Word, thus eventually killing those companies. Lotus had to shift gears and may have lost a couple of years to MS.
I used to work on Wine and don't recall encountering any APIs that made things magically faster. That was a popular rumour on Slashdot in the early 2000s because at the time, most devs were unaware of how IE could start so much faster than Mozilla, and how MS Office could start so much faster than OpenOffice. Cheating via pre-loading was assumed. It was eventually proven that this couldn't be the case when these apps started faster than their competitors even on Wine on Linux. The actual cause was that MS cared about and heavily optimized startup time. No magic.
The OS/2 history isn't quite how I remember it. The fact there'd be a new version of Windows surprised nobody. Chicago development wasn't exactly a secret that caught anyone unawares. Also OS/2 Warp came out before Windows 95 did.
No offense, but I don't think you looked too hard. There are lots of calls that could be used to do things in a more performant way, or to make things possible that were not possible using documented APIs. [0]
Generally speaking though, what you say is true. There are certainly no "magically faster" API calls.
There are thousands of undocumented calls that, if you were aligned with the internal team at Microsoft that wrote them, allowed you to write better performing code than if you were a third party. And as a major developer inside Microsoft, you had the power to get API calls created for your needs, while third parties didn't. That is the crux of the matter.
Here's one straight from the site we're discussing today, the IOwnerDataCallback interface [0] makes it possible to do grouping on a virtual ListView. Windows Explorer uses it to great effect, everyone else can't use it. [2]
Of course there are internal APIs, every OS has those. I don't know of any that would make the difference between an app being competitive and not, certainly not in that timeframe.
Grouping on a virtual list view was added in Vista which is after I stopped working on Wine, but again, that is hardly the sort of thing that makes or breaks apps. Most competing office suites and browsers don't even use comctl32 at all, preferring to roll their own widgets for portability reasons.
The reasons IE and Office were so fast to start was due entirely to heavy optimization. In particular Microsoft were very good at doing profile guided re-ordering of code pages to minimize HDD head movements, which was critical in an era when hard disks were the only storage medium and also much slower. The Linux toolchains didn't have anything like that and the technique wasn't even well known outside of Microsoft back then, so to GNU hackers the results appeared to be almost magic. OpenOffice or Mozilla would take like 30 seconds to start and Word/IE could start in 3.
So what thousands of calls are you thinking of? To give MS such a huge competitive advantage that other companies get wiped out they'd need to have done stuff like kept a new DirectX back only for themselves. Back then they didn't even have the technology to do that. Even your link where you say people "can't do that" is about how to use that private API you named. Blocking that sort of thing requires pervasive code signing, package identity and for that to be propagated robustly through IPC. Even today Windows is kinda ropey in that regard (vs macOS/iOS where robustly enforced Apple only APIs are widespread and critical, e.g. mmap +x is an Apple-private API on macOS).
> No offense, but I don't think you looked too hard. There are lots of calls that could be used to do things in a more performant way,
Undocumented API calls were rumored to be a big deal even back in the Windows 3.x days. I remember reading through this at the time looking for the 'smoking gun'.
There were some cute and offensive names, and a few interesting details about the internal implementation of Windows, but nothing that would've been hugely beneficial.
Things might well have changed since then. (Both at Microsoft and at Apple, where their software is definitely allowed to do things that third party software is not.)
So much stuff thrown within this submission comments. One can wonder how much of this is misinformation, because someone once said something and the other one echoes it back...
> When Windows 95 was being developed, MS kept telling Lotus (and maybe Word Perfect) that OS/2 was the real future, so Lotus was focusing on a GUI version of their main product for OS/2. And Notes was originally developed on OS/2.
This story doesn’t make sense to me. IBM and Microsoft’s falling out was public knowledge by July 1991 - there was an article about it in the New York Times. [0] Windows 95 wasn’t released until July/August 1995 - 4 years later. Everyone who was paying attention knew by mid-1991 that Microsoft’s future was Windows not OS/2.
> Lotus was focusing on a GUI version of their main product for OS/2.
Lotus and Wordperfect both spent a lot developing for almost every platform other than Windows. It always surprised me that they never had even a fallback for Windows for their main products, given how dependent they each were on a single product.
GUI Excel 2.2 was released for Windows 2.0 in 1989, 3 major releases before Office for Windows 95. Essentially same for Word.
WordPerfect had a perfectly working GUI version for Windows by 1994, it just couldn't compete with Word. Same for Lotus123, they were out of fashion long before Windows 95.
Excel and Word both ran on Windows 2.0 (released Dec 1987). I supported Excel on Windows 2 in production.
In the late 1980s, yes, Microsoft and IBM told the industry that OS/2 was the future, because they both thought it was.
OS/2 1.0 was released the same month as Win 2.0) had no GUI, because it wasn't ready.
OS/2 1.1 had in, released nearly a year later in Nov '88. This was what Lotus and others needed. 1.1 was not good and barely worked. For example, OS/2 1.1 still had the Windows 2 MS-DOS executive style user interface.
OS/2 1.2 was nearly another year: Oct '89.
Now, it worked, it included advanced features such as the HPFS filesystem, meaning long filename support, it had a revamped and improved user interface, and the performance was OK... but also the 80386 had been out for 2 years and 386 PCs were becoming mainstream. OS/2 1.X was limited to the 286. That meant a maximum of 16 MB of RAM, that meant no ability to multitask DOS applications, and other serious limitations. The high end PC market was visibly accelerating away from the new operating system.
It also had formidable hardware requirements. For example it wanted 8 MB of RAM minimum.
Somewhere around the timeframe of OS/2 1.1 or OS/2 1.2 is when Microsoft realised that this project was running late, it had high hardware requirements, and yet it still couldn't fully exploit the hardware of new PCs shipping in the late 1980s, and it was becoming apparent that the future was not OS/2 after all.
So it's somewhere around the 1988 to 1989 that Microsoft realised that's unless it was willing to sacrifice the PC operating system market, it needed a fallback plan, it needed some kind of alternative: something that could run on high-end mainstream commodity PCs, which means a 386 with 2 to 4 MB of RAM, that offers more compatibility with DOS, DOS device drivers, and DOS applications than OS/2.
That's roughly the time that the school choir project within Microsoft started to turn into Windows 3. Windows 3.0 was released in 1990, it had the new user interface from OS/2 1.2, it could support and use the new facilities of 386 chips… but it could also run in just 1 MB RAM, ran quite well in standard mode in 2 MB of RAM, and ran really well with 4 MB of RAM in 386 enhanced mode with multitasking of DOS applications. In other words, in half the RAM requirement of OS/2 1.2, they could actually do more than that operating system could do, in terms of important things that MS-DOS users actually wanted and needed.
So yes in the very late 1980s, Microsoft did lie to large software vendors, promising them that OS/2 was the future, while it was working on something that would ultimately destroy OS/2. But even now I am no admirer of Microsoft, I have to admit that it was very far from a certainty that Windows 3 was going to be a hit. In the time frame that Microsoft was developing Windows 3, Word for Windows and Excel were already shipping products.
Yes Lotus and WordPerfect believed the lies. Yes it's true, Lotus and WordPerfect could've targeted Windows 2, but Windows 2 was pretty terrible and was a commercial flop. So if they had targeted Windows 2 it would cost a lot of money and the products would never have made it back. Yes they made a mistake, and yes later on Microsoft encouraged them to continue investing in that mistake, knowing that there was a gamble that might make it all a huge waste of money. But what they did probably looked like the sensible prudent decision the time.
And more to the point, relevant to your comment, this all occurred in the late 1980s, long before the industry went 32-bit and long before anybody even dreamed of Windows 4 which would eventually become Windows 95. That stuff happened in the 1990s, when frankly the OS/2 war was already long over.
Just one confusion I have: wasn't NT Win 4.0? The first NT release IIRC was 3.5, which had the same UI style as 3.0-3.2, but with the new kernel. This of course muddles the waters, having two parallel OSs with almost the same APIs but different kernel being sold at the same time with easy to confuse versioning (all the way up to Me and 2000 and until XP finally finished merging the lineages).
NT's first version released as 3.1, to align with the traditional Windows 3.1. Windows NT 3.5 (Code name 'Daytona') was a performance and stability improvement release. You can think of NT 3.1 as the "1.0" release and 3.5 as the "1.1" release.
Windows NT was natively 32-bit, but this was also the same time that the traditional Windows kernel was developing its own story for running 32-bit code. Windows/386 introduced the 386-specific 32-bit underpinnings and Windows 3.1 added something called Win32s. Win32s was an extension to the Windows executable loader and a set of 32-bit libraries that mapped a subset of Win32 calls to the underling Win16 API. Win32s made it possible to take the same 32-bit binary and run it unmodified on both Windows NT and on Windows 3.1. The caveat (and it was a big one) was that you only had access to a very restrictive subset of the Win32 API.
For Windows 95, Microsoft's strategy was mainly to build out more of Win32s. This built on the Windows 3.1/Win32s ability to run 32-bit binaries and added more of the API's that Win32 developers would've been used to from NT.
> The first NT release IIRC was 3.5, which had the same UI style as 3.0-3.2, but with the new kernel.
It's Windows NT 4 that unified the new UI from Windows 95 and the NT kernel. Even then, the system requirements and compatability issues were demanding enough that it took a few releases to make the NT kernel suitable for the mainstream.
Small correction if I may: Windows 3.1 did not add Win32S.
Win32S was an optional extra: a separate download and was never included with any version of Windows 3.x.
Win32S came along sometime later -- I think approximately in the time frame of Windows for Workgroups 3.11.
There were two purposes for Win32S: an official public one, and a secret one.
The official one was that it allowed developers to experiment with the new Win32 API, develop applications for Windows NT but which could be deployed onto Windows 3.1.
The secret reason behind Win32S was that it didn't work very well if Windows 3 was being hosted on top of a different 32-bit operating system. In other words, to be specific, it gave IBM a really hard time supporting Win32S in WinOS2 on top of 32-bit OS/2. So these new Win32S applications wouldn't run on top of IBM's OS/2 2.x. IBM kept finding ways to implement the additional Apis in Win32S, and Microsoft get changing them and putting out new point revisions of Win32S which broke those Apis again on OS/2.
Eventually the final version did this so effectively that as for as I know IBM never managed to get it entirely working.
By the way Win32S is still out there and you can still download it. There are not many reasons that you would want to do that, but there is one: it includes the original demonstration app for Win32S -- Microsoft Freecell.
This 30-year-old binary runs perfectly on Windows 10 64-bit and Windows 11. You can download Win32S, unpack the zip file, and just copy the files called `freecell.*` to wherever you want. Bingo: the original tiny Freecell Game, in place of the bloated advertisement filled one on the Windows store, for nothing. Enjoy.
> Small correction if I may: Windows 3.1 did not add Win32S.
>
> Win32S was an optional extra: a separate download and was never included with any version of Windows 3.x.
Andrew Schulman (in Unauthorized Windows 95) and Matt Pietrek (in Windows Internals) both describe the Windows 3.1 EXE loader as shipping with special case code for detecting PE executables. Win32s was an add on to Windows 3.1, but Windows 3.1 shipped out of the box with the necessary hook.
Whether or not that qualifies as Windows 3.1 _adding_ Win32s is a matter of packaging. (But it is why I used the wording I did.)
> IBM a really hard time supporting Win32S in WinOS2 on top of 32-bit OS/2.
Interesting, I never imagined Win32s working on OS/2 at all. I didn't use it much, but I always envisioned the Windows on OS/2 2.x as being closer to Standard mode (286) windows, since the Windows VMM probably didn't run on OS/2. But like I said... I didn't use it much.
Related to this: do you happen to remember Microsoft's earlier solution for 32-bit code on Windows? Predating Win32s, I remember there being a library that allowed allocation of 32-bit memory and jumping to 32-bit code. This code wasn't like Win32s code that had API access (it didn't), but it was a rudimentary way to access 32-bit offsets.
There's a bit of nuance in what I was saying.... I agree (and agreed) that Windows 3.1 didn't include Win32s. What it _did_ include, though, is direct support for Win32s in the form of PE executable detection and a hook for the (separately installable) Win32s PE loader.
Windows 4.0 was the original planned name for the product code-named Chicago, which was eventually released as Windows 95.
The first-ever version of Windows NT was called version 3.1. The public reason that it was called 3.1 is is to keep it parity with the then current version of 16-bit Windows which was at that time Windows version 3.1.
Industry rumour at the time was that the real reason it was called Version 3.1 was that Microsoft had a contract in place with Novell which gave them some confidential internal details of how the Novell NetWare IPX/SPX network protocol and the NetWare network client worked.
At the time that NT was in beta, Novell still did not have a client for the new operating system. Microsoft had to write its own client so that the new NT operating system would be able to connect to Novell NetWare servers over Novell's own network protocol. So the first several versions of Windows NT what bundle with a Microsoft written Novell network client, and subsequently a third-party client became available from Novell itself which implemented additional functionality such as support for the Novell NDS directory system.
The licensing agreement between Microsoft and Novell only covered up to and including Windows version 3.1. Therefore in order to use that information, that was the version number that Microsoft had to use for the new product.
I also add to that that you include another red herring that Microsoft's marketing department put out in your comment. The Windows 9X and Windows NT product lines were never merged.
Windows 2000 internally was Windows NT version 5.0. It changed to using plug and play device enumeration so that it could boot on p&p systems designed for Windows 9X. It was able to cope with not knowing the IRQ or DMA channels in use for its boot hard disk for example.
So what that means is that Windows 2000 was the version that incorporated support for the key technology that enabled Windows 9X but which could prevent NT 4 from running effectively on such machines.
Windows 2000 was meant to be the first consumer-focused version of the Windows NT product family... But Microsoft got cold feet, was afraid that it wasn't quite ready, and pushed out one more iteration of the 9X product line: Windows ME. Then it gave a bit of cosmetic facelift to Windows NT 5, added theming to the GUI, substantially increased the speed of boot up and suspend and resume, called it Windows NT 5.1, the marketing department branded it as "Windows XP", and the rest is history. But it doesn't actually include any technology from Windows 9X.
As I understand it some people from the DOS-based Windows product development team were moved over to the Windows NT development team, and the rest were laid off. Not many people were transferred and no technology whatsoever -- there never was a merger.
I don't think that qualifying XP as merely 2000 with a facelift is not entirely fair. XP benefited from having drivers produced for 2000 by the time it came out, but it also had additional compatibility shims to allow almost every Windows application in existence to work (in 32bits). 2000 was a great OS, that I liked, but it wasn't ready for consumers (not dissimilar to the Vista/7 situation). I believe that waiting until XP for the NT kernel big push was the right one, even if it gave us Me which was likely the worst release of the OS.
Lotus was at a crossroads. They could continue with DOS, port to Windows, or port to OS/2. Which path should a cash-rich company with one product pick?
All three.
I have little sympathy for Lotus. They need to own their decisions. Blaming their competitor for misdirection is eye rolling.
That's on top of plain old threatening other companies if they dared use technology that they were trying to suffocate.