Dr. Dobb's Journal November 1997
Michael is editor-at-large for DDJ. He can be contacted at mswaine@cruzio.com.You might want to read this month's paradigmatic perambulations over by the copy machine. It touches on several of the more popular varieties of imitation -- intellectual property infringement, operating system emulation, reincarnation, embracing and extending, and computer-book publishing.
We begin with some thoughts on Apple Computer, a company trying desperately to copy its early mystique by bringing back its founder. As Steve Jobs consolidates his control at Apple, details of his vision for the company are beginning to emerge. During his keynote address at MacWorld Expo in Boston in August, he clarified one theme and left another muddy. Both concerned imitation.
Saying, "We have to let go of the notion that for Apple to win, Microsoft needs to lose," Jobs announced that Microsoft would be investing in Apple, that the two companies would be sharing technologies, and that the long-running dispute over whether Microsoft had infringed Apple patents with Windows would be put to an end.
If Microsoft has been granted clemency for the imitation that former Apple CEO John Sculley thought was too close for mere flattery, recent Mac imitators have been treated rather more ambiguously.
It began when a much-quoted remark by Jobs at the World Wide Developers Conference (WWDC) this spring got Apple clonemakers nervous. I think the word "parasites" figured in it. It rankled. "Parasites" wasn't how the big fleas at Umax, Power Computing, et al liked to think of themselves. They took umbrage.
Here's what he actually said:
I think Apple should license everything, with a few exceptions. I think the clone setup was done really poorly. For one thing, Apple licenses the hardware designs and forces the clonemakers to use them. That's stupid. Let the clonemakers do their own hardware designs, let them do whatever hardware they want. If they wanna OEM Apple hardware and pay extra for that, fine; but if they don't, let them design their own. And on the software, Apple should get a fair price based on volume.
He said he considered it poor policy to have "clonemakers paying $10 a copy and picking off the high-margin products." He concluded: "But I'm not making the decisions."
Now, clearly, he is. And the changes he's making are a little more extreme than he hinted at WWDC.
Things got uglier as the summer wore on, and in late July, hints were being dropped that Apple might change its licensing terms, with rumors that it might eliminate licensing completely. Then OS 8 was released to enthusiastic response, but not, initially, to clonemakers. Some of them, rebels that they are, started shipping the new OS with their machines anyway, without waiting for authorization from Mother Apple. Petition drives were launched to beg Apple not to kill the clones.
By the time of the MacWorld keynote address, no licensing change had been made, but there was also no reassurance that Apple was committed to licensing its OS for the long term. The keynote, by not addressing the licensing issue, did the worst possible thing regarding clones -- it promulgated FUD.
This was particularly damaging to the clones: Power Computing had to put off its IPO since its most important asset, its MacOS license, was in limbo. And the company management began to pull in two directions, a tension that would ultimately pull the company apart.
Surely this was not deliberate. But apparently, it was. Steve Jobs, as we all know, is the result of an early experiment in cloning, grown in a petri dish from the genetic material of Prince Machiavelli. Everything he does is deliberate, and his motives are never what they seem.
Let us not forget (or allow him to forget) that while he was serving as advisor to the Apple board and to the CEO he got rid of, while he was promoting Apple and talking up its future and advising developers not only to develop for it but to buy Apple stock, he was quietly (as quietly as possible) selling off all but one share of his own Apple stock.
As it turns out, the FUD was apparently calculated. It looks like Steve decided that if you're going to swim in a smaller pond, you'd better be the big duck. Power Computing had become less a partner in expanding the Mac market than a competitor to Apple in the niche it was being forced into. So Steve employed some FUD and $100,000 to sabotage Power Computing's IPO, drive a wedge in its top management, destroy a competitor, and gobble up its assets. Although I hate to say it, I think it was smart: Competition may be good, but this particular competition at this particular time wasn't helping Apple post the good numbers that are all that will impress the general press and the stock market. Smart, but ruthless.
If it sounds like I have strong opinions about Mr. J, I confess it. Who doesn't? Mine, at least, are complex. Although I would rather eat nails than work for him, I do think that he's incredibly focused, that he is probably going to turn Apple around in terms of focus and PR, and that most of his ideas for Apple's future are sound.
He shared some of those in that keynote address.
One of the most intriguing is that Apple and Microsoft will share Java technology.
There are those who think that Microsoft has just found its tool for co-opting Java. The scenario is: Microsoft ships Internet Explorer with no support for JFC on Windows and the Mac, with IE being the default web browser on all platforms, and JFC is dead. At least so far as the Internet is concerned; as Lou Grinzo reminds me, that doesn't necessarily mean JFC is dead in desktop applications. But...I always thought that imitation was the sincerest form of flattery. Now I think maybe the sincerest form of flattery is Embrace and Extend.
Emulation is another sometimes controversial form of imitation, but the emulation controversy is different from the software patent controversy or the look-and-feel copyright controversy or the clone licensing controversy.
Kevin Fowler wrote to say:
I enjoyed your emulation comments in the August 1997 Dr. Dobb's. As a former Macintosh Application Environment developer at Apple, I remember trying to come up with the most convoluted emulation chain. The best that actually ran was:
An UltraSparc running M.A.E. (which emulates A/UX 3.XX running on a 68K mac).
*SoftPC running inside MAE.
**Free //e running inside SoftPC.
***Sweet16 -- the "secret" 16-bit Apple II virtual machine.
****Running "Sounder" a sweet16 app.
I also got the Apple UCSD p-system up & running on the same emulation chain.
Okay, that's weird, but hardly controversial.
Another reader, Michael Bedward, wrote from Sydney to remind me that I shouldn't have let my subscription to the weekly British science magazine New Scientist lapse. He says that the May 15th issue had a fascinating article "about code-breaking efforts in England during World War II, including a description of the two Colossus computers that were built to help decode messages produced by the German Lorenz machines." What caught Bedward's fancy were the following details:
It closes with a comparison of the processing time for programs run on a Pentium that emulate the operation of the machines from 1943. A program that emulates the Colossus takes twice as long on the Pentium as the original machine took. Even more striking, another program that emulates the "Bombe", a machine designed by Alan Turing and Gordon Welchman to help crack the Enigma codes, takes 18 hours on the Pentium compared to 15 minutes with the original hardware. I found these results amazing but strangely satisfying.
Now we're getting closer to the controversial stuff.
I decided to emulate Kevin Fowler a bit by doing a little circular emulation.
Several years ago, I got e-mail from a guy in Colorado, saying, in effect, that he had emulated Apple's HyperCard on UNIX. What he had was a product called "MetaCard" that looked and acted a lot like HyperCard, but ran on UNIX systems. When it became clear to him recently that the commercial opportunities were on Wintel systems, he ported MetaCard to Windows (95 and NT).
MetaCard is a tool for multimedia authoring and GUI development. Anything developed in MetaCard will run unmodified on any supported platform, without recompiling or preprocessing. Native look and feel is provided on all supported platforms.
MetaCard uses a scripting language derived from HyperTalk, the scripting language inside HyperCard. MetaCard adds regular-expression pattern matching, associative arrays, binary data manipulation, HTTP GET and POST support, "URL" as a semiobject (container, in HyperTalk parlance). These and other Internet-related features make it an appealing tool for Internet/intranet server programming. It can execute scripts from text files, making it a candidate for batch and CGI programming. It hits me where I live, being more flexible than a code-free development tool, but easier and more RAD than Java or C++ programming.
As of the August beta release of 2.1.1, MetaCard exists for the following platforms: Win32 (Windows 95, NT, and Windows 3.1 with Win32s), HP9K700, SPARC Solaris, SPARC SunOS, Irix 5.3-6.X, Solaris x86, Linux, and RS/6000. The ftp site at ftp://ftp.metacard.com/MetaCard/2.1.1B5/ has a free, limited version called the "MetaCard Starter Kit" and a demo. (It's limited in scriptability, but you can actually use it to develop prototypes, multimedia presentations, and complete applications that you can distribute to others.)
I decided to download the Win32 version and see how it ran on VirtualPC on my PowerMac. Now this is not a fair performance test of MetaCard, since VirtualPC (from Connectix) is painfully slow on my machine (as is SoftPC from Insignia Solutions, which Kevin Fowler used in his long emulation chain). Also, my PowerMac 8100/100 is not, alas, a state-of-the-market benchmarking machine. I just wanted to see if it would run at all.
VirtualPC is usable if you have a fast machine. Apple clone makers are picking up on it. Motorola and Umax Computer are bundling it with new Mac clones, and Newer Technology, a company that sells processor upgrades for Macs, ditto. Connectix says that Virtual PC supports all the hardware functions of a standard MMX Pentium-based PC. Part of the price of the program is a Windows license, and VirtualPC installs Windows 95 or Windows 3.11 on the Mac as part of its installation.
MetaCard isn't really usable in this configuration, but I'm impressed that it runs under emulation at all. And now Scott Raney, MetaCard's inventor, says he's working on a native PowerPC version. Closing the circle, I guess you'd say, and bringing it back to the Mac.
Dr. Dobb's Sourcebook Contributing Editor Hal Hardenbergh has more than once reminded us (see his "DTACK Revisited" column, January/February 1997, for example) that any conceivable emulated Foobar is necessarily slower than the real Foobar.
Hal's right of course. No controversy there. Except that there is. The controversy revolves around the fact that, inefficient or not, there is a lot of emulating going on, from the 68K emulation in the PowerMacOS and the Blue Box implementation of the MacOS in Rhapsody (which Apple insists, with some justification, is not emulation, but still...) to Java.
If emulation is necessarily slow and if speed matters, why do people keep doing emulations?
The unstated assumption seems to be that, while extra layers of software undeniably cost something in performance, the end user is willing to pay that price for the benefits the extra layers provide. I won't try to characterize those user benefits attributable to emulation; it's easier to see the benefits to the vendor. In the case of Rhapsody, Apple is a one-legged man trying to change his shoe while running, and the solution the company has settled on is to put the new shoe on over the old one (And what? Let the old one eventually rot away?). In the case of Java, the goal of the vendor is to trip the Microsoft juggernaut. (Which didn't work out entirely as planned, now that Microsoft has done an end run through Apple's territory.)
Well, whatever the motives and purported benefits, is there any reason to believe that end users will trade performance for other benefits, like ease of use?
I think the answer hinges on an unanswered question in psychophysics: How fast is fast enough? That there is some speed that is fast enough seems clear. There must come a point beyond which further speedups of window opening or application launching or whatever do not add any perceivable (or at least valued) user benefit. And if we keep speeding up the hardware, we'll get to that point. Even for emulation. However, based on this week's limited experiment of running a Windows application in a 32-MB partition on a 100-Mhz PowerPC 601 CPU, I'd say we ain't there yet.
If you're really sucked in by this emulation stuff, here are some sites where you can indulge your perverse tastes: The http://emulation.net/ site is a good place to read about or download emulators of all sorts of machines if your target machine is the Macintosh. Remember the Commodore 64, the Tandy CoCo, the Atari ST, the BBC Micro, the Sinclair ZX81? How about Colecovision, GameBoy, Sega Genesis? Arcade machines like Joust, Robotron, Lunar Lander, Crazy Kong? Download the 68K or PowerPC emulators and emulate 'em on your Mac. If you're into emulating nonexistent computers, you can run a Turing Machine at http://www.dbit.com/~greeng3/cgi-bin/tm.cgi. It's a little hard to assess the performance of an emulator of a theoretical machine. For emulators for other target platforms, see http://www.chac .org/chhistpg.html#HistPg_Emul, http://wilbur.stanford.edu/, and http:// www.freeflight.com/fms/comp/.
Chuck Downing agrees that I haven't been tough enough on Java books. He wrote to tell me that he bought Web Developers Guide to JavaBeans, by Jalal Feghhi, from the Coriolis Group based on my recommendation (see "Programming Paradigms," September 1997) and found ten spelling or grammatical errors in chapter one alone. I suspect that Chuck and I are not working from exactly the same text; one of the two sample errors he sent me is not an error in my copy of the book. But yes, the book has typos. The one that Chuck sent me that I also found: "read-world" for "real-world."
"Is an entire industry in trouble when one of its gurus condones such laxity?" Chuck asks, shamelessly trying to get back into my good graces after nailing me for not catching all the typos in Feghhi's book. I don't know if the entire industry (Which industry, I wonder? Software development or book publishing?) is in trouble, but shoddy editing in computer-book publishing is epidemic. Publishers are under great pressure to get books out fast, and they don't do the job they should in editing the books, or even evaluating the books' publishability. But while I don't condone noncrucial typos, I don't usually report them: Most computer books have typos. Now and then, though, I come across editing errors that really impact the understandability of the material; those I report. And once in a while, I find code samples that don't even compile. That's inexcusable.
I've been reading a pretty good book on the history of UNIX, Usenet, and the Internet. It's called Netizens, and it's by Michael and Ronda Hauben (IEEE Computer Society Press, 1997, ISBN 0-8186-7706-6).
One of the things I like about it is the copious quotations from the actual participants in the developments it discusses.
For example, I learned what I take to be the true story of the invention of the UNIX command grep, in the words of Doug McIlroy, for whom grep was written by Ken Thompson. I've heard several versions of what grep stands for, but according to McIlroy, Thompson was just collapsing the editor commands it simulated: g/re/p, or "global, regular expression, print." It was McIlroy, incidentally, who pushed for the idea of pipes in UNIX, which one learns a couple of pages earlier.
There are many histories of the Net, from the memoirs of participants to dry academic reports to popularized accounts for mass consumption. The Haubens have produced a readable but well-documented story of the development of the Internet.
They spent years working on the book, and really seem to have done their research.
Java book publishers ought to emulate them.
DDJ