Mac EIAS 64? Apple possibly canceling Carbon 64, so...

[futagoza]

So suddenly the idea of Maya 64, Lightwave 64 and, of course, EIAS 64 for Mac becomes quite nebulous.


Quite interesting. So i´m no programmer nor a pro (only a hobbyist), but what does it mean in reallity? Like when EIAS 7.0 is comming out, would this be the last EIAS version for a long period of time, or is EITG planning already to use then COCOA libraries and port all stuff over?

Brian, can you say a bit about the future develpment of EIAS, concerning this. Any words from the advisory board yet on this?

Regards
Stefan

[arketype]

EITG just finished porting for Mac-Intel compatibility (via carbon libraries i think).

I would assume that going to Cocoa would require further "porting" effort without any other feature enhancement.

"64 bit" will only lift the current RAM ceiling for Camera/Animator above 2GB. So unless you are running out of RAM 64 bit really does not gain you anything. I'm not sure where this is on the list of priorities.

Of course 32 bit EIAS should run just fine on Leopard.

[juanxer]

In many cases, 64 bit addressing is simply about managing more memory than the 32 bit ceiling allows (which usually means about 2 GB: it ought to be 4 GB, but I believe the OS parts the app calls while running must share it with the app's code and the working projects' data, too) be it real RAM or virtual memory. Even if it is virtual memory, it makes the programmer's life far easier than having to do paging tricks and such.

Curiously, I heard that one of the uses of Windows 64's capabilities was doing a 64 bit version of a "First Person Shooter" game scene editing tool, as it was able to map in memory all the game "world" and simplified things a lot (you could slice it later into loadable chunks for the 32 bit game).

Obviously, for 3D apps, it is about both things: being able to manage bigger that 2 GB projects in RAM, or at all even if you haven't got the RAM but the hard disk space.


There is an specific advantage in running in 64 bits on Intel/AMD processors, although it has nothing to do with 64 bitness per se: seeing that 64 bits mode was a very clear separator (you have to code and compile specifically for it), they thought about implementing some new features in their processors (more registers and so) that, by only being available in 64 bit mode, wouldn't produce 32 bit code forks and incompatibilities. A compiler ought to take advantage of those features to make more efficient code. At least the NewTek guys attributed some of their LW64's more speed to that (better written code aside).


The incredible thing is that Apple posted a set of new APIs for Carbon 64 apps in last year's WWDC, developers complied with the changes, and now Apple is saying that, even if everything is mostly finished and in place, some people ready to go betatest their 64 bit apps, they are canceling it (at least canceling the most important bit, the GUI-related APIs they directed developers to change to). For many of them, specially if there is a multiplatform codebase, Cocoa is simply not an option.

[arketype]

at least canceling the most important bit, the GUI-related APIs they directed developers to change to

You know, to be critical of Apple, this is an ongoing problem.
Apple has been willing to make the "hard choices" and cut ties to past technologies in order to adopt new ones, which I think is a good thing.

BUT the Mac platform has been in flux for as long as I can remember. First the move to PowerPC, then porting to OSX (carbon), then porting to intel, now porting to "Cocoa". Developers are spending as much time porting as they are developing new useful features. The OS is a moving target, and developers don't know if they can trust their codebase to be current in a year, or even the direction Apple is telling them to move in.

Apple needs to be honest with their developers and not pull this kind of "switcheroo" on them first saying "carbon is life" and then killing it just a couple of years later. It would have been better to let developers bite the bullet with Cocoa in the first place.

[juanxer]

Add to that the fact that Cocoa is Mac only... and that current Macs are PCs too. Not the kind of pressure one would dare apply to the Adobes and Microsofts and Autodesks out there, frankly.

What I wonder is why Apple doesn't clarify this right now. My guess is they really want to be silent until the October launch, All these guys hoping to launch their Carbon 64 apps simultaneously better be satisfied some way or this is going to be too like old times (I still remember Bedrock and other idiocies like that).

[halfworld]

The way I understand it, there is NOTHING that stops EIAS going 64bit except time :)

Right now EITG is busy working on EIAS 7 (the hardest and longest feature has been done, and it's looking really nice so far).

It isn't necessary to write in Cocoa in order to get 64bit support.

Ian

[juanxer]

(An estimated release date, please please please? :))

[halfworld]

I literally have zero idea, couldn't even guess, you'd have to ask EITG :)

It just depends how many new features they put in...

Ian

[arketype]

Don't forget some "new product" mentioned by EITG.
I wonder what that's going to be?

Can't find the link to that........Hmmm....

[AVTPro]

I'm not a programmer and I would like to keep it that way :)

However, I'm not clear what this all means either. I just saw the WWDC07 in it's entirety this morning. When Steve Jobs (SJ) announced Leopard would be 64 bit through and through, I can considered it a good thing especially in the wake apps like Maya 8 not being simultaneously released due to the lack of OSX 64 bit systems.

Then there were also complaints from the 3D community about OSX not being true 64 bit.
So Leopard is now true 64 bit. Wasn't that not only the expectation but also the demand?

So here's my question. What does that mean in the day to day life of a modeler, TD, animator?

Maya 8.5 won't run on Leopard? Current EIAS won't run on Leopard? New versions of EI won't run unless they port again. Most of my apps like ZB2 work run?

My MacPro Quad-Core occasionally crashes from incompatiblity with 10.4.9. as it is.
Or is it just the rest of the world may need to catch up with the Leopard on a new Octo?

AVT

[futagoza]

Don't forget some "new product" mentioned by EITG.
I wonder what that's going to be?

Can't find the link to that........Hmmm....

It´s mentioned in the EIAS General Forum section, page 2, Press Release March 9th.

[arketype]

However, I'm not clear what this all means either.
AVT

Hey Alonzo,
It's confusing to be sure. Often I've read articles by "technology reporters" that get things very wrong when it comes to 64 bit.
All this talk of 64 bit is a little silly. It is a "milestone" in computing for sure, but it's not like a 64 bit computer is twice as fast as a 32 bit one.

Basically 64 bit means "more memory". It's like adding an area code so you can have more local phone numbers that are 10 digits instead of 7. More digits don't make phones faster, it just lets the overall phone system handle more people.

In most cases that means more ram for applications (32 bit addressing can only give you 4GB per application, the current Mac implementation only gives you acces to 2GB).
64 bit calls can also used when reading and saving files, so there would be no limit on file size. There are some 64 bit math functions, but I don't think a 64 bit computer will compute faster. As I understand there are some "tricks" so you can do 64 bit math on a 32 bit computer.

So the main feature of 64 bit computing is holding more than 2GB of information in memory at a time. Occasionally I've pushed Camera up to it's limit of 2GB. This would be the main advantage of 64 bit Camera. The new "ceiling" for memory would be so high, we'd probably never reach it.

Leopard should maintain its backward compatibility with 32 bit apps. That's the point. No one has been able to integrate 32 bit and 64 bit computing into a single OS before Leopard (some one correct me if I'm wrong here). Windows has a special 64 bit version that is NOT 32 bit compatible, so special drivers are needed for all the hardware, etc.

Any speed enhancements that come from a 64 bit application, are probably coming from developers cleaning up their code when they re-write for 64 bit., and not the "64 bit-ness" of the App.

Maya, EIAS, etc. should all run fine on Leopard. So no worries!

[arketype]

Thanks Stephan

From the EITG Website:

EITG Press Release March 9th, 2007

EITG has also just released a redesigned website online and has targeted 2007 for the release of two new 3D animation products.

“EI Technology Group is on the move! We are already well on our way to version 7.0 of EIAS and have begun the development of two new products for the 3D marketplace,” says Brad Parscale, CEO of EI Technology Group.

So there are 2 new products!

My guess is that one is a Maya integration system.
What's the other one? Hmmm...

[splitpoint]

Leopard should maintain its backward compatibility with 32 bit apps. That's the point. No one has been able to integrate 32 bit and 64 bit computing into a single OS before Leopard (some one correct me if I'm wrong here). Windows has a special 64 bit version that is NOT 32 bit compatible, so special drivers are needed for all the hardware, etc.


I'll correct you. :)
32 bit binaries (applications) run on just about every 64 bit OS out there including Solaris, HPUX, AIX, IRIX, and Windows XP64. What doesn't work is 32 bit drivers on a 64 bit OS.

[arketype]

I'll correct you. :)
32 bit binaries (applications) run on just about every 64 bit OS out there including Solaris, HPUX, AIX, IRIX, and Windows XP64. What doesn't work is 32 bit drivers on a 64 bit OS.

Thanks Al. :)

[AVTPro]

Hey Alonzo,
Any speed enhancements that come from a 64 bit application, are probably coming from developers cleaning up their code when they re-write for 64 bit., and not the "64 bit-ness" of the App.

Maya, EIAS, etc. should all run fine on Leopard. So no worries!


Thanks David. My concern is mainly compatibility so "they say" it's should be fine. :)

10.4.9 shut a lot of folx down.

[juanxer]

So Leopard is now true 64 bit. Wasn't that not only the expectation but also the demand?
AVT
The problem is that OS X has two main routes for programming on it: Carbon, which uses a mainstream style of programming; and Cocoa, which inherits the style in use on the NeXTStep OS, which is extremely nice to the programmer and has some awesome features but has very little commonality with most things out there.

Carbon was born as a cleaned subset of classic Mac OS remapped to the OS X infrastructure, to help programmers port their old code to the new OS without having to do a total Cocoa rewrite. Since then, it has gained many OS X-only thoroughly modern elements, to the point that not only it is a genuine first citizen interface to OS X facilities but Cocoa fills many of its lackings by wrapping Carbon blocks with means of talking to them. Most multiplatform apps come to OS X via Carbon because it is easier to port Windows and Unix code to it, specially regarding apps' user interface code

Cocoa has its origins in the NeXTStep OS. Apple, after buying NeXT Computers from Jobs, first tried to produce a multiplatform Mac OS called "Rhapsody": the idea was that NeXTStep would be the native Application Programming Interface (API), and old Mac OS and Windows apps would run in "compatibility boxes". It meant that all apps, to run native on Rhapsody, would have to be reprogrammed on NeXTStep, with no possibility of reusing nearly the tiniest bit of existing code. When one considers how big apps such as Photoshop or Ms Word are, you can imagine what the general reaction was: thanks, but no, thanks.

So Apple thought about it and thus was born Mac OS X: Carbon would be a way of porting apps to the new OS by reusing most old code and changing whatever needed to change, ultimately evolving into something much more complete and modern; Cocoa would still be the preferred OS X' API (and deservedly so, most programmers say), but no longer would be multiplatform, making it somewhat niche, a Macs-only thing. Apple itself would promote programming hybrid apps in which Cocoa called Carbon functions that it lacked itself, and a bit of the other way round, and defend Carbon as an OS X' Thoroughly Modern Millie. So one could say there was a practical parity of importance.

So it comes 64 bitness. In Tiger it was constrained to interfaceless Unix apps. For Leopard it was promised for both Carbon and Cocoa. Producing a 64 bits Cocoa seems to have been relatively painless. For Carbon I didn't think it was to be possible at all until they happened to announce it. Last year, in WWDC 2006, Apple told developers which parts of Carbon would become 64 bits-able, plus which new parts had been created to achieve that and other things (like resolution independence and some new Leopard features). They told them what ought to change in their apps to guarantee 64 bitness when Carbon 64 arrived.

So developers proceeded to make those changes while Apple kept on porting Carbon and Cocoa to 64 bits. The most important change involved a new Carbon element dealing with the graphical user interface. A year passes, developers come to WWDC 2007, some of those with Carbon 64 apps nearing or already at beta status, and chaos ensues:

-Apple won't list Carbon 64 as a Leopard feature.

-All hints show that actually there is a complete or a hair width from complete Carbon 64. What's more, Cocoa 64 has no choice but call to many Carbon 64 parts to function.

-Apparently Apple has listed what Carbon components are officially 64 bits-able, the omitted one being precisely the one Apple insisted so much on Carbon developers to adopt, the one that affected user interface programming. One which seems to be already 64-bit capable. One which is absolutely fundamental for any hope of producing 64 bit Carbon applications and porting 64 bit applications such as Maya64 or Lightwave64 or a future Photoshop64 to the Mac world. Hell, what about Apple's own creative suites? Most of them are Carbon-based.

-Actually, Xcode, the development environment that Apple gives for OS X programming, is a 64 bit app which uses the very Carbon component Apple is pulling out of the Carbon 64 list.

-And this decision seems to be "political", not due to a technical issue but rather to a "we'd prefer you'd go Cocoa and let us concentrate on Cocoa". Which looks a lot like Rhapsody all over again, with a heavy dose of old Apple, The Backstabber from Cupertino, year by year promoting and then demoting new APIs and letting programmers fall with them: Bedrock, Quickdraw GX, etc.

So no, Leopard is not truly completely 64 bits, developers are rather irate (the other bomb was iPhone "openness" via web programming), and Mac's future as a 64 bit workstation suddenly looks rather dubious.



As Arketype said, the main advantage of 64 bit memory addressing is that an app can break through the 32 bit 4GB ceiling of memory available to it, be it real RAM or virtual memory. It makes life easier for the programmer whose app has to deal with humongous amounts of data: without it the app would have to have its own "virtual memory" scheme and do all sorts of contortions to page data in less that 4GB segments. Also, it allows for novel ways of addressing data elements, such as mapping them to memory. As a curiosity, Multics, the OS that preceded Unix, mapped both RAM and hard disks into a continuum of 64 bit-addressable memory space.

[AVTPro]

Very Heavy Duty Post...Thanks. Great Recap as well..

I'm wondering the political implications on the OS market if developer did quickly adopt to Cocoa (?). I'm hoping it's not an effort of Apple to corral developers into a Mac-Only standard like QD3D.

I can see the resourcefulness of Apple settling on one API but it's not likely they can herd developers through a narrow canyon when they don't have the lion's share of the market.

I think only if the big boys developers who have the resources and would already be fully geared up for a 64 bit app (cocoa port) would be needed to lead the way... then the small fries may follow.

If Apple could gently nudge the them along instead of giving them an ultimatum "port or die" then it could look good for Intel Macs, OSX and 64-bit apps.

[juanxer]

My guess is that developers of small Mac apps can adapt. The ones that do multiplatform small apps decidedly have a problem. The Maya/Photoshop-level app developers are in for a world of pain if they want to go 64 bit on Mac.

I wonder what the EITG guys think about it: as it was said, they are going one step at a time, so 64 bits is not a too inmediate priority. But, If I am not wrong, they have a multiplatform framework of code from which to derive Mac and Windows versions of EIAS and such, which includes their common across platforms graphical interface. I don't know how much of that is dependent on Carbon for OS X (I'd guess enough to be a problem in the future).

[AVTPro]

I could see if SJ waved the Carbon 64 "carrot" in front of the developr to draw them closer to more manageable Cocoa port. Bait and Switch as David mentioned. If he can say, "OK.. now that you are Carbon 64 ready you're 90-95% of the way to Cocoa". I could sympathize with his strategy of railing everybody into the "next step of OS advancement" or (future of computing).

Anyway, as the market stands, there's still of a lot of Carbon IMacs and PBs that will be sold for some time yet. There's no brand new CPUs so I don't think Leopard has to ship with new sales. I forgot what they call it when they open the old CPU and drop in the new OS (repack?) but I don't think they have to do it this time. It's an stand alone upgrade purchase (?).

Also, personally, I can't sweat Leopard right now. My Mac is less than a year old. Tiger is what? 1 1/2-2 years old? I have only started using it in late last year. Maya is current.
As long as ZB3 will run on Tiger. I'm good til my next Mac :)

Apple is a strong platform right now...200,000 Developers more this year alone? It would seem like developrs could release their current Carbon 64 version and still have plenty of time to prepare themselves for the future of a strong intel Mac platform.

Just trying to understand SJ's thinking and how his decision will affect my immediate center.

[AVTPro]

Thinking about it...

With the EA and ID games support...and simultaneous releases, I don't think Apple has too much to worry about.

[arketype]

There is no way to know what Jobs is thinking. He can be brilliant, and arrogant.

Another possiblity: We do not know what "future" that Jobs has envisioned. He may be trying to cut Carbon 64 because it has some fatal flaw that would come back to bite Apple later. Or he could be just trying to not support 2 different programming technologies. Carrying on with Carbon AND Cocoa would eat a lot of support resources vs. just one.

The other thing that could be going on (and this is a REAL longshot) is that Apple may have a new version or offshoot of "yellowbox" from NextStep which would allow Cocoa apps to be recompiled to run on Windows. If this is possible, then Apple would have a cross-platform development environment in Cocoa/ X-code. Write once, and recompile for Mac or Windows. PPC, or Intel, 32 bit or 64 bit, whatever. Why did Apple create BootCamp? Maybe for the developers using the new "yellowbox" to program for Windows. THAT might entice developers to move to the Mac as a primary development platform. It would make sense for big Apps like Photoshop Maya, etc. to be re-written if they could share 100% of their codebase for both Mac and Windows.

I think Leopard looks like a good buy. Time Machine by itself is probably worth the upgrade price. Hopefully they have fixed a few quirks in the Finder that drive me crazy!

The discussion and speculation has been fun guys.

[juanxer]

I think Apple resucitating the OpenStep/Yellow Box concept and doing a Cocoa for Windows wouldn't have much traction, no matter its virtues: Apple promoted such a a thing when Rhapsody, just to kill it when OS X appeared (destroying all its multiplatform OpenStep developers' products' future outside Apple). Once burned... That Apple is playing dangerous games again is not doing any good, either. Adobe just can't allow itself to depend on Apple so completely.


(BootCamp I think it is the biggest about-face, lots of spin included, that Apple has done for a long time. When Apple announced its transition to Intel, many of us rejoiced: we would be able to dual-boot OS X and Windows/Linux/whatever. Then Apple, as per becoming the new Intel tech poster child, adopts EFI instead of BIOS as a booting system. Huh? Well, that could make things a bit difficult... Oh, wait, EFI has a BIOS emulator: all is well.

But then they decided not to include the BIOS emulator part.

It didn't sit well. Some projects to put a BIOS appeared and actually succeded (even if it was a hair-raising tweak), and then the Parallels gang started their show. I think Apple got not only the message, but did some numbers too and saw that it would increase the Mac's appeal. So BootCamp was born.

Apple's publicity is very funny: "Macs use an ultra-modern industry standard technology called EFI to handle booting. Sadly, Windows XP, and even Vista, are stuck in the 1980s with old-fashioned BIOS. But with Boot Camp, the Mac can operate smoothly in both centuries.". yeah, well: this is an ultra-modern thingy nobody else was interested in supporting, among other things because its first implementation wasn't compatible with certain AMD processors, and nobody wants Intel to dictate things even more than it does. BIOS works just fine, EFI allows things Apple's hardware/software isn't taking advantage of at all, and thanks to EFI our choice of graphic cards to reflash seems to have dropped to zero).


Argh, I should stop being the anti-Apple Fanboi Supreme :) It's just that it's been decades owning Macs at home and working with them at my job, and it feels like a Jack Kirby-level cosmic battlefield :D

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.