Linked by Thom Holwerda on Thu 14th Jun 2007 15:58 UTC, submitted by Jeremy Fox
Thread beginning with comment 247889
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
RE: QT and Openoffice.Org
by meianoite on Thu 14th Jun 2007 17:11
in reply to "QT and Openoffice.Org"
Normally leaving out Carbon in the 64 bit transition wouldn't be such a big deal (i.e. for small apps, commercial apps, etc...). However, this is going to probably be somewhat of a problem for efforts like QT and Openoffice.org which use Carbon as the basis for their frameworks/ports. Especially for Mac users hoping to see a native OpenOffice port, this is bad news.
And I need a 64-bit version of OpenOffice for what reason, exactly? Bragging about having a 100% 64-bit clean OS without a single shade of legacy around?
...
How about talking how only Apple managed to keep 32-bit device drivers working on the 64-bit OS? This is FAR bigger news in my book.
RE[2]: QT and Openoffice.Org
by ilprontoro on Thu 14th Jun 2007 17:22
in reply to "RE: QT and Openoffice.Org"
Obviously a 64 bit openoffice isn't the major point. While Cocoa has clearly been the framework of choice for building new applications, Carbon and Cocoa have been up until now essentially equivalent frameworks sitting on top of CoreFoundation and Quartz (esp. when writing in objective C was not an option). This is the first time we're seeing a major signal on Apple's part about the future deprecation of Carbon. In that case should OpenOffice.org change porting strategies? I'm interested in what they think about this. In addition, I find it funny that no one's commented on QT. If you read the thread in which 64 bit Carbon was ruled out in Leopard, TrollTech is clearly unhappy (as are many other developers) about this news.
RE[2]: QT and Openoffice.Org
by PlatformAgnostic on Thu 14th Jun 2007 23:39
in reply to "RE: QT and Openoffice.Org"
How about talking how only Apple managed to keep 32-bit device drivers working on the 64-bit OS? This is FAR bigger news in my book.
Let's talk about this one, since it's really interesting: I read somewhere (I think in the Apple developer list thread discussing 64-bit carbon's disappearance), that the way this is accomplished is by making the OS mostly 32 bits. When kernel code is being executed, the processor is switched to compatibility mode and runs 32 bit code. All the 32/64 bit switching occurs at the interupt and syscall gates.
It's an interesting decision, and I'd bet that it is likely the most pragmatic way to make this transition, since the OS itself doesn't really need 64-bit address space (I think Mac already has a 4 GB system address space that is switched to on every syscall). It's only the apps that need to be 64-bit, so there's no disadvantage to keeping most of the Core OS as 32-bit (except for marketing purposes... you can't call it 64-bit clean).






Member since:
2007-06-14
Normally leaving out Carbon in the 64 bit transition wouldn't be such a big deal (i.e. for small apps, commercial apps, etc...). However, this is going to probably be somewhat of a problem for efforts like QT and Openoffice.org which use Carbon as the basis for their frameworks/ports. Especially for Mac users hoping to see a native OpenOffice port, this is bad news.