[gmpi] Re: Topic 3: Cross platform
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 5 Mar 2003 11:16:14 -0500 (EST)
On Wed, 5 Mar 2003, Paul Davis wrote:
> >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.
agreed.
> secondly, calling 32->64 bit a "transition" is a bit of a
> misnomer.
well, it's a transition on the wintel/macos world.
> >> 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.
I think what Ron means here is that defining the interface in standard C
means the interface is supported under C++ with no code changes.
> supporting C++ requires a C++ runtime environment,
> which is not at all guaranteed to exist within the host.
Another one to mark down for "later"... module-sharing / runtime-sharing
between plugins and hosts that happen to be written in the same language..
something that needs to be thought about on some platforms.
> 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.
seconded.
> That means that the API itself cannot contain any
> platform-specific stuff
With one or two exceptions:- module-load time and GUI initialization (both
instantiation of GUI module, and setup of pipes to deliver GUI events
around the place). It may be that one or two platforms (e.g. Mac OS 9)
require an API section of their own to deal with GUI event piping.
> 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.
I think that's taking it too far. Plugins that interface to the GMPI
standard interface may still need platform specific code internal to
themselves for any number of reasons, and there may be reasons why a
vendor wishes to export this code to allow other of that vendor's code
modules to access them.
Regards,
Angus.
----------------------------------------------------------------------
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:
