"Chipsets"? I'm sorry, but if you're going to get that pedantic, please get your terms straight. I assume you mean "architectures". Chipsets are something else.
I love the term 'FAT binary", just as I love 'thin client', 'FAT pipe', 'FAT lip', 'thick as two planks', ('hung like a whores' ), 'superscalar', 'multi-threaded' and boxes of any colour. FAT lip is my favourite though.
Talking of future hardware, I collect my new Trek road bike on Friday. I'm the only FAT binary that will successfully boot that one though!
Unrelated, but what about ternary logic?! Base 2 is so passé, lets use base 3 and leapfrog the competition! How l33t be we!
Seriously though, yellow box for windows would likely use the same cocoa universal binaries that would run on MacIntel machines. Although I'd expect that Leopard will include an updated package/bundle format to aid in this cross-os deployment. Additionally, I doubt it would be limited to Windows. I'd release it for Linux too.
Is it correct to say that if an application is built with xCode, it will be a Cocoa Application? And that those developers who already have Universal Binaries of their applications were able to do so very quickly because their programs were already xCode/Cocoa based? And that those like Adobe who didn't make the move to xCode years ago are currently rewriting their applications in Cocoa? Or will their applications still be Carbon-based, even after moving to xCode? Basically I'm wondering if the result of building an application in xCode will be that your application is also Cocoa.
Is it correct to say that if an application is built with xCode, it will be a Cocoa Application?
No. Xcode allows for building Carbon applications as well; always has.
Quote:
And that those developers who already have Universal Binaries of their applications were able to do so very quickly because their programs were already xCode/Cocoa based?
Because they were Xcode-based, yes. Cocoa has little to do with it.
Quote:
And that those like Adobe who didn't make the move to xCode years ago are currently rewriting their applications in Cocoa? Or will their applications still be Carbon-based, even after moving to xCode? Basically I'm wondering if the result of building an application in xCode will be that your application is also Cocoa.
Once Adobe redesigns their development process to have the applications build in Xcode, rather than in Metroworks CodeWarrior, they will benefit from a much smoother transition in the long run. Apple has been recommending this for many years, regardless of the Intel transition, but Adobe knew better.
I would add that like this current transition to Universal Binaries, if developers stick to Apple's encouraged development process (XCode, libraries, linking methods) future changes should also come along for the ride. If your app didn't do anything super custom, switching to Universal Binary was practically checking a somewhat hidden checkbox and clicking Build.
For example, if a developer correctly uses the accelerate framework for vector computation, this should run correctly on the GPU if that feature is part of Leopard with little additional work from the developer.
Chucker, thanks for clearing that up. Would you assume then that large applications like Maxon Cinema 4D, and Apple's own soon-to-be-released Universal Binaries of Final Cut Pro, Motion, DVD Studio Pro, & SoundTrack Pro are carbon-based? How about the iLife applications? And when Adobe moves their appications from Codewarrior to xCode, will they will remain Carbon-based?
How separate is Carbon from Cocoa at this point in OS X's life? Are they still very much both separate sets of Frameworks, Extensions, etc? Or have they pretty much been folded into eachother?
Where I'm going with this is back to the concept of Apple being able to create a "Yellowbox" invironment for Windows. Ideally, a third checkbox would be added to xCode to allow compiling for PowerPC-based Macs, Intel-Based Macs, and also Windows. These applications would automatically install the Yellowbox frameworks on Windows system if they hadn't been installed already by another application, such as a future version of iTunes. Such a move would allow Apple's current developers to standardize on one development platform, cutting costs dramtically and assuring Mac versions of those appications never get dropped.
Getting all developers onto xCode out of necessity for the Intel Switch seems like just the right way to pull this off. As we have seen with Adobe, big companies won't move to another set of development tools unless they absolutely have to. Telling them after the fact that they now get Windows versions 'for free' would go over much better than trying to convince developers to move to xCode so they can get Windows versions for free.
But if all the big name applications are indeed still Carbon-based, and if Carbon and Cocoa are still too distinct to both be included in this theoretical "YellowBox" for Windows, then the whole theory is shot to hell.
Chucker, thanks for clearing that up. Would you assume then that large applications like Maxon Cinema 4D, and Apple's own soon-to-be-released Universal Binaries of Final Cut Pro, Motion, DVD Studio Pro, & SoundTrack Pro are carbon-based? How about the iLife applications? And when Adobe moves their appications from Codewarrior to xCode, will they will remain Carbon-based?
Cinema 4D is presumably Carbon. All of Apple's pro apps are Cocoa by now (DVD Studio Pro 1.x was Carbon; Final Cut Pro 1.x and 2.x were Carbon, not sure about 3.x).
iMovie has been Cocoa since 3.0(?); iDVD I don't know (2.0 and newer?); the rest of the iLife suite has, as far as I can tell, been Carbon from the start. Note that iTunes is excluded because, as of iLife '06, it is no longer considered an iLife component. iTunes has always been Carbon and still is.
Quote:
How separate is Carbon from Cocoa at this point in OS X's life? Are they still very much both separate sets of Frameworks, Extensions, etc? Or have they pretty much been folded into eachother?
It has always been Apple's (official, anyhow) goal to try and create as little discrepancy feature-wise between the two as possible. This is what CoreFoundation is mainly about; a common foundation that both are based on.
In practice, they haven't exactly reached that and possibly never will. Of note, Carbon apps still can't use the system-wide spell-checker, for instance.
Quote:
Where I'm going with this is back to the concept of Apple being able to create a "Yellowbox" invironment for Windows.
YellowBox, as an aside, is a former name of Cocoa. Before YellowBox, it was called OpenStep.
GNUstep, in turn, is an open source implementation of OpenStep, as OpenStep at one point became an open standard.
Quote:
Ideally, a third checkbox would be added to xCode to allow compiling for PowerPC-based Macs, Intel-Based Macs, and also Windows. These applications would automatically install the Yellowbox frameworks on Windows system if they hadn't been installed already by another application, such as a future version of iTunes. Such a move would allow Apple's current developers to standardize on one development platform, cutting costs dramtically and assuring Mac versions of those appications never get dropped.
As said, the yellow box is Cocoa. Three boxes once existed, more or less officially, in Rhapsody concepts: blue for old-school Mac OS (notice its process is still called the "TruBlueEnvironment"), red for Windows and yellow for "NeXT".
Blue Box then became "Classic", Red Box got ditched entirely and Yellow Box got rebranded as "Cocoa"; in addition, a "Green" box, "Carbon", was added due mainly to vehement protest from developers who refused to rework their apps to work with Cocoa.
Quote:
Getting all developers onto xCode out of necessity for the Intel Switch seems like just the right way to pull this off. As we have seen with Adobe, big companies won't move to another set of development tools unless they absolutely have to. Telling them after the fact that they now get Windows versions 'for free' would go over much better than trying to convince developers to move to xCode so they can get Windows versions for free.
Assuming Apple were to allow Carbon apps to compile on Windows, yes, but that has nothing to do with the Yellow Box, and thus not with the "Dharma" rumor either.
Notice that iTunes is, indeed, an example of a Carbon app that runs on Windows, almost unchanged, burning drivers, WMA support, optimizations and UI customizations aside.
Cinema 4D is presumably Carbon. All of Apple's pro apps are Cocoa by now (DVD Studio Pro 1.x was Carbon; Final Cut Pro 1.x and 2.x were Carbon, not sure about 3.x).
iMovie has been Cocoa since 3.0(?); iDVD I don't know (2.0 and newer?); the rest of the iLife suite has, as far as I can tell, been Carbon from the start. Note that iTunes is excluded because, as of iLife '06, it is no longer considered an iLife component. iTunes has always been Carbon and still is.
It has always been Apple's (official, anyhow) goal to try and create as little discrepancy feature-wise between the two as possible. This is what CoreFoundation is mainly about; a common foundation that both are based on.
In practice, they haven't exactly reached that and possibly never will. Of note, Carbon apps still can't use the system-wide spell-checker, for instance.
YellowBox, as an aside, is a former name of Cocoa. Before YellowBox, it was called OpenStep.
GNUstep, in turn, is an open source implementation of OpenStep, as OpenStep at one point became an open standard.
As said, the yellow box is Cocoa. Three boxes once existed, more or less officially, in Rhapsody concepts: blue for old-school Mac OS (notice its process is still called the "TruBlueEnvironment"), red for Windows and yellow for "NeXT".
Blue Box then became "Classic", Red Box got ditched entirely and Yellow Box got rebranded as "Cocoa"; in addition, a "Green" box, "Carbon", was added due mainly to vehement protest from developers who refused to rework their apps to work with Cocoa.
Assuming Apple were to allow Carbon apps to compile on Windows, yes, but that has nothing to do with the Yellow Box, and thus not with the "Dharma" rumor either.
Notice that iTunes is, indeed, an example of a Carbon app that runs on Windows, almost unchanged, burning drivers, WMA support, optimizations and UI customizations aside.
YellowBox was termed to be generally NeXT tools, by more specifically Openstep for NT.
Yes Blue Box is Classic.
Yes Red Box was Windows emulation inside of Rhapsody.
Too bad back at WWDC 97 the folks who got the Carbon documentation didn't take for reality that eventually this "Transistional API" was going to bite it. The writings on the wall. Whether this means the mach-o for XP/Vista will be only available to Apple for apps like iTunes is yet to be seen but I highly doubt they will open it up for everyone. iTunes on NT/XP drives revenue for iPod sales. So unless Apple is coming out with more devices that such an interface on Windows makes sense I think they'll stick to OS X only.
Now for my rant and one that frustrated me when I worked within it.
First, Yellow Box was Openstep for Windows/NT (Dev/run-time on Windows for Openstep Dev Tools so EOF based apps and any Openstep client app could run as a separate layer above Windows, but faster than emulation.
Cocoa marketing lingo was born because when Openstep was around EOF was a separate product. EOF was absorbed by WOF when WebObject morphed from ObjC base to a pure Java based solution. They rewrote EOF as much as possible using Java.
And this was during the time I left Apple Enterprise. Most people don't know that during the merger between NeXT and Apple quite a few top quality managers at NeXT bailed for double the money offers. Unfortunately, 90%+ were in Professional Services.
Hell, my mentor, Mark Tacchi (HipBone founder) left just one week after I moved from NeXT SQA to Professional Services. He took double the money at 911 Entertainment (failed startup) before starting Hipbone with a Federal sales rep, Dan Rolla.
Who replaced them? Professional services engineers who have never managed and whose primary jobs were dedicated consultants for accounts like Merrill Lynch, AT&T Wireless, Fannie Mae, Swiss Bank, etc. They were good at interfacing with other engineers but piss poor at interfacing with the rest of Professional services including sales, sales engineers, regional sales and upper management. They weren't inexperienced and showed they didn't have strong diplomatic skills.
After a 18 months of no reviews, no cost of living adjustments and wearing too many hats while bearing the brunt of frustrations due to most management living on the East coast I left. I left after offering several proposals to relocate in other regions where the cost of living was less. Living in the Bay Area on a salary none of you would take today just to gain industry experience was the last straw.
The enterprise was put on life support and the tools were redirected.
In short, they fucked up EOF and WebObjects by stripping its original ObjC Cocoa based foundation and making it a Java only solution. Many thought it the smart maneuver with Java all the rage but then again when you're Apple and you have your own operating system you should think like NeXT did and make your tools specific to your platform and expand to other platforms as a secondary condition. How did they fuck it up? By not growing Professional Services and targeting the enterprise markets as it would need to compete against solutions like JBOSS and others they left Professional Services to run a skeleton crew and thats when the mass exodus of former NeXT employees in professional services began. Quite a few regional accounts managers left, along with various sales and support personnel.
By allowing present [short-term] clients to demand a transition to Java or else and not insisting that it was going to be an ObjC or else only solution for the long haul they made it clear that they didn't want to have to put resources into competing against Java in the enterprise appserver business.
When Apple wants to do an OS/Hardware marriage they fail for the enterprise by not wanting to keep the Cocoa WOF version alive. For all I know they are and I hope it eventually returns: they've got some talented Cocoa devs hired in the past year and a half now working on WOF. They are bilingual in their ObjC/Java backgrounds with ObjC years ahead.
WOF 5.3 is mature and very powerful, but not nearly as powerful if it were written entirely in Cocoa. And seeing that WOF on NT is dead it would make sense to resume WOF for Cocoa.
WOF 6 rewritten in ObjC and fully aware of the entire Cocoa Frameworks with a complete version of EOF 6 in ObjC would help push more Macs into the enterprise as well as help OS X Server sales, etc.
Right now there is Microsoft C#/.NET, Sun Java/J2EE and both actually are children in years of presence compared to WOF ObjC/Cocoa, yet most don't even know it.
If Apple wants to be across the board they need to eat all of their own dogfood.
A very cynical view but then again, working through the transition was 50% good and 50% bad. The bad only surfaced because certain highlevel executives at NeXT didn't foresee an exodus of management during a post merger time frame.
Comments
Talking of future hardware, I collect my new Trek road bike on Friday. I'm the only FAT binary that will successfully boot that one though!
Seriously though, yellow box for windows would likely use the same cocoa universal binaries that would run on MacIntel machines. Although I'd expect that Leopard will include an updated package/bundle format to aid in this cross-os deployment. Additionally, I doubt it would be limited to Windows. I'd release it for Linux too.
Originally posted by Cory Bauer
Is it correct to say that if an application is built with xCode, it will be a Cocoa Application?
No. Xcode allows for building Carbon applications as well; always has.
And that those developers who already have Universal Binaries of their applications were able to do so very quickly because their programs were already xCode/Cocoa based?
Because they were Xcode-based, yes. Cocoa has little to do with it.
And that those like Adobe who didn't make the move to xCode years ago are currently rewriting their applications in Cocoa? Or will their applications still be Carbon-based, even after moving to xCode? Basically I'm wondering if the result of building an application in xCode will be that your application is also Cocoa.
Once Adobe redesigns their development process to have the applications build in Xcode, rather than in Metroworks CodeWarrior, they will benefit from a much smoother transition in the long run. Apple has been recommending this for many years, regardless of the Intel transition, but Adobe knew better.
For example, if a developer correctly uses the accelerate framework for vector computation, this should run correctly on the GPU if that feature is part of Leopard with little additional work from the developer.
How separate is Carbon from Cocoa at this point in OS X's life? Are they still very much both separate sets of Frameworks, Extensions, etc? Or have they pretty much been folded into eachother?
Where I'm going with this is back to the concept of Apple being able to create a "Yellowbox" invironment for Windows. Ideally, a third checkbox would be added to xCode to allow compiling for PowerPC-based Macs, Intel-Based Macs, and also Windows. These applications would automatically install the Yellowbox frameworks on Windows system if they hadn't been installed already by another application, such as a future version of iTunes. Such a move would allow Apple's current developers to standardize on one development platform, cutting costs dramtically and assuring Mac versions of those appications never get dropped.
Getting all developers onto xCode out of necessity for the Intel Switch seems like just the right way to pull this off. As we have seen with Adobe, big companies won't move to another set of development tools unless they absolutely have to. Telling them after the fact that they now get Windows versions 'for free' would go over much better than trying to convince developers to move to xCode so they can get Windows versions for free.
But if all the big name applications are indeed still Carbon-based, and if Carbon and Cocoa are still too distinct to both be included in this theoretical "YellowBox" for Windows, then the whole theory is shot to hell.
Originally posted by Cory Bauer
Chucker, thanks for clearing that up. Would you assume then that large applications like Maxon Cinema 4D, and Apple's own soon-to-be-released Universal Binaries of Final Cut Pro, Motion, DVD Studio Pro, & SoundTrack Pro are carbon-based? How about the iLife applications? And when Adobe moves their appications from Codewarrior to xCode, will they will remain Carbon-based?
Cinema 4D is presumably Carbon. All of Apple's pro apps are Cocoa by now (DVD Studio Pro 1.x was Carbon; Final Cut Pro 1.x and 2.x were Carbon, not sure about 3.x).
iMovie has been Cocoa since 3.0(?); iDVD I don't know (2.0 and newer?); the rest of the iLife suite has, as far as I can tell, been Carbon from the start. Note that iTunes is excluded because, as of iLife '06, it is no longer considered an iLife component. iTunes has always been Carbon and still is.
How separate is Carbon from Cocoa at this point in OS X's life? Are they still very much both separate sets of Frameworks, Extensions, etc? Or have they pretty much been folded into eachother?
It has always been Apple's (official, anyhow) goal to try and create as little discrepancy feature-wise between the two as possible. This is what CoreFoundation is mainly about; a common foundation that both are based on.
In practice, they haven't exactly reached that and possibly never will. Of note, Carbon apps still can't use the system-wide spell-checker, for instance.
Where I'm going with this is back to the concept of Apple being able to create a "Yellowbox" invironment for Windows.
YellowBox, as an aside, is a former name of Cocoa. Before YellowBox, it was called OpenStep.
GNUstep, in turn, is an open source implementation of OpenStep, as OpenStep at one point became an open standard.
Ideally, a third checkbox would be added to xCode to allow compiling for PowerPC-based Macs, Intel-Based Macs, and also Windows. These applications would automatically install the Yellowbox frameworks on Windows system if they hadn't been installed already by another application, such as a future version of iTunes. Such a move would allow Apple's current developers to standardize on one development platform, cutting costs dramtically and assuring Mac versions of those appications never get dropped.
As said, the yellow box is Cocoa. Three boxes once existed, more or less officially, in Rhapsody concepts: blue for old-school Mac OS (notice its process is still called the "TruBlueEnvironment"), red for Windows and yellow for "NeXT".
Blue Box then became "Classic", Red Box got ditched entirely and Yellow Box got rebranded as "Cocoa"; in addition, a "Green" box, "Carbon", was added due mainly to vehement protest from developers who refused to rework their apps to work with Cocoa.
Getting all developers onto xCode out of necessity for the Intel Switch seems like just the right way to pull this off. As we have seen with Adobe, big companies won't move to another set of development tools unless they absolutely have to. Telling them after the fact that they now get Windows versions 'for free' would go over much better than trying to convince developers to move to xCode so they can get Windows versions for free.
Assuming Apple were to allow Carbon apps to compile on Windows, yes, but that has nothing to do with the Yellow Box, and thus not with the "Dharma" rumor either.
Notice that iTunes is, indeed, an example of a Carbon app that runs on Windows, almost unchanged, burning drivers, WMA support, optimizations and UI customizations aside.
Originally posted by Chucker
Cinema 4D is presumably Carbon. All of Apple's pro apps are Cocoa by now (DVD Studio Pro 1.x was Carbon; Final Cut Pro 1.x and 2.x were Carbon, not sure about 3.x).
iMovie has been Cocoa since 3.0(?); iDVD I don't know (2.0 and newer?); the rest of the iLife suite has, as far as I can tell, been Carbon from the start. Note that iTunes is excluded because, as of iLife '06, it is no longer considered an iLife component. iTunes has always been Carbon and still is.
It has always been Apple's (official, anyhow) goal to try and create as little discrepancy feature-wise between the two as possible. This is what CoreFoundation is mainly about; a common foundation that both are based on.
In practice, they haven't exactly reached that and possibly never will. Of note, Carbon apps still can't use the system-wide spell-checker, for instance.
YellowBox, as an aside, is a former name of Cocoa. Before YellowBox, it was called OpenStep.
GNUstep, in turn, is an open source implementation of OpenStep, as OpenStep at one point became an open standard.
As said, the yellow box is Cocoa. Three boxes once existed, more or less officially, in Rhapsody concepts: blue for old-school Mac OS (notice its process is still called the "TruBlueEnvironment"), red for Windows and yellow for "NeXT".
Blue Box then became "Classic", Red Box got ditched entirely and Yellow Box got rebranded as "Cocoa"; in addition, a "Green" box, "Carbon", was added due mainly to vehement protest from developers who refused to rework their apps to work with Cocoa.
Assuming Apple were to allow Carbon apps to compile on Windows, yes, but that has nothing to do with the Yellow Box, and thus not with the "Dharma" rumor either.
Notice that iTunes is, indeed, an example of a Carbon app that runs on Windows, almost unchanged, burning drivers, WMA support, optimizations and UI customizations aside.
YellowBox was termed to be generally NeXT tools, by more specifically Openstep for NT.
Yes Blue Box is Classic.
Yes Red Box was Windows emulation inside of Rhapsody.
Too bad back at WWDC 97 the folks who got the Carbon documentation didn't take for reality that eventually this "Transistional API" was going to bite it. The writings on the wall. Whether this means the mach-o for XP/Vista will be only available to Apple for apps like iTunes is yet to be seen but I highly doubt they will open it up for everyone. iTunes on NT/XP drives revenue for iPod sales. So unless Apple is coming out with more devices that such an interface on Windows makes sense I think they'll stick to OS X only.
Now for my rant and one that frustrated me when I worked within it.
First, Yellow Box was Openstep for Windows/NT (Dev/run-time on Windows for Openstep Dev Tools so EOF based apps and any Openstep client app could run as a separate layer above Windows, but faster than emulation.
Cocoa marketing lingo was born because when Openstep was around EOF was a separate product. EOF was absorbed by WOF when WebObject morphed from ObjC base to a pure Java based solution. They rewrote EOF as much as possible using Java.
And this was during the time I left Apple Enterprise. Most people don't know that during the merger between NeXT and Apple quite a few top quality managers at NeXT bailed for double the money offers. Unfortunately, 90%+ were in Professional Services.
Hell, my mentor, Mark Tacchi (HipBone founder) left just one week after I moved from NeXT SQA to Professional Services. He took double the money at 911 Entertainment (failed startup) before starting Hipbone with a Federal sales rep, Dan Rolla.
Who replaced them? Professional services engineers who have never managed and whose primary jobs were dedicated consultants for accounts like Merrill Lynch, AT&T Wireless, Fannie Mae, Swiss Bank, etc. They were good at interfacing with other engineers but piss poor at interfacing with the rest of Professional services including sales, sales engineers, regional sales and upper management. They weren't inexperienced and showed they didn't have strong diplomatic skills.
After a 18 months of no reviews, no cost of living adjustments and wearing too many hats while bearing the brunt of frustrations due to most management living on the East coast I left. I left after offering several proposals to relocate in other regions where the cost of living was less. Living in the Bay Area on a salary none of you would take today just to gain industry experience was the last straw.
The enterprise was put on life support and the tools were redirected.
In short, they fucked up EOF and WebObjects by stripping its original ObjC Cocoa based foundation and making it a Java only solution. Many thought it the smart maneuver with Java all the rage but then again when you're Apple and you have your own operating system you should think like NeXT did and make your tools specific to your platform and expand to other platforms as a secondary condition. How did they fuck it up? By not growing Professional Services and targeting the enterprise markets as it would need to compete against solutions like JBOSS and others they left Professional Services to run a skeleton crew and thats when the mass exodus of former NeXT employees in professional services began. Quite a few regional accounts managers left, along with various sales and support personnel.
By allowing present [short-term] clients to demand a transition to Java or else and not insisting that it was going to be an ObjC or else only solution for the long haul they made it clear that they didn't want to have to put resources into competing against Java in the enterprise appserver business.
When Apple wants to do an OS/Hardware marriage they fail for the enterprise by not wanting to keep the Cocoa WOF version alive. For all I know they are and I hope it eventually returns: they've got some talented Cocoa devs hired in the past year and a half now working on WOF. They are bilingual in their ObjC/Java backgrounds with ObjC years ahead.
WOF 5.3 is mature and very powerful, but not nearly as powerful if it were written entirely in Cocoa. And seeing that WOF on NT is dead it would make sense to resume WOF for Cocoa.
WOF 6 rewritten in ObjC and fully aware of the entire Cocoa Frameworks with a complete version of EOF 6 in ObjC would help push more Macs into the enterprise as well as help OS X Server sales, etc.
Right now there is Microsoft C#/.NET, Sun Java/J2EE and both actually are children in years of presence compared to WOF ObjC/Cocoa, yet most don't even know it.
If Apple wants to be across the board they need to eat all of their own dogfood.
A very cynical view but then again, working through the transition was 50% good and 50% bad. The bad only surfaced because certain highlevel executives at NeXT didn't foresee an exodus of management during a post merger time frame.