A blog reader recently pointed to an interesting problem which affects older Solaris releases on certain systems. The symptoms (crash/reboot) may at first glance look like the previously described problem which affected Solaris 2.5.1 and 2.6, but both the cause and the set of affected systems are different.
When systems based on the Pentium 4 started appearing in the early 2000s, users of several then-recent versions of Intel editions of Solaris discovered that Solaris could not be successfully booted (or installed) on Pentium 4 processors. The affected versions were Solaris 2.6 (1997), Solaris 7 (1998) and Solaris 8 (2000). On the other hand, Solaris 2.5.1 (1996) and older continued working; Solaris 9 (2003) was never affected.
The problem manifested itself as a “BAD TRAP” panic very early in the boot, often but not always accompanied by a triple fault/reboot. There was no easy way to avoid the problem, but there was a workaround which required a little bit of typing, and which was available thanks to the very helpful Solaris kernel debugger. Because the kernel debugger was available even on the installation media, it was entirely possible to engage the workaround, install the OS, and then patch the kernel.
The cause of the problem was somewhat careless coding on the part of Solaris kernel developers, combined with Intel’s ever-changing MSR (Model-Specific Register) implementation. Solaris 2.6 was the first to add support for Intel MCE, or Machine Check Exceptions. Continue reading →
5) Vibrato Wars rage between factions disagreeing on how classical music should be played with regard to vibrato to be historically accurate.
6) In The Vibrato Thing, David Montgomery makes very sarcastic remarks (on pages 5 and 6) about the perceived unlikelihood of Fritz Kreisler (an Austrian violinist born in 1875) being able to hear Gypsies play violin.
7) Wait a second! That article about a Hungarian baby mentioned a Gypsy musician named Mihaly Fatyol who “played the dance halls of Budapest and Europe from the 1920s to the 1970s, at a time when no restaurant, no society wedding was complete without a Gypsy orchestra”. Hmm, maybe Mr. Montgomery is the one jumping to conclusions and it was not at all unlikely for an Austrian living in Vienna to hear a Gypsy violinist in a Viennese café in the late 19th century? Then again, I’d rather not take part in the vibrato wars…
Anyway, there you have it—the connection between an OPL3 chip and a Hungarian baby.
Thanks to a kind reader, the OS/2 Museum obtained a file archive of the ThinkPad 701 recovery CD. The 701C/701CS was also known as Butterfly thanks to its unique folding keyboard.
The recovery tool appears to have been designed for all ThinkPads and desktop PCs that IBM sold during the era (circa 1995). Since the recovery CD was, well, a CD, the software was able to either boot from a specially created floppy in the target system and directly use a built-in CD-ROM, or connect a CD-ROM-less target system (such as the ThinkPad 701) over a parallel (or even serial, if one had a lot of spare time) cable to a host system equipped with a CD-ROM.
Neither of these methods sounded particularly attractive. PCMCIA-attached CD-ROMs are rather exotic, and the files weren’t even on a CD anyway. A parallel cable would have been a possibility, but since the host system needed to run Windows 3.1 (and have a parallel port), this was rejected too. Oh, and the ThinkPad 701 needs a port expander or a special cable to even have a physical parallel port connector, since it is so small.
On the other hand, the ThinkPad 701 has two PCMCIA slots, and both PCMCIA to CF adapters as well as CF cards and microdrives are inexpensive and easy to find. Better yet, with a USB to CF adapter, it’s very convenient to transfer large chunks of data to/from a modern PC or a Mac. How hard would it be to restore the Butterfly using a CF card? Not too hard. Continue reading →
Last week I encountered a problem that I have never seen before with a recently acquired Socket 7 motherboard. The board was a Gigabyte GA-586HX (Rev. 1.58), a relatively uninteresting older Socket 7 board based on the well-regarded Intel 430HX chipset.
Apart from automatic voltage detection, the one distinguishing feature of this board is six memory slots rather than the usual four. That makes memory upgrading easier, although in order to get the full 512MB, one would still need at least two of the somewhat hard to find 128MB SIMMs.
What made this particular board much more interesting was that although it wasn’t in original packaging and had memory and CPU installed (four 4MB SIMMs—worthless; a K5 PR133 “goldcap” CPU—at least interesting), it looked completely unused. No signs of wear, no discoloration, and rather tellingly, no dust.
The board as such appeared to work well, but it had one very strange problem: It wouldn’t remember any BIOS settings. No matter what I changed in the setup, on next boot the old settings were back. The only thing that I could change was the date and time. Continue reading →
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 →