This is a guest post by Nils aka stecdose
I would like to present a „storage card“ for the XT bus (8-bit ISA bus) that I built from scrap parts. It is based on a small device called DiskOnChip, or DOC.
DOC-based storage card
I have been using the card for about 3 years now and it has proven to be quite a handy tool. The storage card shows up as drive C: in a system and it is even bootable! Continue reading
Short answer: Yes.
Before launching into the long answer, let’s recap what it even is. FasterModeSwitch is a SYSTEM.INI setting in Windows 3.1 which applies only to Standard (286) mode and can therefore be found in the [standard] section of the INI file. KB article Q83387 describes the setting accurately and explains everything… except what it actually does.
Here’s what Microsoft had to say on the subject: Enabling this setting causes Windows running in standard mode to use a faster method of switching from protected to real mode on many 80286-based computers. When this setting is enabled, Windows responds quicker to hardware interrupts, allowing better throughput for interrupt-intensive applications, such as communications applications. In addition, you should enable this setting if you are using a Zenith Z-248 system and are losing characters while typing, or if you are using an Olivetti M-250-E and lose control of the mouse.
Note: This setting has no affect [sic] on 80386-based computers. Some early IBM-AT and compatible computers do not have the BIOS support necessary to use this setting. Enabling this setting on these computers may cause them to hang when starting Windows.
The upshot then is that enabling FasterModeSwitch either speeds up Windows 3.1 or hangs it, depending on the machine’s BIOS implementation. Now, what does the setting really do, and why is the behavior system specific? Here’s the long answer… Continue reading
Once the ThinkPad T43p with a bad fan was in working shape again, I restored the preloaded software on it. Which meant Windows XP (this is a system from 2005).
It didn’t take long for me to establish that XP is really hard to use these days. Even Firefox doesn’t support it. Getting any kind of halfway modern software running on XP is simply a no go. After reading about fairly good experience with installing Windows 7 on T43/T43p, I decided to go the same route.
I happened to have a burned DVD with Windows 7 Ultimate lying around, so I tried that. After installation, there was no WiFi, but there was wired Ethernet—good enough. Windows Update successfully installed drivers for WiFi, graphics, and a number of other devices. The rest (power management, fingerprint software, hotkey OSD) I grabbed from Lenovo.
Once I was done, I had a reasonably functioning laptop (surprisingly well functioning for a 13-year old machine) with just one small problem—no Windows 7 license. The T43p obviously came with an XP Pro license. And I would probably be able to scrounge a Windows 7 Pro license, but I installed Windows 7 Ultimate without thinking much about the problem. Is it even possible to buy a Windows 7 license these days? Continue reading
After I successfully upgraded two Windows 10 VMs to the 1809 release at the beginning of October, I tried to do the same with more VMs and an actual laptop this week. But I couldn’t, no update was offered. While trying to find out how to install the 1809 update, I found out why I couldn’t—Microsoft withdrew it after the update, among other things, deleted users’ data.
Reading about the details left me stunned (though only momentarily, and now I can write about it). The complaints included this now-famous gem: “I have just updated my windows using the October update (10, version 1809) it deleted all my files of 23 years in amount of 220gb. This is unbelievable, I have been using Microsoft products since 1995 and nothing like that ever happened to me. […] I am extremely upset. Not sure what to do….please let me know.”
One would like to answer “easy—just restore the files from your latest backup” but that could perhaps be construed as insensitive.
The fact that someone has been using PCs for 20+ years and still hasn’t figured out that yes, your data can and will go poof is just mind-boggling. External hard disk? NAS? USB stick or two? A cloud backup if there’s nothing else? There are so many options. And are there really people so lucky that in over twenty years, they never had a bad sector on a hard disk, never a bricked SSD, never an accidental file delete caused by a slip of the finger? That’s amazing luck.
But then there is the other side of the story. Files got deleted because of confusion caused by “Known Folder Redirection” aka KFR, which manages to make symlinks look good. The key takeaways are that a) the complexity of Windows is out of control (not news, I know), and b) someone at Microsoft thinks that upon encountering a set of unknown user files, deleting them without asking is an appropriate response. That’s just… wow.
It also turned out that the file deletion bug was reported months ago but ignored, presumably (speculation on my part) because it was a) lost in the deluge of low-quality bug reports, and b) only affected a tiny fraction of users with who were convinced that there was nothing special about their configuration and anyone not seeing the bug was either not looking hard enough or lying. That at least is not surprising.
I suppose I am one, but recently I had trouble with the other kind of a ThinkPad fan. An elderly ThinkPad 43p with a 2.13 GHz CPU (Dothan Pentium M with 2MB L2 cache) and a rather nice 1600×1200 IPS screen (hello, 2005!) was effectively unusable due to a near-dead fan. At startup, the laptop almost always complained about a fan error and turned itself off. Pressing Esc made it possible to get past the error, but as one would expect, the laptop got very uncomfortably hot.
Upon closer examination, it turned out the fan was beyond repair. It was so worn out that as soon as it started spinning at higher revs, it began vibrating so badly that it stopped again. Not really fixable. But finding a new (that is, old but unused) fan assembly wasn’t hard, so I thought I’d just swap it out.
This is in theory not overly difficult, as only the ThinkPad keyboard and top bezel need to be popped off the laptop, which involves removing about 15 screws from the bottom of the unit. The screws are well labeled and the process is well documented in the HMM (Hardware Maintenance Manual).
Copper fan/heatsink assembly in a T43p
Trouble hit when I tried to remove the old fan assembly, held in place by three screws. The screws weren’t difficult to remove, but the fan was stuck fast. It was apparent that the heatsink effectively glued itself to the GPU (ATI Mobility FireGL V3200 aka Mobility Radeon X600, a PCI Express chip with 128MB video memory). For whatever reason, IBM used thermal paste for the CPU but a thermal pad for the GPU, possibly because the GPU comes with a heat spreader and the CPU doesn’t. The thermal pad turned into surprisingly good glue. Continue reading
Warning: If you do not care for the finer points of x86 architecture, please stop reading right now—in the interest of your own sanity.
A while ago I was made aware of a strange problem causing a normal user process running on 32-bit i386 OpenBSD 6.3 to crash the OS (i386 only, not amd64). The problem turned out to be a security hole with history that goes back more than three decades.
The crashing code looked like it didn’t really have any business crashing, but the CPU was in a very odd state with inaccessible kernel stack and GDT (that’s extremely unhealthy because exceptions and interrupts cause triple faults and CPU shutdown).
After much head scratching, I noticed that the (virtual) CPU’s A20 gate was off. That’s a big no-no because when the CPU is in protected mode, turning the A20 gate off has very nasty, unpredictable, and system-specific consequences. It’s one of those Just Don’t Even Try That things. But could a user process really turn off the A20 gate? That makes no sense.
As it turns out, a user process really could do that on i386 OpenBSD 6.3 (again, i386 only, not amd64). A security hole allowed regular user processes to read and write many I/O ports, which is obviously very unhealthy. The chain of events that led to this is long, and probably the biggest player in it is Intel, with important contributions from NetBSD and OpenBSD developers. Thanks to the nature of open source, we can trace back exactly how it came to be, and perhaps even learn a thing or two from the mistakes. Continue reading
A mysterious full-length sound card recently arrived at the OS/2 Museum. It was clearly manufactured by IBM in 1985, and sports a 20 MHz Texas Instrument TMS32010 DSP (the DSP is the large black DIP chip near the lower left corner, not the ceramic gold cap chip).
A curious 1985 IBM sound card
The card has a FCC ID sticker, which is usually a good way to identify hardware:
A suspicious FCC ID sticker
The FCC ID is ANO95A6450611… which apparently does not exist. However, ANO9SA6450611 does. It is hard to say whether the typo is on the IBM card or in the FCC database. Either way, it’s an IBM FCC ID… from 1988. On a card made in 1985. If we discount time travel, there must be some other explanation. Continue reading
I happen to own several old laptops, now about 10 years old, that had the misfortune of being delivered with a Windows Vista license and matching Windows Vista OEM installations on their recovery partitions/media. About a year ago, I noticed that updating Vista no longer worked. That is to say, trying to look for updates just took for ever and ever, eating CPU cycles but never coming up with any result. Nothing happened overnight, nothing happened after two or three days, Windows Update just kept wasting CPU cycles.
This problem started sometime in early 2017, and only affected Vista SP2. It was perfectly possible to update a Vista installation to SP1 and then SP2 through Windows Update, but not to the latest state, it would just get stuck. The same problem was visible on three laptops and in several VMs.
Over a month ago I decided to see what would happen if I just left one of those old laptops running. It was a circa 2008 Compaq Presario V3000 with an AMD Turion 64 X2 processor. I booted it up and left it chugging along in the basement. Every few days I’d check on it and the CPU fans were still spinning, with Windows Update keeping one CPU core more or less fully loaded. Then I went on vacation for over a week, and when I came back, the fans were still spinning, and Windows Update was still busy.
Then one day I checked on the laptop and it was silent. Not dead, just resting. I started wondering what happened and soon enough I discovered that lo and behold, Windows Update in fact installed a number of updates from 2017 and was finally done! And that is why the laptop could finally go to sleep.
I don’t know how long the process actually took, but I estimate that it was about three weeks, give or take a few days (more likely give than take).
Now, a fully updated Windows Vista laptop is only marginally more useful than one which keeps wasting CPU cycles by checking for updates. The experiment was however useful in highlighting that a) Windows Update is (or at least was) seriously out of control, and that b) even if it took several weeks, the update process eventually did finish, as surprising as that was.
This is a good example of software which is functional yet its performance is so awful that it might as well be completely broken. With no progress indication whatsoever, after a day or two users have absolutely no reason to expect that the update process might ever successfully complete and give up.
A few weeks ago, an interesting question cropped up: How fast is a PS/2 keyboard? That is to say, how quickly can it send scan codes (bytes) to the keyboard controller?
One might also ask, does it really matter? Sure enough, it does. As it turns out, the Borland Turbo Pascal 6.0 run-time, and probably a few related versions, handle keyboard input in a rather unorthodox way. The run-time installs its own INT 9/IRQ 1 handler (keyboard interrupt) which reads port 60h (keyboard data) and then chains to the original INT 9 handler… which reads port 60h again, expecting to read the same value.
That is a completely crazy approach, unless there is a solid guarantee that the keyboard can’t send a new byte of data before port 60h is read the second time. The two reads are done more or less back to back, with interrupts disabled, so much time cannot elapse between the two. But there will be some period of time where the keyboard might send further data. So, how quickly can a keyboard do that? Continue reading
Thanks to a generous reader, a curiously nondescript box labeled “OS/2 32-Bit Pre-release” recently turned up at the OS/2 Museum. The box looks very much like retail IBM products from the early 1990s, but has no identifying description except for a mysterious “PR00001” label. There is no real part number, no version number, no date. Given the professional packaging, I assumed it to be perhaps OS/2 2.0 LA from late 1991, or some other beta version not far from the final March 1992 release.
A mysterious 32-bit box
After opening the box, I wasn’t much wiser. There were three loose sheets of paper constituting a “Getting Started” brochure. This included real gems such as “we believe the PS/2 Model 90 and the PS/2 Model 95 are supported at this time”. That does not exactly inspire a lot of confidence.
The Getting Started manual (all of it)
The floppy labels were no more illuminating, except for a tiny “4/91” inscription at the bottom of each label. That would make this one of the earliest IBM OS/2 2.0 betas, older than build level 6.149/6.605 from Summer 1991.
OS/2 32-bit Pre-release diskettes dated 4/91
After checking the floppy contents (all 13 were error-free), a clearer picture emerged. The printer driver floppies were from late March 1991, which makes sense for an April 1991 release. But the rest was slightly older… Continue reading
