Make 64-bit compatible

[GoogleCodeExporter]

... right.

I guess most changes concerns opening the Cocoa GUI, but who knows.

Original issue reported on code.google.com by malstro...@gmail.com on 12 Aug 2010 at 12:21

[GoogleCodeExporter]

Any idea when 64bit support is likely to be done?

Original comment by garyer...@googlemail.com on 16 Nov 2010 at 5:04

[GoogleCodeExporter]

Update: 64-bit support for GUI-less plug-ins is now available.

Original comment by malstro...@gmail.com on 15 Feb 2011 at 12:10

[GoogleCodeExporter]

I was hoping that would include GUI's - is that likely to happen any time soon?

Original comment by garyer...@googlemail.com on 15 Feb 2011 at 12:56

[GoogleCodeExporter]

Hopefully soon yes, but there is a lot of research and testing remaining to do, 
as 64-bit GUI use Cocoa and not Carbon.

Original comment by malstro...@gmail.com on 15 Feb 2011 at 1:01

[GoogleCodeExporter]

Yippie! 1.29 beta (in the svn repository now) adds support for Cocoa GUI. I 
haven't been able to test it that thorough yet. I don't have 64-bit compatible 
versions of my own GUI's yet to start with, so I've been trying with a few 3rd 
party 64-bit VSTs and it works well with those.

The biggest challenge was working around the horrible, horrible single 
namespace problem in Objective C. I wanted Symbiosis to work without having to 
edit source or predefines to prefix all Cocoa classes with unique identifiers. 
That's such a kludge. Finally found a solution after a few days of tears, sweat 
and frustration.

(On a very subjective note I think Objective-C is pretty crap. I mean, I can 
appreciate how minimal it is, but some of its short-comings are quite 
horrifying when you are used to C++.)

Notice that Symbiosis.cpp is now called Symbiosis.mm. Since well, it contains 
Cocoa.

Cocoa is only used in 64-bit btw. Carbon is still the way to go for 32-bit.

Original comment by malstro...@gmail.com on 21 Feb 2011 at 12:19

[GoogleCodeExporter]

1.29 beta is now also available from the download tab.

There is a detail in my solution that I would need to check with an Objective-C 
expert / Apple developer before really committing to it. I am afraid it might 
break in the future. It concerns how I avoid problems with class name collision.

Here is the full deal. Prepare for a long story.

As any Cocoa plug-in developer (should) know, Objective-C does run-time linking 
on class names in a single global namespace. This stinks. It basically means 
two different plug-ins must have 100% unique class names, even for internal 
classes only. Apple's recommendation for now is that all classes should be 
prefixed with a unique signature (e.g. ComSonicChargeSynplantRoundKnob). 
Described here http://j.mp/fzYZoc . (In my opinion one would need to prefix 
with a version number too.)

Now look at the specific case of Symbiosis, which is a binary bridge between 
one host and potentially many different plug-in. I need a couple of Cocoa 
classes defined in Symbiosis to present the UI. According to Apple, I would 
need to give these classes unique names for each and every individual plug-in 
that Symbiosis is bridging. In practice this can't be done without recompiling 
Symbiosis (e.g. with some prefix macros) for every plug-in. This goes against 
the Symbiosis design today where a single binary can be used for all plug-ins.

At first I thought, well, this can't be that big of a deal as the binary code 
for all plug-ins (using the same version of Symbiosis) must be the same, a 
little collision wouldn't really matter. If the host would end up using the 
code for plug-in A for bridging plug-in B, C and D too, that is fine with me.

Wrong.

Apparently Objective-C classes are tied to the bundles they are loaded from. So 
when the host loads the Symbiosis bundle and asks for a specific class name, it 
will only see the classes defined in that particular bundle. Adding the rule of 
class name uniqueness on top of this seems to mean that if ever we have the 
same class name in two different bundles, Objective-C will return nil when you 
try to load the class from the second bundle. It will *not* return the class 
from the first bundle and it will *not* return the class from the second one. 
(My assumption is that this is a security / safety issue. Objective-C isn't so 
stupid that it actually wants to mix classes on mistake from two different 
bundles, although it won't allow them to work side by side either.)

I tried creating classes dynamically (through the Objective-C run-time C API) 
when the host requests them, but that didn't work. The classes have to be 
compiled into the bundle in order for the host to successfully load them 
through the NSBundle methods.

What I did end up doing is using the Objective-C run-time API to find the 
bundle that holds the definition of the classes that Symbiosis declares. First 
time a Symbiosis plug-in is loaded into memory, this will simply return the 
same plug-in bundle. Second time (and onwards) new plug-ins are loaded, this 
will still return the bundle for the first plug-in. Now I return the URL of 
this first plug-in bundle and the class name to the host, and the host will 
instantiate the objects through the class definition inside the first plug-in 
for all wrapped plug-ins.

This seems to work. I had to use the run-time C API though (objc_getClass) and 
then [NSBundle bundleForClass:]. I couldn't use e.g. [AClassThatSymbiosisNeeds 
class]. I guess again this is for security reasons. Objective-C assumes you 
don't normally want to get classes from other bundles, but "objc_getClass" can 
give you that if you really want to.

This last assumption is basically what I need verified. That this is a design 
by choice by Apple, and that it won't break in OS X 10.7 or something.

Original comment by malstro...@gmail.com on 21 Feb 2011 at 4:21

• Changed state: Fixed