Licensing iTunes/iPod Compatibility

Wouldn't it be interesting if Apple allowed third parties to support iPod and iTunes right about now? Creative, Samsung, et al, must just be thrilled by the Zune announcement.

Or maybe just wait for Zune to come out, wait until Microsoft has spent a billion or two getting up to, say, 20% market share, and then do it.

Just a thought.

Windows on the Mac, Revisited

One of the comments on a recent post points out that he (or she?) has blogged on this topic before and in more detail. (I'm hardly the first to observe that WINE, Crossover, et al are, at least conceptually, a far better solution to this problem than Parallels or Boot Camp.)

However, on reading his comments, which I summarize below as five reasons Apple should do this and five reasons it shouldn't (I've paraphrased and renumbered):

Reasons it Should

1. The hard work is done (WINE etc.)
2. Since they're dropping Classic support...
3. Vista will not support EFI in first release...
4. Apple desperately wants to break into the Enterprise market...
5. Leopard seems to have few compelling new features

Reasons it Shouldn't

6. Fear of Microsoft retaliating
7. Support would be a nightmare
8. Microsoft's Mac Business Unit would be alienated
9. Not a new issue and they've never done it before
10. It's not very Apple

Here's my reaction to said reasons.
1. Agreed.
2. That's just stupid. It's not a reason.
3. Irrelevant.
4. Yes, but so what?
5. So, you know what's in Leopard?!
6. Far-fetched. What could Microsoft try* to do that's more malicious than "Zune"?
7. Absolutely true and a good point. Might have to be a free download "beta" like Boot Camp.
8. Possibly true.
9. Completely and utterly wrong. Aside from some horrible kludges (like Mac Charlie and the PC compatibility card for early PowerPC Macs) which were essentially low-end PCs that shared the Mac's monitor, Apple has never had x86 CPUs in its machines, and Mac OS has never run on x86 CPUs.
10. Simply a matter of opinion, and I think far MORE Apple like than Boot Camp or Apple's previous PC compatibility efforts.
* Actually, Zune is probably a gift for Apple, since the real victims are PlaysForSure licensees. But I doubt Microsoft considered Apple's feelings.

Mentioned, but not enumerated, is a very important reason -- the fact that a company which is on the cusp of developing a native Mac version of a program might decide simply to support the Mac's Win32 compatibility layer instead. This is a real issue, but it's not really clear that it doesn't already exist because of Parallels and Boot Camp. If it's a key productivity app, then chances are you'll want it native. Photoshop native is going to kick pretend Photoshop native for the foreseeable future.

The Bottom Line

Apple's core PC market is people who buy their own computers or can tell their company which computer to buy for them. The whole enterprise thing is never going to work out because enterprise IT hates, loathes, and fears Apple (subject of another blog post I think :-) ).

There are a certain number of people out there who want to use both a Mac and a PC for whatever reason. (I'm one of them.) You can only really use one at a time. I would argue that the vast majority of these people want to use their Macs for almost everything and their PCs for gaming and/or 3D apps (like 3DS Max) and one or two random Windows-only apps.

At the moment, Apple and Dell (say) are selling these folks two computers every X months for 1.7Y dollars. If Apple can produce a computer for Y dollars that serves all these people's needs then their customers will be very happy, and either upgrade more frequently or buy a higher end computer. In my case I'd also save on desk space, power bills, fan noise, and carpet wear from sliding my chair from desk to desk).

If Apple is working on this, it's doing a very good job of keeping it secret (e.g. it is either doing it from scratch -- unlikely -- or working on Open Source projects and either not pushing back its changes or somehow concealing its contributions or working with someone like Codeweavers and maintaining absolute radio silence). So it probably isn't. That said, the solution I'm describing is going to happen whether Apple does it or not. So all the arguments against it are, in the end, irrelevant.

Creating an Application in Five Minutes

It used to be really hard to build a new application. If you find a copy of the original Inside Macintosh there's a "roadmap" application which is, in essence, the sketch of a minimal Mac app (actually, it's not even that, because it doesn't implement multiple windows, or a bunch of other things). This simple text editor program occupies four large pages of commented source code, and figuring out what it all means will involve many trips through the first three volumes of Inside Macintosh.

Writing applications for the Amiga and Windows wasn't much (any?) easier. Note that I say "writing applications" and not "programs". Writing computer programs had been really easy up until then...

E.g. almost everyone who had used a computer knew you could do something like:

> 10 PRINT "HELLO"
> 20 GOTO 10
> RUN

on a computer in a department store and the screen would fill with "HELLO"s and the computer would kind of lock up until a salesperson unplugged it or (and this would be astonishing when it happened) typed CTRL-C.

It was even pretty easy to write a program for a mainframe computer. Something like:

include 
void main (){ printf("hello"); }

could actually be turned into a reusable executable fairly easily. (You also needed to type some arcana to compile it.) Shell scripts were even easier.

But it took a long time for graphical user interfaces to actually simplify the task of programming, and there were many missteps and dead ends along the way.

Probably the first truly easy-to-use GUI programming tool was HyperCard. HyperCard was so easy to use and so good at what it tried to be (and so oddly implemented) that it has never really been bettered. Even the various attempts to clone HyperCard (notably Toolbook, SuperCard, Runtime Revolution) ever succeeded in making a completely live development tool (i.e. where using your program and developing your program were seamless acts). Indeed, I would suggest that a web-based HyperCard clone is a true killer app.

Various less ambitious but more conventionally useful imitations of HyperCard, notably Visual Basic and Delphi, appeared, as did class libraries which allowed you to subclass a bare-bones application and its components, such as MacApp, PowerPlant, and MFC. Today, most of our development tools are spiritually derived from Visual Basic and its brethren, i.e. HyperCard with a sharp line between "development" and "use", or MacApp and its brethren, i.e. a class library which assumes you'll be writing a "totally general" app, where "totally general" means "something a lot like a common office app". Some of our development tools are more primitive than either, but let's not discuss Perl, PHP, et al here ;)

What all this means is that you can write "hello, world" using a GUI-based IDE in about fifteen seconds, except that it takes 15s to launch your development environment, and about 30s to five minutes to compile and run it. Versus getting the same thing done instantly in UNIX or on a Commodore 64 twenty-something years ago.

I've recently started using a new Mac-based game development tool called Unity and it's interesting ... amazing even ... to realise that in many ways it's closer to HyperCard than Visual Basic. You do need to explicitly save changes (probably not a bad thing). You can create a 3d game application (well, you know, the gaming equivalent of "hello, world") in about thirty seconds. There is no sharp line between playing and development. It still takes fifteen seconds to launch the IDE and 30s to compile, but...

Game development just got a little more interesting.

Running Windows Apps on a Mac & Other Stories

One of the best stories I've heard about Apple's history concerns Ellen Hancock, whom Gil Amelio brought into Apple as Chief Technology Officer. Her role is pretty much overlooked these days, but she is responsible for pulling the plug on Copland, looking for a viable replacement, and -- ultimately -- acquiring NeXT, Steve Jobs, and Avie Tevanian (her successor).

Anyway, back to the story which I am reciting from memory. Ellen Hancock comes in to work and she is the most senior woman -- ever -- at Apple, surrounded by a lot of cocksure guys. She holds a meeting with her key reports and during the meeting utters the following statement. "One of the things that's always puzzled me about Macs is why when I have a Windows .exe file on my desktop and I double-click it, it doesn't just work." The reaction is one of utter consternation. How could anyone working at Apple, let alone its new Chief Techology Officer, be so utterly clueless. And then it starts to dawn on them:

1) She has a PhD in Maths.
2) She has done serious shit at IBM.
3) She's right.

Not long after this, Virtual PC added a feature which actually allowed .exe files to "just work" if you double-clicked them. It was a horrible kludge -- you double-clicked the .exe and Virtual PC (which claimed ownership of that type of file) launched, loaded up the last version of Windows you had run with it, booted Windows, copied the .exe file over to some place Windows (under VPC) could see it, and then attempted to execute it. If the .exe required a bunch of local context to work (as most Windows .exes do) it quite likely crashed.

But the principle was there.

The only word we've seen from Apple on Windows compatibility lately is (a) Bootcamp -- a pretty much wholly unsatisfactory option for serious users (it's a great security blanket for switchers). (I am not going to reboot my Mac to run some dumb Windows app; I hardly reboot my Mac at all period. If a Mac OS update requires a reboot, I often leave the dialog up for days before I finally click "Restart"...); (b) pushing Parallels Workstation -- almost as unsatistfactory as Bootcamp since it won't run games, which are Windows's killer app; and (c) a statement by Phil Schiller that Apple is not going to implement virtualization in Leopard.

So Apple has implemented one pretty much lousy option, is pushing a second, also lousy option, and has denied that it will implement the second lousy option itself.

What Apple hasn't denied, because no-one has asked, is whether it will implement the correct answer to Hancock's question -- a Win32 compatibility box in the Mac OS X block diagram. You know, those rectangular diagrams which show "QuickTime" in a box that is kind of offset on top of another box labelled "Quartz". The one with "Carbon" and "Cocoa" sitting side-by-side.

This isn't the stuff of Science Fiction or a bad rumor page. It has existed under UNIX for years, Linux for not-so-many years, and is currently available for free as Open Source WINE (WINE is not an Emulator) and in various commercial forks. Apple in fact used to sell an equivalent product for UNIX that let you run Mac apps on Sun workstations. Unlike bad option #1 it doesn't require rebooting your Mac, and unlike bad option #2 it doesn't require partitioning your hard disk, booting up Windows in a virtual environment, or giving up games. Word has it that World of Warcraft (for Win32) actually runs faster under WINE than under Windows itself.

Let's see. This option is Open Source or (for certain versions) fairly inexpensive to license, works better than any other option, satisfies the it just works mantra, is unbelievably cool (as in "would make a kickass TV ad"), is already out there, and Apple hasn't denied that it is working on it. Oh and it doesn't sell more Windows licenses.

But, you know, maybe Apple will just buy Parallels.