The OS/2 Museum just posted a three-volume set of draft Windows Presentation Manager reference documentation. This refers to the OS/2 Presentation Manager GUI but highlights the story Microsoft pushed in 1987: Windows and OS/2 both used the same graphical user interface called “Windows Presentation Manager”.
By the time OS/2 1.1 was released, the “Windows” part was dropped and the GUI was called simply Presentation Manager. And conversely Windows dropped the “Presentation Manager” moniker again and went back to being simply Windows.
But for a while, users were going to be able to run the same Presentation Manager applications on top of either DOS or OS/2, and developers only needed to design a GUI application once. Practice clearly does not always follow theory.
The preliminary OS/2 Presentation Manager documentation was almost certainly published in July 1987. That meant it predated the release of OS/2 Presentation Manager by more than a year, and in fact even predated the release of Windows 2.0 by a few months.
The references at the outset say that “it is strongly recommended that the documentation be read for informational purposes only”. Nevertheless, it is valuable historical documentation showing the Presentation Manager design as it existed in mid-1987, about nine months before the first beta version of Presentation Manager was even available (in the MS OS/2 SDK 1.03 release of April 1988).
The documentation still refers to “DOS” in many places when it’s clearly talking about OS/2 (for example, “a DOS module definition file”). This goes back to the times when OS/2 was called DOS 5, so as to distinguish it from the “legacy” DOS 3 and multitasking DOS 4, of course. There are notably no screenshots in the documentation, only ASCII art mock-ups of GUI windows.
The references do not contain only programming information. A fairly detailed description of the user interface and basic Presentation Manager applets is also included. Volume 3 then on the other hand contains device driver programming information, which was not part of the released Presentation Manager programming documentation (it was documented separately in a DDK).
The sections about the Filing Cabinet and its affliated Start-A-Program and the related API calls were a fascinating read. Simplification as the development realized that program launching definition information was already available in PM executables and didn’t need a separate AIF. Mac users would have needed something different to complain about if the split into File Manager and Program Manager had not happened.
Having common executables or even common source code for Windows and PM seems to already have been lost as PM used bottom left for the origin point.
Yes, reading the preliminary docs makes me wonder how much of it was just a spec and how much was actual code. The first “public” beta from April ’88 was much closer to the final release than to the mid-’87 documentation.
It seems that the way the API schism went down was that both Microsoft and IBM were unhappy about many aspects of the Windows API and decided to improve it in incompatible ways. The coordinates were just the most visible difference. But then Windows 2.0 came out and kept compatibility with the old Windows 1.x API and the whole portability thing flew out of the window.
It was probably more an accident of history than a conscious decision, but I’m sure it did hurt OS/2 (and maybe Windows, too, at least initially) when developers realized that having shared code for PM and Windows apps was quite difficult to achieve.
What did you use to straighten the scanned pages? They look flawless!
It’s Acrobat X Pro, version 10.1.10… the app itself is kind of terrible (I can’t read PDFs while another is being OCRed? Seriously!?!) but it does produce decent output. So far I haven’t found anything better.
What I will add is that sometimes software can only do so much. Some manuals are simply badly printed such that the lines aren’t quite parallel, or aren’t straight. At first it took me a while to realize that it’s not a software bug, the print was just so bad 🙂
“… sometimes software can only do so much …”
Agreed. I was bummed when Scan Tailor and ABBYY FineReader 11 ($150 US) didn’t straighten pages satisfactorily. I wound up prototyping an app using the Hough transform in AForge.NET and learned the transform /itself/ isn’t very precise — even on 1-bit ‘sanity check’ samples with just a few parallel lines.