There's stuff in scripts/OS2 which Alexander wrote to do
similar things for OS/2.
Can it be reused ?
Danny
On Wed, 2004-06-02 at 00:26, Dave Williss wrote:
> After doing a little more research into .def files, it appears we could
> use one to export all of the functions. However, according to the
> MSDN documentation...
>
> "Note that when you export a variable from a DLL with a .def file, you do
> not need to specify __declspec(dllexport) on the variable. However, in any
> file that uses the DLL, you must still use __declspec(dllimport) on the
> declaration of data."
>
> So in other words, we may only need to add the XMLIBEXPORT to
> the variables like xmArrowButtonWidgetClass. And we'd still have to
> create a file listing all the functions to export.
>
> Still a pain, but maybe less pain than adding an XMLIBEXPORT line
> to every function and vairable that needs to be exported..
>
> ----- Original Message -----
> From: "Dave Williss" <[EMAIL PROTECTED]>
> To: "Danny Backx" <[EMAIL PROTECTED]>
> Sent: Tuesday, June 01, 2004 9:25 AM
> Subject: Re: [Lesstif] Exporting functions from DLLs in Windows
>
>
> > The XMLIBEXPORT gets defined to be either __declspec(dllimport)
> > or __declspec(dllexport) (or just exern if not compiling on Windows)
> >
> > When building the library, dllexport tells the compiler/linker
> > to actually make the symbol visible outside the dll. Without it, its as
> > if the entire dll is one module and all the functions are static.
> > You can accomplish almost the same thing as dllexport by creating a
> > .def file which lists all the functions to export and passing that to the
> > linker. This, however has other limitations that I'll explain later.
> >
> > When an include file is used by code that will eventually link to the dll
> > and pull functions from it, the dllimport tells the compiler that the
> > function
> > will be coming from a dll, which causes it to behave slightly differently.
> > I believe in the past it had to generate a small wrapper function that
> > would lookup the function in the dll and call it indirectly. I don't
> think
> > they actually do this any more unless you mark the DLL as delay loaded,
> > in which case the wrapper loads the DLL if it hasn't already done so.
> >
> > The reason that the .def file is useless (unless I'm missing something) is
> > that when you export symbols from a dll, they get __imp__ prepended
> > to the names, and the linker knows what to do with this. If you don't
> have
> > __declspec(dllimport) in front of the prototypes when compiling code
> > that links to the dll, it won't know that and will look for functions
> > without
> > the __imp__. So you still have to put something in front of every
> prototype
> > that's to come out of a dll.
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Danny Backx" <[EMAIL PROTECTED]>
> > To: "Dave Williss" <[EMAIL PROTECTED]>
> > Cc: "LessTif Mailing List" <[EMAIL PROTECTED]>
> > Sent: Monday, May 31, 2004 4:19 AM
> > Subject: Re: [Lesstif] Exporting functions from DLLs in Windows
> >
> >
> > > I believe Alexander has been doing similar things for OS/2.
> > > I'll have a peek.
> > >
> > > I'm not too familiar with NT. I guess exporting symbols in
> > > this way makes a difference. Could you tell me exactly what
> > > it causes ?
> > >
> > > Danny
> > >
> > > On Fri, 2004-05-28 at 19:57, Dave Williss wrote:
> > > > I'm building lesstif as a dll on Windows and ran across a problem
> > > > which is tedious to fix but not very difficult. The include files
> > > > don't
> > > > export anything.
> > > >
> > > > To fix this, I added the following lines to Xm/Xm.h
> > > >
> > > > #ifdef WIN32
> > > > #ifdef XMDLL /* <-- Set this when compiling Lesstif as a
> > > > DLL */
> > > > #define XMLIBEXPORT __declspec(dllexport)
> > > > #else
> > > > #define XMLIBEXPORT __declspec(dllimport)
> > > > #endif
> > > > #else
> > > > #define XMLIBEXPORT extern
> > > > #endif
> > > >
> > > > I then went through all the include files and added XMLIBEXPORT
> > > > in front of every function that needs to be exported (and maybe some
> > > > that don't)
> > > >
> > > > Now I have a set of Xm include files which export functions from the
> > > > DLL, and when my applications include them, they know that the
> > > > functions
> > > > are to be imported from a DLL. This is unnecessary for gcc on Unix
> > > > machines, but necessary for Microsoft VC compiler on Windows.
> > > >
> > > > The logic on when XMLIBEXPORT is set to what may need to change.
> > > > It doesn't account for the possibility of static linking on Windows,
> > > > for
> > > > example.
> > > >
> > > > Once I had changed all the include files (unfortunately in a merged Xm
> > > > directory, not separated out by version like in the distribution) I
> > > > used
> > > > Araxis Merge to generate a diff report for the whole thing. This gave
> > > > a diff file for each changed file.
> > > >
> > > > I posted the report on our web site here...
> > > >
> > > > http://www.microimages.com/LesstifIncludeFileChanges/
> > > >
> > > > This is temporary. I'll take it down in a couple weeks.
> > > >
> > > > Comments about exporting symbols from the DLL are welcome.
> > > > If anybody has a better idea, let me know. If you'd like a better
> > > > form of diff, tell me know the command line parameters to standard
> > > > Unix diff to generate the output you'd like.
> > > >
> > > >
> > > > -- Dave Williss
> > > > ------
> > > > Meddle not in the affairs of dragons,
> > > > for you are crunchy and taste good with catsup
> > > --
> > > Danny Backx - danny.backx-at-skynet.be
> > >
> > > _______________________________________________
> > > Lesstif mailing list
> > > [EMAIL PROTECTED]
> > > https://terror.hungry.com/mailman/listinfo/lesstif
> >
>
> _______________________________________________
> Lesstif mailing list
> [EMAIL PROTECTED]
> https://terror.hungry.com/mailman/listinfo/lesstif
--
Danny Backx - danny.backx-at-skynet.be
_______________________________________________
Lesstif mailing list
[EMAIL PROTECTED]
https://terror.hungry.com/mailman/listinfo/lesstif
