12:30 a.m.
-----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
3:48 a.m.
New subject: Dynamic Modules under NT
Andrew Begel wrote:
> -----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.
this is not really a good idea. the basic problem here is that the xemacs
developers would like to have freedom to change the internal api whenever they
want, and this becomes problematic with random code around that might use any
function.
what i'd rather happen is to provide a limited api to modules, principally to
allow them access to the allocation system, and then provide a specific function
that they can use to call Lisp functions, including primitives defined in C.
global variables should for the most part not be exported at all; with the
proper higher-level functions, this should be mostly unnecessary in any case.
would you be interested in helping design such an api?
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
>
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/
7:55 a.m.
New subject: Dynamic Modules under NT
On 6/5/2000 7:48 PM, Ben Wing at ben(a)666.com wrote:
this is not really a good idea. the basic problem here is that the
xemacs
developers would like to have freedom to change the internal api whenever they
want, and this becomes problematic with random code around that might use any
function.
what i'd rather happen is to provide a limited api to modules, principally to
allow them access to the allocation system, and then provide a specific
function
that they can use to call Lisp functions, including primitives defined in C.
global variables should for the most part not be exported at all; with the
proper higher-level functions, this should be mostly unnecessary in any case.
would you be interested in helping design such an api?
I understand why that'd be a bad thing. I don't have time to work on this
kind of API (for my purposes, I can just export the symbols I need), though
I can imagine what it could need pretty easily.
Actually, my latest project points to another area where the current
mechanism is unsuitable for extension: the WndProc for XEmacs under Windows.
I needed to add some callbacks for a project I'm working on, but there's no
mechanism to extend the switch statement in the MSW wndproc found in
event-msw.c. There should be a way to add tags into here (through some
event-hook mechanism) so extensions can do things at event-handling time
without directly modifying this code in the XEmacs source.
Andrew
8746
days inactive
8748
days old
2 comments
3 participants
participants (3)
-
Andrew Begel -
Andrew Begel -
Ben Wing