RE: Dynamic Modules under NT
-----Original Message-----
From: Craig Lanning [mailto:CraigL＠DyCon.com]
Sent: Saturday, June 03, 2000 11:48 AM
To: Andrew Begel
Cc: 'xemacs-nt(a)xemacs.org'; 'xemacs-beta(a)xemacs.org'; Marat
Boshernitsan
Subject: Re: Dynamic Modules under NT
>There are three ways to make XEmacs compile on Windows: gcc
with cygwin, gcc
>no cygwin, and MSVC++. I've gotten all three to work, though
I prefer gcc no
>cygwin and MSVC++, since that allows one to use DLLs
>Now, the more annoying bits. In order to compile DLLs for
Windows, you need
>to resolve all symbols at static link time. This means if a DLL needs
>symbols from the application which is loading it, those
symbols must be
>munged into an import library for the DLL to link with. In
addition, those
>same symbols must be munged into an export library for the
application to
>link with. Yes, that's right, temacs needs to be linked with
an export
>library that must "predict" what symbols any DLL might use.
The normal way to make this work would be to define an API that looks
something like this:
1. Each DLL is required to export a set of specific functions with
specific names so that the loading application (XEmacs in
this case) can
hook everything up.
This is all taken care of by the standardized XEmacs dynamic-module
interface. Dynamic modules must define several functions and constants for
Xemacs to find it and properly load it. These must be exported from the DLL,
so it wouldn't be too hard to create a .h file (with ellcc or make the user
do it) with
#if defined(WIN32) && defined(HAVE_SHLIB)
#define EXPORT __declspec(dllexport)
#define IMPORT __declspec(dllimport)
#else
#define EXPORT
#define IMPORT
#endif
(or put that in symdll.h or somewhere nice).
Then make the user put EXPORT in front of all of these standard symbols
(defs_of_<module>, syms_of_<module>, etc.)
2. Each DLL can expect the application (XEmacs in this case)
to export a
set of specific functions with specific names so that the DLL can gain
access to those aspects of the application that it needs.
I needed these:
Qt DATA
message
defsubr
dumpopaque
Qnil DATA
staticpro
defvar_magic
assert_failed
make_uninit_string
Fbuffer_substring
Fcons
Ffind_face
Fintern
alloc_lcrecord
gcprolist DATA
print_readably DATA
signal_simple_error
write_c_string
boolean_specifier_methods DATA
display_table_specifier_methods DATA
image_specifier_methods DATA
integer_specifier_methods DATA
generic_specifier_methods DATA
natnum_specifier_methods DATA
toolbar_specifier_methods DATA
lrecord_implementations_table DATA
lrecord_markers DATA
lrecord_type_count DATA
As you can see, some of them are symbols, some are functions...
You need a macro like this:
#if defined(WIN32) && defined(HAVE_SHLIB)
#ifdef BUILDING_XEMACS
#define EXTERNAL __declspec(dllexport)
#endif
#ifdef BUILDING_MODULE
#define EXTERNAL __declspec(dllimport)
#endif
#if defined(BUILDING_XEMACS) && defined(BUILDING_MODULE)
#error "BUILDING XEMACS and BUILDING_MODULE both defined!"
#endif
#if !defined(BUILDING_XEMACS) && !defined(BUILDING_MODULE)
#define EXTERNAL
#endif
#else
#define EXTERNAL
#endif
and then put EXTERNAL in front of all Xemacs symbols and functions that
potentially may be used by dynamic modules. Since I couldn't hope to guess
what a module may or may not use, I'd just as soon as put EXTERNAL in front
of every non-static symbol.
If you do this, you won't need to define the export library for XEmacs (just
#define BUILDING_XEMACS), though you will still need the import library for
compiling the DLL (where you'll #define BUILDING_MODULE).
andy
These kinds of mechanisms eliminate the need to do what you
describe below.
From your description, I suspect that some significant work
needs to be
done with regard to defining the API.
What would be extremely useful is if you could make a list of
the kinds of
things that you need access to in the application and another
list of the
kinds of things that you expect to provide to the
application. This kind
of information would be useful in beginning the definition of the API.
Craig Lanning