Anyone want to help out Mr Hater…?

Poor Mr Hater is having trouble running FireMonkey applications and/or the remote debugger (it’s unclear what) on OS X Lion. Would any XE2-user-with-a-Mac have a suggestion? The error message reported (‘You cannot open the application because the Classic environment is no longer supported’) doesn’t make any sense in itself, since the ‘Classic’ environment was the emulator that ran OS 9 applications compiled for PowerPC, and XE2 has as much chance compiling for OS 9 and PowerPC as it has targeting CP/M on a Motorola 68000.

In fact, in the main, XE2’s RTL and FMX sources keep well away from legacy Mac APIs. Despite some (probably unintentional) misinformation around, the frame of an FMX form is a Cocoa window, not a Carbon one (‘Carbon’ was/is the API Apple provided to allow C and C++ applications to cross compile for OS 9 and OS X, ‘Cocoa’ the ‘modern’ Objective-C and OS X-only API). As for the RTL, this delegates to the POSIX layer as much as possible, and failing that CoreFoundation, which is C-based but OS X specific API layer. There is however one exception – due to OS X’s apparently incomplete implementation of POSIX threading (it doesn’t support unnamed semaphores), the Carbon ‘Multiprocessing Services’ API is used instead for TSemaphore, TEvent and TMonitor. This then brings in TCriticalSection and a few other things, which are based on TMonitor when targeting OS X. While the RTL team should probably be at least investigating an alternative to the Carbon API here pretty sharpish, surely use of an API only recently marked ‘deprecated’ (‘v10.7’ = Lion) wouldn’t have caused Mr Hater’s problem…?

8 thoughts on “Anyone want to help out Mr Hater…?

  1. Surely the error message makes perfect sense. What doesn’t make sense is the idea that simply compiling code in XE2 should result in that error when attempting to run the compiled products on an OS X system.

    But, on the face of it, we have to accept that something, somewhere is causing that error.

    Since you were unable to unequivocally rule out the possibility that some legacy API is somehow being invoked, this would seem to be the most likely explanation, we just need to figure out which legacy API it is. Which will be difficult without the problem source (either the app or perhaps some undisclosed source – possibly in the Platform Assistant or other closed source element in the cross-platform runtime support)

    • Surely the error message makes perfect sense.

      I don’t follow – supposedly something from XE2 has caused it, yet XE2 has nothing to do with the subject of the message. Even if the root cause of the message is something XE2 is doing (I’m unconvinced it is), the message itself will still be incorrect.

      Since you were unable to unequivocally rule out the possibility that some legacy API is somehow being invoked

      Well, if course I can’t ‘unequivocally’ do such a thing. My main motive in raising the threading point was in a vague hope it might get on Embarcadero’s radar for XE3…

  2. “After some time, it gets boring to see that OSX Lion is not supported by Delphi XE2”.

    Good grief… he does like hyperbole and false statements, doesn’t he. I’m posting here rather than on his blog because I don’t want to support it in any way – I do want to be helpful, though.

    For what it’s worth, I run applications built with XE2 on OSX Lion just fine. Other people do too. His statement about Lion being ‘not supported’ is false.

    I think it’s unlikely that Carbon APIs would cause this. This error normally occurs for a OS9 application, i.e. something is probably making the loader think it is not a OSX app. They have very different executable formats. This is guesswork, but makes more sense than an old API somehow drawn in – I don’t see how Embarcadero could have done that, given they provide translations of the Apple-provided headers / APIs and were probably working with those same translations themselves.

    Some googling would have turned up threads like this: where other new apps, in this case iTunes itself (!) gives this error. The solutions imply it’s due to corruption of some sort: possibly of the app, the app bundle, permissions, or even the OS.

    Things to try would be:
    – Clean and rebuild the app (and completely remove it from where it’s located on OSX, to be sure to make the IDE moves everything across again.)
    – Open the app bundle and compare it to a working app. What’s different? Can he execute the program located in the bundle from the command line? If not, what error does it give?
    – Reinstall the remote debugger. Maybe it’s this thats corrupted, not even his app…? It’s impossible to know from his post when this error occurs (running from the IDE, i.e. debugging? Running the app normally on OSX? …?)
    – Open Disk Utility and verify the disk, and check / fix file permissions.

    After that, if he still has problems, I’ll admit it’s more complicated. The next appropriate move would be to post on the Embarcadero forums or open a support request rather than complaining on his blog that it ‘doesn’t work’.



      • Chris – sure, feel free. If you do, perhaps just the bits about the possible problem / solution. I feel bad even writing the bit about “hyperbole and false statements”, even though I think it’s true. I don’t want to get personally involved, just technically involved to help, if that makes sense.

      • David – done, thanks.

        ‘Even though I think it’s true’ – you don’t say! This is a guy who in the previous year or so has claimed multithreaded programming is impossible in Delphi, and that once 64 bit targeting comes, the VCL won’t be ported because it is intrinsically tied to Win32. On the plus side, he does seem to have a genuinely encylopaedic knowledge of the Delphi 3rd party component market circa 2001 though…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s