As Apple moves from IBM’s and Freescale’s PowerPC RISC architecture to Intel processors, developers must rebuild their products to support both platforms, into what Apple calls a UB (Universal Binary). And while Apple lists over 1000 UB applications currently available, this process is challenging developers, especially those of some of the largest and most critical applications for the platform.
i don’t see apple’s ethics and methods as dramatically different from microsoft’s, and so it’s hard for me to conjure sympathies for mac developers. they could put their efforts towards technical architectures founded upon more noble goals, and perhaps continue to develop for their favorite cpu’s in the process.
So who is more noble – Novel Red Hat???!!!
Bull shit (sorry)!
at the moment redhat and novell are far more noble than apple because they contribute to open source operating system development rather than leech off it like apple. but i was thinking more of debian, gentoo, ubuntu, gnome, x.org, etc.
apple is going in a shitty direction. macs will be nothing more than ATM’s for dispensing entertainment.
macs will be nothing more than ATM’s for dispensing entertainment.
A possibility, but with one tiny flaw. ATMs are supposed to be cheap :-).
The big difference between APPL and MSFT is that only one of the two has decent products. I don’t hate MSFT because they are a monopoly; I hate them because they I have to USE their c**p every work day.
i agree tha apple’s product is better. but the quality differences will start to get smaller as the two seem to be increasingly intent on cozying up. every other story these days is about running apple/microsoft something in a microsoft/apple something else. OS X may end up being an elegant container for microsoft apps.
i think it’s accepted that apple and microsoft coordinate strategies. open source is a threat to both companies. apple could be microsoft’s biggest play against open source, and could serve as a wedge for microsoft’s divide/conquer games.
OS X isn’t threatened by opensource software, but rather, it leverages it.
Apple uses opensource database software and a webserver. It’s “webkit” or whatever is based on Safari, and a fair amount of it’s core is opensource or based on or derived from opensource software (for example Darwin).
Think about how much work it’s had done by independent developers for nothing, including people submitting patches for Darwin and stuff.
Apple even boast about how easy it is to get “UNIX” technologies to work and how you can get a wealth of UNIX based software working on an OS X system.
Many developers I know use OS X rather than Linux because they can do the things they need in it as well as the things they like, easily.
Wrong, Webkit is based on *KHTML*, which forms the base of Konqueror. Apple uses this codebase to create *Webkit* which not only is used by Safari, but by other browsers such as Shiira or Omniweb, and the Dashboard (widget system).
Oh yeah, sorry, strange think-o/typo type thing. Meant to write KHTML rather than Safari…
“i agree tha apple’s product is better. but the quality differences will start to get smaller as the two seem to be increasingly intent on cozying up. blah, blah, blah….”
Get real. You have no idea what you are talking about.
Agreed. Jobs is just like Gates, only with a better haircut and less success.
“Agreed. Jobs is just like Gates, only with a better haircut and less success.”
Really? I know your a troll and all but check the stock prices anyway.
Um, could you explain that comment?
Also planing some trivial app to MacOS X. Problem: Facing PPC and Intel architecture now, I’d have to buy two Macs for testing. Guess my app is too trivial to justify this investment.
No you don’t, at least according to Apple. You just compile it for both in Xcode. Whether this work for all apps, alll the time remains to be seen.
You can develop with an x86 Mac only by compiling for PPC and using Rosetta for testing the PPC code.
(You can try two Xcode projects (PPC, x86) or a Universal an forcing it to run under Rosetta).
So you need only one Mac for you project.
“Byer explained that Adobe Photoshop in particular was tied to CodeWarrior, in part because of the way Adobe had to update the application during Apple’s last processor migration. That was in 1994, when Macs moved from the 68000 family from then-Motorola to the first PowerPC chips.”
Adobe has had all this time to update Photoshop and wasted it, basically selling us an updated product with old code.
If Adobe can re-write Premeire ground up for the Windows. Adobe should of had Photoshop in Cocoa ready by now.
Agree, it was 12 years since the upgrade from 68000 to PPC, and 5 years to get rid of all the carbon stuff from OS9. You’d think they would have done that… its like complianing that they’ve been using the same compiler since Windows95 and dont want to change, waah waaaah.
But I’m really looking forward to when Photoshop for Intel comes out and next keynote speech Steve Jobs can ask Bruce Chizen the question back: “WHAT TOOK YOU SO LONG?!?!”.
And he’ll have a winning smile on his face.
is that not only do you have to move your code to xCode, but that as of right now, only one compiler is really supported in XCode, and that’s GCC. So not only do all the developers have to port their code ot use XCode’s build environment and process, but they also have to use a totatly different compiler that almost no comercial software developer uses.
From this and other articles I’ve read, the developers that are the most vocal about it are the ones who don’t use gcc. Not that it’s their fault, GCC didn’t even exist when many of these projects were born. And gcc also generates sub-optimal code for the PPC. Codewarrior still generates the fastest PPC code (especially for G4s) so it’s not really a question as to why they didn’t switch until they were forced to.
Even Apple hasn’t gotten all of its code updated to be a UB.
Fair point. However, I’m sure I read about Intel’s plans to release their compilers (better optimised) for OS X on x86.
However, if I recall correctly, the compiler will only support Carbon, not Cocoa.
Carbon = OS 9 APIs leftover in OS X.
Cocoa = OX X native APIs.
“For apps that use Carbon, however, there is an alternative. Intel is porting their compilers (including C and C++) to Mac OS (as a plug-in for the Xcode environment, as I understand it.) But the Intel compiler will not generate PPC code, so it won’t be able to produce universal binaries. It will generate Intel-only applications.”
Wow, so we’ll end up with Universal binaries for Xcode, and Intel or PPC versions for others. Hmm.
Also: “CodeWarrior is essentially out of business on the desktop and is now focused on embedded processors. After their unfortunately timed decision to sell off their Intel compiler technology mere months before Apple’s announcement of the switch last summer” Ouch.
Carbon is not a leftover API. According to Apple:
“Carbon is a set of APIs for developing full-featured, high-performance, and reliable applications for Mac OS X. Carbon enables C and C++ developers to take advantage of Mac OS X-specific features, including an advanced user interface toolkit, an efficient event-handling mechanism, the Quartz 2D graphics library, and multiprocessing support.”
If anything riles me, it’s the attitude. Apple spent years telling everyone how much better PPC was, then reversed themselves overnight and we’re expected to leap in and cheerlead. What do developers get out of it? The chance to use deficient tools to rewrite our software so we can sell it to a small fraction of a small fraction of the market, and be abused in the press when it doesn’t happen overnight.
A lot of developers have gotten burned by Apple’s great ideas in the past: what do OpenDoc, QuickDraw3D, and most recently Altivec, all have in common? They got ditched with no warning or abruptly replaced with technically inferior buzzword technology that we were expected to help Apple sell.
What if Cocoa is next? It’s probably used more than OpenDoc or QuickDraw3D ever was, but very rarely in the big name products that matter to Apple. Would anyone really be surprised if Steve announced a wonderful new framework at WWDC and Cocoa was suddenly “not recommended for new development?” Did anyone notice that Intel isn’t supporting it in their compiler (and not for technical reasons, either: there really aren’t any)? Maybe it’s only because Intel knows that the shareware writers that use Cocoa can’t afford their tools anyway….
They got ditched with no warning or abruptly replaced with technically inferior buzzword technology that we were expected to help Apple sell.
OpenDoc was was an aborted technology. It never achieved widespread use, and died when the whole Taligent thing went south. Actually, both technologies from that era have disappeared. You don’t see OLE much around these days, for example, and Active X (nee OLE 2.0) has achieved limited use in third-party applications. In ditching OLE, Apple realized the same thing the GNOME folks did: nobody really wants to embed applications at that level. Bonobo is effectively dead technology, and note how little enthusiasm there is about creating a replacement for it.
QuickDraw3D was obsoleted along with QuickDraw, which died a richly-deserved death. Again, while MIcrosoft still supports QuickDraw’s contemporary, DirectDraw, for the sake of compatibility, it should be noted that DirectDraw is effectively obsoleted as well. Ostensibly its been subsumed into Direct3D, but in the process, it has lost the whole “direct” nature that charecterized it. Apple’s replacement for QuickDraw, Quartz, is superior in ever respect that matters. QuickDraw 3D has no apparent replacement, but now that OpenGL is the de-factor Mac 3D API, one is free to use the very good scene graphs that have been built on top of it (including a QD3D implementation).
Altivec is the only one that fits your statement, and even that is questionable. Yes, Altivec is probably superior to SSE, but don’t think you’ve seen the true nature of the comparison just yet. SSE implementations on existing x86 have never been very good. No current x86 chip features a dedicated 128-bit FPU for SSE operations — they break SSE operations into 2 64-bit components. Meanwhile, Altivec implementations have multiple 128-bit ALUs to handle vector operations. The situation will be quite different with Conroe. First, it will be an amd64 chip, meaning it will support a larger SSE register set. Second, its 3 SSE units will be backed by 128-bit FPUs. From the initial information, it seems that one unit is a adder, the other is a multiplier, and the third is most likely a permute unit. This change is very significant, because it basically means that SSE will have the same theoretical VFMAC throughput as the G5 (which has one VFMAC and one VPERM). On top of that, you can count on it to have unit latencies closer to the G4 than to the G5. Couple that with the larger caches and greater memory bandwidth of the Intel chips, and I would not be surprised to see Conroe’s SSE unit keeping up with the G5’s Altivec even on a per-clock basis.
Edited 2006-04-03 04:03
You don’t see OLE much around these days, for example, and Active X (nee OLE 2.0) has achieved limited use in third-party applications.
On windows OLE/COM/ACTIVEX is very much alive and is used very heavy use. ActiveX had limited use ? Most bad software installs on windows are caused by a COM/ACTIVEX component that wasn’t registered correctly in the registry.
The aftermarket for OLE (ActiveX) components was huge and is still quite large.
If you mean people don’t embed Word documents in their application using OLE anymore I’d have to agree but OLE is still firmly entrenched in the windows world.
Did anyone notice that Intel isn’t supporting it in their compiler (and not for technical reasons, either: there really aren’t any)?
Actually there is a technical reason. They’d have to write an Objective-C/C++ frontend, and the runtime library to go with it. Objective-C’s object model is quite different from C++’s, so it might also require some substantive changes to the compiler’s intermediate representation.
But yes, they might well have decided that the prospective market isn’t worth all the effort.
Actually there is a technical reason. They’d have to write an Objective-C/C++ frontend, and the runtime library to go with it. Objective-C’s object model is quite different from C++’s, so it might also require some substantive changes to the compiler’s intermediate representation.
OC’s object model is different, but it’s completely separate from C++. About all that Objective-C++ adds (and it’s a major, major plus, admittedly) is the ability to mix the 2 languages in one file and use C++ syntax. Actual interop is pretty limited, mostly a convenience (GNUStep does just fine without Objective-C++, it’s mostly another porting obstacle for them.)
Objective-C started as a preprocessor and runtime library: no compiler support at all was needed. That’s still possible, but it’s cumbersome and existing tools are pretty old. Note that the pure-ANSI C output of that preprocessor would likely be compatible w/ C++ with very little effort.
In any case, FreeScale has a now-unused Objective-C++ front end and runtime library that they’d probably be happy to license. There should be little or no changes in the intermediate code, since OC syntax is mostly just sugar for struct declarations and calls into its runtime: Objective-C is Plain-C long before a code generator sees it. Most of its special optimizations (e.g., selector caching) are in the runtime library.
If Intel isn’t bothering, it’s not because it’s hard to do, it’s because they see no value in it and Apple isn’t pushing even though they’re helping advertise the compiler. That may be because most Cocoa users are small Mac-only operations that don’t need and / or can’t afford Intels’s tools anyway. Or there may be other reasons, which Intel knows and the rest of us will find out when Apple decides to tell us (if Apple and Intel could keep OSX86 mostly secret for 5 years….)
Apple had no choice. IBM didn’t offer a road map. I mean IBM couldn’t even produce a Intel or AMD rival for notebooks.
Altivec/PPC has and had its advantages, but what good are they if they can’t fit into notebooks or have heat problems like the 970?
So what they’re basically saying is while over a thousand developers have moved to UB, two have not.
Even worse the two of them are the ones with the biggest wallets. Go figure.
“If anything riles me, it’s the attitude. Apple spent years telling everyone how much better PPC was, then reversed themselves overnight and we’re expected to leap in and cheerlead. What do developers get out of it? The chance to use deficient tools to rewrite our software so we can sell it to a small fraction of a small fraction of the market, and be abused in the press when it doesn’t happen overnight.”
Your obviously not a developer with all that whining. Platforms change, OS’ change, IDE’s change. Get used to it. Deficient tools? Uh huh…I bet you’ve never written “Hello World” with those silly comments. The fact is that hundreds of apps have been ported with no issues and the smaller the easier in most cases.
I’m a bit surprised that Adobe’s build system is so tied to Metrowerks. When will developers learn to put some effort into a nice, portable build system? Based on the previously closed software I’ve seen open-sourced, build systems in the commercial software realm tend to be pretty hackish. I’m not really sure why, though. It’s not like the tools for creating good build systems are new (and no, I don’t mean auto*).
Rayiner, it all has to do with the ‘code, code, code, code’, then press the build button – they don’t want to deal with the building system, they just want to keep taking on those files to their build tree and not have to worry about anything else.
The ideal situation would be (not to sure about Xcode) is an IDE which uses the GCC toolchain, including the autobuild/conf and the likes; atleast as an end customer, your project isn’t tied to a particular IDE, you can pick up and move if things don’t work out.
That its a couple of organisations who would rather live the good life than re-invest their profits back into their products, and thus provide a universal binary for them. Sorry, I have no sympathy for those who sit on their behind, and expect everyone to feel sorry for them because shock bloody horror, they just might actually have to provide support for the x86 architecture! perish the thought!
As for Adobe and Microsofts excuse about XCode, pulease; ‘doesn’t scale because we have a tonne of code’ is more like ‘we couldn’t be bothered moving, but now we’re in deep shit, so rather than take the blame ourselves, we’ll blame Apple for all our problems’ – bloody typical of them; excuse after excuse after excuse, years of preperation to move from Codewarrior to XCode, but they sat around, a rolling naked in money rather than investing it back into their products.
Edited 2006-04-03 05:29
“excuse after excuse after excuse, years of preperation to move from Codewarrior to XCode, but they sat around, a rolling naked in money rather than investing it back into their products.”
Years? What years of preparation time? Xcode 1.0 came out with 10.3, which was 2.5 years ago. However, until last year (Tiger and Xcode 2.0), it wasn’t all that useful. Xcode 2 and 2.1 finally introduced SCM friendlier project formats, build styles that don’t require full rebuilds when switching between Debug and Release config and a compiler that doesn’t take eternities gcc4).
So, at best, they had one year.
Why not continue to use CodeWarrior, but firstly switch out the compiler, get the thing compiling with GCC, then once that is done, wait till XCode is ready, the move over to that; bit by bit.
I’m sure the whole of XCode when released was totally shithouse, but at the same time, port the parts over – making it work for GCC, then wait, then move, then wait.
Had they done that, it would have been simply a matter of pulling the code over to XCode, all the necessary GCC stuff would have been long along, and it would be simply a matter of integrating the code into XCode.
Why not continue to use CodeWarrior, but firstly switch out the compiler, get the thing compiling with GCC, then once that is done, wait till XCode is ready, the move over to that; bit by bit.
Because CodeWarrior didn’t support “switching compilers?”
If CodeWarrior hadn’t died on us, most professional customers would still be using it. XCode is not yet suitable for professional use, and won’t be for some time to come. gcc has its place and is improving, but it couldn’t compete with CodeWarrior’s toolchain any more than it will with Intel’s.
Why switch to a new product if the old one is better in every way except cost (and CW paid for itself in a few days in a commercial project?) People changed when they were forced to, and given the amount of warning Apple / Metrowerks gave, that wasn’t all that long ago.
No you don’t, at least according to Apple. You just compile it for both in Xcode. Whether this work for all apps, alll the time remains to be seen.
If you’re willing to risk an untested app, sure. Otherwise, that’s just naive. The checkboxes are a compilation option only, they don’t mean your program will magically work.
Adobe should of had Photoshop in Cocoa ready by now.
Having it done in Cocoa would be very difficult to maintain as a cross-platform code base. Porting to XCode isn’t porting to Cocoa. Porting Photoshop to Cocoa would be like porting it to C# for the Windows version – it’s too platform-bound, not convenient for porting old and large codebases to, and doesn’t come with the kind of functionality Carbon has for larger programs.
Carbon = OS 9 APIs leftover in OS X.
Cocoa = OX X native APIs.
No, Carbon is as native as Cocoa is. Many Cocoa functions go through Carbon, and many native and necessary APIs and programs are written in Carbon (Apple Type Services, Core Audio, the Finder, Pro apps).
Cocoa just makes things a lot nicer and faster to work with. But it’s a different programming language with different paradigms.
As for Adobe and Microsofts excuse about XCode, pulease; ‘doesn’t scale because we have a tonne of code’ is more like ‘we couldn’t be bothered moving, but now we’re in deep shit, so rather than take the blame ourselves, we’ll blame Apple for all our problems’ – bloody typical of them; excuse after excuse after excuse, years of preperation to move from Codewarrior to XCode, but they sat around, a rolling naked in money rather than investing it back into their products.
XCode was not that great until it got out of the Project Builder stage. It still doesn’t scale the way CodeWarrior did, and starts slowing down when you have more than a dozen or two files in your project. There are still serious issues.