Menu
▾
▴
mingw-users
|
From: Stefan B. <sb...@sb...> - 2005-10-29 09:37:39
|
Coming from the GNU/Linux side and now having to port my application across to Windows, I have two fundamental questions in understanding DLLs opposed to shared objects (.so) under GNU/Linux. 1) If I have global variables in a DLL (ie. the DLL is not stateless) and several applications make use of the DLL simultaneously, do they operate on the same data or has each application an own instance of the DLL's global data? I hope the latter is the case. 2) On GNU/Linux, I have one project where one shared object refers back to symbols of the main application. When linking that .so file with gcc -shared, that's no problem. When linking the main application, the library is given on the command line with the -L/-l switches and linking works. The undefined references from the .so are resolved using the main application. Now, when trying to build the same on Windows (using gcc -shared as well), the DLL doesn't even build but throws errors of "undefined references". I want those to get resolved when linking against the main application. Is such a set-up not possible on Windows? Can't symbols in a DLL refer back to the main application? (And yes, I know that I can have a register function and let the DLL know the functions of the main applications via callbacks, but that's not what I want.) -- Stefan Bellon |
|
From: Michael G. <mg...@te...> - 2005-10-29 17:06:35
|
> 1) If I have global variables in a DLL (ie. the DLL is not stateless) > and several applications make use of the DLL simultaneously, do they > operate on the same data or has each application an own instance of > the DLL's global data? I hope the latter is the case. Each application has it's own local copy. You have to use shared memory if you wish to share data among applications (or whatever other means you prefer). > 2) On GNU/Linux, I have one project where one shared object refers back > to symbols of the main application. When linking that .so file with > gcc -shared, that's no problem. When linking the main application, > the library is given on the command line with the -L/-l switches and > linking works. The undefined references from the .so are resolved > using the main application. >=20 > Now, when trying to build the same on Windows (using gcc -shared as > well), the DLL doesn't even build but throws errors of "undefined > references". I want those to get resolved when linking against the > main application. Is such a set-up not possible on Windows? It is possible. I no longer remember the details but earlier this year there had been a discussion on dynamic linking which also dealt with this very problem (and presented a solution). Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
|
From: Tor L. <tm...@ik...> - 2005-10-29 23:47:47
|
> 2) On GNU/Linux, I have one project where one shared object refers
> back to symbols of the main application. [...] Now, when trying to
> build the same on Windows (using gcc -shared as well), the DLL
> doesn't even build but throws errors of "undefined references". I
> want those to get resolved when linking against the main
> application. Is such a set-up not possible on Windows?
It is possible, but it is not as flexible as on ELF-based systems like
Linux. Firstly, you must mark the function in the main .exe that you
want to access from a DLL for export using
__declspec(dllexport). Then, there are two possibilities how to
actually access the functions from the DLL:
1) you can create an import library for the foo.exe using a foo.def
file like this:
EXPORTS
some_function_in_main
and dlltool:
dlltool --input-def foo.def --output-lib libfoo.a --dllname foo.exe
Then link the DLL with libfoo.a.
This has the disadvantage that the .exe really has to be called
*exactly* foo.exe. This might be a disadvantage.
2) Look up the symbol at runtime. Read up on GetProcAddress() and
GetModuleHandle().
--tml
|
|
From: Stefan B. <sb...@sb...> - 2005-10-30 10:34:25
|
Tor Lillqvist wrote: > > 2) On GNU/Linux, I have one project where one shared object refers > > back to symbols of the main application. [...] Now, when trying to > > build the same on Windows (using gcc -shared as well), the DLL > > doesn't even build but throws errors of "undefined references". I > > want those to get resolved when linking against the main > > application. Is such a set-up not possible on Windows? > It is possible, but it is not as flexible as on ELF-based systems like > Linux. Firstly, you must mark the function in the main .exe that you > want to access from a DLL for export using > __declspec(dllexport). Then, there are two possibilities how to > actually access the functions from the DLL: > 1) you can create an import library for the foo.exe using a foo.def > file like this: [snip] > dlltool --input-def foo.def --output-lib libfoo.a --dllname > foo.exe > Then link the DLL with libfoo.a. Ok, I see. However, this doesn't work if the foo.exe itself depends on the DLL. So, circular dependencies are impossible, correct? > 2) Look up the symbol at runtime. Read up on GetProcAddress() and > GetModuleHandle(). And how would I link the DLL itself using this second approach? -- Stefan Bellon |
|
From: Brian D. <br...@de...> - 2005-10-30 12:47:31
|
Stefan Bellon wrote:
> > Then link the DLL with libfoo.a.
>
> Ok, I see. However, this doesn't work if the foo.exe itself depends on
> the DLL. So, circular dependencies are impossible, correct?
Actually it's the other way around. If the .exe does not import from
the .dll (like for example, the .dll is a plug-in of some sort and is
dynamically loaded at runtime) then you can just link the .exe normally
and use -Wl,-out-implib,libfoo.a during link to just create the import
library for the .exe without the need to create a .def file.
It's only in the case that there is a circular dependency at link-time
that you have to create the .def file. So you create the import library
for the .exe, then you link the .dll against that import library (and
use -Wl,-out-implib to generate the import library for the .dll) and
then you link the .exe using the .dll's import library.
The key point here, as pointed out in the earlier reply, is that if you
do this the name of the .exe is hard-coded into the .dll, and so the
.dll ceases to be a general purpose library and can only ever be used
with that .exe. This is analogous to saying that when you link an .exe
that imports from a given .dll, it hard-codes the name of that .dll into
the .exe, which will refuse to run if the .dll cannot be located. But
that's the behavior everyone expects, not so much the reverse.
For this reason it's somewhat considered bad design on Windows to import
from the .exe in a .dll. It will work, but it's not a very pretty
situation. The way it's supposed to work is that you factor out
everything in the .exe that needs to be accessed from both the .exe and
from the .dll, and make that into its own .dll. Then both the .exe and
the original .dll import from this .dll. Or, do run-time linking
instead.
> > 2) Look up the symbol at runtime. Read up on GetProcAddress() and
> > GetModuleHandle().
>
> And how would I link the DLL itself using this second approach?
If you use GetProcAddress then you are doing run-time (sometimes called
dynamic) linking - the analogy to dlopen()/dlsym() on *nix. This means
that all calls to imported routines go through function pointers and
there are no symbols to resolve at link-time, because the linker has no
knowledge of what you're doing. Example (without any error checking):
int (*funcpointer) (void);
HMODULE hm = LoadLibrary ("foo.dll");
funcpointer = GetProcAddress (hm, "some_func");
int result = funcpointer ();
In this example the linker has no idea that you are importing
some_func() from foo.dll, so there is no need for an import library or
even for foo.dll to exist.
In the case of importing from an .exe, you don't need to use
LoadLibrary() since the .exe is already loaded, and the HMODULE has to
be that of the .exe, which you get from GetModuleHandle (NULL). [I
think...]
Brian
|
|
From: Stefan B. <sb...@sb...> - 2005-10-30 13:02:16
|
Brian Dessent wrote: > Stefan Bellon wrote: > > Ok, I see. However, this doesn't work if the foo.exe itself depends > > on the DLL. So, circular dependencies are impossible, correct? [snip] Thanks, this is _very_ valuable information. > > > 2) Look up the symbol at runtime. Read up on GetProcAddress() and > > > GetModuleHandle(). > > > > And how would I link the DLL itself using this second approach? > If you use GetProcAddress then you are doing run-time (sometimes > called dynamic) linking - the analogy to dlopen()/dlsym() on *nix. > This means that all calls to imported routines go through function > pointers and there are no symbols to resolve at link-time, because > the linker has no knowledge of what you're doing. Yes, I pretty much understand all of that. But in your example you assume the DLL "foo.dll" to exist. My question is: How do I _create_ this foo.dll? At present I cannot build the DLL because of undefined references back into the main program. So, even with this second approach originally mentioned I do have to create an import library for the main .exe in order to build that DLL at all. Right? -- Stefan Bellon |
|
From: Brian D. <br...@de...> - 2005-10-30 13:57:07
|
Stefan Bellon wrote: > Yes, I pretty much understand all of that. But in your example you > assume the DLL "foo.dll" to exist. My question is: How do I _create_ There are three scenarios that I can think of. A) The .exe links directly against the .dll, and the .dll uses GetProcAddress to access the symbols in the .exe. From the standpoint of the linker this is bog standard - creating the .dll does not depend on the .exe at all. gcc -shared foo.o -o foo.dll -Wl,--out-implib,libfoo.dll.a gcc main.o -o main.exe -lfoo B) The .exe uses LoadLibrary and GetProcAddress to load and access the .dll (such as in the case of a plugin that can be dynamically added/removed as necessary) and the .dll links directly against the .exe without using GetProcAddress. This is just the converse of the above, except that now creating the .exe does not depend on the .dll existing at all. gcc main.o -o main.exe -Wl,--out-implib,libmain.a gcc -shared foo.o -o foo.dll -lmain C) Both the .exe and the .dll link directly against each other; neither uses GetProcAddress. Here there is a circular dependency that you have to break by creating a .def file by hand and then using dlltool to turn that into an import library. You can create the .def file for either the .exe or the .dll - it really just depends on which has the more complex set of exports, and how your build is structured. Let's assume for the example you choose to write the .exe's .def file by hand, but you can just as well do it the opposite way. # create main.def dlltool --input-def main.def --output-lib libmain.a --dllname main.exe gcc -shared foo.o -o foo.dll -lmain -Wl,--out-implib,libfoo.dll.a gcc main.o -o main.exe -lfoo Note that in B) and C) you hardcode the name of the .exe into the .dll, so it can only ever be used with that .exe and not as a general purpose library. In all three cases you need __declspec(dllexport) on the symbols in main. Brian |
|
From: Stefan B. <sb...@sb...> - 2005-10-31 23:15:52
|
Brian Dessent wrote: > B) The .exe uses LoadLibrary and GetProcAddress to load and access > the .dll (such as in the case of a plugin that can be dynamically > added/removed as necessary) and the .dll links directly against the > .exe without using GetProcAddress. This is just the converse of the > above, except that now creating the .exe does not depend on the .dll > existing at all. > gcc main.o -o main.exe -Wl,--out-implib,libmain.a > gcc -shared foo.o -o foo.dll -lmain Are you sure this works like you describe it? The man page of "ld" says that --out-implib only works when linking a DLL (i.e. -shared). And in fact, the version of gcc that I have here seems to agree: --out-implib is simply ignored when linking an executable. -- Stefan Bellon |
|
From: Brian D. <br...@de...> - 2005-11-01 02:16:51
|
Stefan Bellon wrote:
> Are you sure this works like you describe it? The man page of "ld" says
> that --out-implib only works when linking a DLL (i.e. -shared). And in
> fact, the version of gcc that I have here seems to agree: --out-implib
> is simply ignored when linking an executable.
It works fine here:
$ cat main.c
#include <stdio.h>
int __declspec(dllexport) somefunc()
{
return 42;
}
int main()
{
printf("hello world\n");
}
$ gcc -c main.c
$ gcc main.o -o main.exe -Wl,-out-implib,libmain.a
Creating library file: libmain.a
$ ls -l main.* libmain*
-rw-r--r-- 1 brian None 1.4K Oct 31 18:09 libmain.a
-rwxr-xr-x 1 brian None 128 Oct 31 18:04 main.c
-rwxr-xr-x 1 brian None 9.7K Oct 31 18:09 main.exe
-rw-r--r-- 1 brian None 714 Oct 31 18:08 main.o
$ ./main
hello world
$ ld --version
GNU ld version 2.16.91 20050610
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
This is under Cygwin, but you get the same result if you pass
-mno-cygwin to gcc to signal mingw mode.
Brian
|
|
From: Stefan B. <sb...@sb...> - 2005-11-01 08:49:54
|
Brian Dessent wrote: > Stefan Bellon wrote: > > Are you sure this works like you describe it? The man page of "ld" > > says that --out-implib only works when linking a DLL (i.e. > > -shared). And in fact, the version of gcc that I have here seems to > > agree: --out-implib is simply ignored when linking an executable. > It works fine here: [snip] Ah, you are right. It works for C, but it does not work if the main program is written in Ada. -- Stefan Bellon |
|
From: Stefan B. <sb...@sb...> - 2005-11-03 06:33:52
|
Chris Douty wrote: [gnatbind, pragma Export, ...] Yes, thanks a lot for this information. I'm aware of all of it because I make heavily use of those features already. But unfortunately it's not the solution to my present problem. -- Stefan Bellon |
|
From: John B. <joh...@ho...> - 2005-10-30 13:02:07
|
> > 1) you can create an import library for the foo.exe using a foo.def > > file like this: [snip] > > Then link the DLL with libfoo.a. >Ok, I see. However, this doesn't work if the foo.exe itself depends on >the DLL. So, circular dependencies are impossible, correct? I don't know. > > 2) Look up the symbol at runtime. Read up on GetProcAddress() and > > GetModuleHandle(). > >And how would I link the DLL itself using this second approach? > Use your normal command line to generate the DLL. In the DLL, you will use the function pointer returned by GetProcAddress to call the functions that live in foo.exe. |
|
From: Danny S. <dan...@cl...> - 2005-11-01 18:03:20
|
----- Original Message -----
From: "Stefan Bellon"
Sent: Tuesday, 1 November 2005 21:49
> Brian Dessent wrote:
> > Stefan Bellon wrote:
>
> > > Are you sure this works like you describe it? The man page of "ld"
> > > says that --out-implib only works when linking a DLL (i.e.
> > > -shared). And in fact, the version of gcc that I have here seems to
> > > agree: --out-implib is simply ignored when linking an executable.
>
> > It works fine here:
>
> [snip]
>
> Ah, you are right. It works for C, but it does not work if the main
> program is written in Ada.
>
Don't you have to hardcode this into a pragma in Ada?
pragma Linker_Options ("-out-implib libfoo.a");
A bug report about gnatlink's failure to honour target flags was opened here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20530
and closed as invalid,
Danny
> --
> Stefan Bellon
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
|
|
From: Stefan B. <sb...@sb...> - 2005-11-02 20:58:38
|
Danny Smith wrote:
> Don't you have to hardcode this into a pragma in Ada?
> pragma Linker_Options ("-out-implib libfoo.a");
No, the -Wl,--out-implib,libfoo.a is indeed passed to the linker. But
it looks like it only has an effect if (in C) functions have been
marked with __declspec(dllexport). And Ada doesn't (to my knowledge)
have an equivalent and therefore no import library is created. :-(
--
Stefan Bellon
|
|
From: Danny S. <dan...@cl...> - 2005-11-02 22:51:08
|
> -----Original Message-----
> From: Stefan Bellon
> Sent: Thursday, November 03, 2005 9:58 AM
>
>
> Danny Smith wrote:
> > Don't you have to hardcode this into a pragma in Ada?
>
> > pragma Linker_Options ("-out-implib libfoo.a");
>
> No, the -Wl,--out-implib,libfoo.a is indeed passed to the linker. But
> it looks like it only has an effect if (in C) functions have been
> marked with __declspec(dllexport).
As alternative you could provide a main.def file as linker input to
specify the dllexports from your main.exe, eg
;main.def
NAME main.exe
EXPORTS
from_main
Or add -Wl,--export-all.
The other way is to not bother with an import lib for main.exe but
specify yout imports from main in a def file for the dll build, eg
;dll.def
LIBRARY my_dll.dll
RXPORTS
foo
doo
dah
IMPORTS
; [ <internal-name> = ] <module-name> . <external-name>
from_main = main.exe.from_main
when building dll, add dll.def to input files
gcc -shared -omy_dll.dll -Wl,--out-implib,libmy_dll.dll.a dll.def
dllmod.o
This way is actually simpler. Since the def file will resolve the
imports from main, you could build the dll and its implib at same time,
rather thn chase circular dependencies between main and the dll
Unfortunately the use of IMPORTS statement is not well documented and I
do not think it is compatible with MSVC
Danny
And
> Ada doesn't (to my knowledge) have an equivalent and therefore no
> import library is created. :-(
>
> --
> Stefan Bellon
>
|
|
From: Greg C. <chi...@co...> - 2005-11-02 23:21:52
|
On 2005-11-2 22:51 UTC, Danny Smith wrote:
>
> ;dll.def
> LIBRARY my_dll.dll
> RXPORTS
> foo
> doo
> dah
> IMPORTS
> ; [ <internal-name> = ] <module-name> . <external-name>
> from_main = main.exe.from_main
>
> Unfortunately the use of IMPORTS statement is not well documented and I
> do not think it is compatible with MSVC
I had used that technique about ten years ago to interface an
ms-built third-party closed-source dll to a borland compiler:
IMPORTS
_SSAttach =VTSSDL32.SSAttach
and I think I learned it from one of those old Petzold books.
Of course, ms may have stopped documenting it or even
supporting it since. Hmm...looks like someone may have
scanned an old copy:
http://the.wall.riscom.net/books/win/petzbook/PART5_19.TXT
I won't quote from it here because I'm not sure whether it
poses copyright issues, but it does document IMPORTS, and
it was published by ms, I'd guess in the MSC version 5.0 era.
Which was the last time I used an ms compiler, so...I don't
say it often enough, but thanks for MinGW.
|
|
From: Stefan B. <sb...@sb...> - 2005-11-03 11:58:45
|
Danny Smith wrote: > ;dll.def > LIBRARY my_dll.dll > RXPORTS > foo > doo > dah > IMPORTS > ; [ <internal-name> = ] <module-name> . <external-name> > from_main = main.exe.from_main > when building dll, add dll.def to input files > gcc -shared -omy_dll.dll -Wl,--out-implib,libmy_dll.dll.a dll.def > dllmod.o That's a nice idea. I've set up a small .def file which contains all the symbols that I want to import from the main.exe and use inside the DLL: ;main.def LIBRARY _main.dll IMPORTS a_func = main.exe.a_func b_func = main.exe.b_func Then I build the DLL like this: gcc -shared -o _main.dll main.def file1.o file2.o ... The DLL builds fine then. But when I (or rather the Python interpreter) want to load the DLL, then the following error message is raised: DLL load failed with error code 193 What does this mean? Did I misunderstand anything? -- Stefan Bellon |
|
From: Luke D. <cod...@ho...> - 2005-11-03 14:36:05
|
----- Original Message ----- From: "Stefan Bellon" <sb...@sb...> To: <min...@li...> Sent: Thursday, November 03, 2005 7:06 PM Subject: [Mingw-users] Re: Generic DLL questions > Danny Smith wrote: > >> ;dll.def >> LIBRARY my_dll.dll >> RXPORTS >> foo >> doo >> dah >> IMPORTS >> ; [ <internal-name> = ] <module-name> . <external-name> >> from_main = main.exe.from_main > >> when building dll, add dll.def to input files > >> gcc -shared -omy_dll.dll -Wl,--out-implib,libmy_dll.dll.a dll.def >> dllmod.o > > That's a nice idea. > > I've set up a small .def file which contains all the symbols that I > want to import from the main.exe and use inside the DLL: > > ;main.def > LIBRARY _main.dll > IMPORTS > a_func = main.exe.a_func > b_func = main.exe.b_func > > Then I build the DLL like this: > > gcc -shared -o _main.dll main.def file1.o file2.o ... > > The DLL builds fine then. But when I (or rather the Python interpreter) > want to load the DLL, then the following error message is raised: > > DLL load failed with error code 193 > > What does this mean? Did I misunderstand anything? > > -- > Stefan Bellon What are you trying to do? If your DLL is being loaded by one executable (python.exe I assume), how does it make sense to import symbols from a different .exe? Luke |
|
From: Stefan B. <sb...@sb...> - 2005-11-03 16:31:58
|
Luke Dunstan wrote: > What are you trying to do? If your DLL is being loaded by one > executable (python.exe I assume), how does it make sense to import > symbols from a different .exe? I develop an application (written in Ada) to which I added a Python interpreter because I want to make it possible to "script" the application via Python. In order to generate the binding to Python, I'm using SWIG (http://www.swig.org/). SWIG's idea is, that the Python interpreter loads (via an import command) a Python file which itself loads a DLL. This DLL provides the commands of the main exe that can be called via the Python scripting. On the Ada side, those functions that can be called from the script, are exported with pragma Export to C. The static link-time dependency is only from the DLL to the main exe, but not otherwise. The other dependency is run-time and established via the Python interpreter, so there's no static cyclic dependency. This setup works straight out of the box on GNU/Linux. But I'm having endless trouble on Windows. -- Stefan Bellon |
|
From: Brian E. <be...@me...> - 2005-11-04 08:03:09
|
Stefan Bellon <sb...@sb...> writes: > using SWIG (http://www.swig.org/). SWIG's idea is, that the Python > interpreter loads (via an import command) a Python file which itself > loads a DLL. This DLL provides the commands of the main exe that can be > called via the Python scripting. On the Ada side, those functions that > can be called from the script, are exported with pragma Export to C. This is indeed an interesting thread. To fully understand your problems: Why is it that your main.exe cannot be a dll? -- Brian (remove the sport for mail) http://www.et.web.mek.dtu.dk/Staff/be/be.html http://www.rugbyklubben-speed.dk |
|
From: Stefan B. <sb...@sb...> - 2005-11-04 16:48:01
|
Brian Elmegaard wrote: > Stefan Bellon <sb...@sb...> writes: > > using SWIG (http://www.swig.org/). SWIG's idea is, that the Python > > interpreter loads (via an import command) a Python file which > > itself loads a DLL. This DLL provides the commands of the main exe > > that can be called via the Python scripting. On the Ada side, those > > functions that can be called from the script, are exported with > > pragma Export to C. > This is indeed an interesting thread. To fully understand your > problems: Why is it that your main.exe cannot be a dll? Because main.exe uses GtkAda and it's currently not possible to make a DLL that uses GtkAda on Windows. -- Stefan Bellon |
|
From: Danny S. <dan...@cl...> - 2005-11-03 20:04:20
|
From: "Stefan Bellon" Sent: Friday, 4 November 2005 05:31 > > I develop an application (written in Ada) to which I added a Python > interpreter because I want to make it possible to "script" the > application via Python. In order to generate the binding to Python, I'm > using SWIG (http://www.swig.org/). SWIG's idea is, that the Python > interpreter loads (via an import command) a Python file which itself > loads a DLL. This DLL provides the commands of the main exe that can be > called via the Python scripting. On the Ada side, those functions that > can be called from the script, are exported with pragma Export to C. > > The static link-time dependency is only from the DLL to the main exe, > but not otherwise. The other dependency is run-time and established via > the Python interpreter, so there's no static cyclic dependency. > error 193 is ERROR_BAD_EXE_FORMAT How did you build your main.exe. This error could happen if you built your main.exe with -shared or -mdll option. Those options set the preferred base address of the exe to 0x10000000 (in dll address space) as well as flagging exe characteristic as DLL Danny |
|
From: Stefan B. <sb...@sb...> - 2005-11-03 21:16:53
|
Danny Smith wrote: > From: "Stefan Bellon" [snip] > > The static link-time dependency is only from the DLL to the main > > exe, but not otherwise. The other dependency is run-time and > > established via the Python interpreter, so there's no static cyclic > > dependency. > > > error 193 is ERROR_BAD_EXE_FORMAT Oops? :-/ BTW: Where is this error code explained? > How did you build your main.exe. This error could happen if you built > your main.exe with -shared or -mdll option. Those options set the > preferred base address of the exe to 0x10000000 (in dll address > space) as well as flagging exe characteristic as DLL I have neither supplied -shared nor -mdll when building the exe (I used gnatmake and that doesn't set -shared or -mdll when building an executable AFAICT). And besides, main.exe works fine as executable on its own. Is there some debugging tool which displays those flags in order to make sure? -- Stefan Bellon |
|
From: Brian D. <br...@de...> - 2005-11-03 22:04:05
|
Stefan Bellon wrote: > BTW: Where is this error code explained? http://msdn.microsoft.com/library/en-us/debug/base/system_error_codes.asp > its own. Is there some debugging tool which displays those flags in > order to make sure? Under the "Characteristics" header of objdump -p it will list "DLL" if that bit is set in the pe header. Brian |
|
From: Stefan B. <sb...@sb...> - 2005-11-03 22:38:27
|
Brian Dessent wrote: > Stefan Bellon wrote: > > BTW: Where is this error code explained? > http://msdn.microsoft.com/library/en-us/debug/base/system_error_codes.asp Thanks, very much appreciated. > > its own. Is there some debugging tool which displays those flags in > > order to make sure? > Under the "Characteristics" header of objdump -p it will list "DLL" if > that bit is set in the pe header. Wow, that's interesting information. :-) No, the main.exe does _not_ have DLL set: main.exe: file format pei-i386 Characteristics 0x106 executable line numbers stripped 32 bit words Time/Date Thu Nov 3 08:59:53 2005 ImageBase 00400000 SectionAlignment 00001000 FileAlignment 00000200 MajorOSystemVersion 4 MinorOSystemVersion 0 MajorImageVersion 1 MinorImageVersion 0 MajorSubsystemVersion 4 MinorSubsystemVersion 0 Win32Version 00000000 SizeOfImage 01fb8000 SizeOfHeaders 00000400 CheckSum 024f6228 Subsystem 00000003 (Windows CUI) DllCharacteristics 00000000 SizeOfStackReserve 02000000 SizeOfStackCommit 00001000 SizeOfHeapReserve 00100000 SizeOfHeapCommit 00001000 LoaderFlags 00000000 NumberOfRvaAndSizes 00000010 [ ... and so on, please ask for more of this output if it helps ... ] Then I had a look at the DLL that uses the library definition file to refer to that exe. Remember, the library definition file looks like this: ;main_dll.def LIBRARY _main.dll IMPORTS a_func = main.exe.a_func And the objdump -p output of the _main.dll looks like this: _main.dll: file format pei-i386 Characteristics 0x2106 executable line numbers stripped 32 bit words DLL Time/Date Thu Nov 3 09:22:23 2005 ImageBase 10000000 SectionAlignment 00001000 FileAlignment 00000200 MajorOSystemVersion 4 MinorOSystemVersion 0 MajorImageVersion 1 MinorImageVersion 0 MajorSubsystemVersion 4 MinorSubsystemVersion 0 Win32Version 00000000 SizeOfImage 0011e000 SizeOfHeaders 00000400 CheckSum 00125af4 Subsystem 00000003 (Windows CUI) DllCharacteristics 00000000 SizeOfStackReserve 00200000 SizeOfStackCommit 00001000 SizeOfHeapReserve 00100000 SizeOfHeapCommit 00001000 LoaderFlags 00000000 NumberOfRvaAndSizes 00000010 [snip] There is an import table in .idata at 0x10008000 The Import Tables (interpreted .idata section contents) vma: Hint Time Forward DLL First Table Stamp Chain Name Thunk 00008000 00008068 00000000 00000000 0000868c 00008174 [snip] 0000803c 00008168 00000000 00000000 00008780 00008274 DLL Name: main.exe vma: Hint/Ord Member-Name Bound-To 8658 0 a_func So, here can be seen that the _main.dll indeed refers to the main.exe in order to get at a_func. However, I'm not sure whether everything else is right. Perhaps somebody does notice something which is wrong? -- Stefan Bellon |
Thanks for helping keep SourceForge clean.
X