“One of the salient points repeated at the WWDC keynote was Leopard’s support for ’64 bits top to bottom’. However, a close peek at the slide shown this year showed a subtle difference to last year’s – the word ‘Carbon’ was missing. Of course a storm of confusion soon ensued, with the usual wailing and gnashing of teeth from some quarters and polite shrugging from others. Apple stock fell and rose again, some developers professed bliss while others threatened to leave the platform, non-developers wrote learned analyses about obscure technical points, not to speak of reports of raining frogs or even an unconfirmed Elvis sighting in a Moscone restroom. Allow me to try to explain all (well, Elvis excepted).”
From an e-mail linked-to in the article:
“I suspect I would give up on my own Mac development efforts, and just concentrate on creating embedded products, if I had to give up C++ (or D).”
God, programmers are so whiny. If I can put up with C++, you sure as hell can put up with Obj-C!
(I have a friend who got so used to the crappy hamburgers they served in our cafeteria that he couldn’t like a real good one when he had it. A C++ programmer complaining about Obj-C strikes me as being basically the same phenomenon…)
Edited 2007-06-24 22:59
No need for any analogies.. this line says it all.
“God, programmers are so whiny. If I can put up with C++, you sure as hell can put up with Obj-C!”
Except for one thing: Obj-C is basically a one trick pony…it’s good on one platform, which is Mac. Most programmers know C++ which means as long as they can read API documentation, they can write software for almost any platform currently in existence. To invest the amount of time it takes to learn Obj-C just so they can write Mac based apps is asking a lot, especially from the big software houses who will need to sink millions of dollars into retraining.
For someone who knows C++, learning Obj-C should be easy. That was the whole point of Obj-C, to allow a very simple transition for C programmers, and Apple has done a pretty good job (with Obj-C++) of doing the same for C++ programmers. So since difficulty can’t be the reason for the resistance, that leaves me with my conclusion: programmers are whiny.
If you know C++, you can pick-up the Objective-C language in about 2 hours. I did, and I’m not what you’d call a bright kid.
Seriously, whining about dropping C++ for Objective-C is just whiny.
I wouldn’t whine about having to learn Obj-C. But as Jayson.Knight implied, I would whine about having to create code for the Mac that cannot be shared with or easily adapted to code that runs on other Unix or on Windows. It can be seen as a form of platform lockin: sure all your Unix apps run on the Mac with a recompile, but Mac apps cannot be as effortlessly ported off the platform without rewriting all the Obj-C.
GNUstep code runs clean on various *nix platforms, not to mention Linux. Your ObjC code is portable.
I’m fortunately not a Mac developer and seeing things like these I won’t be any time soon. If or when the Qt or GTK people took advantage of such trickery the whole FLOSS development community would fall all over them.
I’m of the opinion that an operating systems provider should facilitate anything within reason that developers want because they are the premier customers, even more so than end users. Apple supposedly deems itself more important than its developers and customers.
This kind of platform lock-in should not be condoned and developers leaving or adding to their Windows/Unix developments are not better of with Apple at all, actually worse because they are being treated like idiots!
It’s ideology that goes back straight to the Unix wars.
Someone should remind Apple that those are over and Linux/BSD have emerged from those. There are only three general-purpose high-end Unix operating systems left and Apple’s isn’t one of them.
I was thinking of developing my future software with Mac OS X in mind without writing the same thing multiple times over but Apple has probably ensured that I will keep developing for Linux/Solaris/BSD and Windows only.
With the advances Linux and Solaris are making with respect to userfriendliness and application availability Mac OS X will be increasingly irrelevant to a larger part of (cross-platform) developers.
I’m certain hell will break loose when Adobe and others port modern versions of their software to Linux and Solaris.
If you know C++, you can pick-up the Objective-C language in about 2 hours. I did, and I’m not what you’d call a bright kid.
It’s not just about learning Objective-C, it’s about integrating Objective-C into your multiple platform C++ only project.
If you have a application framework built over Carbon, such as Qt, it’s not so easy to just switch everything to Cocoa. You end up with a lot of bridge code to make things compatible, so either you break your methodology and switch completely, which costs more, or you end up with bloat. Nevermind, that someone will see the cost as too much and drop the Mac project completely.
Apple will likely get their act together, late, as usual, but they will finish the migration.
The trouble about Carbon vs Cocoa and C++ vs Objective C is about sharing codebase.
Without 64-bit Carbon, you can forget about 64-bit Openoffice, 64-bit Firefox or anything using Qt (and many more).
OTOH, nobody forced OpenOffice, Firefox, and Qt developers to build on Carbon. They could have built their apps on Cocoa, but they didn’t.
Not that it matters, since if Photoshop won’t benefit from 64-bit, then I have a feeling apps like OpenOffice and Firefox really won’t benefit.
I understand that most of Carbon WILL be 64-bit and what will not is some of the GUI part. Thus, Cocoa apps, which build on Carbon can be 100% 64-bit. On the other hand, Carbon apps cannot because much of their GUI is limited to 32-bits.
What I don’t understand is if this is due to a lack of time/resources on Apple’s part or deprecation. Basically, is Apple putting its foot down and saying that Cocoa is the future and Carbon’s GUI components will not be transitioned to 64-bits or are they going to completely bring Carbon to 64-bits at a later time?
Edited 2007-06-24 23:00
Cocoa always was the future. I thought everyone understood that. Carbon was just supposed to bridge the gap. I am sure if there is a huge enough cry Apple may make the ui portion 64-bit as well. I wouldn’t hold my breath though. Cocoa IS the future.
Sure, but Cocoa is built on Carbon for many things, like menus. Some functions actually have to use Carbon directly even if it’s a Cocoa program. Is this expected to change? Moreover, some lower level stuff might only be possible in Carbon. And of course, Carbon is much more like existing paradigms on Windows/Linux/Solaris/Mac OS <X and so it is far more maintainable from a cross-platform perspective. This is why Adobe and Microsoft use Carbon for all of their programs. Bridging to other languages is also obviously easier.
I was always under the impression that Carbon and Cocoa existed as teammates each serving their own function; not as competitors. This is why I thought Apple would support them pretty much equally and that Carbon would never go away. Was this a false assumption? How does Carbon relate to Cocoa?
Edited 2007-06-25 02:51
These Cocoa built on Carbon was a redesign, not a limitation of Cocoa. When the rest of Carbon is ripped out of OS X you won’t discover your menus are now crippled.
They will be restored to the paradigm that Cocoa/ObjC used in Openstep and beyond.
Carbon didn’t exist in Openstep. No special voodoo exists in Carbon that straight C libraries in Openstep, wrapped in ObjC cannot produce.
“What I don’t understand is if this is due to a lack of time/resources on Apple’s part or deprecation.”
That’s answered right in the article, from an Apple engineer quote:
“Fundamentally, Apple engineering is focused on Cocoa much more than Carbon, and Apple’s engineering management made the decision to un-support 64-bit Carbon to emphasize that fact.”
This is gonna be a PR nightmare for Apple, and all of the big software houses who write apps for Apple will be pissed…and for good reason.
This is gonna be a PR nightmare for Apple, and all of the big software houses who write apps for Apple will be pissed…and for good reason.
Read the linked article, specifically the quote from the (not at all angry) Adobe guy.
In short, 64-bits is not some magical thing that makes everything faster. It can actually make some applications slower.
“In short, 64-bits is not some magical thing that makes everything faster. It can actually make some applications slower.”
Yes, I understand that. But 64 bit was promised across the board…this isn’t just a run of the mill feature cut, it fundamentally impacts a lot of software which needs to run on Mac.
I’m not a Mac developer (longtime Windows developer though); if Microsoft came out and said “Future versions of Win32 (the Windows equivalent to Carbon) will only be partially 64 bit” I’d be up in arms, and nothing short of “we just don’t have time to implement it now, but will implement it in a future release” would appease Windows developers. I’ve already chimed in my .02 on other OSNews threads similar to this one so I won’t rehash here. The reason it isn’t such a big deal is that there just aren’t that many companies who write for Mac to raise much of a fuss.
“Yes, I understand that. But 64 bit was promised across the board…this isn’t just a run of the mill feature cut, it fundamentally impacts a lot of software which needs to run on Mac. ”
Wrong, wrong and wrong. Only a few softwares will need to run in 64 bits, both Carbon and Cocoa. How many times we will have to repeat again and again? A very few applications need to be 64 bits, if your applications needs this :
-It involves random access manipulation of “huge” data objects (at least 2 GB)
-It needs concurrent access to a quantity of data that will not fit in a 32-bit address space (multi-gigabyte data modeling, for example)
, then it is a good candidate for being 64 bits. And then the type of applications which fulfill those conditions are, according to Apple:
“data mining, web caches and search engines, CAD/CAE/CAM software, large-scale 3D rendering (like a movie studio might use, not a computer game…), scientific computing, large database systems (for custom caching), and specialized image and data processing systems.”
This implies that all Carbon applications DO NO NEED to be 64 bits, or you are assuming that all Carbon apps are those of the types cited above. I really don’t think so!!!!!
“I’m not a Mac developer (longtime Windows developer though); if Microsoft came out and said “Future versions of Win32 (the Windows equivalent to Carbon) will only be partially 64 bit” I’d be up in arms, and nothing short of “we just don’t have time to implement it now, but will implement it in a future release” would appease Windows developers. I’ve already chimed in my .02 on other OSNews threads similar to this one so I won’t rehash here. The reason it isn’t such a big deal is that there just aren’t that many companies who write for Mac to raise much of a fuss.”
Read again this link, and read it carefully:
http://www.carbondev.com/site/?page=64-bit+Carbon
Is is clearly said that a full implementation of Carbon 64 bits has been done and it is running. Again, the reason of the drop of the 64 bits Carbon UI is not technical or that Apple did not have to implement it. Apple has DECIDED to drop it even though 64 bits CArbon UI is working, and i guaranty you that you could call the Carbon HIToolbox in 64 bits with the Leopard build prior to the WWDC build. IT WAS WORKING, APPLE DECIDED TO REMOVE THE HITOOLBOX FROM THE CARBON 64 BITS BECAUSE THEY WANT CARBON DEVELOPERS TO REALLY START TO MOVE TO COCOA.
And finally, concerning the fact that “here just aren’t that many companies who write for Mac to raise much of a fuss” well given that you are not a mac developer, i guess you don’t know what you are talking about……..
Indeed, and Microsoft is doing something sort of similar with Vista 64 – by making only signed driver binaries work, dropping 16 bit support and keeping 32 bit apps in separate directories, as well as publishing a 32 bit version, Microsoft can gradually ditch support for a bunch of legacy apps and hardware without causing too much fuss. And this is a good thing – Windows has become a preposterous beast due to extended legacy support and backwards compatibility, and needs to shed some excess baggage to move forward.
Apple, quite wisely, have been much quicker to dispense with redundant and obsolete technologies, and moving away from Carbon is just the next logical step for them. Of course, this will always leave a few people who are clinging to old techniques and technology and understandably frustrated, but that is no reason not to keep on improving, or to let backward compatibility hold you back.
Microsoft is doing something significantly different with Win64, in my perception. They’re using the necessary driver rewrites for the 64-bit platform to change their policy on what they’ll accept into the kernel. These parts of the system are necessarily platform-specific anyway, so it’s not like they’re further locking you into their system by their choice of language or style. Your Windows Kernel-mode driver is already locked into Windows quite a bit.
The dropping of 16-bit? Well, that was done because literally no one is writing 16-bit applications anymore and almost everything from that generation has been replaced long ago (at least since the turn of the millenium). Carbon apps are still everywhere and Carbon lends itself a lot better to cross-platform applications, so you really should look at this as an abusive lockin move for Apple towards developers of highly customized big applications. Either that, or they want to ensure that no one will be stupid enough to write a native-GUI rendering app for the Mac and instead just use X11 or avoid that platform altogether.
Carbon apps are still everywhere
The new Finder is written in Carbon.
“Is is clearly said that a full implementation of Carbon 64 bits has been done and it is running. Again, the reason of the drop of the 64 bits Carbon UI is not technical or that Apple did not have to implement it. Apple has DECIDED to drop it even though 64 bits CArbon UI is working, and i guaranty you that you could call the Carbon HIToolbox in 64 bits with the Leopard build prior to the WWDC build. IT WAS WORKING, APPLE DECIDED TO REMOVE THE HITOOLBOX FROM THE CARBON 64 BITS BECAUSE THEY WANT CARBON DEVELOPERS TO REALLY START TO MOVE TO COCOA. “
———————-
That’s interesting, given that (according to the aritcle) Leopard’s Finder is a Carbon app. If Microsoft were to begin deprecating the Win32 API and forcing a move to .NET in that manner you describe Apple is doing wrt Cocoa/Carbon, Microsoft would be ripped to shreds all over the internet.
In my previous comment regarding this issue in an earlier osnews thread, I refrained from stating my opinions on Obj-C, but given the above posts, I will state those now. Obj-C is an outmoded language. It was created at a time when Smalltalk was state of the art in OOP and Obj-C is basically Smalltalkized C. But OOP design/theory has advanced since those days, and Obj-C hasn’t kept up with the times.
Obj-C doesn’t even have namespaces, for Pete’s sake. Apple suggests that you prepend all your methods with an abbreviation, as Apple does with their NS (“NextStep”) prefix. For Framework devs, you even need to do this for “private” methods just in case someone extends your class with a Category which itself might have methods with the same names as your own classes’ “private” methods. Oh, and you might note that I’m using the term “private” in quotes. Why? Because in Obj-C all methods are “public”! Give me a break! You make them “private” by not putting them in public headers, but the language has no formal support for private, let alone protected, methods. There’s nothing preventing an app from accidentally calling a “private” method of a library, which is another reason to prepend the names of even internal methods of a library’s classes with a prefix.
Oh, and how about the horrible, horrible object construction mechanism? Rather than having constructors (in the C++, C#, Java sense), you have initializers, and you must designate a “designated initializer” that is the base initializer, and implement a convoluted intialzer pattern to support multiple “constructors”. Oh, but the language has no formal support for designated initializers either! It’s a convoluted hack that Obj-C devs came up with for the lack of actual constructors.
On a related note, in Obj-C object allocation and initialization are separate operations, so objects can are allocated without being fully “constructed”. Apple’s documentation actually touts this as a feature! In practice, devs combine the allocation and initiazation operations in a single statement, but come on!
Then, of course, there’s the autoRelease hack to make up for the lack of garbage collection (I won’t rip it, because I actually *like* it.
. Garbage collection is finally being added, but if none of the NS apis use it, then what’s the point?
BTW, in real-world programming, almost NOBODY cares about the ability to add methods to classes at runtime or change the class of an object at runtime. Much of Obj-C is devoted to that kind of stuff that’s only there because it looked cool in Smalltalk back in the day.
The problems go on and on. Obj-C has a lot of Smalltalky stuff nobody cares about and lacks many modern features that people do care about. I’m not ripping Obj-C’s creators; it was cool at the time that it was invented, but times have passed it by.
If Apple wants devs to use Cocoa, they should provide support in a language besides Obj-C. There is Obj-C++, but that is not really different from Obj-C, as far as I’m concerned. The C++ objects can’t talk with Cocoa objects/classes as if they were C++ objects/classes, nor can they act as Cocoa objects wrt the runtime (e.g. you can’t implement a derived NSView or NSDocument class as a C++ class). The only difference between Obj-C and Obj-C++ is the ability to compile C++ code. You still can’t use C++ code to interact with Cocoa; that code must be Obj-C.
Apple themselves, at one point, recognized the fact that Obj-C had problems, so they allowed devs to use Java to write Cocoa apps. But lo and behold, they deprecated that too! Now they’re bringing in Ruby-Cocoa and Python-Cocoa, but please, there’s no way C/C++ devs are going to move to those languages if they didn’t move to Obj-C/Obj-C++.
Given Apple’s coercion to force devs to Cocoa (I only use the term “coercion” since your post suggests as much), devs with large C/C++ codebases should keep all of their code in C/C++ and only use Obj-C when making/receiving OS calls. When I was doing Cocoa programming last year (only as a hobbiest, thank God), I ported my code entirely to Obj-C (i.e. C++ classes became Obj-C classes and so forth), so I could really “bathe” in Obj-C’s “goodness”. But big-time devs should definitely NOT do that. They should only use Obj-C where Apple forces them to (when making/receiving OS calls).
Edited 2007-06-25 13:21
About your point on OOP, frankly I’m not convinced that OOP has changed that much since Smalltalk (except for the namespace which is very useful): after all Ruby is Smalltalk with a less-alien syntax, and programmers like it.
>BTW, in real-world programming, almost NOBODY cares about the ability to add methods to classes at runtime
Well Ruby has also this capability and they also advertise it, I don’t know if it’s used that much though.
Incidentally, C# 3.0 has a new feature known as “extension methods” that let you add methods to existing classes at compile time.
http://dotnet.org.za/ernst/archive/2005/11/19/48385.aspx
The NS for Cocoa APIs do not stand for NeXTStep. The syntax prefix that did was NX. The NS was the transition to Openstep clean APIs during the Openstep Initiative.
“Wrong, wrong and wrong. Only a few softwares will need to run in 64 bits, both Carbon and Cocoa. How many times we will have to repeat again and again? A very few applications need to be 64 bits, if your applications needs this.”
The need for 64 bit features really doesn’t have much to do with why software developers will move their applications over to 64 bit, and actually the reason for needing 64 bit ports is an easy (and an obvious one…I’m surprised I haven’t seen it mentioned in any of these threads): On a 64 bit platform, native 64 bit code will always run faster than 32 bit code which needs to go through a thunking layer, or which needs some sort of external process spawning mechanism to communicate with modules of other ‘bitness’.
That combined with the fact that keeping two branches of a software project alive (one per bitness) is something like 4x as expensive as just maintaining/developing one branch. Companies want to move to 64 bit in an all or nothing fashion, not piecemeal, or “we’ll leave some modules in 32 bit until later”, etc.
“And finally, concerning the fact that “here just aren’t that many companies who write for Mac to raise much of a fuss” well given that you are not a mac developer, i guess you don’t know what you are talking about”
I’ve never once seen any IT departments writing software for Mac. I don’t know anyone who’s heard of one. I don’t think they exist, period. And let’s face it, the number of developers who write in house IT apps for computers outnumbers the folks who work in ISV’s by probably 100 to 1, maybe even 1000 to 1.
Edited 2007-06-25 18:30
On a 64 bit platform, native 64 bit code will always run faster than 32 bit code
Read the article. A guy from Adobe says you are wrong. (In 64-bit mode pointers are bigger, consuming more memory, causing more cache misses, making the program run slower.)
That combined with the fact that keeping two branches of a software project alive (one per bitness) is something like 4x as expensive as just maintaining/developing one branch. Companies want to move to 64 bit in an all or nothing fashion, not piecemeal, or “we’ll leave some modules in 32 bit until later”, etc.
Good software engineers know how to write a single portable codebase that can be compiled for many platforms; no branches are needed. The testing cost will probably be 2x as expensive for twice as many platforms.
> if Microsoft came out and said “Future versions of Win32
> (the Windows equivalent to Carbon) will only be partially
> 64 bit” I’d be up in arms
And after beeing “up in arms” for a while (read: whining) you’ll adapt to the new situation.
Yeah, a valid way for many developers to ‘adapt’ is to ‘drop’ the mac platform completely.
“And after beeing “up in arms” for a while (read: whining) you’ll adapt to the new situation.”
Not true…MS has a good history of listening to their developers; enough of them would raise hell in this case and MS would change it, lest they risk defectors to other platforms. Windows devs would never stand for something like this in the first place, so it wouldn’t happen.
If MS cared about what developers thought, they never would have released Win32.
While I agree that Win32 is not the cleanest GUI implementation around you could have elaborated on why you think so, lest being considered a troll.
I have tried to program Windows programs in the past first trying to get into MFC. I didn’t look further because I found it an abomination which didn’t have anything over and above plain Win32 systems calls.
I still have the books by “Windows 95 Programming” by Charles Petzold and “Advanced Windows” by Jeffrey Richter but they are collecting dust in my bookcase. Win32 is just too low-level of an API to create complex applications.
At that time there were Borland Delphi and C++ Builder, which were much easier to program with. Their progenitor moved on to Microsoft and cloned Java to create .Net and C#.
Admittedly this is much nicer than what came before, albeit having the same performance problems of managed code that Java has. It would be nice to have a C# to native compiler just like GCJ can compile Java code to machine language.
Qt is nice in that it has the same ease of development as Java and C# but the performance of native code and of course the fact that it’s multi-platform.
Edited 2007-06-26 15:48 UTC
“But 64 bit was promised across the board…”
No it was not. Apple are dropping many other legacy APIs for 64-bit too. There is no 64-Bit QuickDraw, use Quartz Extreme instead. Eventually all consumer computers will have 64-bit chips. Apple are using this eventual reality to drop a number of legacy parts of the OS to simplify things and get everybody working on the same page.
Read the linked article, specifically the quote from the (not at all angry) Adobe guy.
You do realize that the quote from the Adobe guy is from last year?
>but necessary since nearly all currently shipping Macs use Intel’s Core 2 Duo, which is 64-bit capable.
All Macs except the Mac Mini are 64bit capable iirc. That’s the reason I don’t have one…
A lot of the application areas Hakime lists like CAD/CAM and scientific apps are cross-platform apps: the same apps exists on Mac, Windows, Linux, etc. These are exactly the apps where developers do not want to spend time porting from Carbon to Cocoa as all development is cross platform.
The number of apps only sold for the Mac that need 64 bits must be trivial, mainly Final Cut Pro (as it’s developed by Apple) from what I can tell.
Mathematica is a 64bit Carbon already. It has a 32 bit GUI and (AFAIK) spawns a 64 bit Unix/BSD process on G5 and Core2 Macs under Tiger.
Mathematica can do that because it doesn’t need to transfer huge amounts of data to the front end very often, so the cost of IPC isn’t too great when all it’s used for is to display equations.
CAD software or other rendering stuff really can’t adopt the Mathematica solution.
Write your core code in C/C++ and use ObjC++ for the interfaces to access Cocoa and bring over Pro/E, Catia, Ansys, SolidWorks, COMSOL, NEiNastran, AutoCAD [begrudgingly the standard] and others to OS X.
Carbon being available hasn’t produced these crucial standards in the Mechanical and Materials Science Engineering Fields.
Providing compelling ObjC APIs to leverage toolkits like OpenGL 2.1 by making it painless will be more attractive to developers, not to mention increased market share and penetration into specific conglomerates that need such tools and want to switch to OS X.
Apple is just sawing off their branch while standing on it. As one very successful company representative (albeit a bit wacko) once shouted “Developers, developers, developers!”.
That aforementioned company has a lot of it’s success tied to being backwards compatible and developer friendly. One would think other companies understand that by now.
Also the “you can just switch to Obj-C” argument is one of the bigger bulls*** I read lately. Not only is Obj-C practically useless on other platforms (sorry, GNUstep just doesn’t cut it), but you’re just throwing away all the existing AND other-platform code base.
Have you ever considered that there are cross-platform projects out there based on other languages who try to make native look possible for all platforms? And no, they are not written in Obj-C.
Of course you could do a wrapper around the OOP stuff and provide a C-level dynamic library so anyone can use cocoa but then what’s the reason of abandoning carbon hmm?
I just don’t get it. Especially since going 64 bit shouldn’t be SUCH a hassle (well, honestly I don’t know what kind of crappy code they used in carbon libs so it MIGHT be such a hassle..)
One factor is that the kernel is 32-bit.
You’re talking about the perls of good programming – here is one for you; if you were interested in making sure that the software you’re using it easily portable, then explain why you’re mingling your GUI code with your computation code?
It confuses the crap out of me when I see large companies bitch and whine about porting applications, where one like me would ask this; had they created it so that the two were modular, as to allow multiple gui front ends, and the back end written in plain C (or as plain can be) back end, the issue would just be writting a new front end – Or better yet, why not create a expressive XML GUI which is transformed into platform dependent GUI code upon compilation?
One thing to realize, is that only the UI portion of Carbon is being deprecated for 64bits.
Which means, a Carbon app needs only its UI to be redone in Cocoa, to be available as a 64-bit app. Apple is saying that Cocoa and Objective-C is the future for native UIs on Mac OS X. What’s underneath is entirely up to the developer.
Most code is cross-platform on the backend anyway, and the low level API calls can still be in Carbon, Cocoa, or just plain CoreFoundation.
Also, the UI part of the code is already non-cross platform if you do it in pure Carbon (just like in Cocoa). And if you use libraries like wxWidgets or equivalent, those libraries simply need to interface to Cocoa, and all is set (though, most likely a lot of these would need recoding, since I think they use Carbon at this time).
Edited 2007-06-25 14:23
Why should Apple decide what framework an application is being developed for? If Cocoa has any advantages (speed, maintainability etc.) to Carbon the developer would be wise to choose it.
Otherwise it doesn’t have much of an added value. If I preferred Carbon then it wouldn’t matter to me if it’s 32-bit, 64-bit or 128-bit.
Can you give me a reason why Cocoa and Obj-C should be considered the future and what makes them so much better than Carbon and C/C++?
@psychicist
Because of the bloody OOP hype. Carbon is not OOP, the same way Win32 is not OOP. Microsoft’s idea of OOP is the atroscity we know as MFC and COM. .Net is MS’ attempt to make things right. Cocoa is an OOP API that’s been around for some time. This is just simply how things fell into place.
Apple should make Cocoa available on Windows, like the GNUStep and Cocotron guys have been doing. I assume Apple’s already ported a large portion of it to get Safari up and running. Providing a real cross-platform solution would instantly make Cocoa a much more attractive proposition to a lot of developers.
“Apple should make Cocoa available on Windows, like the GNUStep and Cocotron guys have been doing. I assume Apple’s already ported a large portion of it to get Safari up and running. Providing a real cross-platform solution would instantly make Cocoa a much more attractive proposition to a lot of developers.”
///////////////////////////////////////////////
You echo the sentiments of Jeremy Hughes.
http://lists.apple.com/archives/Carbon-dev/2007/Jun/msg00466.html
“Subject: Re: Is Carbon Viable?
From: “Jeremy Hughes” <email@hidden>
Date: Fri, 15 Jun 2007 16:37:09 +0100
…
…
The other issue is cross-platform development. Cocoa (OpenStep) was
originally a cross-platform framework which ran on Windows and NeXT.
When it was introduced for the Mac, developers were told that it would
give them the ability to write cross-platform applications. Of course,
this failed to happen, and Apple now appear to be discouraging cross-
platform development – except for themselves…”
Edited 2007-06-25 19:25
If I buy a new MacBook Pro and it only comes with 2GB of memory should I really care about 32bit vs. 64bit?
Doesn’t 64bit just allow you to use 64bit address space and not much else?
I saw Steve’s keynote where he showed a 32bit and 64bit app side by side and the 32bit version had to keep paging to disk and I’m not sure that I understand what was going on…
If the 32bit app was paging and the 64bit app didn’t need to that tells me that the image was over 2GB. Right?
Well, if it was over 2GB, how could the 32bit app even manipulate that much data?
Thanks in advance for the explanation,
~Eric
This is a common misconception about 32->64 bit code. Having >= 4GB of RAM is one of the benefits of 64bit processors, but the other, usually much greater benefeit), is that you get twice the available registers on the CPU (at least for x86->x64 anyways, I’m not so sure about PPC). An Intel Core 2 running in 32bit mode will have 8 General Purpose Registers (GPRs) and 8 SSE registers. When running in 64bit mode though, there are 16 GPRs and 16 SSE registers.
For multi-media applications, this equates to more work being done by the CPU and less time spent transfering data back and forth to memory. Most multi-media, video, and audio editing applications as well as heavy number crunchers (i.e. Mathematica, or perhaps large statistics packages), should all see a rather decent performance increase in 64bits.
So if you use you laptop for web-browsing and email only, then you will notice little to nothing. But, if you rip DVDs, encode your own movies, and encode lots of MP3s, then it will make a difference.
Edit: Added the third paragraph.
Edited 2007-06-25 19:47 UTC
Umm..if the image is over 2GB then duhh, an application built 32bit machine has to page it into and out of memory. It can’t keep it all in memory at once.
A 64bit application is able to address the image pixels in their entirely.
Really what this mean is:
Currently state of the art 64bit allows you to code without having to deal with the “what if” conditions. At least until aggregate data sets start to push over 64bits.
What if you decided to you wanted to load your life’s worth of digital photos and screw with them? Using 64bit properly it can be a very trivial task, with no need to worry about blowing out the heap or having to play special games (like paging).
Or to put it another way, with 64bit you actually delegate more work to the kernel regarding resource management. I’m very certain the kernel guys have done a much better job than I have.
Edited 2007-06-25 19:57 UTC
Umm..if the image is over 2GB then duhh, an application built 32bit machine has to page it into and out of memory. It can’t keep it all in memory at once.
I’m still not sure that I understand. I thought a 32bit app couldn’t address more than 2GB of memory whether it is real memory or the OS has it paged.
Or are you saying that the 32bit app would have to explicitly (actually in the source code) page it in and out of memory instead of the OS doing it?
See, normally when I think of paging I think of it being transparent to the application because it is something that the OS handles.
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.msp…
So a modern 32-bit operating system can handle 4 GB of physical RAM, the first 1 GB address range is reserved by the OS, leaving the last 3 GB range for applications.
When dealing with data files larger than 2 GB, a dumb program would try to load the entire file and hit an “out of memory” error. A smarter program would first check the file size and deal with it appropriately. Not all file types can be split up and loaded in chunks. What file type you’re dealing with is a major factor in when the program is able to “let go” of a chunk of data and load from another area.
EDIT: Doh! I just realized I posted a Microsoft link. Sorry. I was trying to find evidence that 32-bit programs can address up to 3 GB of memory.
Edited 2007-06-26 14:51
Unfortunately the GNUStep guys have no interest in making the Windows implementation have a native Windows look and feel (like say not have a completely out of place NeXTStep menu and X-looking widgets) or completely tracking all of Apple’s changes. The guy doing Cocotron is going in the right direction IMO, all the widgets are implemented natively so it looks like a real Windows application, and you can cross compile to Windows from XCode, but it’s basically just one guy going it alone trying to implement the whole Cocoa API. I say, Apple, bring back Yellow Box!
Oh BTW, according to this post, Safari is *not* written in Cocoa.
http://forums.macrumors.com/showpost.php?p=3762466&postcount=45
“The windows ‘port’ of Safari does not use one line of Objective-C/Cocoa but is programmed in C/C++ against C-libraries from Apple (CoreFoundation/CoreGraphics) and Microsoft (Win32).”
Edited 2007-06-25 23:01