Message-ID: From: Shawn Hargreaves To: djgpp AT delorie DOT com Cc: ug98008 AT ee DOT ucl DOT ac DOT uk Subject: Re: Portable Plugins Date: Tue, 2 Nov 1999 16:34:59 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: djgpp AT delorie DOT com Ali Ahmad Siddiqui writes: > Does ne1 know a way of implementing plugins(code modules that can be > accessed by the host application) in ansii C++(or with support of > most compilers includin djgpp) so that all code works with all all > compilers with preferebly the main programe not having to be > recompiled each time. Do you mean portable so that you can recompile your program with any compiler, or so that you can use modules built with one compiler alongside a program built using another? Not that it makes all that much difference which you meant, because I'm afraid there is no entirely portable way to do this. For djgpp programs, you could use the DXE system, which is simple and efficient. It is very low level, though, only giving you a single entrypoint into the loadable module, so if you want to share many variables and functions, it is up to you to transfer pointers to these, and write your code to do all the referencing through those pointers. There are some other dynamic linking systems for djgpp that are more complete, but none of these systems are portable to other compilers. For Windows programs, you could use a DLL, which can be both produced and used by any competent Windows compiler. This is quite a flexible and easy to use system, but only works for Windows programs (loading a DLL requires a great deal of support from the OS). Alternatively you could roll your own relocation system. For example you might want to look at how VBE/AF drivers work: that is an official VESA standard that defines a block of 32 bit x86 code, with a header describing how to load it into memory, relocate it, and call functions from it. When the FreeBE/AF project (http://www.talula.demon.co.uk/freebe/) wanted to write some drivers in this format, we had to figure out a way to generate binaries in this format, and ended up modifying the DXE system to do this. The resulting process is quite closely tied to djgpp, so we can't compile the FreeBE/AF drivers with any other compiler, but the actual binaries are very portable. Take a look at the vbeaf.c file from Allegro: this same source can load and use the drivers in the djgpp, Watcom, and Linux versions, and could easily do this for any other C compilers that we needed. Yet another option is to forget binary modules altogether, and do your plugins at the source level. This obviously only works if you are distributing source code, but is very flexible and portable. Allegro uses this system for the grabber program, where other packages can place .c and .inc files into the tools/plugins directory. The Allegro makefile arranges for all of those .inc files to be included inside the init function in datedit.c, and links all the .c files into the program (see tools/plugins/plugins.txt for a full explanation of how all this works). This system seems to be working quite well, and several people have used it to add new features to the grabber (for example import/export for additional file types, and a tracker that can both import and play mod files). This system automatically works with any C compiler at all, and is far more flexible than binary module loading, since the plugins have direct access to the entire namespace of the main program. Shawn Hargreaves.