or Connect
AppleInsider › Forums › Software › Mac OS X › Road to Mac OS X 10.6 Snow Leopard: 64-Bits
New Posts  All Forums:Forum Nav:

Road to Mac OS X 10.6 Snow Leopard: 64-Bits - Page 3

post #81 of 102
ignore
.
Reply
.
Reply
post #82 of 102
I hate to jack this thread but I have received no info from my posting over at MacOSXHints forums....

How can one tell what apps are written in Carbon and in Cocoa?

I'd like to put together a list of the current apps that we have for both formats and then do it for each OS X version.
Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"
Reply
Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"
Reply
post #83 of 102
Usually you can tell by right clicking on the toolbar and if you get the option to customize it, it's cocoa BUT some apps emulate that behaviour, such as, and I may be wrong now, Safari.
post #84 of 102
Quote:
Originally Posted by aegisdesign View Post

Filemaker - old and cross platform

Don't even get me started on Filemaker Pro.
The evil that we fight is but the shadow of the evil that we do.
Reply
The evil that we fight is but the shadow of the evil that we do.
Reply
post #85 of 102
The Apple II line actually lasted through to the early 90's (15 Oct 1993 for the Apple IIe, 1992 for the 65c816-using Apple IIgs). It could be said to have outlasted the manufacture of the majority of 386 PCs.

From 1985 onwards Apple devised a scheme for 8-bit Apple IIs to use up to 1 MB of RAM on a card in an expansion slot (aka "Slinky" RAM cards). Other companies had already come out with bank-switched cards that expanded the RAM in Apple IIs beyond 64 KB, but Apple's standard replaced those schemes and was later incorporated into the Apple IIc, IIgs (for 8-bit programs), IIc Plus, and the IIe Card for the Mac LC family. Of course the major software that was written to access this expanded memory was AppleWorks, but other third party software did also incorporate it. So for the last 8 years of its life the Apple IIs "typical RAM limit" could be described to actually be 1 MB.

The Apple /// which came out in 1980 also used a variant of the 6502 called the 6502A and it had its own scheme for accessing RAM beyond 64 KB (called raising and lowering the "fence"), up to 512 KB.

BTW, the IBM PC and PC XT actually were released with the 8088 processor, not the 8086. The 8088 had an 8-bit external data bus, which allowed systems to be designed more inexpensively with only 8-bit components (specifically I/O, such as drives and ports). It still had 16-bit internal registers and a 20-bit address bus for up to 1 MB of RAM, though, making it somewhat of a Frankenstein's monster CPU.

It then may be more accurate on the chart to replace "Intel 8086" with "Intel 8088/8086," and "IBM PC" with "IBM PC/clones."

At the same time "Motorola 68020" could be updated to "Motorola 68020/30" and "Mac II" to "Mac II-series," since the 68020 was only ever used in the Mac II and Mac LC.

By then you might as well update "Intel 386" to "Intel 386/486" and "386 PCs" to "386/486 PCs."
post #86 of 102
Quote:
Originally Posted by mcarling View Post

mdriftmeyerSnow Leopard would certainly be the sensible time to drop support for both PPC and 32 bit Intel. Legacy code should not be maintained forever. If you want the benefits of Snow Leopard, buy a Mac produced after 2005.

I don't see Apple dragging support for PPC like they did with Carbon, but I do see support for 32-bit Intel processors because it has only been 2 years since the first 64-bit Intel Mac and just over a year since the last 64-bit Intel Mac. Offering 32-bit Snow Leopard will provide Apple with that many more sales of 10.6 to 32-bit Intel Mac owners, although I do see Mac OS X 10.7 as being 64-bit Intel-only.
post #87 of 102
You can't really tell if an app is Cocoa or Carbon because an increasing number of apps are a mix. One hint that Cocoa is in use is that the app will look more like iTunes, with standard controls, rather than the Tiger Finder, or Office, where a lot of custom controls lacked that "je ne sais quoi" and look more like System 7 dressed up.

However, I'm not sure that the Leopard Finder is actually 100% Cocoa (and I find that hard to believe), as Apple worked pretty to enable Carbon apps to include Cocoa elements to help transition apps. It used to be that Carbon apps couldn't load Services, but now they can. I believe Input Managers are Cocoa only, so you might be able to tell if an app is Cocoa by loading one.

However, it increasingly doesn't matter. It's also not always "best" to dump code that works to provide a snappy new Cocoa app that loses features and code maturity. That's what Adobe is worried about with Photoshop. It could blow out a new Photoshop in Cocoa, but it would end up being a Lightroom-like beta that would suddenly be competing against rivals rather than far ahead in terms of familiarity and stability.

-

Snow Leopard will definitely run on 32-bit Macs, none of which are currently more than two years old, and will only be less than 3 when SL ships.
post #88 of 102
Well, if my shell fu were a bit better...

Here's what you need to do: search for all directories on the machine that end in '.app'.

Glob for "*.app/Contents/MacOS/$1" ($1 should match the wildcard, meaning you're looking for things like Finder.app/Contents/MacOS/Finder)

Take *that* list, and for each run "otool -L" on it, then grep for AppKit in the resulting list of linked libraries.

If AppKit appears, it's a Cocoa app.

If not, it's Carbon.

That's a decent rough approximation. AppKit is the top level UI library for Cocoa, and *should* only appear when the app has a (primarily) Cocoa UI. I can't think of a situation where a Carbon UI app would link to AppKit, although there may be some boundary cases. FoundationKit would be a possible alternate, but I can imagine a Carbon UI app using some bits from there to speak to some Cocoa services, so AppKit is probably a better bet.

OTOH, a lot of Cocoa apps link to the Carbon framework, so that's a poor test, and they both link to the Core* libs, so those won't work.
My brain is hung like a HORSE!
Reply
My brain is hung like a HORSE!
Reply
post #89 of 102
Quote:
Originally Posted by Hiro View Post

That's what I said, minus the second sentence editorial.



WhereTF did that all come from? Did you even read what you quoted? You certainly weren't replying to anything in my post after the CARBON EDITORIAL. I have no problems with that line, dev's perception doesn't need to mesh with Apple's message, and I was relating the message. I agree fully that moving away from Carbon is a Good Thing™, I even gave a reason why!

I don't tend to be as vitriolic as you were on whether the Apple message and reality are in sync, Apple said from WWDC in 1999 that Cocoa was the way to go for all new apps, but that Carbon would maintain feature equivalence for existing apps. That message NEVER changed, that's all I said. If you want to call that second class, I won't argue, but I think it's a tad over the top.

After that, I said absolutely nothing about Apple not moving to Cocoa. Actually I said the opposite. So either READ THE POST; or break out the multi-quote goodness to point the ire at the real recipient; or chop your responses into separate posts.

Relax: I wasn't targetting you. I was addressing the entire Thread and the absurdity in which these claims were coming from that claims Apple cannot even eat it's own dog food.

My apologies if you were offended. I'll be more clear on my target audience, next time.
post #90 of 102
Quote:
Originally Posted by mdriftmeyer View Post

Relax: I wasn't targetting you. I was addressing the entire Thread and the absurdity in which these claims were coming from that claims Apple cannot even eat it's own dog food.

My apologies if you were offended. I'll be more clear on my target audience, next time.

Thanks, it's was near impossible to see that being the post quoted though...
.
Reply
.
Reply
post #91 of 102
Quote:
Originally Posted by Prince View Post

You can't really tell if an app is Cocoa or Carbon because an increasing number of apps are a mix. One hint that Cocoa is in use is that the app will look more like iTunes, with standard controls, rather than the Tiger Finder, or Office, where a lot of custom controls lacked that "je ne sais quoi" and look more like System 7 dressed up.

iTunes is a Carbon application. IIRC it's the only Carbon app Apple now ships in iLife.

It's the perfect example of a System 7 application dressed up badly. eg.

- the Preferences and Info window not having the red/yellow/green buttons and instead having OK/Cancel
- the Toolbar isn't configurable.
- No spell checking in the text areas

I would guess that iTunes 8 might be Cocoa but they're having difficulty cramming in all the crap they've crammed in to iTunes 7.x and getting it working cross platform.

Quote:
Originally Posted by Prince View Post

However, I'm not sure that the Leopard Finder is actually 100% Cocoa (and I find that hard to believe), as Apple worked pretty to enable Carbon apps to include Cocoa elements to help transition apps. It used to be that Carbon apps couldn't load Services, but now they can. I believe Input Managers are Cocoa only, so you might be able to tell if an app is Cocoa by loading one.

Finder in Leopard is 32-bit Carbon through and through with embedded NSViews to wedge in Cocoa stuff like Coverflow. So that's not a good example of a Cocoa app either.

Try iWork's apps for perfect examples of Cocoa in action.

Quote:
Originally Posted by Prince View Post

However, it increasingly doesn't matter. It's also not always "best" to dump code that works to provide a snappy new Cocoa app that loses features and code maturity. That's what Adobe is worried about with Photoshop. It could blow out a new Photoshop in Cocoa, but it would end up being a Lightroom-like beta that would suddenly be competing against rivals rather than far ahead in terms of familiarity and stability.

Hmmm. Whilst it 'increasingly doesn't matter' as Carbon has been getting a lot of Cocoa like stuff added to it eg. HICocoaView and Cocoa has been getting more APIs that Carbon traditionally only had access to, it DOES matter going forward since it's clear new UI elements are only going to be Cocoa.

For Adobe, most of the stuff that they rely on is still going to be available in 64bit Carbon which *is* still happening despite the keynotes. It's only the UI stuff that isn't 64bit. Since Adobe implement their own UI libraries anyway, I'm not sure what their griping is for. Every few years they've replaced their UI Library anyway.

Quote:
Originally Posted by Prince View Post

Snow Leopard will definitely run on 32-bit Macs, none of which are currently more than two years old, and will only be less than 3 when SL ships.

It's a real pity Apple even shipped those Macs. I thought it bizarre at the time and still do but I guess that's what happens when you're stuck with G4s and a Keynote deadline to hit rather than waiting on the engineers.
post #92 of 102
Quote:
Originally Posted by aegisdesign View Post

It's a real pity Apple even shipped those Macs. I thought it bizarre at the time and still do but I guess that's what happens when you're stuck with G4s and a Keynote deadline to hit rather than waiting on the engineers.

I am sure Steve was none too pleased they did not have 64-bit Intel processors straight out the gate for their transition, especially since the iMac (G5) was already 64-bit; however, Apple did take their sweet old time putting a 64-bit processor in the Mac mini.
post #93 of 102
Quote:
Originally Posted by troberts View Post

I am sure Steve was none too pleased they did not have 64-bit Intel processors straight out the gate for their transition, especially since the iMac (G5) was already 64-bit; however, Apple did take their sweet old time putting a 64-bit processor in the Mac mini.

I think the Intel laptop CPUs available at the time prevented a clean 64-bit switchover, so Apple had to settle for the 32-bit compromise. The Mini was incidental, and primarily driven by cost concerns. 10.7 will probably give us a clean 64-bit plateau to work from.

Oh, and another Carbon artifact in iTunes - the stupid wristwatch cursor, left over from the very first Mac operating system (1.0) back in 1984!
post #94 of 102
Quote:
Originally Posted by Dlux View Post

I think the Intel laptop CPUs available at the time prevented a clean 64-bit switchover, so Apple had to settle for the 32-bit compromise. The Mini was incidental, and primarily driven by cost concerns. 10.7 will probably give us a clean 64-bit plateau to work from.

One can hope. No legacy crap. No carbon. 64bit only.

Quote:
Originally Posted by Dlux View Post

Oh, and another Carbon artifact in iTunes - the stupid wristwatch cursor, left over from the very first Mac operating system (1.0) back in 1984!

I'd forgotten that one. Every time I see the pointer turn into a B/W Mac pointer a little bit of me dies, though maybe not as much as the multi-colour beachball.

But then I'm an ex-BeOS guy, which had nothing of the sort even on the dual Celeron 333Mhz machine I used to run it on.
post #95 of 102
Snow Leopard would certainly be the sensible time to drop support for both PPC and 32 bit Intel. Legacy code should not be maintained forever. If you want the benefits of Snow Leopard, buy a Mac produced after 2005.[/QUOTE]

I also was thinking they would drop PPC and perhaps 32bit support to make SL fast and get rid of some of the fat, as you suggest. But, it is also a shame... I bought my MacBook Pro new in late '06, but I think Apple had not changed the line to 64bit yet. So even Macs bought after '05 may not run SL if Apple does in fact drop 32bit support.
post #96 of 102
Quote:
Originally Posted by codymr View Post

Snow Leopard would certainly be the sensible time to drop support for both PPC and 32 bit Intel. Legacy code should not be maintained forever. If you want the benefits of Snow Leopard, buy a Mac produced after 2005.

I also was thinking they would drop PPC and perhaps 32bit support to make SL fast and get rid of some of the fat, as you suggest. But, it is also a shame... I bought my MacBook Pro new in late '06, but I think Apple had not changed the line to 64bit yet. So even Macs bought after '05 may not run SL if Apple does in fact drop 32bit support.[/QUOTE]

You are right, except that Apple can't afford to lose the large contingent that still uses both machines.

Dropping the PPC 9 months from now, may be supportable, but I'm not so sure about 32 bit yet.

This is all coming about a year earlier than we expected for 10.6. If it was another year and 9 months, then it would all be fine. this may be a bit close though.

But Apple will do what it wants, as it always does, unless there is enough protest as there was about the finder as originally constituted for X. They did relent there, and compromised. So we'll see.

Wow! Sorry about the spelling. Must change it!
post #97 of 102
Quote:
Originally Posted by melgross View Post

You are right, except that Apple can't afford to lose the large contingent that still ises noth machines.

Dropping the PPC 9 months from now, may be supportable, but I'm not so sure about 32 bit yet.

This is all coming about a year earlier than we expected for 10.6. If it was another year and 9 months, then it would all be fine. this may be a bit close though.

But Apple will do what it wants, as it always does, unless there is enough protest as there was about the finder as originally constituted for X. They did relent there, and compromised. So we'll see.

I think 32-bit x86 will be there, I recall you making a good point about SL easily supporting 32-bit Intel several months ago. But if they did drop 32-bit and released SL in 2009 they can always continue Leopard point releases and even some of the SL features add-ons, like Exchange support in Mail, if need be.

Regardless, it seems clear that SL will not support PPC in any regard so I think Apple is very likely to continue support to PPC Macs with Leopard point updates until that 36 month window in reached. The items below don't make for the best evidence to support my position here, but I'm posting them anyway since I went to the trouble to look them up.
Mac OS — 2001
.9.1.. — January
10.0.. — March
10.0.1 — April
10.0.2 — May
10.0.3 — May
10.0.4 — June
.9.2.. — July
.9.2.1 — August
10.1.. — September
10.1.1 — November
.9.2.2 — December
10.1.2 — December
Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"
Reply
Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"
Reply
post #98 of 102
Quote:
Originally Posted by solipsism View Post

I think 32-bit x86 will be there, I recall you making a good point about SL easily supporting 32-bit Intel several months ago. But if they did drop 32-bit and released SL in 2009 they can always continue Leopard point releases and even some of the SL features add-ons, like Exchange support in Mail, if need be.

Regardless, it seems clear that SL will not support PPC in any regard so I think Apple is very likely to continue support to PPC Macs with Leopard point updates until that 36 month window in reached. The items below don't make for the best evidence to support my position here, but I'm posting them anyway since I went to the trouble to look them...
Mac OS 2001
.9.1.. January
10.0.. March
10.0.1 April
10.0.2 May
10.0.3 May
10.0.4 June
.9.2.. July
.9.2.1 August
10.1.. September
10.1.1 November
.9.2.2 December
10.1.2 December

Yeah, these things are hard to predict. Someone will be right, but it's through sheer luck, as an argument could be made either way.
post #99 of 102
I just thought of something. If the ARM processor is 32-bit and the iPhone OS "is" Mac OS X then we might see 32-bit support for the foreseeable future.
post #100 of 102
Quote:
Originally Posted by troberts View Post

I just thought of something. If the ARM processor is 32-bit and the iPhone OS "is" Mac OS X then we might see 32-bit support for the foreseeable future.

Unless they decide to completely fork it. I don't think this would be a good idea.

It's possible that even processors for phones will become 64 bits before too long.
post #101 of 102
Quote:
Originally Posted by Snafu View Post

Yes, that is so, but it is easier to map multiplatform UI features to Carbon or create new ones based on it, and that avenue is closed for 64bit. When most comments talk about separating the program's logic from the program's UI, they seem to assume that the UI is the easy part, and that's not necessarily so, when one considers, say, Maya's UI or After Effects'. Cocoa won't cover for their needs in a straightforward way.

Anyway, it feels a bit forced to do a "what was Adobe thinking all these years", as if it was so easy peasy a porty: how many gigantic apps is CS3 composed of? A dozen or so, plus a inmense community of plug-in developers which will have to rewrite (again!) their products (we'll see how many we lose this time). It's not trivial, it was even less so in the past, and they gain nothing but 64bitness and a big headache testing and reoptimizing things.

Anyway, of course they are going to do it: http://blogs.adobe.com/jnack/2008/04...hop_lr_64.html

How many pro apps has Apple ported from Carbon to Cocoa? Do they intend to port any, actually? One suspects we'll see the Pro Apps UI toolbox inherit what's left of Carbon64's development and so sidestep the issue.

Why don't you sign up for an NDA Apple Premiere Developer account and test out Snow Leopard to answer your questions? I mean, seriously. You want to know the state of Apple's APIs and direction for their own Professional applications then get the new operating system and with that level of clearance you'll get the inside scoop.

Otherwise, just keep pissin' in the wind.
post #102 of 102
Quote:
Originally Posted by AppleInsider View Post

While Leopard's 32-bit kernel can run both 32- and 64-bit apps, a 64-bit app can not load 32-bit plugins or shared libraries, and vice versa. The 64-bit kernel similarly requires 64-bit kernel extensions and drivers, as it can't mix 32- and 64-bit code either. The move to a 64-bit kernel will therefore require an across-the-board upgrade for all kernel drivers in Snow Leopard.

Snow Leopard will also require developers who write any plugins for Mac OS X apps to recompile their code to 64-bit. This includes everything from System Preferences panes to web plugins.

I don't know if this has been mentioned before but one thing I noticed when looking at the Wacom driver site here:

http://www.wacom-asia.com/node/121360

"This driver supports beta versions of OS X v.10.6 in 32-bit emulation."

Now, if they tested 10.6 while running on 32-bit hardware then if there are native 32-bit binaries supplied with 10.6, this is not the emulation they refer to.

On the other hand, emulation would more likely refer to some compatibility while running 64-bit code natively on 64-bit hardware whilst also allowing the use of 32-bit drivers. Either that or you have the option to boot the entire system in some 32-bit mode on 64-bit hardware where everything remains 32-bit.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac OS X
AppleInsider › Forums › Software › Mac OS X › Road to Mac OS X 10.6 Snow Leopard: 64-Bits