Quite the opposite actually. Think about it, if you had a Mac/PC all in one, which OS would you buy software for? I'd say it's a no brain'er, the Mac of course. Now, how many people with this set up do you think would be screaming for more apps for the Mac OS? The more people with a Mac/PC the more the apps will be ported over to the Mac OS.
The fastest way to get a chunk of the other 95% is to get into their camp. "Look, you can now buy a Mac and run all you window's apps just as if you had bought a Dell." The Mac would become another PC. Haaaa but wait, here's the unsuspecting surprise by most of the PC users, once you use OS X, how many do you think would want to mess with Windows? Fact is most have never used a Mac.
The problem: People want to use what is "standard." This is a fact. Not what is better, but what is "STANDARD!" Windows, right or wrong is the Standard.
If Apple can actually get Windows to run flawlessly on Macs, only a stupid CEO would pass up on this opportunity.
My question is, can Apple legally do this and is it actually technically possible? :eek: </strong><hr></blockquote>
Like virtual pc, you would probably have to buy a retail copy of Windows and install it to have access to Windows apps. Or Apple could buy Windows at the OEM discount and include it with a copy of OS X that cost 199 or something. (But what is the chance of Microsoft agreeing to this?)
As to the "market forces" argument: What market forces, and how long are you willing to wait for the few there actually are to kick in? How long did we have to wait for a decent web browser again? And what market is there for all the millions of little vertical market apps that industry runs on? If someone's little special-purpose business app runs on Windows, you're running Windows. Alternatives? Where? And what guarantee is there that the alternatives won't suck in the same or different ways? We ended up rolling our own cancer data collection application after years of frustration with the stuff that's out there. It cost us a mint (especially since we're a non-profit), sucked up our development staff for a solid year, and we've been cleaning up after the (necessarily) abrupt release and transition since then - not to mention picking up all the projects we had to drop to concentrate on this. Guess which platform all the other apps runs on? Guess which one ours runs on? Guess what market pressure there is for a Mac version? None. Zip. Nada. Zero. As it was, the suckage of the other applications had to reach crisis levels before we felt compelled to roll our own, and we cut out as many costly options as we possibly could to get the thing out there and working. Sad as it may seem, this scenario is not unusual for software development.
I'm sorry for your experiences, but that's not really what I was thinking of. I'm not naive enough to think that simply including x86 emulation means that all developers drop whatever they're doing and start making Mac ports. What I'm thinking of is more like making a breach in the dam - it may be only a trickle at first, but it turns into a flood before long.
Let's just use Photoshop as an example. A Windows graphics shop needs new hardware. They've heard about the butt-kickin' 970 processor and realize they need to be on Macs to maximize their productivity. However, they can't afford both new hardware and new software simultaneously. So now we've got a chicken-and-egg situation - no point in buying Macs because their software won't run. No point in buying Mac Photoshop because it won't run on their x86 hardware. x86 emulation in OS X offers them a leg up to get over to the right side of the fence. They buy Macs, and run their Windows Photoshop in emulation mode. Then, as their budget allows for new software, they buy Mac versions of Photoshop. This begins to grow the Mac's marketshare. They opt for Office X when it's time to upgrade that. Gradually, they replace all their Windows software with Mac equivalents. Developers notice that their Mac versions are selling better. This situation is repeated with other software as more and more people use x86 emulation as an easy way to get through to the superior Mac hardware. Mac marketshare continues to climb, as does demand for Mac software. Other developers who had previously ignored the Mac market start to sit up and take notice - particularly when they see competitors with Mac versions of their software starting to make more and more money from their Mac divisions. Thus the trickle starts to turn into a flood of Mac development. I don't know how high the Mac marketshare might go in this scenario - it may stall at 10%, it may go much higher. Windows users tend to be lemmings, so once the pack turns a new direction, it could be a bloodbath for Windows (ok, ok, REALLY wishful thinking there). The key is having early adopters take notice and get interested in using OS X. That already seems to be happening. x86 emulation is all about lowering the barrier to getting on board.
I've gotten myself sucked into this again, and I'm going to quit again (for good this time) with this post. Either Apple includes x86 emulation or they don't. Us arguing about its merits here isn't going to make a fig's worth of difference, so there's no point in us all getting worked up about it.
anyone know what the advantages the 970 will have on dual 1.8 or 2.5 while running OSX server, I think the 970 was found in IMB servers before their current migration to Apple (hopefully).
My goal is to get a tower and run Quicktime movies over the internet.
what kind of improvemnets will we see in benchmarks?
will it be more stable ? Quicker? what should I be looking for ?
Also if the 970 is currently found in IBM hardware can someone show me where to find it
The problem with x86 emulation is that, unfortunately, MS wins. The developers would develop once and run anywhere. Mac software versions would be very slow to come if at all. Apple does not need to include an x86 emulation layer on OS X for this reason. They need to get more developers using Cocoa.
It would seem that MS is more interested in providing an x86 layer on OS X and this concerns me. If the layer runs decently on the 970, MS could lock the developers into the W32 API. Perhaps MS is afraid that Intel's Itanic won't effectively compete with the 970 and want to ensure that Windows remains relevant. It doesn't matter, Apple needs to distance itself from x86 applications and encourage development on the PowerPC. It seems that they do realize this and have made an easy way to transition from the various flavors of Unix/Linux to OS X. There is simply no easy way to convert x86 code to PowerPC code. It would be nice if there was, but there isn't (at least as far as I am aware). Perhaps someone will develop a program that would make the conversion fairly easy. Until that day, Apple needs to resist the temptation of providing a good x86 emulation layer. All this would do is allow MS to extend their dominance to the PowerPC in addition to the Intel/AMD platforms.
IBM is pushing back at the lowend servers that are starting to take sales away from the high end market. MS might port to the PowerPC again, but so what? It means more money and incentive for IBM, and would push the development of the 980 and beyond...We need this chip to succeed, the more units sold the more successfull the chip is.</strong><hr></blockquote>
Imagine seeing "Optimized for AltiVec!!" on a Windows XP box.
<strong>The problem with x86 emulation is that, unfortunately, MS wins. The developers would develop once and run anywhere. Mac software versions would be very slow to come if at all. Apple does not need to include an x86 emulation layer on OS X for this reason. They need to get more developers using Cocoa.</strong><hr></blockquote>
Exactly. If as a developer you knew you only had to maintain one codebase that could run anywehere (in native x86, or emulated at native speeds on the 970), why take the time to port to native PPC? Sure the specialty apps would still remain (photoshop, etc) only because the code is already there, but any new apps need not be written for PPC. As a developer you could get 100% penetration, while only mainting 1 code base. Plus you would have a "simulatnius" release. The downside? None for the developer. For us, the consumer on a mac, there is a big impact (shit for an interface, inconsistency with other apps, yada, yada). How is this a good thing?
But where did this idea even come from. What makes people think that just because we have the 970, we will get super x86 emulation performance? I dont' see why it would get miraculously better. It would still run at only half speed with no GFX card support (so we could emulate a 1 GHz Pentium 2 now, oh yea!) People jumped all over this, with no foundation in any truths (at last I dont think, someone correct me if IBM said it could emulate an x86 at blazing speeds). There is no way we would be getting equal performance to an x86 box, its emulation remember. So that makes all this moot, as no such "uber" emulation will exist, so no one would count on it for squat.
Here's a question - if Apple suddenly reversed course and released Yellow Box for Windows, would people stop writing Windows programs? If not, why not? Does the same thing apply to the Mac market?</strong><hr></blockquote>
Yellow Box for Windows (nee OpenStep for Windows, nee Cocoa for Windows if it were alive) was the Windows framework that allowed OpenStep/Cocoa applications to run on Windows, as well as other platforms. When NeXT was acquired, the hope was that the Yellow Box's (Cocoa's) superiority would attract Windows developers, who would release fat binaries for PPC and x86. We all figured it would be a prominent strategy for Apple; it seemed like a great way to enlarge our software base. Unfortunately, after the next generation OS moved from its Rhapsody stage to OS X, all references to Yellow Box for Windows were eliminated. I'm pretty sure that Cocoa for Windows is still in shrouded development (along with OS X x86). Unlike OS X x86, I think it would be a viable product and that it should be released.
Cocoa for Windows wouldn't cause developers to leave Win32 for a variety of reasons. Even though many regard it as superior, Objective C is known by a minority of programmers. Moreover, even if developers were to bother to learn Objective C, they still would need to learn the Cocoa framework. Most don't want to spend the time learning an entirely new framework when Win32 works fine for them. Finally, even if Cocoa for Windows gained widespread acceptance, developers would still use it to build Windows compatible binaries. (Wintel would still be the dominate platform, so it's not like it would be abandoned. Developers wouldn't code for Cocoa if they couldn't deliver Windows binaries.)
In contrast, Win32 is the dominant API for the dominant platform. All it takes is simple logic to understand that developers would rather only code for one API if they could. And many do today, which is why so much software is PC only. Cocoa for Windows is absolutely not analogous to transparent Win32 for OS X.
The only true way to increase the amount of Mac software is to grow the Mac's market share. Making the Mac "Windows Compatible" is certainly not the way to do it (unless it were executed perfectly). Sure, it may convert a few more end user switchers, and it would certainly please developers. Yet, it would please them because they wouldn't have to develop for the Mac anymore! Granted, as others have stated, applications that benefit heavily from Altivec (like Photoshop) would stick around for awhile. But for the majority of applications that rely mostly on integer performance, a 20% lead would hardly be sufficient cause to continue development. One person said demand for native software would elicit developer supply. That would be true but only if you think we could substantially grow the platform quickly. We would have to make serious dents in the market share picture quickly, or else we would be relegated to OS/2 status very fast. I'll throw the transparent Win32 crowd a bone with the following statement: If MS is in a vulnerable position, and if Apple is really confident it can take advantage of that (with great hardware supplied in quantity quickly), then transparent Win32 could help cause a massive switch. But that's a whole set of conditions Apple would have to meet before transparent Win32 could pay off. And if Apple bet wrongly, it would have to kill Win32 support. Otherwise, our platform would be truly dead. If Apple thinks conditions are right, then it would be worth the risk. We're certainly not winning anything with declining market share. But it is a significant risk, nonetheless.
Apple wants to increase its market share. We discuss MacOS for Windows and Soft Windows for MacOS (be it software or hardware emulation ? not so important). Either way it is, yes, penetration into the Windows world; and either way it is a merge with Windows. To degrade the problem, the question is, if a schoolboy can have both Windows and Mac games running on one computer, will he choose Mac ones?
Either way there is certain risk for Apple. Soft MacOS may hurt Apple's hardware sales, and Soft Windows may halt software sales. The result is fairly unpredictable and depends mostly on the choice of hardware and software available.
Yellow Box is a development platform and, in essence, is a similar risk. It can help a developer create a cross-platform app, but the app will be used on Windows with probability of 95% to 97%. One example I know is Heidelberg's imposition solution (Signa Station). Its interface is written in Java for Yellow Box for Windows NT, it requires AppleTalk, it is Mac-friendly, but it has never been released for MacOS X.
There are substantial pros and cons to both extremes. Customers' choice depends on both hardware and software. The software side belongs to Windows for some 95%+. The hardware side is in the hairy hands of IBM and Intel.
The future is interesting. <img src="graemlins/cancer.gif" border="0" alt="[cancer]" />
Thank you for the reference to the Java application, costique. I wasn't going to reference the one potential pitfall of Cocoa for Windows since I didn't think it was worth mentioning. I didn't even know Yellow Box for Java existed. Has it been updated since the NeXT acquisition? (I thought the only thing close to Yellow Box for Windows that was still around was Web Objects.) Cocoa for Windows would allow developers to build applications that would run on Windows and OS X, but it would be up to them which binaries they wished to include. It seems pretty illogical to me to preclude an OS X sale when one would get it for free (a simple recompile), but if the developer's particularly anti-Mac I guess it could happen. But I believe all would agree Cocoa for Windows is far less risky than either transparent Win32 or OS X x86.
<strong> I didn't even know Yellow Box for Java existed. Has it been updated since the NeXT acquisition? (I thought the only thing close to Yellow Box for Windows that was still around was Web Objects.) Cocoa for Windows would allow developers to build applications that would run on Windows and OS X, but it would be up to them which binaries they wished to include. It seems pretty illogical to me to preclude an OS X sale when one would get it for free (a simple recompile), but if the developer's particularly anti-Mac I guess it could happen. But I believe all would agree Cocoa for Windows is far less risky than either transparent Win32 or OS X x86.
[ 03-04-2003: Message edited by: Big Mac ]</strong><hr></blockquote>
Yellow Box rocked!
A couple friends of mine had their Rhapsody app, which they had spent a year writing, over onto the Windows platform running perfectly fine in a week.
Ta-Da, both markets handled, and Apple gets a (virtually) guarateed simultaneous release with windows.
And then Apple killed Yellow, and nobody knew why.
We never did get a full answer, but in hind sight, we can speculate a bit:
A - Apple may have figured that, faced with the possibility of loosing control of the Win32 API under a Yellow Box layer for a potentially significant proportion of developers, Uncle Bill would respond by simply constantly changing the API layer that Yellow Box had to run in, thus breaking Yellow Box at his whim. We have to remember that one of Bill's great lording powers is his control of the API ... The last thing he'd ever want to do is let this slip from his hands ... "Oh, Yellow Box is broken again? Geez, what a shame, if only they had paid attention to this minute detail this this documentation bla-bla ..." This game, after all, is one of MS's favorite things.
B - Or perhaps, keeping Yellow feature matched on both Quartz and Windows simply made doing a Yellow box impractical and chained Apple to a lowest common denominator interface.
C - or perhaps both.
Either way, a final answer to the killing of Yellow was never found, regardless, it takes a Java developer a couple of days to get comfy with Obj-C , and perhaps three months to get used to COREFoundation framework ... which compared to the Win32 API, is a piece of cake. Given all the advantages it has over Win32 and the ability to almost guarantee simultaneous Windows and Mac releases of the same apps, and the ability to draw more developers to a Mac write-once-run-anywhere YB platform, you'd think that Apple would be big on this.
That is, unless the situation above hasn't changed at all, in which case, we have another beautiful mirage.
The "does PC emulation hurt Apple" issue is complex, and it's hard to say whether or not better and faster Windows compatibility would help or hurt Apple in the long run.
But I did want to address the VPC speed issue.
We all know that VPC is sluggish...even on Apple's top of the line machines. But whether or not the PPC 970 will change that in some way is very clear. In some excellent posts make by Moki elsewhere on this forum, he stated that based on current benchmark projections the PPC 970 is TWICE as fast as a G4 in integer calculations. That means that with the release of the first PPC 970 machines:
PPC 970 @ 1.8 GHz = G4 @ 3.6 GHz
PPC 970 @ 2.5 GHz = G4 @ 5.0 GHz
Compared to a 1 GHz G4, VPC could be running between 3.6x and 5x faster on a PPC 970 machine in just a few short months. And this would be without major changes to the code. That in itself would be pretty amazing. But now that Microsoft owns VPC (and let's do away with all the MS/Gates conspiracy theories for a moment), what would be the #1 thing I'd expect to change in MS's first update to VPC? MORE SPEED!
Why? Because MS knows how Windows works better than any 3rd party, and they have unlimited dollars for development. Their Mac programmers will be going over VPC's source code with a fine-toothed comb, and will undoubtly find and remove bottlenecks that Connectix could never have known about. Despite the heated arguments against them as a corporation, if anyone can make VPC useable, it's Microsoft.
So combine the sheer brute force hardware of the PPC 970 and a highly refined VPC optimized extensively by Microsoft, and suddenly VPC could be approaching speeds easily 5-7x faster than is possible now. It would STILL be emulation, and it would STILL be slower than Intel and AMD's latest and greatest chips. But within 6 months, Windows emulation on a Mac will be a whole new level of performance.
There is no doubt that this will be good for Microsoft. Let's hope that as part of the "Switchers" campaign, it works out well for Apple too.
But now that Microsoft owns VPC (and let's do away with all the MS/Gates conspiracy theories for a moment), what would be the #1 thing I'd expect to change in MS's first update to VPC? MORE SPEED!
</strong><hr></blockquote>
I'd bet LESS SPEED! is the result.
Ever used IE, Word, or Excel on a mac? They work but not as fast as they could.
I once saw an Apple rep demo VPC for classic on a powerbook and one of the things he showed us was how excel in windows inside of VPC opened faster than excel for classic mac OS. Go figure...
ZThe real point is however, that millions of former PC users will have MACS. Once they have a mac, technically, our market share will grow. Would you as a developer take the chance that EVERYONE WHO BOUGHT A MAC with pc emulation IS USING A WINDOWS APP? No. There are no guarantees who using the windows version or the mac version. Hey macs can run window versions of photoshop now, ok, let's kill photoshop for mac. Right, come oen people. All this does is increase market share, make apple more money and give developers MORE reason to develope for mac because more macs would be in use! Who in their right fricking mind would stick using the window apps and windows OS after they'ed played with X and quartz extreme and iApps on a 970!?!? Yea, I think I want to kill the mac version even tho the 970 just sold more then 2 million units this quarter. Right, stop bein paranoid about macs being stranded if X included emulation. Not to mention the MILLIONS of users who DON'T OWN a 970 (once released).
<strong>Perhaps Microsoft already uses an emulator to port its products to Mac OS? (One less efficient than VPC) </strong><hr></blockquote>
Nope. Around the time of Word 6, MS decided that rather than maintaining two separate products, they'd rather write on version of Word and compile it on MacOS with a wrapper (different from an emulator). It was a piece of crap. It didn't feel Mac-y at all, and it was slow due to the need to translate Win32 API calls into MacOS API calls.
They learned their lesson, and the next version of Word was a rewritten Mac application. What we're using now is a descendent of that program.
[quote] ZThe real point is however, that millions of former PC users will have MACS. Once they have a mac, technically, our market share will grow. Would you as a developer take the chance that EVERYONE WHO BOUGHT A MAC with pc emulation IS USING A WINDOWS APP? No. There are no guarantees who using the windows version or the mac version. Hey macs can run window versions of photoshop now, ok, let's kill photoshop for mac. Right, come oen people. All this does is increase market share, make apple more money and give developers MORE reason to develope for mac because more macs would be in use! Who in their right fricking mind would stick using the window apps and windows OS after they'ed played with X and quartz extreme and iApps on a 970!?!? Yea, I think I want to kill the mac version even tho the 970 just sold more then 2 million units this quarter. Right, stop bein paranoid about macs being stranded if X included emulation. Not to mention the MILLIONS of users who DON'T OWN a 970 (once released). <hr></blockquote>
Kid Red's on the money. Why would you want to kill the codebase for 25 million Macs? And with four million more sold every year, Adobe suddenly kills Photoshop? Macromedia kill Dreamweaver MX? Or Flash? Or M$ killing Office?
Either a market is worth supporting or its not.
Can you see Adobe turning down all that revenue from people who own PCs and Macs? That's quite a bit of dosh. Likewise, Macromedia Director. Decent revenue from anybody who needs both Mac and PC versions because they got both machines. Kill the Mac version and there's a 50% cut in revenue there. That tots up in Key creative markets.
Virtual PC under a 970 might emulate a 1 gig Pentium 3. Decent performance for a 'Switcher' legacy app.
I can see all the print shops running the slow Windows version... All the switchers being happy with their box being underused by a factor of five.
Pitch that against a 5 gig G4 equivalent 970 2.5 gig.
I guess I'm waiting for M$ to kill off the Mac platform with Virtual PC, 'Run your apps 5 times slower...on Windows...'
That'll work.
What does a Mac base want to do? Run native or emulation? Native. What does a Switcher base want? Safety. The option to run legacy x86 apps...while trying 'X'. Once they use 'X'. They won't go back. Sure, you have to buy Virtual PC. An apple emulation layer for x86 would sell all new machines with x86/Windows. But if the machine was dual boot? With no Windows on it?
I think if Apple sells 'dual boot' boxes. Maybe they leave it up the 'Switcher' if they want to install their copy of Windows on the Apple box.
M$ can't stop Apple selling x86 hardware, can they?
And how will M$ stop a 'Switcher' from installing their copy of Windows on their choice 'x86' dual boot box?
This way, Apple wouldn't be selling a copy of Windows to every customer. The 'Switchers' could use the 'x86' layer to intall Windows legacy apps and use the 970 PPC for 'X' at blazing speeds.
Developers wouldn't cut their Mac support because they'd be unable to quantify the 'Switch' base that was actually using the x86 layer.
Apple doesn't or can't give x86 to PPC switch numbers. So how will developers use something Apple can't?
All the time, Apple's base grows by selling to PPC and to x86. Dreamteam. Kinda. Trojan horse.
'Buy Windows...you've got an x86 layer/dual boot box...use it...' Are they going to say that? Don't think so.
You can win. If your product is compelling enough. Apple need to keep their software, OS and kit compelling. It won't matter if they offer dual boot or emulation or not.
I haven't used Safari yet. But from what people have said, I get the feeling I may end up using that rather than IE suckplorer on this Athlon thing.
Give me a 970...and I'll prove it.
(Apple just needs more and more and more compelling software. And I think its coming. If Apple can get half of its revenue from Software...that puts them in a much, much stronger position.)
Comments
<strong>
Quite the opposite actually. Think about it, if you had a Mac/PC all in one, which OS would you buy software for? I'd say it's a no brain'er, the Mac of course. Now, how many people with this set up do you think would be screaming for more apps for the Mac OS? The more people with a Mac/PC the more the apps will be ported over to the Mac OS.
The fastest way to get a chunk of the other 95% is to get into their camp. "Look, you can now buy a Mac and run all you window's apps just as if you had bought a Dell." The Mac would become another PC. Haaaa but wait, here's the unsuspecting surprise
The problem: People want to use what is "standard." This is a fact. Not what is better, but what is "STANDARD!" Windows, right or wrong is the Standard.
If Apple can actually get Windows to run flawlessly on Macs, only a stupid CEO would pass up on this opportunity.
My question is, can Apple legally do this and is it actually technically possible? :eek: </strong><hr></blockquote>
Like virtual pc, you would probably have to buy a retail copy of Windows and install it to have access to Windows apps. Or Apple could buy Windows at the OEM discount and include it with a copy of OS X that cost 199 or something. (But what is the chance of Microsoft agreeing to this?)
<strong>
As to the "market forces" argument: What market forces, and how long are you willing to wait for the few there actually are to kick in? How long did we have to wait for a decent web browser again? And what market is there for all the millions of little vertical market apps that industry runs on? If someone's little special-purpose business app runs on Windows, you're running Windows. Alternatives? Where? And what guarantee is there that the alternatives won't suck in the same or different ways? We ended up rolling our own cancer data collection application after years of frustration with the stuff that's out there. It cost us a mint (especially since we're a non-profit), sucked up our development staff for a solid year, and we've been cleaning up after the (necessarily) abrupt release and transition since then - not to mention picking up all the projects we had to drop to concentrate on this. Guess which platform all the other apps runs on? Guess which one ours runs on? Guess what market pressure there is for a Mac version? None. Zip. Nada. Zero. As it was, the suckage of the other applications had to reach crisis levels before we felt compelled to roll our own, and we cut out as many costly options as we possibly could to get the thing out there and working. Sad as it may seem, this scenario is not unusual for software development.
[ 03-03-2003: Message edited by: Amorph ]</strong><hr></blockquote>
I'm sorry for your experiences, but that's not really what I was thinking of. I'm not naive enough to think that simply including x86 emulation means that all developers drop whatever they're doing and start making Mac ports. What I'm thinking of is more like making a breach in the dam - it may be only a trickle at first, but it turns into a flood before long.
Let's just use Photoshop as an example. A Windows graphics shop needs new hardware. They've heard about the butt-kickin' 970 processor and realize they need to be on Macs to maximize their productivity. However, they can't afford both new hardware and new software simultaneously. So now we've got a chicken-and-egg situation - no point in buying Macs because their software won't run. No point in buying Mac Photoshop because it won't run on their x86 hardware. x86 emulation in OS X offers them a leg up to get over to the right side of the fence. They buy Macs, and run their Windows Photoshop in emulation mode. Then, as their budget allows for new software, they buy Mac versions of Photoshop. This begins to grow the Mac's marketshare. They opt for Office X when it's time to upgrade that. Gradually, they replace all their Windows software with Mac equivalents. Developers notice that their Mac versions are selling better. This situation is repeated with other software as more and more people use x86 emulation as an easy way to get through to the superior Mac hardware. Mac marketshare continues to climb, as does demand for Mac software. Other developers who had previously ignored the Mac market start to sit up and take notice - particularly when they see competitors with Mac versions of their software starting to make more and more money from their Mac divisions. Thus the trickle starts to turn into a flood of Mac development. I don't know how high the Mac marketshare might go in this scenario - it may stall at 10%, it may go much higher. Windows users tend to be lemmings, so once the pack turns a new direction, it could be a bloodbath for Windows (ok, ok, REALLY wishful thinking there). The key is having early adopters take notice and get interested in using OS X. That already seems to be happening. x86 emulation is all about lowering the barrier to getting on board.
I've gotten myself sucked into this again, and I'm going to quit again (for good this time) with this post. Either Apple includes x86 emulation or they don't. Us arguing about its merits here isn't going to make a fig's worth of difference, so there's no point in us all getting worked up about it.
My goal is to get a tower and run Quicktime movies over the internet.
what kind of improvemnets will we see in benchmarks?
will it be more stable ? Quicker? what should I be looking for ?
Also if the 970 is currently found in IBM hardware can someone show me where to find it
It would seem that MS is more interested in providing an x86 layer on OS X and this concerns me. If the layer runs decently on the 970, MS could lock the developers into the W32 API. Perhaps MS is afraid that Intel's Itanic won't effectively compete with the 970 and want to ensure that Windows remains relevant. It doesn't matter, Apple needs to distance itself from x86 applications and encourage development on the PowerPC. It seems that they do realize this and have made an easy way to transition from the various flavors of Unix/Linux to OS X. There is simply no easy way to convert x86 code to PowerPC code. It would be nice if there was, but there isn't (at least as far as I am aware). Perhaps someone will develop a program that would make the conversion fairly easy. Until that day, Apple needs to resist the temptation of providing a good x86 emulation layer. All this would do is allow MS to extend their dominance to the PowerPC in addition to the Intel/AMD platforms.
<strong>
IBM is pushing back at the lowend servers that are starting to take sales away from the high end market. MS might port to the PowerPC again, but so what? It means more money and incentive for IBM, and would push the development of the 980 and beyond...We need this chip to succeed, the more units sold the more successfull the chip is.</strong><hr></blockquote>
Imagine seeing "Optimized for AltiVec!!" on a Windows XP box.
<strong>The problem with x86 emulation is that, unfortunately, MS wins. The developers would develop once and run anywhere. Mac software versions would be very slow to come if at all. Apple does not need to include an x86 emulation layer on OS X for this reason. They need to get more developers using Cocoa.</strong><hr></blockquote>
Exactly. If as a developer you knew you only had to maintain one codebase that could run anywehere (in native x86, or emulated at native speeds on the 970), why take the time to port to native PPC? Sure the specialty apps would still remain (photoshop, etc) only because the code is already there, but any new apps need not be written for PPC. As a developer you could get 100% penetration, while only mainting 1 code base. Plus you would have a "simulatnius" release. The downside? None for the developer. For us, the consumer on a mac, there is a big impact (shit for an interface, inconsistency with other apps, yada, yada). How is this a good thing?
But where did this idea even come from. What makes people think that just because we have the 970, we will get super x86 emulation performance? I dont' see why it would get miraculously better. It would still run at only half speed with no GFX card support (so we could emulate a 1 GHz Pentium 2 now, oh yea!) People jumped all over this, with no foundation in any truths (at last I dont think, someone correct me if IBM said it could emulate an x86 at blazing speeds). There is no way we would be getting equal performance to an x86 box, its emulation remember. So that makes all this moot, as no such "uber" emulation will exist, so no one would count on it for squat.
<strong>
Here's a question - if Apple suddenly reversed course and released Yellow Box for Windows, would people stop writing Windows programs? If not, why not? Does the same thing apply to the Mac market?</strong><hr></blockquote>
Yellow Box for Windows (nee OpenStep for Windows, nee Cocoa for Windows if it were alive) was the Windows framework that allowed OpenStep/Cocoa applications to run on Windows, as well as other platforms. When NeXT was acquired, the hope was that the Yellow Box's (Cocoa's) superiority would attract Windows developers, who would release fat binaries for PPC and x86. We all figured it would be a prominent strategy for Apple; it seemed like a great way to enlarge our software base. Unfortunately, after the next generation OS moved from its Rhapsody stage to OS X, all references to Yellow Box for Windows were eliminated. I'm pretty sure that Cocoa for Windows is still in shrouded development (along with OS X x86). Unlike OS X x86, I think it would be a viable product and that it should be released.
Cocoa for Windows wouldn't cause developers to leave Win32 for a variety of reasons. Even though many regard it as superior, Objective C is known by a minority of programmers. Moreover, even if developers were to bother to learn Objective C, they still would need to learn the Cocoa framework. Most don't want to spend the time learning an entirely new framework when Win32 works fine for them. Finally, even if Cocoa for Windows gained widespread acceptance, developers would still use it to build Windows compatible binaries. (Wintel would still be the dominate platform, so it's not like it would be abandoned. Developers wouldn't code for Cocoa if they couldn't deliver Windows binaries.)
In contrast, Win32 is the dominant API for the dominant platform. All it takes is simple logic to understand that developers would rather only code for one API if they could. And many do today, which is why so much software is PC only. Cocoa for Windows is absolutely not analogous to transparent Win32 for OS X.
The only true way to increase the amount of Mac software is to grow the Mac's market share. Making the Mac "Windows Compatible" is certainly not the way to do it (unless it were executed perfectly). Sure, it may convert a few more end user switchers, and it would certainly please developers. Yet, it would please them because they wouldn't have to develop for the Mac anymore! Granted, as others have stated, applications that benefit heavily from Altivec (like Photoshop) would stick around for awhile. But for the majority of applications that rely mostly on integer performance, a 20% lead would hardly be sufficient cause to continue development. One person said demand for native software would elicit developer supply. That would be true but only if you think we could substantially grow the platform quickly. We would have to make serious dents in the market share picture quickly, or else we would be relegated to OS/2 status very fast. I'll throw the transparent Win32 crowd a bone with the following statement: If MS is in a vulnerable position, and if Apple is really confident it can take advantage of that (with great hardware supplied in quantity quickly), then transparent Win32 could help cause a massive switch. But that's a whole set of conditions Apple would have to meet before transparent Win32 could pay off. And if Apple bet wrongly, it would have to kill Win32 support. Otherwise, our platform would be truly dead. If Apple thinks conditions are right, then it would be worth the risk. We're certainly not winning anything with declining market share. But it is a significant risk, nonetheless.
[ 03-04-2003: Message edited by: Big Mac ]
[ 03-04-2003: Message edited by: Big Mac ]</p>
Apple wants to increase its market share. We discuss MacOS for Windows and Soft Windows for MacOS (be it software or hardware emulation ? not so important). Either way it is, yes, penetration into the Windows world; and either way it is a merge with Windows. To degrade the problem, the question is, if a schoolboy can have both Windows and Mac games running on one computer, will he choose Mac ones?
Either way there is certain risk for Apple. Soft MacOS may hurt Apple's hardware sales, and Soft Windows may halt software sales. The result is fairly unpredictable and depends mostly on the choice of hardware and software available.
Yellow Box is a development platform and, in essence, is a similar risk. It can help a developer create a cross-platform app, but the app will be used on Windows with probability of 95% to 97%. One example I know is Heidelberg's imposition solution (Signa Station). Its interface is written in Java for Yellow Box for Windows NT, it requires AppleTalk, it is Mac-friendly, but it has never been released for MacOS X.
There are substantial pros and cons to both extremes. Customers' choice depends on both hardware and software. The software side belongs to Windows for some 95%+. The hardware side is in the hairy hands of IBM and Intel.
The future is interesting. <img src="graemlins/cancer.gif" border="0" alt="[cancer]" />
[ 03-04-2003: Message edited by: Big Mac ]</p>
<hr></blockquote>
20th anniversary of the Macintosh in January 2004?
<strong>
20th anniversary of the Macintosh in January 2004?</strong><hr></blockquote>
please no...
not the 20th anniversary argument again! <img src="graemlins/oyvey.gif" border="0" alt="[oyvey]" />
<strong> I didn't even know Yellow Box for Java existed. Has it been updated since the NeXT acquisition? (I thought the only thing close to Yellow Box for Windows that was still around was Web Objects.) Cocoa for Windows would allow developers to build applications that would run on Windows and OS X, but it would be up to them which binaries they wished to include. It seems pretty illogical to me to preclude an OS X sale when one would get it for free (a simple recompile), but if the developer's particularly anti-Mac I guess it could happen. But I believe all would agree Cocoa for Windows is far less risky than either transparent Win32 or OS X x86.
[ 03-04-2003: Message edited by: Big Mac ]</strong><hr></blockquote>
Yellow Box rocked!
A couple friends of mine had their Rhapsody app, which they had spent a year writing, over onto the Windows platform running perfectly fine in a week.
Ta-Da, both markets handled, and Apple gets a (virtually) guarateed simultaneous release with windows.
And then Apple killed Yellow, and nobody knew why.
We never did get a full answer, but in hind sight, we can speculate a bit:
A - Apple may have figured that, faced with the possibility of loosing control of the Win32 API under a Yellow Box layer for a potentially significant proportion of developers, Uncle Bill would respond by simply constantly changing the API layer that Yellow Box had to run in, thus breaking Yellow Box at his whim. We have to remember that one of Bill's great lording powers is his control of the API ... The last thing he'd ever want to do is let this slip from his hands ... "Oh, Yellow Box is broken again? Geez, what a shame, if only they had paid attention to this minute detail this this documentation bla-bla ..." This game, after all, is one of MS's favorite things.
B - Or perhaps, keeping Yellow feature matched on both Quartz and Windows simply made doing a Yellow box impractical and chained Apple to a lowest common denominator interface.
C - or perhaps both.
Either way, a final answer to the killing of Yellow was never found, regardless, it takes a Java developer a couple of days to get comfy with Obj-C , and perhaps three months to get used to COREFoundation framework ... which compared to the Win32 API, is a piece of cake. Given all the advantages it has over Win32 and the ability to almost guarantee simultaneous Windows and Mac releases of the same apps, and the ability to draw more developers to a Mac write-once-run-anywhere YB platform, you'd think that Apple would be big on this.
That is, unless the situation above hasn't changed at all, in which case, we have another beautiful mirage.
But I did want to address the VPC speed issue.
We all know that VPC is sluggish...even on Apple's top of the line machines. But whether or not the PPC 970 will change that in some way is very clear. In some excellent posts make by Moki elsewhere on this forum, he stated that based on current benchmark projections the PPC 970 is TWICE as fast as a G4 in integer calculations. That means that with the release of the first PPC 970 machines:
PPC 970 @ 1.8 GHz = G4 @ 3.6 GHz
PPC 970 @ 2.5 GHz = G4 @ 5.0 GHz
Compared to a 1 GHz G4, VPC could be running between 3.6x and 5x faster on a PPC 970 machine in just a few short months. And this would be without major changes to the code. That in itself would be pretty amazing. But now that Microsoft owns VPC (and let's do away with all the MS/Gates conspiracy theories for a moment), what would be the #1 thing I'd expect to change in MS's first update to VPC? MORE SPEED!
Why? Because MS knows how Windows works better than any 3rd party, and they have unlimited dollars for development. Their Mac programmers will be going over VPC's source code with a fine-toothed comb, and will undoubtly find and remove bottlenecks that Connectix could never have known about. Despite the heated arguments against them as a corporation, if anyone can make VPC useable, it's Microsoft.
So combine the sheer brute force hardware of the PPC 970 and a highly refined VPC optimized extensively by Microsoft, and suddenly VPC could be approaching speeds easily 5-7x faster than is possible now. It would STILL be emulation, and it would STILL be slower than Intel and AMD's latest and greatest chips. But within 6 months, Windows emulation on a Mac will be a whole new level of performance.
There is no doubt that this will be good for Microsoft. Let's hope that as part of the "Switchers" campaign, it works out well for Apple too.
-- Ensoniq
<strong>
But now that Microsoft owns VPC (and let's do away with all the MS/Gates conspiracy theories for a moment), what would be the #1 thing I'd expect to change in MS's first update to VPC? MORE SPEED!
</strong><hr></blockquote>
I'd bet LESS SPEED! is the result.
Ever used IE, Word, or Excel on a mac? They work but not as fast as they could.
I once saw an Apple rep demo VPC for classic on a powerbook and one of the things he showed us was how excel in windows inside of VPC opened faster than excel for classic mac OS. Go figure...
<strong>Perhaps Microsoft already uses an emulator to port its products to Mac OS? (One less efficient than VPC)
Nope. Around the time of Word 6, MS decided that rather than maintaining two separate products, they'd rather write on version of Word and compile it on MacOS with a wrapper (different from an emulator). It was a piece of crap. It didn't feel Mac-y at all, and it was slow due to the need to translate Win32 API calls into MacOS API calls.
They learned their lesson, and the next version of Word was a rewritten Mac application. What we're using now is a descendent of that program.
Kid Red's on the money. Why would you want to kill the codebase for 25 million Macs? And with four million more sold every year, Adobe suddenly kills Photoshop? Macromedia kill Dreamweaver MX? Or Flash? Or M$ killing Office?
Either a market is worth supporting or its not.
Can you see Adobe turning down all that revenue from people who own PCs and Macs? That's quite a bit of dosh. Likewise, Macromedia Director. Decent revenue from anybody who needs both Mac and PC versions because they got both machines. Kill the Mac version and there's a 50% cut in revenue there. That tots up in Key creative markets.
Virtual PC under a 970 might emulate a 1 gig Pentium 3. Decent performance for a 'Switcher' legacy app.
I can see all the print shops running the slow Windows version... All the switchers being happy with their box being underused by a factor of five.
Pitch that against a 5 gig G4 equivalent 970 2.5 gig.
I guess I'm waiting for M$ to kill off the Mac platform with Virtual PC, 'Run your apps 5 times slower...on Windows...'
That'll work.
What does a Mac base want to do? Run native or emulation? Native. What does a Switcher base want? Safety. The option to run legacy x86 apps...while trying 'X'. Once they use 'X'. They won't go back. Sure, you have to buy Virtual PC. An apple emulation layer for x86 would sell all new machines with x86/Windows. But if the machine was dual boot? With no Windows on it?
I think if Apple sells 'dual boot' boxes. Maybe they leave it up the 'Switcher' if they want to install their copy of Windows on the Apple box.
M$ can't stop Apple selling x86 hardware, can they?
And how will M$ stop a 'Switcher' from installing their copy of Windows on their choice 'x86' dual boot box?
This way, Apple wouldn't be selling a copy of Windows to every customer. The 'Switchers' could use the 'x86' layer to intall Windows legacy apps and use the 970 PPC for 'X' at blazing speeds.
Developers wouldn't cut their Mac support because they'd be unable to quantify the 'Switch' base that was actually using the x86 layer.
Apple doesn't or can't give x86 to PPC switch numbers. So how will developers use something Apple can't?
All the time, Apple's base grows by selling to PPC and to x86. Dreamteam. Kinda. Trojan horse.
'Buy Windows...you've got an x86 layer/dual boot box...use it...' Are they going to say that? Don't think so.
You can win. If your product is compelling enough. Apple need to keep their software, OS and kit compelling. It won't matter if they offer dual boot or emulation or not.
I haven't used Safari yet. But from what people have said, I get the feeling I may end up using that rather than IE suckplorer on this Athlon thing.
Give me a 970...and I'll prove it.
(Apple just needs more and more and more compelling software. And I think its coming. If Apple can get half of its revenue from Software...that puts them in a much, much stronger position.)
Lemon Bon Bon <img src="graemlins/cancer.gif" border="0" alt="[cancer]" />
[ 03-04-2003: Message edited by: Lemon Bon Bon ]</p>
Hmmm. Looks like Apple is boosting revenue from Services and more and more software.
Seems to tie in with their hardware...
Lemon Bon Bon