Octo-Core coming very soon to a Pro Mac near you?

2

Comments

  • Reply 21 of 54
    thttht Posts: 6,019member
    Quote:
    Originally Posted by Marvin


    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.
     0Likes 0Dislikes 0Informatives
  • Reply 22 of 54
    chuckerchucker Posts: 5,089member
    Quote:
    Originally Posted by THT


    It is simply to costly for software developers to port their software to Carbon or Cocoa.



    Bull. That has never been true.
     0Likes 0Dislikes 0Informatives
  • Reply 23 of 54
    moochmooch Posts: 113member
    I want the Mac Pro to get cheaper, not more expensive! Cheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeaper!!
     0Likes 0Dislikes 0Informatives
  • Reply 24 of 54
    Quote:
    Originally Posted by THT


    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?
     0Likes 0Dislikes 0Informatives
  • Reply 25 of 54
    chuckerchucker Posts: 5,089member
    Quote:
    Originally Posted by thetru7h


    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").
     0Likes 0Dislikes 0Informatives
  • Reply 26 of 54
    thttht Posts: 6,019member
    Quote:
    Originally Posted by thetru7h


    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.
     0Likes 0Dislikes 0Informatives
  • Reply 27 of 54
    chuckerchucker Posts: 5,089member
    Quote:
    Originally Posted by THT


    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.
     0Likes 0Dislikes 0Informatives
  • Reply 28 of 54
    cubitcubit Posts: 846member
    How about a decompiler.
     0Likes 0Dislikes 0Informatives
  • Reply 29 of 54
    wmfwmf Posts: 1,164member
    Quote:
    Originally Posted by THT


    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.
     0Likes 0Dislikes 0Informatives
  • Reply 30 of 54
    thttht Posts: 6,019member
    Quote:
    Originally Posted by wmf


    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.
     0Likes 0Dislikes 0Informatives
  • Reply 31 of 54
    thttht Posts: 6,019member
    Quote:
    Originally Posted by Chucker


    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?
     0Likes 0Dislikes 0Informatives
  • Reply 32 of 54
    chuckerchucker Posts: 5,089member
    Quote:
    Originally Posted by THT


    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?



    Ignorance.
     0Likes 0Dislikes 0Informatives
  • Reply 33 of 54
    thttht Posts: 6,019member
    Quote:
    Originally Posted by Chucker


    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.
     0Likes 0Dislikes 0Informatives
  • Reply 34 of 54
    Marvinmarvin Posts: 15,585moderator
    Quote:
    Originally Posted by THT


    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.
     0Likes 0Dislikes 0Informatives
  • Reply 35 of 54
    slewisslewis Posts: 2,081member
    Quote:

    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
     0Likes 0Dislikes 0Informatives
  • Reply 36 of 54
    chuckerchucker Posts: 5,089member
    Quote:
    Originally Posted by Marvin


    You can build a 100% C/C++ program using Cocoa



    There are no C++ language bindings for Cocoa.
     0Likes 0Dislikes 0Informatives
  • Reply 37 of 54
    gugygugy Posts: 794member
    not that macosrumors.com can be trusted. they are saying that the octo-core might come at MWSF.

    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.
     0Likes 0Dislikes 0Informatives
  • Reply 38 of 54
    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.
     0Likes 0Dislikes 0Informatives
  • Reply 39 of 54
    Marvinmarvin Posts: 15,585moderator
    Quote:
    Originally Posted by ZachPruckowski


    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.
     0Likes 0Dislikes 0Informatives
  • Reply 40 of 54
    gugygugy Posts: 794member
    Possibly Marvin.

    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!
     0Likes 0Dislikes 0Informatives
Sign In or Register to comment.