CGTalk - Has Apple Made Good On 64-bit?

NWoolridge

10-18-2007, 01:59 AM

The situation is not as completely bleak as all that: Apple has said that the non-UI parts of carbon are 64-bit. It seems that Apple has made a (stupid, annoying) decision to force devs to use Cocoa frameworks for the front-facing parts of their apps. I can see the rationale for this; there are persistent interfaces inconsistencies between carbon and cocoa apps, and it would be nice to see those go away. But its still annoying.

Maxon's response seems to indicate that this will delay a 64-bit C4D, not make it impossible.

Nick

Kuroyume0161

10-18-2007, 03:33 AM

See, that raises an interesting question to which I alluded but didn't spell out. Cocoa is Objective-C/C++ (pretty much limited to MacOSX). The Cinema 4D SDK is C++ (which is a real, ubiquitous language available on ALL computers everywhere). What would be the best way to support this considering that some API access must be outside of the SDK (frameworks, dylibs, etc.)?

Maxon can't just plop on over to Objective-C/C++ since it would require its developers and plugin developers to recode pretty much entire plugins for MacOS from Windows versions wherever the system API is required. I ain't doin' it. Bad enough for Maxon, but any Carbon frameworks in use by my plugins would need to be changed to Cocoa with who knows what consequences and gritty details to interface C++ with Objective-C++.

If Apple wants developers to use Cocoa in favor of Carbon to get 64-bit support, they should just provide a C++ API for Cocoa and drop the proprietary Objective-C crap. Very Objectionable, yes. I'm reminded soooo fondly of a similar move by M$ involving hijacking Java - the oh-so memorable J++ (or J-- as I call it). I never even installed it from the Visual Studio install options. When I learned and used Java, it was Sun Java.

wbj

10-18-2007, 09:14 AM

Maxon can't just plop on over to Objective-C/C++ since it would require its developers and plugin developers to recode pretty much entire plugins for MacOS from Windows versions wherever the system API is required. I ain't doin' it. Bad enough for Maxon, but any Carbon frameworks in use by my plugins would need to be changed to Cocoa with who knows what consequences and gritty details to interface C++ with Objective-C++.

If you rely on the Cinema SDK, you won't have to worry about Objective-C or Cocoa, because the translation from the C++ SDK api to MacOS (or Windows/Linux) api is handled by the (Cinema) kernel.

If you use direct Carbon UI calls (instead of using the SDK), you will have to rewrite this for OS X 64 bit.

Best regards,

wbj

NWoolridge

10-18-2007, 03:10 PM

If Apple wants developers to use Cocoa in favor of Carbon to get 64-bit support, they should just provide a C++ API for Cocoa and drop the proprietary Objective-C crap. Very Objectionable, yes. I'm reminded soooo fondly of a similar move by M$ involving hijacking Java - the oh-so memorable J++ (or J-- as I call it). I never even installed it from the Visual Studio install options. When I learned and used Java, it was Sun Java.

But, you can use C++ in cocoa: "Apple’s Objective-C compiler allows you to freely mix C++ and Objective-C code in the same source file."

http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_10.html#//apple_ref/doc/uid/TP30001163-CH7-TPXREF167

Now, I know that this elides some complexities, and that devs will have to learn some small amount of Objective-C just to encapsulate their C++ code, but the capability is there. Also, how many cocoa calls would a C4D plugin dev be making? Shouldn't you just be using the C4D SDK?

And the analogy to MS's handling of Java doesn't work: Objective-C's history is very old, back to when the "market" hadn't decided on the "right" object-oriented extensions to C. NeXT chose to throw-in with Objective-C in the late 80s, and built their frameworks and tools around it. Most concede that Objective-C is the far more elegant way to add OO features to C, but that C++ (beta vs VHS?) won out in the market for various reasons unrelated to ease of programming or technical quality.

Nick

Kuroyume0161

10-18-2007, 03:59 PM

The C4D SDK can't deal with Resource Fork Data. Unfortunately, I have to.

martinweber

10-18-2007, 08:59 PM

But, you can use C++ in cocoa: "Apple’s Objective-C compiler allows you to freely mix C++ and Objective-C code in the same source file."
You can use C++ in Objective-C but that requires you to have Objective-C files. You still need to learn Objective-C to use Cocoa and for a C/C++ programmer Objective-C is awkward. Its syntax (eg. messaging) does not resemble anything in C/C++.

And the analogy to MS's handling of Java doesn't work: Objective-C's history is very old, back to when the "market" hadn't decided on the "right" object-oriented extensions to C. NeXT chose to throw-in with Objective-C in the late 80s, and built their frameworks and tools around it. Most concede that Objective-C is the far more elegant way to add OO features to C, but that C++ (beta vs VHS?) won out in the market for various reasons unrelated to ease of programming or technical quality.
No, not unrelated to ease of programming. C++ extends on C syntax while Objective-C does not. Objective-C actually forces Smalltalk syntax on top of C and makes it a hybrid. Is the argument that Objective-C is very old back when the "market" decided on the "right" object-oriented extension to C something in favor of Objective-C? I would not think so. Computer Science has moved on since then and developers have decided. It is not Objective-C.

Its clear that Apple proposes Objective-C as far more elegant. Too bad the myriads of C++ programmers don't agree. Its like them saying that their HTML API to the iPhone is elegant despite everyone asking for a real API (which they finally realized they need to provide).

Put it that way: What would you say if Microsoft would only allow to have 64-bit applications using C#?

stew

10-18-2007, 11:52 PM

The situation is not as completely bleak as all that: Apple has said that the non-UI parts of carbon are 64-bit.
Apple has said a lot of things...let's wait until the cat is out. Ignore Apple's announcements, wait what they actually ship.

martinweber

10-19-2007, 08:25 AM

Non-GUI APIs are 64-bit in Tiger already. If you are happy to work with applications without GUI then that's fine.

sketchbook

10-19-2007, 11:11 AM

Non-GUI APIs are 64-bit in Tiger already. If you are happy to work with applications without GUI then that's fine.

totally clueless here, but would this allow for a command line 64 bit renderer? all we need is the ability to access lots of ram for rendering yeah?

Srek

10-19-2007, 12:00 PM

Not realy. A commandline only 64 bit version would not allow for the creation of large scenes and testrenderings in the editor. Also it would need to be a completely different development branch which in turn increases the workload for MAXON seriously. The result of this would be either higher prices, longer development cycles or less features.
No, the only real solution is waiting for Apple to get their act together and then build a usefull version like it was done for 64 bit Windows.
Cheers
Björn

TBoxman

10-19-2007, 12:48 PM

This is bad news. I specifically visited cgtalk this morning to start a thread wondering if Maxon would release C4D 64 bit for Mac on Oct. 26. I figured since they were first out with an Mactel version they would be out the gate with a 64 bit version for Mac.

Unfortunately it seems to be a waiting game now. I wonder if there's anything users can do to help convince Apple to go the distance.

Terry

Srek

10-19-2007, 01:01 PM

Unfortunately it seems to be a waiting game now. I wonder if there's anything users can do to help convince Apple to go the distance.

Nothing i know of, the main obstacle was Apple canceling Carbon 64 bit support a few months ago, i doubt very much that they will change this decision again.
Cheers
Björn

NWoolridge

10-19-2007, 02:03 PM

Nothing i know of, the main obstacle was Apple canceling Carbon 64 bit support a few months ago, i doubt very much that they will change this decision again.
Cheers
Björn

But, on the carbondev mailing list, around WWDC Apple engineers were actively soliciting developer impact stories, as some decisions were still up-in-the-air:

http://www.carbondev.com/site/?page=64-bit+Carbon

In other words, if enough devs had given negative feedback to Apple, this stupid decision might have been changed (or at least made less restrictive). You can read between the lines in those mailing list exchanges, and see that the Apple engineers are frustrated, too, especially since the 64-bit carbon engineering was done, but some of it was going to be (arbitrarily) throttled.

I have no idea what the fallout from that was, but if developers did not speak up, then Apple might not have got a very important message.

And I want to emphasize, I don't support Apple's decision. It was stupid, and reneged on a promise to developers. There are workarounds for many of the issues it raises, but many developers will, unfortunately, just not bother.

Nick

martinweber

10-19-2007, 02:27 PM

NWoolridge

10-19-2007, 02:29 PM

No, not unrelated to ease of programming. C++ extends on C syntax while Objective-C does not. Objective-C actually forces Smalltalk syntax on top of C and makes it a hybrid. Is the argument that Objective-C is very old back when the "market" decided on the "right" object-oriented extension to C something in favor of Objective-C? I would not think so. Computer Science has moved on since then and developers have decided. It is not Objective-C.

No, I'm not trying to defend Apple's decision here, I just objected to the analogy that made an explicit comparison between MS's use of "embrace and extend" to complicate (and attempt, essentially, to hamstring) Java, and Apple's use of Objective-C. I was simply pointing out that ObjC has a long history (about as long as C++), and that there were various historical reasons for its use in Apple's Cocoa. Apple wasn't trying to "split the market" by using ObjC, that's just what the whole history of their current OS is based around.

I know that promoting one programming language over another is extraordinarily contentious; its like dissing someone's religion. ObjC has its partisans, C++ has its partisans, as do Pascal, Python, Ruby, etc. etc. etc.

Nick

NWoolridge

10-19-2007, 02:32 PM

I hope Apple reconsiders their decision. To me dropping Carbon 64-bit support feels somewhat like a stunt. It seems Apple tries to create a lock-in for developers to their platform as using Objective-C and Cocoa does not get you anywhere else. Apple will soon realize that - despite their success and popularity - they are not in a position to alienate developers. They already realized it with the iPhone.

Me too. I find it extraordinary that they made this decision, especially since some of their most important developers (Adobe, Autodesk, Microsoft) all rely, to a greater or lesser extent, on Carbon.

Nick

Srek

10-19-2007, 03:13 PM

I have no idea what the fallout from that was, but if developers did not speak up, then Apple might not have got a very important message.
MAXON along with several other well known companies that develop software for the Macintosh plattform did speak up very clearly on this issue.
Apple did not revise the decision though.

Cheers
Björn

NWoolridge

10-19-2007, 03:19 PM

MAXON along with several other well known companies that develop software for the Macintosh plattform did speak up very clearly on this issue.
Apple did not revise the decision though.

Ahh, well, that really sucks. That's really foolish of Apple.

Nick

Kuroyume0161

10-19-2007, 03:26 PM

Maybe the analogy between Java-J++ and C++-ObjectiveC is a bit stretched. But that line is neither here nor there.

I don't find the move to be as contentious as myopic. I am not partisaned to any particular programming language - have used assembler, C, C++, BASIC, Pascal, LISP, Java, JavaScript, etc. and so forth. Whatever gets the job done. But moreover, whatever gets the job done with the least pain and suffering. ;) I moved to Java mainly because it avoided the drudgery of having to juggle intimate knowledge of several OSs and maintaining functional similarities despite systemic differences. Java isn't perfect, but it is enpowering to know that an app written in Windows XP could run on an Amiga or Mac or Linux without any of that worry. I only moved to C++ because that is what the C4D SDK requires (not a big fan of C++). But I wasn't forced into this - C++ was already the long established language for the SDK.

If Maxon feels that this short-sightedness will encroach on their development, how do you think this will impact small developers like me? I'm already 'juggling' four different build environments. Obviously, this whole situation wouldn't impact many C4D SDK developers as there is that layer of support provided by the SDK to avoid dependency issues. So I'm speaking more to appliction developers here and the impact it will have. Great that Carbon will do non-GUI 64-bit - great for BSD-type apps. But most apps are GUI-centric, 3D apps being GUI-dependent.

Not to go too far away from the topic, but when the SDK moved to Universal Binary support via Xcode there was an interesting situation with respect to zlib. The Mac developer line was that you should use the libz.dylib provided with the OS (if you could ever find it) via the -lz option. The problem is that Apple kept updating the darn thing, people had problems getting it found by their applications, and there seemed to be problems with versions and compatibility. Eventually, I had some success on my end but there was a long stream of users who couldn't get things to work related to zlib. As the last straw, I took the zlib source into Xcode, built a static library, and used that instead. No more problems. Sometimes taking control away from developers, in a sense to ease their work, removes flexibility and causes more problems than it is worth. Take from that what you will.

designbytes

10-19-2007, 04:42 PM

Java isn't perfect, but it is enpowering to know that an app written in Windows XP could run on an Amiga or Mac or Linux without any of that worry.

could you please tell me what that java app is? ;-)

as Dir. of IT in my real job, my crew curses, cries and laughs over all the support hoops we go thru supporting various verision of java required by different web delivered apps.....give us LAMP and Web services any day!

sure hope Apple resolves the 64bit confusion though....

Kuroyume0161

10-19-2007, 05:28 PM

People often confuse Java application and Java web applet. I don't do applets, I do applications that run outside a browser so that keeps it a bit simpler. Almost all platform problems with Java (and probably other languages like Python) are implementation ones. Some are Sun's fault some aren't. For a while I couldn't do Mac Java applications at all since Mac didn't support Java. When the finally did, they started at an earlier version than the current at the time.

Java isn't my main language any longer. C++ is for obvious reasons. But if I wanted to move to another language for platform independence reasons, it would probably be a newer language.

stew

10-19-2007, 06:02 PM

Non-GUI APIs are 64-bit in Tiger already. If you are happy to work with applications without GUI then that's fine.
Non-GUI non-Carbon non-Cocoa non-CoreImage non-CoreAudio non-Anything-that-would-make-a-Mac-app-a-Mac-app APIs are 64-bit ready in Tiger. The 64-bit support in Tiger is reduced to a bare minimum that does not allow you to do basic things like loading or saving an image file through any of Apple's APIs.

For touting their horns about shipping a 64-bit desktop for the masses with the G5 a couple of years ago, Apple is far behind at actually shipping frameworks that allow you to use that address space.

seco7

10-19-2007, 06:53 PM

First, I am distressed about Apple's Carbon / Cocoa and ObjC / C++ decisions, but it seems to me that it may simply be a matter of time and resources. I'm thinking of a senerio like:

Given that Leopard could not be delayed any longer and Apple doesn't have the time and resources to FULLY develop Carbon 64-bit, what choices are left? Unfortunately very few. One option could have been including support for non-GUI 64 only, that at least in theory, addresses the MOST need aspects of the 64-bit framework ... for heavy math. Unfortunately, it doesn't address much else.

Of course I could be completely offbase too.

Steve

ps. Wow assoc, Smalltalk? I haven't heard it even mentioned in many years. I still have an old Smalltalk textbook from when I was in school many many moons ago. :)

stew

10-19-2007, 07:00 PM

There's no need to speculate, the reasons were mentioned months ago on the Carbon-Dev list:

64-bit Carbon works pretty well in Leopard; you can see it in action when opening a menu in 64-bit Xcode, for example, since menus are still displayed in 64-bit compositing WindowRefs and HIViews. I spoke with several developers at the conference today who were making good progress in porting their Carbon apps to 64-bit, including one who was almost ready to go to beta- testing.

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.
http://lists.apple.com/archives/Carbon-dev/2007/Jun/msg00435.html

seco7

10-19-2007, 07:54 PM

I don't know Stew, there is just so much unknown and conflicting information floating around. No doubt the decision as it stands sucks, I'm just trying to be optimistic because the alternative is terrible. I pulled this excerpt from a quote a couple later than the link you supplied regarding Bertrands decision.

Steve

>>Then June rolls around and, oh, by the way, that Carbon 64-bit stuff
>>we promised last year? Bertrand nixed it. If you really want 64-bit
>>support, rewrite your application in Cocoa.
>>
>>Some people don't have to imagine this scenario because they're
>>living it. Still boggles my mind to think Apple could do something
>>this crummy and, IMO, strategically stupid.

>imho Apple isn't that stupid, but that manager who made this decision.
>But in the past we experienced that stupid decisions were made undone,
>and that the decision making manager had to look for a new job.
>imho this is one of those cases.

stew

10-19-2007, 08:52 PM

For reference, the quote I posted is from an Apple employee (it isn't obivous from the archive web site).

I don't see any conflicting or confusing information: Apple announced Carbon 64-bits at WWDC 2006, shipped semi-working beta versions and eventually decided to cut it when they realized that getting it ready for release by October was either not possible or not worth it. It's standard in the software industry that when a project is late, you either push the release date back or cut features. Or as seen in this case, do both if necessary.

martinweber

10-19-2007, 08:55 PM

I know that promoting one programming language over another is extraordinarily contentious; its like dissing someone's religion. ObjC has its partisans, C++ has its partisans, as do Pascal, Python, Ruby, etc. etc. etc.
I don't mind Apple promoting Objective-C. It actually has some features that are really nice.

What I just don't get it how Apple binds their system APIs to a single programming language. I see what they want to do. Make the APIs object oriented and therefore more comfortable to use than procedural APIs. Its forward thinking in one way. Unfortunately it is also ass backwards to leave out any other way to access system APIs.

To add insult to injury Apple announced and confirmed that Carbon will be 64-bit until the last WWDC where it was a big ugly surprise for a lot of people when Apple announced that Carbon won't get a 64-bit treatment. Heck, they had enough resources to keep an intel version going in parallel to the PPC version over all the years but do not have the resources to maintain an existing API? Smells foul to me.

@seco7: Never really learned Smalltalk but it is also a long time since I heard something about it that was not academic. I still find it odd that they made a hybrid out of C and Smalltalk to create Objective-C.

Kuroyume0161

10-19-2007, 09:41 PM

I don't mind Apple promoting Objective-C. It actually has some features that are really nice.

It doesn't bother me either. MS endlessly promotes VisualBasic and C#. :)

What I just don't get it how Apple binds their system APIs to a single programming language. I see what they want to do. Make the APIs object oriented and therefore more comfortable to use than procedural APIs. Its forward thinking in one way. Unfortunately it is also ass backwards to leave out any other way to access system APIs.

This happens often. Amiga was tied explicitly to C, but then anything that could made to interface C (such as assembler) was also supported. For OS-level APIs, binding the system to one language is fine as long as there are bindings to the language (read: build systems) for other languages. Let's face it, Objective-C++ binds C++ to Objective-C. This was probably done out of necessity since C++ is probably the most used language these days.

Never really learned Smalltalk but it is also a long time since I heard something about it that was not academic. I still find it odd that they made a hybrid out of C and Smalltalk to create Objective-C.

That's what bugs me. Smalltalk is all MacOS. Here's my total knowledge of Smalltalk: _. This forces developers generally to learn something that an extremely small percentage of people use on any basis. Although any decent programmer can learn any programming language, it is more an issue of maintaining paradigms. I tend to stick to particular OOP languages nowadays (though you've see my list of procedurals from the past). This makes it easy to switch gears quickly when moving from project to project in different languages. Someone wanted me to help them develop Perl scripts - but the paradigm shift was so great and detrimental to the thinking processes used daily for C++ that I ended up only assisting in resolving basics (logic, structure, flow). At that level, all languages are similar - the details and methodologies can be confusing.

Kuroyume0161

10-19-2007, 09:42 PM

double-post... uhggg.

flingster

10-21-2007, 11:23 AM

i'm getting slightly lost here in the mass of complexification issues for various reasons of why its not going to be available in the form they originally promoted...HOWEVER what i really need to know is... will/can c4d be made 64bit on a mac in leopard?

marshalartist

10-21-2007, 02:32 PM

I take it that the 32bit version of C4D on Leopard will run with no performance hit or compatability problems, it just will not be able to access more RAM, is this right?

Other3DMaster

10-21-2007, 03:44 PM

I take it that the 32bit version of C4D on Leopard will run with no performance hit or compatability problems, it just will not be able to access more RAM, is this right?

As I understand it, that is it in a nutshell.

ooo

10-21-2007, 03:55 PM

wbj

10-21-2007, 04:25 PM

If I understood a previous answer by Srek well, MAXON will work on a 64bit version for OSX, but it will take more effort and time and #@$%@^ than it would have taken if Apple had kept to it's words on Carbon. That said, I have more fears for third party developers that will not go that route, so that will limit the availability of plugins for the 64bit version for OSX. Am I right?

odo

Regarding the third party plugins: If the source code of the plugins is 64 bit ready and uses the SDK (instead of making own Carbon UI api calls), then it will just an additional compile cycle (like for Win XP 64).

Best regards,

wbj

LucentDreams

10-21-2007, 04:49 PM

Regarding the third party plugins: If the source code of the plugins is 64 bit ready and uses the SDK (instead of making own Carbon UI api calls), then it will just an additional compile cycle (like for Win XP 64).

Best regards,

wbj

Yes and the biggest problem with using b4 bit cinema on windows would be.... LACK of plugins compiled for it. Sadly this is nothing maxon can fix its up to the plugin developers to decide and support, and most the major current developers are, its the cheap freebies or older plugins that don't get that treatment. Mac users don't realize how slow the transition to 64 bit has been for cinema PC users. They will all try the 64 bit cinema on mac os when they get it, and then the forum will be cluttered with plugins not working posts for a while and most will go back to 32 bit and wait until their core plugins are supported.

Least they shouldn't have to worry about not having a 64 bit quicktime though can't believe apple is screwing 64 bit windows apps by not making a 64 bit quicktime for windows.