Yves Surrel <surrel@[EMAIL PROTECTED]
> wrote:
> > If LabView for X is Cocoa and not Carbon, it will almost surely not be
> > able to link to Carbon SharedLibs.
>
> This is probably the point, if the second part of your sentence is
> true. Labview 7.0 for macOSX is surely Cocoa...
Offhand, I cannot think of an easy way to differentiate between a Mach
(Cocoa) bundled app and a CFM (Carbon) one, although there likely is
one. I could not find any "real" technical specs on LabView at NI's
site, nor what type of shared libraries LV7 requires. Do they supply no
sample libraries nor do***entation about building libraries to use with
LV?
> > If LabView is expecting to link to a C++ SharedLib, it may expect C++
> > name mangling in the library (this may be something you can specify in
> > LabView).
>
> I don't know precisely about this name mangling; does it concern extra
> leading underscore characters in ex****ted symbols or what?
Name mangling is often done in C++ and Objective-C to "mangle" the
procedure name with the class it belongs to. It is considered poor form
for a library to ex****t symbols in that form, however.
It would almost surely be possible to adapt Mop's library maker to build
ones that are of a format that could be used from a Mach/Cocoa
application.
Apple Events might work for you, since they are much faster under X than
previously. Unfortunately, the old PPC Toolbox is no longer available,
as that was **very** fast and suitable for passing large blocks of fdata
between applications (probably was deemed too insecure for X, what with
isolated memory spaces, etc). TCPIP would be another method you might
look into and give the added benefit of being able to run client-server
on different machines - it appears that LV sup****ts this.
-- w
|
