David's Stone
{{{Speculation / Need for information}}}
allenmcjones (whether you believe he is credible or not) had mentioned something that is integrated with a lot of products called "David's Stone" which he asserts is "the big one."
It got me thinking, because of the very nice name. David's Stone obviously killed Goliath.
Now, whether or not there is some actual project at Apple called "David's Stone" I do not want to debate. What is obvious about the situation is that the mentality of "David's Stone" is in place, as we see in the "Switch" commercials.
So, if we can call a truce on the authenticity of the code name, I would appreciate it, and for now, and for the sake of argument, let's just call it "David's Stone." (Not quite as poetic as "Priam's Arrow," but then again, Achilles was not a lumbering giant.)
The first question would be, who would be Goliath? Microsoft or Intel? I think the answer is both.
In thinking about this, my mind wandered back to the Transmeta situation, where the "Code Morphing, "if I understand correctly, is flashed onto a chip. <a href="http://transmeta.com/technology/architecture/code_morphing.html"; target="_blank">Link to Transmeta Diagram and Information</a>
Transmeta, though, assumes that an OS, Windows or Linux, will be installed over this chip, sending it instructions....
As I wondered, I had been thinking about not only X86 emulation but MS behavioral emulation: no one wants to run Windows on a Mac: they just want their Windows programs to run on a Mac. {Attaching the GUI on the front end of the Windows applications, of course, would be problematic, but that would be the price one would pay for using an Windows application.} Wintel apps, like Apple apps, from what I understand, do not only make calls to the processor, but to OS functions as well. This obviously is a problem in terms of licensing.
My point is, essentially, if Transmeta can put an x86 instruction translator in front of their CPU, why can't Apple?
Would a dedicated, on-board, flashable translation chip which provides this ability avoid all the problems of speed that plague emulation applications like VirtualPC? Obviously this is possible, as Transmeta can do it, and it removes the translation load from the main CPU, freeing it to do the operations it needs to do, without bogging down.
This hypothetical translation chip would not cost much, I think, to fabricate, as it operates solely as a limited-task layer in front of the main CPU. (It would cost much more to develop.) Whoever knows anything about this, I would be interested to hear your comments on feasibility.
The issue once again, it seems, how to deal with OS functionality and calls to Windows functions. No idea what to do about this. Obviously Connectix has found some way to do this at least in a limited fashion.
The question then becomes, of course, what laws Apple would be breaking by making this chip.
I am not sure about this either. I do not know what Transmeta's agreement with Intel/MS is, or whether they even have one. Are the instructions common property, and the implementation patented? Somehow AMD manages to compete with Intel, so they had to know and assumably be able to use the instructions that were coming to the chip, so those things can't be Intel's property.
My point is, essentially, that a possibility for a "David's Stone" could be not software emulation, but a hardware-based solution.
Anyway, my feeling is that if anything hiding in Apple's pocket did could ever slay Goliath, this could be it.
Though this has been a little rambling, maybe someone who knows much more about this than I could comment on these ideas. I know I am seeing the forest and not the trees here, and the devil is probably in those details. However, I am still curious to hear considered comments on these ideas. Or.... perhaps I took a toke from Meader's pipe.
Hope Springs Eternal,
Mandricard
AppleOutsider
allenmcjones (whether you believe he is credible or not) had mentioned something that is integrated with a lot of products called "David's Stone" which he asserts is "the big one."
It got me thinking, because of the very nice name. David's Stone obviously killed Goliath.
Now, whether or not there is some actual project at Apple called "David's Stone" I do not want to debate. What is obvious about the situation is that the mentality of "David's Stone" is in place, as we see in the "Switch" commercials.
So, if we can call a truce on the authenticity of the code name, I would appreciate it, and for now, and for the sake of argument, let's just call it "David's Stone." (Not quite as poetic as "Priam's Arrow," but then again, Achilles was not a lumbering giant.)
The first question would be, who would be Goliath? Microsoft or Intel? I think the answer is both.
In thinking about this, my mind wandered back to the Transmeta situation, where the "Code Morphing, "if I understand correctly, is flashed onto a chip. <a href="http://transmeta.com/technology/architecture/code_morphing.html"; target="_blank">Link to Transmeta Diagram and Information</a>
Transmeta, though, assumes that an OS, Windows or Linux, will be installed over this chip, sending it instructions....
As I wondered, I had been thinking about not only X86 emulation but MS behavioral emulation: no one wants to run Windows on a Mac: they just want their Windows programs to run on a Mac. {Attaching the GUI on the front end of the Windows applications, of course, would be problematic, but that would be the price one would pay for using an Windows application.} Wintel apps, like Apple apps, from what I understand, do not only make calls to the processor, but to OS functions as well. This obviously is a problem in terms of licensing.
My point is, essentially, if Transmeta can put an x86 instruction translator in front of their CPU, why can't Apple?
Would a dedicated, on-board, flashable translation chip which provides this ability avoid all the problems of speed that plague emulation applications like VirtualPC? Obviously this is possible, as Transmeta can do it, and it removes the translation load from the main CPU, freeing it to do the operations it needs to do, without bogging down.
This hypothetical translation chip would not cost much, I think, to fabricate, as it operates solely as a limited-task layer in front of the main CPU. (It would cost much more to develop.) Whoever knows anything about this, I would be interested to hear your comments on feasibility.
The issue once again, it seems, how to deal with OS functionality and calls to Windows functions. No idea what to do about this. Obviously Connectix has found some way to do this at least in a limited fashion.
The question then becomes, of course, what laws Apple would be breaking by making this chip.
I am not sure about this either. I do not know what Transmeta's agreement with Intel/MS is, or whether they even have one. Are the instructions common property, and the implementation patented? Somehow AMD manages to compete with Intel, so they had to know and assumably be able to use the instructions that were coming to the chip, so those things can't be Intel's property.
My point is, essentially, that a possibility for a "David's Stone" could be not software emulation, but a hardware-based solution.
Anyway, my feeling is that if anything hiding in Apple's pocket did could ever slay Goliath, this could be it.
Though this has been a little rambling, maybe someone who knows much more about this than I could comment on these ideas. I know I am seeing the forest and not the trees here, and the devil is probably in those details. However, I am still curious to hear considered comments on these ideas. Or.... perhaps I took a toke from Meader's pipe.
Hope Springs Eternal,
Mandricard
AppleOutsider
Comments
Now, let's say you're a developer. Your Windows code now runs well on Windows (obviously), the upstart Lindows, and Linux + WINE, and now Macintosh. You look at the cost and time and personnel involved in keeping your Mac port up to date. Do you can it and tell your customers to use the Windows version? It's tempting, isn't it?
If you're a Windows developer who was contemplating a Mac version, there's much less of a reason to make one now, isn't there? Your customers can just use the Windows version. Now you're saved the trouble of finding and hiring a Mac programmer or retraining staff, buying new hardware, keeping up another codebase, etc.
If you don't believe this could happen, think about companies like UPS telling their Mac-using customers to "just use VPC" (before UPS did the smart thing and went web-based).
Curiously, Microsoft sits back and does nothing. Intel also acts as if nothing untoward had happened. They bide their time until a critical number of apps are Windows-only (MS might help this along by killing Mac Office, since the same people can buy Windows Office). Now, guess what? Apple's development environment and its APIs (Cocoa, Carbon and Java all together) are irrelevant except for platform loyalists like Omni and Bare Bones, and MS effectively controls Apple's software platform, while Intel effectively controls their hardware platform. And our would-be David is now at Goliath's mercy.
Whooops.
<strong>Despite the efforts of a number of companies, including Microsoft, reverse engineering is still legal. It just has to be done very carefully. There are no legal difficulties in theory, although that doesn't mean that MS or Intel wouldn't sic lawyers on Apple and/or the chip supplier anyway.
Now, let's say you're a developer. Your Windows code now runs well on Windows (obviously), the upstart Lindows, and Linux + WINE, and now Macintosh. You look at the cost and time and personnel involved in keeping your Mac port up to date. Do you can it and tell your customers to use the Windows version? It's tempting, isn't it?
If you're a Windows developer who was contemplating a Mac version, there's much less of a reason to make one now, isn't there? Your customers can just use the Windows version. Now you're saved the trouble of finding and hiring a Mac programmer or retraining staff, buying new hardware, keeping up another codebase, etc.
If you don't believe this could happen, think about companies like UPS telling their Mac-using customers to "just use VPC" (before UPS did the smart thing and went web-based).
Curiously, Microsoft sits back and does nothing. Intel also acts as if nothing untoward had happened. They bide their time until a critical number of apps are Windows-only (MS might help this along by killing Mac Office, since the same people can buy Windows Office). Now, guess what? Apple's development environment and its APIs (Cocoa, Carbon and Java all together) are irrelevant except for platform loyalists like Omni and Bare Bones, and MS effectively controls Apple's software platform, while Intel effectively controls their hardware platform. And our would-be David is now at Goliath's mercy.
Whooops.</strong><hr></blockquote>
I heard rumors about a technology Apple was considering to include in OS X early on called "Red Box" which emulated the Windows operating system simular to way Classic is done now.
I guess Apple realized that would be stupid like you said, and it would probably be dog slow like VPC anyway.
<strong>Despite the efforts of a number of companies, including Microsoft, reverse engineering is still legal.</strong><hr></blockquote>
actually, reverse engineering is usually illegal. reengineering using documentable clean room standards is legal but much more difficult to accomplish.
Despite the efforts of a number of companies, including Microsoft, reverse engineering is still legal. It just has to be done very carefully. There are no legal difficulties in theory, although that doesn't mean that MS or Intel wouldn't sic lawyers on Apple and/or the chip supplier anyway.<hr></blockquote>
That is interesting. Thank you for clarifying.
[quote]Now, let's say you're a developer....You look at the cost and time and personnel involved in keeping your Mac port up to date. Do you can it and tell your customers to use the Windows version? It's tempting, isn't it?<hr></blockquote>
AND
[quote]If you're a Windows developer who was contemplating a Mac version, there's much less of a reason to make one now, isn't there? Your customers can just use the Windows version. Now you're saved the trouble of....<hr></blockquote>
AND
[quote]Curiously, Microsoft sits back and does nothing...... And our would-be David is now at Goliath's mercy.<hr></blockquote>
Amorph, you make excellent points, and you paint a dismal picture. Perhaps the idea was loony. But there is a need out there for Apple to grab more market share, and to make inroads into markets that are currently unaccessible. DS might allow Apple to make hardware inroads into these markets in ways that were previously unexpected. Perhaps it could only work on the XServes...
The question then would be, what could be the incentives put into place to keep Mac software developers working?
Perhaps if the the OS moves in, people might get addicted to it, as we all are, and buy more machines, where developers would start taking a look at the platform-specific advantages, and Goliath goes down... But that might be too long a wait.
Anyway, It was idle speculation on my part, but I am still intrigued by the idea. How did Transmeta do this so seamlessly? What would the speed hit be? (A G5 is no David's Stone. That is just the perennial spitting contest.)
If I have gone loony, the question would be what a magic bullet could be: it would have to be tightly integrated into both the OS and the machine. It would have to necessitate Apple hardware and the OS, and it would have to be not just wanted, but needed by most segments of the market.
Hope springs eternal,
Mandricard
AppleOutsider
Hasselhoff will be making design decisions after a few hits of weed.
To use an emulator (be it software or hardware) that allows you to run Windows programs within an Apple operating system precludes either of two things: You already have Apple hardware to run OS X with said emulator OR you have a means to run OS X on x86 hardware and run Windows programs without Windows OS layer below it.
In one case, the switch has been made, why bother scraping the bottom of Windows developer barrel. In the other case, Apple loses hardware sales and profits.
Tilt! Your speculation is dead.
Screed
[ 07-11-2002: Message edited by: sCreeD ]</p>
Not to split hairs, but these are basically the same thing.
How could Mac machines run Windows software without diminishing the need for Mac software development.?
What if only one non mac software title could run at any given time? Maybe it would be an app called iSwitch and it chooses an app from a foreign OS to run sans Windows. Data can then be printed, converted, viewed, saved but not as a true OS workspace replacement.
This would reduce the feature to a convenience as opposed to a replacement to the MacOS and Mac specific software.
But maybe I'm dreaming...
MSKR
The stone that slays Goliath would be the ability to run Mac programs on a Windows machine, not the other way around.
This was the idea behind the "Red Box." A developer would build a Mac application first, then use the 'Rhapsody'-era developer tools to port later to Windows.
Then Goliath is at Davd's mercy.... :cool:
<strong>but if that were to happen, why buy mac hardware? why not stick with a cheap pc and get the whole world in software?</strong><hr></blockquote>
Well, it was 'Yellow Box', actually, which was a migration of the OpenSTEP APIs that ran on PPC, NT, Solaris, and HP/UX. You now know it as Cocoa. 'Blue Box' turned into Classic. 'Red Box' was a *rumored* Windows emulation for PPC hardware.
Yellow Box wasn't Mac OS X on Intel, it was Cocoa apps running on Windows. Given that most Mac apps have Windows versions, there's really no big shift to the consumer.
The concept was that a developer could write to Yellow Box APIs (Cocoa) and compile for both Mac OS X and Windows. Relatively free cross-platform development. 'Relatively free' because the Yellow Box APIs wouldn't cover all native technologies on each platform, but virtually all the UI and foundation code would move pretty well.
When developers balked at Yellow Box, Apple got to work on Carbon and did away with the cross-platform effort as it appeared that it wasn't going to justify the work involved.
Apple's got some pretty nifty stuff that they can leverage, but thus far has opted not to in most cases. Maybe it's a matter of keeping the peace.
[ 07-12-2002: Message edited by: johnsonwax ]</p>
<strong>but if that were to happen, why buy mac hardware? why not stick with a cheap pc and get the whole world in software?</strong><hr></blockquote>
Isn't that what the other 95% are doing right now as we speak? They have the cheap hardware, and the world in software...
But they lack the beauty and the integration
<strong>
Maybe it's a matter of keeping the peace.
[ 07-12-2002: Message edited by: johnsonwax ]</strong><hr></blockquote>
Keeping the peace.....or "non-competition" contractual obligations?
<strong>actually, reverse engineering is usually illegal. reengineering using documentable clean room standards is legal but much more difficult to accomplish.</strong><hr></blockquote>
In other words, like I said, it's legal. It just has to be done carefully. The courts have guarded the right to reverse engineer scrupulously and consistently, because it's as fundamental a right as IP law can define. The reason you have to be careful is so that you can prove you reverse engineered in the first place, instead of just ripping off the other company's work.
[ 07-12-2002: Message edited by: Amorph ]</p>
<strong>Not to split hairs, but these are basically the same thing.</strong><hr></blockquote>
Except that Linux + WINE is incredibly fussy, and Lindows isn't.
<strong>
Yellow Box wasn't Mac OS X on Intel, it was Cocoa apps running on Windows. Given that most Mac apps have Windows versions, there's really no big shift to the consumer.
The concept was that a developer could write to Yellow Box APIs (Cocoa) and compile for both Mac OS X and Windows. Relatively free cross-platform development. 'Relatively free' because the Yellow Box APIs wouldn't cover all native technologies on each platform, but virtually all the UI and foundation code would move pretty well.
When developers balked at Yellow Box, Apple got to work on Carbon and did away with the cross-platform effort as it appeared that it wasn't going to justify the work involved.
[ 07-12-2002: Message edited by: johnsonwax ]</strong><hr></blockquote>
I remember developers balking at Yellow Box, because it would mean a total re-write of Mac applications to run natively, else they would have to run in Blue Box (Classic). But, as Cocoa, Yellow Box still is around. More and more apps are coming out written to the Cocoa API's, though most of the biggies are still Carbon.
I seem to also remember that the reason generally accepted at the time for Apple not releasing the Yellow Box API's for developers to compile to Windows, was licensing issues for their display format (Display PostScript?), as it would have meant paying licensing fees to Adobe or something and the devs wanted the tools to be free.
The reasons given by Amorph for not going with a Windows emulation environment are absolutaly correct. Developers, given a choice of maintaining 2 code bases, or 1 code base that runs, albeit somewhat handicapped, on 2 platforms would go with the path of least resistance and expense and simply produce Windows versions of their apps.
Once Apple went with their own display engine, thereby avoiding licensing fees, I always felt that Apple was holding back releasing the Cocoa API's for Windows until there was a saturation level of Cocoa Apps. Giving Devs the ability to write once, run anywhere was a corner stone of Next's strategy. And when Apple first bought Next, it was a major part of Apple's strategy. Gil Amelio once said "we have done the most beautiful thing in the world, we have made Windows invisible", refering to devs ability to write for Rhapsody and run on Windows.
I think now is the time to go back to this strategy. There are many Cocoa Apps out there, though most are not thought of as 'main stream' apps yet. This is partly due to the fact that they are Mac only apps. Even in the Mac community, given the choice of using a industry standard app like IE, or a Mac only app like OmniWeb, most will use the standard (Office is another example). The only way a Cocoa app can become 'main stream' is for it to run across platforms (or only on Windows......)
Now is the time to allow Mac Devs to have access to a larger market and allow their apps to become standards. This could, in my mind would, create the inertia for more apps to be written to Cocoa. In this case, a dev writes for the Mac and has access to the Windows market. Suddenly, Mac developers are at a major advantage. Their expenses go way down, as they can maintain a single code base, yet run everywhere. This is a major competitive advantage. Macs would get industry standard or superior apps at the same time or before the Windows world. Apple gets the advantage of having more apps concurrently available for the Mac and Windows, and the ability to control the API's. This is exactly opposite to the idea originally presented in this thread, yet I think it has the better advantage of being a David's Stone.
My ramble for the night
[ 07-12-2002: Message edited by: Tulkas ]</p>
<strong>
Keeping the peace.....or "non-competition" contractual obligations?</strong><hr></blockquote>
Well, Apple has had a contract with MS that expires next month, but I don't think that's it. With YellowBox comes a level of education and support that could have turned off more developers than it would encourage. Apple can't promote it as a silver bullet, because it isn't, and in the face of something like Win XP, which it would need to integrate with, it would certainly present a serious resource drain on Apple.
Except the problem is, what if a Cocoa app runs BETTER on Windows than on OS X? What then? What if Apple ports Cocoa to Windows, but because of Wintel hardware superiority, ALL Cocoa apps are faster on Windows? That would be a disaster....and possibly the reason Apple won't port Cocoa to Windows.