Hi Robert,
I am an occasional reader of your column (truthfully, mostly when it comes up on slashdot). I usually find your comments insightful, or at least thought provocing. I'm afraid the column at the subject is a stark exception to this rule (http://www.pbs.org/cringely/pulpit/pulpit20060420.html). If you'll excuse the strong words, the claim made was nothing more then wishful thinking, with no possibility of basing it on anything real.
Before I get to "why", allow me to introduce myself. My name, as you can probably see from the email headers, is Shachar Shemesh. I am founder and CEO of a small Linux consulting company in Israel (http://www.lingnu.com). More to the point, however, I am (or, at least, used to be) a Wine hacker. Feel free to search for my name at http://www.winehq.com/site/who. As the task you claim Apple has undertaken is, in fact, identical to developing a second "Wine", I think I have some authority in assessing how likely that is. I also took the liberty of CCing the wine-devel list, so that if anyone there wishes to claim me wrong, they can.
And as for the likelihood, I can answer that question rather easilly. The answer is "not very". I would even go as far as to say that the answer is "extremely unlikely".
Wine is a huge project. On last count it had over 1.5 million lines of code. Most of the code inside Wine is written in Win32. Yes, it's a Linux project written, mostly, in Win32. The reason is that the so called "Win32 API" is a convulted huge heap of layers upon layers of miscellanious implementations of anything Microsoft decided to give developers because it seemed like a good idea at the time. Some of these functions misbehave, and some programs rely on this misbehaviour in order to work. Not all of the functions, and hardly any of the misbehaviours, are documented in any way.
The Wine project has been busy, for over ten years now, in duplicating said development. Despite what may appear in your column, the reason it has been taking so long is NOT Microsoft's disapproval. For all intent and purposes, MS has no technical means of slowing Wine down, and here is the main reason - Wine only cares about running actual applications. Microsoft is, of course, at liberty to change and add interfaces as much as it wants, but Wine will only care about these interface changes if and when actual applications start to use them. Over this last point MS has very little control. In that respect, I think it should be clear that Apple is in no better starting position to duplicate the Wine effort than Wine is, and there is no reason to think it will do better.
Which brings us to the task at hand. Because the purpose of an API replacement is to be "bug compatible" with the original, we can already know how the first versions of such an effort from Apple will look. They will probably be able to run "Solitare" and "notepad", but not much more. We know that simply because Wine used to be there itself. Getting from this "90%" to "100%" takes a considerable amount of time. It makes little sense, and has little return on investment, for Apple to take this herculean task upon itself, when it can get to 95% of the task by simply taking the Wine code and adapting it to Mac OS X.
Don't understand this to mean that the next OS X on Intel will not be able to run Windows code without emulation. What I am saying is that it likely WILL be able to do so, but using Wine as its technology. After all, work to get Windows programs running on a Mac using Wine was underway long before Apple made the CPU switch, using thin emulation services. Dumping the emulation (and, more importantly, the endianity misalignment) is only likely to boost this effort. This, however, will happen whether Apple endorses it or not.
Hoping your next column will bring us back to the level of writing you usually produce.
Shachar