One of the most popular add-ons for an Apple II added CP/M compatibility. So I guess it should be no surprise that Commodore tried the same thing. But the Commodore 64 CP/M operating system and the associate Commodore 64 Z80 cartridge was a flop. Why?
An 8086-series microprocessor, the 8088, powered the original IBM PC. Its direct descendants power PCs to this day. Not only that, they power modern Macs too. This was always controversial, especially running Mac OS on Intel chips. Why? What are the disadvantages of the 8086 microprocessor?
CP/M was, as you probably know, the first popular microcomputer operating system. It was good but imperfect, and its cryptic command for copying files, PIP, is often cited as an example. Copy makes sense. Even the Unix equivalent, cp, makes sense–it’s copy without the vowels. But what does PIP mean? What’s the origin of CP/M’s PIP command?
Aug 2016 update: Back in 2015, some kind of spam bot wormed its way into my site. I quickly cleaned it up, then decoded the attack and posted details here. Not long after, the spambot started directing traffic to this post, because it contains enough of the magic words, I guess. Only instead of serving up spam, it’s serving up my analysis. I’d rather you read this than spam, so I’ve left this page up.
On to the original post…
A few minutes ago I received an alert that some files had changed on my site (thanks to All-In-One WP Security). But I hadn’t changed anything and WordPress hadn’t updated itself.
Here’s what I found, and how I fixed it.
The conventional wisdom is that computer viruses can wipe out your data, but they can’t do physical damage. The exception to that rule was, of course, Commodore, the king of cheap 1980s computers. Commodore’s earliest computer, the PET, had an infamous “poke of death” (POKE 59458,62) that would destroy its video display, but the Commodore 64’s sidekick, the 1541 disk drive, had a couple of little-known vulnerabilities as well. Read more
“So did you know there’s a Windows version of Shellshock?” a coworker asked the other day.
“What, Cygwin’s bash?” I asked.
“No, in CMD.EXE.”
I thought for a second, back to some really nasty batch files I’ve seen that do goofy stuff with variables and parenthesis and other reserved characters. Suddenly it made sense. Those cryptic batch files are exploiting the command interpreter to do things that shouldn’t be done. Then I smiled.
I deal with mainframes at work from time to time. I interacted with an old IBM mainframe of some sort when I was in college, using it to get on the Internet, do e-mail for classes, and write programs in Pascal. That mainframe has been gone almost 20 years now, but it’s more mainframe experience than most of the people in my department have.
That’s the thing. Mainframes have been on their way out for 20 years–which was why Mizzou retired Mizzou1–but they aren’t any closer to the door now than they were when I was in college. I wouldn’t call it a growth industry, but there are some tasks that haven’t managed to migrate down to smaller iron yet, and if they haven’t by now, maybe they never will. But the universities aren’t producing new mainframe administrators–ahem, IBM calls them system programmers–so while it’s not a growth area from a numbers perspective, it’s a marketable skill that isn’t going away.
That’s where this book helps.
I saw this piece by Steve Losh last week, and thought it was some of the best advice about writing I’ve seen in a very long time. Programmers don’t generally like to write, but I find if you tell them how, they can do a good job of it. It’s much easier for a programmer to learn to write than for a writer to learn how to program. Losh does a good job of telling how.
But beyond that, I think it’s a good reading assignment for anyone who writes documentation of a technical nature. I’ve worked with some very good writers and some very bad writers over the course of my education and career, and this would have helped both types. It would have made the good ones better and the bad ones at least marginal. The thing about writing is that if you know the rules and you follow them, it doesn’t take much else on top of that to be good.
So, if you ever get stuck writing documentation–and if you’ve been reading me for many years, I’d say there’s a pretty good chance you do sometimes–give this a read. It will help you get into the mindset you need to be in, and write more effectively. Even if you’re not a programmer. Because, even though he’s a programmer, he uses cars and guitars as his examples. So if you were writing about how to build a bookcase, his instructions would help you.
I saw the headline on Slashdot: Forensic evidence trying to prove whether MS-DOS contained code lifted from CP/M. That got my attention, as the connection between MS-DOS and its predecessor, CP/M, is one of the great unsolved mysteries of computing.
Unfortunately, the forensic evidence doesn’t prove a lot.