[gmpi] Re: Topic 3: Cross platform
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 05 Mar 2003 12:25:37 -0500
>> well, it means you can write a C++ plugin and compile it, yes. it
>> doesn't mean that it will run in any given host.
>
>I don't know about Linux-land, but on Wintel the plugin will load and init
>any C++ support as needed, either thru statically linked C++ runtime or
>MSVCRT.DLL.
the same thing happens on all *nix OS's systems i know. but that isn't
enough. exception support and proper initialization of C++ DLL's can
vary according to the compiler flags used for the *host*. if i compile
the host with --no-exceptions to gain the approx 5% speed gain that
this provides, then a plugin throwing an exception will likely cause
the program to abort.
there's also the horrendous problem with C++ that there is no standard
ABI, and so you cannot run-time link code from the "wrong" compiler,
where "wrong" can mean: wrong vendor, wrong version, wrong compile
time flags.
>OK... and as far as platform-specific goes, the library-loading phase will
>be platform specific anyways, simply because the containers are
>different...
not necessarily. i wouldn't want anyone to use it, but libltdl exists
to do run-time loading of DLLs on windows, macos, beos, irix, linux,
os x and others. its implementation is horrible, but it does actually
work. its modelled on the historical *nix (solaris?) API for dlopen()
and dlsym(). i can easily imagine completely platform independent code
to load, create and initialize the DSP part of a plugin.
the GUI part is another can of worms entirely, alas.
>> i have never seen a reason yet for the DSP part of any plugin
>> to contain platform-specific code, with the sole exception of some
>> kind of lock-free mutual exclusion/critical section stuff. GMPI will
>> need to provide that.
>
>Configuration management? File I/O? Plug-ins that may interact with a
>particular feature on a particular system? DSP-accelerated plugins that
>need to call drivers to download code and data to their PCI card?
>
>> which touches on a good subtopic: what functionality do we need to
>> wrap for each supported platform to avoid platform specific code in
>> the DSP part of a plugin?
>
>wrap at SDK level? or are we talking replacing specific functionality..?
>or..?
i'm thinking of things like (as you mentioned): file i/o, mutual
exclusion (lock-based and lock-free), access to & initialization of
DSP resources, discovering associated plugin resources
(cf. discussions on vst-plugins about determining the folder the
plugin was found in), getting current time of day, getting current CPU
configuration, getting CPU features, getting CPU utilization figures
(perhaps) ...
these are all things plugins may want to do, and we'd like them to do
it in a platform-independent way.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
