[B2-devel] Linking to Cocoa for a 64-bit forward development path

[Robert M. <mr...@gm...>]

On 6/18/12, Charles Srstka <bas...@ch...> wrote:
> [...]
> Yep, and -[NSImage initWithData:] gets you an NSImage containing an
> NSPICTImageRep when you use it with PICT data. However, there’s a disclaimer
> in the documentation stating that because it’s not using QuickDraw, the
> image might not look *exactly* the same as the original. However, that
> disclaimer’s pretty much always been there, so I wouldn’t worry too much
> about it.
> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSPICTImageRep_Class/Reference/Reference.html
> [...]
> Just tried it; -[NSImage initWithData:] works fine with PICT on 64-bit Snow
> Leopard too.

Wow, this is great. So it's just Carbon that got deprecated, not the PICT stuff.

If we link to Cocoa objects we can do this, and perhaps all the other
stuff that we're using Carbon for at present.

I know we can link the C to Objective-C using small bits of glue
routines -- I know, because I implemented such routines to add an
NSAutoreleasePool handler for SheepShaver (back when I was trying to
use my MacPorts-installed X11 version of SDL). (I know there is a
NSAutoReleasePool_wrap in BasiliskII/src/MacOSX/utils_macosx.h but it
doesn't seem to be used, and there are some other .mm files that all
seem to be for the GUI-based Prefs editor).

I made SheepShaver/src/MacOSX/autorelease.mm containing:

  #include "autorelease_pool.hpp"
  #import <Foundation/NSAutoreleasePool.h>
  t_autorelease_pool::t_autorelease_pool() : d_pool([NSAutoreleasePool new]) {}
  t_autorelease_pool::~t_autorelease_pool() { [this->d_pool drain]; }

and in SheepShaver/src/MacOSX/autorelease_pool.hpp:

class t_autorelease_pool {
public:
    t_autorelease_pool();
    ~t_autorelease_pool();
private:
#ifndef NO_T_ID
    id d_pool; // << you may opt to preprocess this out when not needed.
#endif
private:
    t_autorelease_pool(const t_autorelease_pool&);
    t_autorelease_pool& operator=(const t_autorelease_pool&);
};

Then in about 10 places, e.g. SheepShaver/src/Unix/ether_unix.cpp I added:

  #define NO_T_ID
  #include "../../../SheepShaver/src/MacOSX/autorelease_pool.hpp"

  //...
  // in slirp_receive_func:
    t_autorelease_pool pool;

Later I figured out that the recurring autorelease messages were SDL's
fault, and I switched to the "build SDL from source first" method like
everyone else uses, and then my autorelease messages went away.

However when I get the SIGSEGV crash, my console output still shows a
lot of __NSAutoreleaseNoPool errors, so I might try it again if I get
really frustrated with the crashes.

My main point here is (IMHO) linking to Cocoa or other Objective C
libraries is quite feasible and perhaps a good way to move B2 and SS
further ahead.

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com