[gmpi] Re: Topic 3: Cross platform

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 05 Mar 2003 11:05:50 -0500

>On Wed, 5 Mar 2003 RonKuper@xxxxxxxxxxxx wrote:
>
>> 1. What processors (or processor architectures) are to be supported?
>>
>> Whatever processors are supported by O/S's we choose to support in (2).
>
>To include current 32-bit and imminent-future 64-bit processors and OSes.
>GMPI should aim to make the 32->64bit transition relatively painless.

more specifically (and said without prejudice toward MS): it will be
very important to drop all reference to MS-inspired terminology such
as WORD, DWORD and so forth in favor of types that are associated with
specific bit widths. most portable operating systems (the BSD's
(including Darwin) and Linux) do this already, and ANSI C includes
standard types for them (u8, s32, etc).

secondly, calling 32->64 bit a "transition" is a bit of a
misnomer. for those of us based on unix-related platforms, we already
have to deal with 64 bit hardware. several unix os's have run on
alpha's and other 64 bit systems for more than 10 years. for example,
its not uncommon (though not common enough) when writing linux
software to be notified by others of 64-bit-clean issues.

>> 4. What programming languages are to be supported?
>>
>> Standard C (which supports C++ by extension), with very clearly specified

actually, unless i'm misunderstanding your point ron, it doesn't
support C++ at all. supporting C++ requires a C++ runtime environment,
which is not at all guaranteed to exist within the host. exceptions,
constructor/destructor handling, virtual function looking, correct DLL
initialization ... these are all tricky with C++. just consider the
problems in deciding whether its safe for a VST plugin (C++) to throw
an exception.

>> calling conventions (cdecl vs. stdcall).

what do cdecl and stdcall mean?

>The interface should be specified at standard C level (as more-or-less

absolutely! this has been the basic principle behind every API i have
seen that has good multi-language support. why C? because the ABI is
standard (at least within a single platform).

>everything can interface with that) but we should consider SDK support for
>other popular development environments (Delphi from a "today" point of
>view, Java/ObjectiveC/C# from a "tomorrow" point of view depending on how
>compilers and processor speeds develop and what platforms GMPI finds
>itself on).

if you look at GTK+ (a GUI toolkit), i think it shows a good path to
follow. the API is in C, but language bindings have been contributed
by many others over the years. there are now bindings for more or less
any language you can name (except VB :): C++, python, ADA, ruby, perl,
and many others.

it would not have been possible to do this if the API were
specified+implemented in anything except C (or asm, i guess).

>Is this the time to start talking about actual interface code conventions
>(dispatchers, function pointers.......) or are we leaving that can of
>worms for later?

i suspect we can leave those details till later, but i would like to
propose that the API follows a simple rule: ANSI C and nothing
else. That means that the API itself cannot contain any
platform-specific stuff, nor require anything from libraries that is
not part of the ANSI C runtime standard. a plugin using GMPI and
written in C will not require any code from anywhere except the
standard C library. 

i would actually like it if this rule could be enforced in the sense
that plugins with DLL's containing symbols that are not part of GMPI
and/or the standard C library should be rejected by a host. i doubt
that we can do this however.

--p

----------------------------------------------------------------------
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: