Mail Archives: djgpp/1999/11/02/13:59:24
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.
- Raw text -