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: &#39;xemacs-nt(a)xemacs.org&#39;; &#39;xemacs-beta(a)xemacs.org&#39;; 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 >