Re: Dynamic Modules under NT
At 02:48 PM 6/2/00 -0700, Andrew Begel wrote:
I've successfully modified XEmacs 21.2.34 to load dynamic modules
under
Windows NT.
Excellent!
My efforts point to some changes that need to be made to XEmacs to
make this
a real workable
solution.
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 compiled by any Windows
C compiler to be used with Emacs (if you use the cygnus cygwin library in
any piece of the application, you break any code that depends on MSVCRT.dll
that pretty much everything not compiled with gcc/cygwin depends on.)
I usually build using the "gcc no cygwin" method.
Anyway, here is a list of my changes:
1. for gcc no cygwin, I changed the config.guess script to return
${UNAME_MACHINE}-pc-mingw32 when it finds cygwin. I'm sure there's some way
to force the configure script to assume this, but this was the easiest way
for me.
This is unnecessary since the normal way to build with no cygwin it to call
configure like this:
./configure i586-pc-mingw32
2. added "-I/usr/local/mingw/include -mno-cygwin" to
xe_cppflags in
configure.
added "-L/usr/local/mingw/lib -mno-cygwin" to xe_ldflags in configure.
These two lines convince gcc that it's compiling for no-cygwin. It may
just be voodoo to put
them here, but it can't hurt to have the configure script also realize
it's not supposed to
use cygwin.
These, too, get taken care of by calling configure like above.
3. Changed nt/config.h to have the line #define HAVE_SHLIB
This one I'll have to look into.
4. Added $(SRC)\emodules.c to DOC_SRC2, and $(SRC)\sysdll.c to
DOC_SRC5 in
nt/xemacs.mak.
Added $(OUTDIR)\emodules.obj and $(OUTDIR)\sysdll.obj to TEMACS_OBJS in
nt/xemacs.mak.
ditto.
5. Added #include <windows.h> in the _WINDOWS/WIN32 section of
sysdll.c. It
was missing.
ditto.
----
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.
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.
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