Conversely, you could say that it is a way to help Microsoft into greater dominance because you'd encourage putting Windows onto a large percentage of Macs. Then where does that leave OS X? We want ports of houdini, XSI, AutoCAD etc, we don't want the developers to give us easy instructions for installing Windows.
I'm not advocating putting Windows onto Mac OS X. I'm advocating CoreWindows as a 90% Win32/*.NET API implementation on Mac OS X. Just think of it as Carbon like API, which is a 90% implementation of the Mac OS 9 toolbox on Mac OS X. It's what got all those Mac OS apps running native on Mac OS X afterall. In fact, Carbon is probably the one true reason why Mac OS X is successful.
Where does this leave OS X? In a position to allow easy porting of houdini, XSI, AutoCAD which gives them a real chance at dominance.
I'm not advocating putting Windows onto Mac OS X. I'm advocating CoreWindows as a 90% Win32/*.NET API implementation on Mac OS X. Just think of it as Carbon like API, which is a 90% implementation of the Mac OS 9 toolbox on Mac OS X. It's what got all those Mac OS apps running native on Mac OS X afterall. In fact, Carbon is probably the one true reason why Mac OS X is successful.
Where does this leave OS X? In a position to allow easy porting of houdini, XSI, AutoCAD which gives them a real chance at dominance.
I think that would result in most applications not portet into carbon or cocoa but into CoreWindows. sure we would get more apps, but afaik the API is one of the worst parts of windows and the portet software would probably not have the 'quality' of the software we are used to.
a better solution for getting more apps onto OSX would imho be the resurrection of yellow box for windows. that would make cross-platform development easy (especially for mac developers). i don't know any developers that have made apps for cocoa and went back to another API?
I think that would result in most applications not portet into carbon or cocoa but into CoreWindows. sure we would get more apps, but afaik the API is one of the worst parts of windows and the portet software would probably not have the 'quality' of the software we are used to.
That's the point, to have developers port their Windows apps to Mac OS X through CoreWindows, a native Mac OS X API. As for quality, it isn't going to be any worse than Carbon apps.
Quote:
a better solution for getting more apps onto OSX would imho be the resurrection of yellow box for windows. that would make cross-platform development easy (especially for mac developers). i don't know any developers that have made apps for cocoa and went back to another API?
Have to disagree. Not only that, it is the surest path to failure. Legacy is one of the primary drivers in application software. Companies won't throw away millions of dollars and thousands of man-years of effort in code development to move to a new API.
OS/2 offered binary compatibility through a virtual DOS machine running a copy of Windows 3.1+, or in earlier versions, employing Windows 3.0 components when IBM and Microsoft weren't total enemies. OS/2 is akin to Mac OS X running Parallels. Once Microsoft shipped Win95, OS/2 essentially died because all of the developers moved to Win32 and OS/2 couldn't run modern Windows apps anymore.
I don't think IBM ever attempted to go the Win32 API clone route. There's a community effort post OS/2 demise, but there's a lot of those (WINE et al). If the Cringely fantasy is true, that Apple has the Win32 source code itself, its a huge leg up compared to the clean-room clone efforts.
If Apple can take the Win32/*.NET API as its own, it'll be a good start in a OS war between MS and Apple. Like iTunes AAC and iPods, the API locks developers into a particular system. With Windows 90+% dominant, it pretty much means either a competitor implements the Windows API on their system or must create a separate market, fairly independent of the Windows market, that can eventually outgrow and supercede Windows.
Why didn't Adobe port their apps to Cocoa? Why didn't Microsoft?
1) Because Carbon is a perfectly fine framework and just as Mac OS-specific as Cocoa is.
2) Because Adobe and Microsoft are too lazy to properly separate their code between front-end and back-end. Without that separation, it's near-impossible to use Cocoa well.
Quote:
Heck, why aren't there more apps available on all of the alternative platforms?
1) Because Carbon is a perfectly fine framework and just as Mac OS-specific as Cocoa is.
2) Because Adobe and Microsoft are too lazy to properly separate their code between front-end and back-end. Without that separation, it's near-impossible to use Cocoa well.
Remember, in the original Rhapsody strategy, all Apple had was a virtual machine running Mac OX 9 for legacy apps and a port to the "pre-Cocoa" API for native apps. Carbon was specifically created by Apple to have application vendors produce native Mac OS X apps in as cheap a manner as possible, otherwise, Apple was dead. And as you know, Carbon is a 90% implementation of the Mac OS 9 toolbox APIs.
Carbon is a perfectly fine framework because the vast majority of a OS 9 toolbox app's didn't have to change much. CoreWindows would serve the same function for Windows apps.
As for lazyness, well, software is expensive to change and if the path to getting on a new platform is essentially an application rewrite, it means tremendous time and expense. Hence, it's too costly for [Windows] app vendors to port to Carbon or Cocoa, especially when all non-Windows systems are less than 10% of the market.
I'm not advocating putting Windows onto Mac OS X. I'm advocating CoreWindows as a 90% Win32/*.NET API implementation on Mac OS X. Just think of it as Carbon like API, which is a 90% implementation of the Mac OS 9 toolbox on Mac OS X.
But what I said about that was Crossover is doing exactly the same but it doesn't work because they have to reverse engineer Microsoft's proprietary APIs. Microsoft are not going to easily give up one of their strongest methods of maintaining a monopoly. Even if they did, as soon as they saw a problem, they would reserve the right to revoke it.
If Apple try to build alternate Microsoft APIs like Crossover, they face massive incompatibility issues and so the effort becomes useless.
Quote:
Originally Posted by THT
Carbon is a perfectly fine framework because the vast majority of a OS 9 toolbox app's didn't have to change much. CoreWindows would serve the same function for Windows apps.
But that only works for future software if you mean a developer API. You also have to remember that people explicitly stop Mac support even if they have a product because of low sales. Remember Bryce?
So we need Windows apps and it would be nice to have a compatibility layer but as Crossover has shown, it just doesn't work well enough.
I don't know what the deal is with Carbon. You can build a 100% C/C++ program using Cocoa so I don't know why the whole thing isn't deprecated.
Well, just for the heck of it, I configured a Dell Precision 690 w/ two Xeon 53-whatevers (the 2.66 GHz ones), and it gave a delivery date of Jan 7th, so Apple isn't in a major rush (since supplies are limited ATM, and CS3 is a few months out). I call the Mac Pro as launching around the time ATI drops the x2800-series.
Well, just for the heck of it, I configured a Dell Precision 690 w/ two Xeon 53-whatevers (the 2.66 GHz ones), and it gave a delivery date of Jan 7th, so Apple isn't in a major rush (since supplies are limited ATM, and CS3 is a few months out). I call the Mac Pro as launching around the time ATI drops the x2800-series.
I would say that if Dell can ship by the 7th then Apple will announce them at the MWSF and ship shortly after.
My gut feeling is sometime in February as the shipping time. And the announcement short while after MWSF.
I think Apple will wait couple weeks at least after MWSF to keep the media talking about them. It's better than announce too many products at the same time. Keep the momentum on the media for Apple.
Comments
Conversely, you could say that it is a way to help Microsoft into greater dominance because you'd encourage putting Windows onto a large percentage of Macs. Then where does that leave OS X? We want ports of houdini, XSI, AutoCAD etc, we don't want the developers to give us easy instructions for installing Windows.
I'm not advocating putting Windows onto Mac OS X. I'm advocating CoreWindows as a 90% Win32/*.NET API implementation on Mac OS X. Just think of it as Carbon like API, which is a 90% implementation of the Mac OS 9 toolbox on Mac OS X. It's what got all those Mac OS apps running native on Mac OS X afterall. In fact, Carbon is probably the one true reason why Mac OS X is successful.
Where does this leave OS X? In a position to allow easy porting of houdini, XSI, AutoCAD which gives them a real chance at dominance.
It is simply to costly for software developers to port their software to Carbon or Cocoa.
Bull. That has never been true.
I'm not advocating putting Windows onto Mac OS X. I'm advocating CoreWindows as a 90% Win32/*.NET API implementation on Mac OS X. Just think of it as Carbon like API, which is a 90% implementation of the Mac OS 9 toolbox on Mac OS X. It's what got all those Mac OS apps running native on Mac OS X afterall. In fact, Carbon is probably the one true reason why Mac OS X is successful.
Where does this leave OS X? In a position to allow easy porting of houdini, XSI, AutoCAD which gives them a real chance at dominance.
I think that would result in most applications not portet into carbon or cocoa but into CoreWindows. sure we would get more apps, but afaik the API is one of the worst parts of windows and the portet software would probably not have the 'quality' of the software we are used to.
a better solution for getting more apps onto OSX would imho be the resurrection of yellow box for windows. that would make cross-platform development easy (especially for mac developers). i don't know any developers that have made apps for cocoa and went back to another API?
afaik the API is one of the worst parts of windows
Not just that; it's also being phased out in favor of .NET 3.0 (formerly "WinFX").
I think that would result in most applications not portet into carbon or cocoa but into CoreWindows. sure we would get more apps, but afaik the API is one of the worst parts of windows and the portet software would probably not have the 'quality' of the software we are used to.
That's the point, to have developers port their Windows apps to Mac OS X through CoreWindows, a native Mac OS X API. As for quality, it isn't going to be any worse than Carbon apps.
a better solution for getting more apps onto OSX would imho be the resurrection of yellow box for windows. that would make cross-platform development easy (especially for mac developers). i don't know any developers that have made apps for cocoa and went back to another API?
Have to disagree. Not only that, it is the surest path to failure. Legacy is one of the primary drivers in application software. Companies won't throw away millions of dollars and thousands of man-years of effort in code development to move to a new API.
That's the point, to have developers port their Windows apps to Mac OS X through CoreWindows, a native Mac OS X API.
Except you wouldn't be porting them at all. You wouldn't even be recompiling them.
I'm not advocating putting Windows onto Mac OS X. I'm advocating CoreWindows as a 90% Win32/*.NET API implementation on Mac OS X.
That idea worked great for OS/2.
That idea worked great for OS/2.
OS/2 offered binary compatibility through a virtual DOS machine running a copy of Windows 3.1+, or in earlier versions, employing Windows 3.0 components when IBM and Microsoft weren't total enemies. OS/2 is akin to Mac OS X running Parallels. Once Microsoft shipped Win95, OS/2 essentially died because all of the developers moved to Win32 and OS/2 couldn't run modern Windows apps anymore.
I don't think IBM ever attempted to go the Win32 API clone route. There's a community effort post OS/2 demise, but there's a lot of those (WINE et al). If the Cringely fantasy is true, that Apple has the Win32 source code itself, its a huge leg up compared to the clean-room clone efforts.
If Apple can take the Win32/*.NET API as its own, it'll be a good start in a OS war between MS and Apple. Like iTunes AAC and iPods, the API locks developers into a particular system. With Windows 90+% dominant, it pretty much means either a competitor implements the Windows API on their system or must create a separate market, fairly independent of the Windows market, that can eventually outgrow and supercede Windows.
Bull. That has never been true.
Why didn't Adobe port their apps to Cocoa? Why didn't Microsoft? Heck, why aren't there more apps available on all of the alternative platforms?
Why didn't Adobe port their apps to Cocoa? Why didn't Microsoft?
1) Because Carbon is a perfectly fine framework and just as Mac OS-specific as Cocoa is.
2) Because Adobe and Microsoft are too lazy to properly separate their code between front-end and back-end. Without that separation, it's near-impossible to use Cocoa well.
Heck, why aren't there more apps available on all of the alternative platforms?
Ignorance.
1) Because Carbon is a perfectly fine framework and just as Mac OS-specific as Cocoa is.
2) Because Adobe and Microsoft are too lazy to properly separate their code between front-end and back-end. Without that separation, it's near-impossible to use Cocoa well.
Remember, in the original Rhapsody strategy, all Apple had was a virtual machine running Mac OX 9 for legacy apps and a port to the "pre-Cocoa" API for native apps. Carbon was specifically created by Apple to have application vendors produce native Mac OS X apps in as cheap a manner as possible, otherwise, Apple was dead. And as you know, Carbon is a 90% implementation of the Mac OS 9 toolbox APIs.
Carbon is a perfectly fine framework because the vast majority of a OS 9 toolbox app's didn't have to change much. CoreWindows would serve the same function for Windows apps.
As for lazyness, well, software is expensive to change and if the path to getting on a new platform is essentially an application rewrite, it means tremendous time and expense. Hence, it's too costly for [Windows] app vendors to port to Carbon or Cocoa, especially when all non-Windows systems are less than 10% of the market.
I'm not advocating putting Windows onto Mac OS X. I'm advocating CoreWindows as a 90% Win32/*.NET API implementation on Mac OS X. Just think of it as Carbon like API, which is a 90% implementation of the Mac OS 9 toolbox on Mac OS X.
But what I said about that was Crossover is doing exactly the same but it doesn't work because they have to reverse engineer Microsoft's proprietary APIs. Microsoft are not going to easily give up one of their strongest methods of maintaining a monopoly. Even if they did, as soon as they saw a problem, they would reserve the right to revoke it.
If Apple try to build alternate Microsoft APIs like Crossover, they face massive incompatibility issues and so the effort becomes useless.
Carbon is a perfectly fine framework because the vast majority of a OS 9 toolbox app's didn't have to change much. CoreWindows would serve the same function for Windows apps.
But that only works for future software if you mean a developer API. You also have to remember that people explicitly stop Mac support even if they have a product because of low sales. Remember Bryce?
So we need Windows apps and it would be nice to have a compatibility layer but as Crossover has shown, it just doesn't work well enough.
I don't know what the deal is with Carbon. You can build a 100% C/C++ program using Cocoa so I don't know why the whole thing isn't deprecated.
I don't know what the deal is with Carbon. You can build a 100% C/C++ program using Cocoa so I don't know why the whole thing isn't deprecated.
Probably waiting for OS XI to do that
Sebastian
You can build a 100% C/C++ program using Cocoa
There are no C++ language bindings for Cocoa.
I doubt it.
hopefully by February it'll be here, can't wait to upgrade my Quad G5. now with Photoshop CS3 beta, sounds very exciting.
Well, just for the heck of it, I configured a Dell Precision 690 w/ two Xeon 53-whatevers (the 2.66 GHz ones), and it gave a delivery date of Jan 7th, so Apple isn't in a major rush (since supplies are limited ATM, and CS3 is a few months out). I call the Mac Pro as launching around the time ATI drops the x2800-series.
I would say that if Dell can ship by the 7th then Apple will announce them at the MWSF and ship shortly after.
My gut feeling is sometime in February as the shipping time. And the announcement short while after MWSF.
I think Apple will wait couple weeks at least after MWSF to keep the media talking about them. It's better than announce too many products at the same time. Keep the momentum on the media for Apple.
Bring it on!