Re: There May Be an End-run for Apple Around Windows After All

[Shachar Shemesh]

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


-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html