Dan -
I can see you like to get me to stretch those memory cells... Let me do the best off the top of my head and see how far we get. Others who are knowledgeable on these topics can feel free to correct me where my recollection is imperfect.
First, on Mr. Allard - I know lots of folks at MSFT but not him. I never heard of him before the current news hit the public.
I have no idea whether Gates knew about the TCP/IP work but Ballmer did. The networking team was part of the OS/2 development group at MSFT, not the Windows team. We had a much closer relationship with the OS/2 team but more on that below.
My experience with OS/2 began ironically through an attempt to develop a simulation package which would use Windows as a display interface. The idea was to do 'drag and drop' creation of process elements into a system, then run a simulation to see what performance would be. Clients such as General Motors and a number of smaller companies wanted the tool to predict assembly line performance more easily. The project was begun in early 1986. But Windows 1.0 was almost unusable, so we switched to GEM for the graphics presentation. At that time, windows was really a kind of graphics program which ran on DOS, using pretty much all of the machine just to bring itself up. GEM was a much more capable graphics environment.
To really work well, the simulation really needed to run a lot of the model in RAM, and have a separate process for display. MSFT convinced us that we should develop to OS/2, the 'next generation' OS they had announced, with IBM, the year before. We got to know the OS/2 development team quite well. Contrary to what you heard, there was almost no MSFT involvement in the early OS/2 work, which was done at IBM's Boca Raton facility. MSFT involvement at that time appeared to be mostly driver and BIOS level work. Almost everyone we worked with throughout 1986 and early 1987 worked for IBM.
In late 1986 we shifted development to a Compaq 386, which at least had larger memory capability. OS/2 DID multitask, but for people used to an OS that booted in 64K, it was a huge slow hog. We assumed it would get slimmed down as it moved along. The graphics capability was being created by yet another IBM group in England, a product known at the time as 'presentation manager for OS/2'. IBM at that time had a grand unified field theory to unite a mid-level graphics layer which would allow mix-and-match between various OS support and graphics display technology, I think it was called SAA. PM was supposed to be SAA compliant. The API layer was called GDDM. I no longer remember what any of these acronyms stood for...
When we got to England we found that there was not much more than a specification for the PM. We concentrated on getting the simulation pieces working on the non-graphics version of OS/2 and hung out in the pubs waiting for the IBM team to get their show on the road. It was actually a pretty good time - I bought a Lotus Turbo Esprit and blasted around the English country backroads through fall of 1986 and early 1987 while occasionally meeting with the IBM team to monitor progress. In February 1987 we gave up and went back to the States, and back to DOS and GEM.
In summer of 1987, the OS/2 PM work seems to have transferred to Boca, and a bunch more MSFT people were involved. We went down a couple of times to check it out, but the MSFT team instead routed us to Houston. A SWAT team composed of both MSFT and Compaq people was developing a 386-specific version of Windows which had much improved performance and better graphics capability. We were able to use a rude clock-driven time slice to run both the simulation and the graphics. The 386 version of windows shipped in fall of 1987, and our product shipped the following spring. MSFT was still saying that OS/2 and PM would be the eventual target, but in the meantime we had a vehicle.
Windows 386 was of course 16-bit DOS and a 16-bit Windows with a bunch of 32 bit stuff for those who knwe how to use it. We mostly stayed in the 32 bit space with our code.
I never heard anything about the 'DOS compatibility box' on OS/2 but I can tell you from personal experience that for the first few years of development there were no MSFT people involved in anything but the graphics work, and that only because the IBM PM group in England couldn't seem to get anything that actually worked. So I doubt if you can charge MSFT with early OS/2 screw-ups, I think IBM did that all on their own.
As far as 16 bit versus 32 bit Windows code, the early windows work was done on 286 machines, the 386 was years in the future. By the time the 386 came out, there was little interest at MSFT in Windows, which is why the Compaq guys had to do a lot of the work. Compaq wanted something that would showcase the 386, since they had a huge engineering lead over IBM on that processor. Compaq likewise had little interest in re-writing the core of Windows, and anyway it all ran over DOS which was 16 bit. The real / protected mode glitch on the 286 was real enough, but there were more fundamental advantages to the 386 which Compaq exploited well. MSFT remained committed to OS/2 for several more years, and a lot of their best people were on that project, but some good people were working on Windows also. The 3.0 version was a fundamental rewrite which was dramatically better than the 2.xx versions. It still retained the clunky 64K resource pool allocations, was leaky, etc. etc. but you could actually DO stuff with it. 3.1 was better yet. Keep in mind that all of our critical applications were running on UNIX boxes in that era, and the Windows systems were increasingly capable graphical clients for the most part.
This is running awfully long so I'll close now, but the answer to your question about 16 vs. 32 bit code is that there was a lot of 16 bit code inherited from both DOS and early Windows, but by 3.0 there was lots of 32 bit code as well, and a careful programmer could keep much of his application in 32 bits. |
