Another rather interesting software artifact surfaced just recently, after more than 25 years since its release: Windows 3.0 Debug Release 1.14 (further referred to as DR 1.14) from February 1989.
This was an alpha version only provided to select ISVs under a non-disclosure agreement as a preview of the future Windows 3.0 product—which turned into a runaway success and made Microsoft king of the software industry. It was first demonstrated at the annual Microsoft Systems Software Forum in February 1989. Continue reading →
Certain older Microsoft software (including Windows font files) contains mysterious strings starting with “mtswslnk”, sometimes longer and sometimes shorter. This led some people to wild speculation about the meaning and purpose of the string.
Let’s start with the full string: it’s “mtswslnkmcjklsdlsbdmMICROSOFT”, although it rarely appears in its entirety. Now there are two questions—what is the purpose of the string, and what does it mean?
Answering the first question is easy. When viewing a binary in a hex editor, it is blindingly obvious that the string can start at any offset, but always ends on a 16-byte boundary. It almost exclusively (see below) appears in 16-bit segmented New Executable (NE) binaries, and that includes font files. Comparing the string locations with the output of any NE parser, it is apparent that it always occurs at the end of a “section” of an NE image. In other words, it is padding, perhaps used to avoid the problems caused by leaking uninitialized data.
Where does it come from? Well, there’s just one executable where the string appears in full and not aligned, and that’s not an NE image: the Windows Resource Compiler (RC.EXE). The string appears to be located at the beginning of a 512-byte buffer padded with zeros, and itself not aligned in the file. Continue reading →
After a lot of scanning and OCRing, here’s the OS/2 2.0 Technical Library (well, most of it) in PDF form. This was IBM’s complete programming documentation for OS/2 2.0, covering general programming, GUI development, Workplace Shell, and device drivers. Certainly an important museum exhibit, and lots of pounds of good quality paper.
It’s interesting to consider what was and wasn’t in there—32-bit pre-emptive multitasking and multithreading, a GUI with advanced graphics engine, DOS virtualization, but strange partially 16-bit device drivers and no built-in networking.
Note that bitsavers has a subset of the Warp 3 version of the Technical Library, but it’s only the Presentation Manager documentation, at least currently. Most of the documentation also existed in electronic form.
Inside Windows NT, by Helen Custer
Microsoft Press, 1992; 385 pages, ISBN 1-55615-481-X; $24.95
Inside Windows NT was one of the earliest published books about Windows NT, predating the actual July 1993 release of Windows NT 3.1 by several months. Helen Custer joined Microsoft as part of Dave Cutler’s team of ex-DEC engineers; her task was to chronicle the development of NT and describe the new operating system in a way accessible to “the rest of us” (who care about operating systems). Continue reading →
While looking at the Windows 95 disk subsystem, something seemed oddly familiar. The nagging feeling was confirmed by the Windows 95 DDK documentation (a file called BLOCK.DOC). The new Windows 95 layered block device driver model called “Dragon” wasn’t all that new—it was a modified implementation of Microsoft’s older LADDR (pronounced “ladder”), or Layered Adapter Device DRiver model which first appeared in MS OS/2 in 1990. The LADDR subsystem could be retrofitted to OS/2 1.2 (producing “LADDRized OS/2″) and came standard with MS OS/2 1.3 (i.e. LAN Manager 2.1).
The structure of LADDR and Dragon was obviously quite similar, although there were just as importantly significant differences. The fact that LADDR was 16-bit and Dragon 32-bit was not necessarily a great difference. But for instance SCSI adapter support was noticeably different. Windows 95 could use NT miniport drivers (.MPD), which weren’t at all relevant with LADDR. Dragon also included special support for real-mode DOS drivers, which was likewise a non-issue with OS/2. Continue reading →
Years ago, Geoff Chappell (the author of DOS Internals, among other things) published an article about mysterious instructions that Microsoft’s LINK knows but Intel’s documentation is silent about. The fourteen listed instructions were: LOADALL, CFLSH, WRECR, RDECR, SVDC, RSDC, SVLDT, RSLDT, SVTS, RSTS, SMINT, XBTS, IBTS, ZALLOC.
Mr. Chappell then explains why Intel never mentioned SVDC, RSDC, SVLDT, RSLDT, SVTS, RSTS and SMINT: Those are instructions defined by Cyrix and in fact reasonably well documented.
But that still leaves seven instructions: LOADALL, CFLSH, WRECR, RDECR, XBTS, IBTS, and ZALLOC. What are those instructions? And why did Intel not document them? Continue reading →
On some systems, both physical and virtual, 64-bit Windows 8.1 as well as Server 2012 R2 consistently crashes with error code (bug check) 0xC4; 64-bit Windows 8 may run on these same systems without trouble. On physical systems, the BSOD is typically accompanied by the machine rebooting so fast that it is very difficult to read the error message at all. If the system keeps attempting to boot Windows 8.1, this results in a nice reboot loop.
In VirtualBox, users at least have a chance to read the error message before the VM terminates with a fatal error:
Not that the error message is in any way helpful. According to MSDN, bug check 0xc4 means DRIVER_VERIFIER_DETECTED_VIOLATION and the first argument of 0x91 is “reserved”. But wait, a driver verifier violation usually means buggy software, so how can that happen with a Windows 8.1 installation DVD? Windows 8.1 couldn’t be buggy, could it? Continue reading →
Thanks to a very helpful reader (Mike Senior—thanks!), the OS/2 Museum can now publish the ThinkPad Power Series 850 Hardware Maintenance Service and Reference manual in the form of a PDF. This is IBM document number 30H2383. The manual might be of help to owners of antique PowerPC portables. The PDF isn’t perfect but it should be quite useful.
Anyone who needed to take apart a ThinkPad knows that although the process isn’t necessarily terribly difficult, it is complicated enough that dismantling a ThinkPad without the corresponding HMM is a perilous journey. And no one wants to break a PowerPC ThinkPad.
There’s very little else to say, just that although the HMMs for Intel-based ThinkPads have long been available in electronic format (for all ThinkPads, even ones much older than the 850), the ThinkPad 850 HMM was for some reason never available electronically, and the HMM is nowadays even harder to find than the actual ThinkPads.
By sheer coincidence, two new computers arrived in my family at almost the same time, and they couldn’t be more different. At first sight, the most striking difference is the quality of their displays, and it says a lot about the state of the computer industry today.
Lenovo Ideapad Z50-75
The first system is a Lenovo Z50-75, a cheap laptop purchased because the OS/2 Museum needed a modern (but not necessarily fast) AMD processor. The CPU is an A10-7300, a low-performance, low-power “APU” with four CPU cores and six GPU cores. In general, the laptop is pretty good for the price, but has one huge downside: The display. Continue reading →
An important fragment of PC history was unearthed a few days ago: An image of a Compaq Deskpro 386 supplemental disk from August 1986, containing among other things CEMM.EXE, Compaq’s original expanded memory emulator shipped with the Deskpro 386. The image is available on pcjs.org (in the 3.10 directory).
Why is CEMM important? It was essentially by definition the first publicly available utility using the 386’s new Virtual 8086 (V86) mode, and it was the first 386 memory manager. Eventually CEMM morphed into EMM386 shipped with DOS and was the “standard” counterpart to memory managers such as Quarterdeck’s QEMM, Qualitas’ 386MAX, or Helix’s Netroom. EMM386 née CEMM was itself a very important piece of software. Continue reading →