Jump to content

Recommended Posts

  • 4 weeks later...

yep. I think that's just the way it works.

Dual 2GHz PowerPC G5

I wish EMC would rewrite Retrospect as a native OSX app instead of a Carbon app.

Maybe they will now that we have Intel Macs. I'd love to see Retrospect Workgroup/Server 7 released as a fat binary for Mac.

Link to comment
Share on other sites

Quote:

I wish EMC would rewrite Retrospect as a native OSX app instead of a Carbon app.

 

 


Hi.

 

Why do you think a Carbon app isn't native? Does it run through an emulator? No it doesn't and that means it's native.

You think a Cocoa app is native? Well, any Cocoa app that can print uses Carbon's printer manager!

 

On an Intel Mac, any app running through Rosetta isn't native, but that's a completely different issue.

 

Regards

Lennart

Link to comment
Share on other sites

I could be wrong, but I say Retrospect is not native OS X because it uses LaunchCFMA. Maybe other Carbon apps do not use LaunchCFMA but Retrospect certainly does. And it doesn't behave like a native app, either.

 

Here's what developer.apple.com has to say about it in technical note TN2032:

Quote:

CFM (Code Fragment Manager) applications (the format used by Mac OS 9-compatible Carbon applications) rely on the LaunchCFMApp application to run on Mac OS X.

 


Link to comment
Share on other sites

But I don't understand what a launch mechanism has to do with anything? Or a run-time library for that matter.

 

 

 

In what way doesn't Retrospect behave like a "native" app?

 

 

 

I'm still not getting what you consider a "native" app.

 

 

 

As I see it, there are only two types of non-native apps on a Mac:

 

1) Java apps.

 

2) PPC apps running on an Intel Mac

Link to comment
Share on other sites

Maybe the confusing part is, that although Retrospect 6.0 and 6.1 are Carbon applications, meaning they were made to run in osx or classic, Retrospect requires 10.1.5 at least. As far as I understand, Cocoa is building on top of Carbon. Carbon is the procedural native framework, and Cocoa is the object-oriented native framework of OS X building on Carbon. So launchcfm is not loading os9 code into osx, that's what classic environment is for. I would wish however that former Dantz would fall back to the quality of product that it used to be before they hit the PC market.

Link to comment
Share on other sites

Perhaps "Native" was a poor word choice. I'm speculating that it was never fully recoded to take full advantage of OS X in all of it's unix guts and Quartz glory, (Importance to the guts). This seems to be supported by the quote I previously cited, and would explain many of it's issues. Interesting reading about Carbon and Cocoa on wikipedia. Cocoa mentions Carbon once as a separate API. Carbon mentions Cocoa at least 8 times.

 

Quote:

But I don't understand what a launch mechanism has to do with anything?

 


I think it's much more than a launch mechanism. "Code Fragment Manager" It could enable some legacy Classic API that most programs don't use anymore.

 

It doesn't behave native because the running process is 'LaunchCFMApp', not itself. The unix process scheduler doesn't know about 'retrospect', it only knows LaunchCFMApp.

It doesn't behave native because 'LaunchCFMApp' runs as root, not as the user who launched it.

It doesn't behave native because it doesn't share the system well with other programs.

 

Quote:

As I see it, there are only two types of non-native apps on a Mac:

 


I see a third: apps ported from Classic, not reconstructed or optimized for X. If Retrospect wasn't a demanding heavy system performance type of application, we really wouldn't care. But it is all that and we do care.

Link to comment
Share on other sites

Quote:

I'm speculating that it was never fully recoded to take full advantage of OS X in all of it's unix guts and Quartz glory

 


 

Gee, ya think?

 

Dantz released Retrospect 5 in tendem with Mac OS X 10.1.2. And it would have been even sooner, except Apple had some bugs in the OS code that prevented a volume from being backed-up/restored completely.

 

Apple made some promises to developers regarding the timeline for OS X that turned out not to be quite (cough) accurate. So Dantz took the Carbon route supported by Apple, and made the changes to the existing code to allow it to run on the new OS instead of scraping it all and writing it fresh (which would then taken longer the the original timeline promised by Apple).

 

EMC has given a few hints that they are working on integrating their codebase for all supported platforms. Hopefully that will still include Mac OS X (along with Windows and Linux). Only then could we hope to see a Cocoa version of Retrospect without any of the left over Carbon API's that bother you so.

 

Dave

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...