>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