I am creating a C++ wrapper for a Fortran function so I can use the
Fortran code with Java through JNI.
What I have been doing is compiling the Fortran code as a DLL
(fortran_code.dll). I then link this with the C++ code, which is in
turn compiled as a DLL (C_code.dll). The C++ code uses JNI to allow
Java to call the C++ function, which in turn calls the Fortran
function. This works beautifully, except for the fact that C_code.dll
must be in the Java library search path, AND fortran_code.dll must be
in the Windows system library search path (c:windowssystem32). This
is a pain for installation as the libraries must be copied into two
different locations.
Ideally, I would like the Fortran code statically linked into the C++
DLL. So all I did was create a new Fortran project and specify it as
a Static Library. I then linked the resulting file (fortran_code.lib)
to the C++ code, and simply changed the Fortran function declaration
in the C++ code to remove __declspec(dllimport). The code compiled
fine, creating a larger c_code.dll file which includes the Fortran
code statically linked. However, when Java now tries to load the new
DLL, it gives the following error:
java.lang.UnsatisfiedLinkError:c_code.dll: A dynamic link
library (DLL) initialization routine failed.
Does anybody have any idea what is causing this? I tried dumpbin
/IMPORTS c_code.dll and there are none except kernel32.dll, which is
correct. Statically linking in the Fortran code must have done
something to mess up a DLL which had been working when loading the
Fortran code from a DLL, but I am clueless as to why or what is
causing this error.
I also tried to debug this C++ wrapper by
writing a simple C++ program which calls the function so I could debug it
easier. I then use this executable for the debug executable in the DLL
project, I get an error message: "The application failed to initialize
properly (0xc0000142). Click on OK to terminate the application." I then
click on OK, and it says "Unhandled exception at 0x77f9e4b4 in testapp.exe:
0xC0000142: DLL Initialization Failed."
The initialization routine is simply a function DllMain which returns true.
I set a breakpoint at the start of it, and it's not even getting there. I
know that this is a convenience method, however, which is called after
something like DllMainCRTstartup or something like that, but the compiler is
supposed to take care of it. When I debug, other than not getting to the
DllMain function, it tells me that there is no source code available where
it crashes and gives me Disassembly, which is not very helpful.
Fortran code with Java through JNI.
What I have been doing is compiling the Fortran code as a DLL
(fortran_code.dll). I then link this with the C++ code, which is in
turn compiled as a DLL (C_code.dll). The C++ code uses JNI to allow
Java to call the C++ function, which in turn calls the Fortran
function. This works beautifully, except for the fact that C_code.dll
must be in the Java library search path, AND fortran_code.dll must be
in the Windows system library search path (c:windowssystem32). This
is a pain for installation as the libraries must be copied into two
different locations.
Ideally, I would like the Fortran code statically linked into the C++
DLL. So all I did was create a new Fortran project and specify it as
a Static Library. I then linked the resulting file (fortran_code.lib)
to the C++ code, and simply changed the Fortran function declaration
in the C++ code to remove __declspec(dllimport). The code compiled
fine, creating a larger c_code.dll file which includes the Fortran
code statically linked. However, when Java now tries to load the new
DLL, it gives the following error:
java.lang.UnsatisfiedLinkError:
library (DLL) initialization routine failed.
Does anybody have any idea what is causing this? I tried dumpbin
/IMPORTS c_code.dll and there are none except kernel32.dll, which is
correct. Statically linking in the Fortran code must have done
something to mess up a DLL which had been working when loading the
Fortran code from a DLL, but I am clueless as to why or what is
causing this error.
I also tried to debug this C++ wrapper by
writing a simple C++ program which calls the function so I could debug it
easier. I then use this executable for the debug executable in the DLL
project, I get an error message: "The application failed to initialize
properly (0xc0000142). Click on OK to terminate the application." I then
click on OK, and it says "Unhandled exception at 0x77f9e4b4 in testapp.exe:
0xC0000142: DLL Initialization Failed."
The initialization routine is simply a function DllMain which returns true.
I set a breakpoint at the start of it, and it's not even getting there. I
know that this is a convenience method, however, which is called after
something like DllMainCRTstartup or something like that, but the compiler is
supposed to take care of it. When I debug, other than not getting to the
DllMain function, it tells me that there is no source code available where
it crashes and gives me Disassembly, which is not very helpful.
連結已複製
20 回應
Rehi,
As I said, I don't have a clue what is going on; so, few sanity checks first:
1) What's the setting for fortran_lib in Project/Settings/Fortran/Libraries category? Should be "Single-threaded" or "Multi-threaded" -- that's supposed to statically link to Fortran RTL and NOT use DFORRT.dll
2) When you wrote DllMain, did you specify its prototype correctly (extern "C" BOOL WINAPI) and did you specify "DllMain@12" in Project/Settings/Link/Output/Entry-point symbol?
3) Are you sure that you have setup the debugging environment correctly? Usually, when I develop & debug a Dll, I change its path in Project/Settings/Link/General to be the same as the calling exe -- no copying required.
Jugoslav
As I said, I don't have a clue what is going on; so, few sanity checks first:
1) What's the setting for fortran_lib in Project/Settings/Fortran/Libraries category? Should be "Single-threaded" or "Multi-threaded" -- that's supposed to statically link to Fortran RTL and NOT use DFORRT.dll
2) When you wrote DllMain, did you specify its prototype correctly (extern "C" BOOL WINAPI) and did you specify "DllMain@12" in Project/Settings/Link/Output/Entry-point symbol?
3) Are you sure that you have setup the debugging environment correctly? Usually, when I develop & debug a Dll, I change its path in Project/Settings/Link/General to be the same as the calling exe -- no copying required.
Jugoslav
OK, I played with it a little and it looks as if it has everything to do with run-time libraries. I was able to reproduce your problem with default RTL settings for caller and dll; when I switched everything to "Debug Multi-threaded", it started working. It looks as if you have to link everything against the same RTLs; try playing with it.
Attached (you have to log on to Forum to download it) is a workspace containing 2 projects (Caller and Dll), both linked against Debug Multi-threaded libraries (I adjusted the settings & paths only for Debug configurations). (The code is rather meaningless -- I had it somewhere as a sample for another issue).
Now, how to make it work with static linking of RTLs (what you probably want, since now even Fortran is linked against DFORRT.dll)... I don't know. Back to comp.os...win32? :-). I'm not sure how Fortran fits into this entire story, i.e. how Fortran RTLs are dependent on MSVC RTLs?
Jugoslav
P.S. A better tool for inspection of dll dependencies is Dependency Walker (Depends.exe) from MSVC tools.
Attached (you have to log on to Forum to download it) is a workspace containing 2 projects (Caller and Dll), both linked against Debug Multi-threaded libraries (I adjusted the settings & paths only for Debug configurations). (The code is rather meaningless -- I had it somewhere as a sample for another issue).
Now, how to make it work with static linking of RTLs (what you probably want, since now even Fortran is linked against DFORRT.dll)... I don't know. Back to comp.os...win32? :-). I'm not sure how Fortran fits into this entire story, i.e. how Fortran RTLs are dependent on MSVC RTLs?
Jugoslav
P.S. A better tool for inspection of dll dependencies is Dependency Walker (Depends.exe) from MSVC tools.
Thank you for your help. However, I am still having the same problem. I have been using all the Debug Mutli-Threaded libraries. The code works fine when both the Fortran and C++ are DLLs. But it is necessary to have only one DLL in my case. Even when I have two DLLs, I am statically linking the Fortran run-time into the Fortran DLL. It's only when I then try to statically link the Fortran LIB into the C++ DLL that I run into the problem. Also, I am using DVF 6.0 and VisualStudio .NET, so I have to compile in DVF and then in a separate workspace (or solution as they call them now for some reason) import the LIB for the now statically compile Fortran, and compile in .NET. The code compiles fine without warnings or anything, which tells me it *should* work, but for some strange reason it won't load the DLL in my program. VERY frustrating. :)
Ugh, it's getting even more complicated with combination 6.0/NET. I didn't bother to create Fortran static library -- I thought it wouldn't matter whether it's inserted as .lib or as a .f90.
Btw, is the setting in Project/Settings/Fortran/Libraries for the Fortran library the same? Which dlls does depends.exe list as dependencies for the dll? Note that DFORRT.dll depends on MSVCRT.dll.
As a test -- try linking everything (.lib, .dll and .exe) against "Debug Multi-threaded DLL" (I know it's not what you want, but just as a sanity check...). If that works, well, that's something...
Jugoslav
Btw, is the setting in Project/Settings/Fortran/Libraries for the Fortran library the same? Which dlls does depends.exe list as dependencies for the dll? Note that DFORRT.dll depends on MSVCRT.dll.
As a test -- try linking everything (.lib, .dll and .exe) against "Debug Multi-threaded DLL" (I know it's not what you want, but just as a sanity check...). If that works, well, that's something...
Jugoslav
?????
Isn't that what I'm doing? If you mean I should just make a Fortran DLL and dynamically link it to the C++ DLL, yes this does work. But I have reasons for not wanting to do this, and I know that the static linking should work.
Isn't that what I'm doing? If you mean I should just make a Fortran DLL and dynamically link it to the C++ DLL, yes this does work. But I have reasons for not wanting to do this, and I know that the static linking should work.
> ?????
>
> Isn't that what I'm doing? If you mean I should just
> make a Fortran DLL and dynamically link it to the C++
> DLL, yes this does work. But I have reasons for not
> wanting to do this, and I know that the static
> linking should work.
No. You appear to be making things more complicated than necessary. Making a DLL and then statically linking it to an exe or another DLL is working at cross purposes no matter what your reasons. Make one DLL, a C DLL, and rather than making a separate Fortran DLL that you then want to statically link to your C DLL, include the Fortran source files in your VC++ project which is now a mixed-language C DLL. This works with VC++ but I'm not sure about VC++ .NET. There are reams of stuff on mixed-language programming in the CVF docs.
Ciao,
Gerry T.
>
> Isn't that what I'm doing? If you mean I should just
> make a Fortran DLL and dynamically link it to the C++
> DLL, yes this does work. But I have reasons for not
> wanting to do this, and I know that the static
> linking should work.
No. You appear to be making things more complicated than necessary. Making a DLL and then statically linking it to an exe or another DLL is working at cross purposes no matter what your reasons. Make one DLL, a C DLL, and rather than making a separate Fortran DLL that you then want to statically link to your C DLL, include the Fortran source files in your VC++ project which is now a mixed-language C DLL. This works with VC++ but I'm not sure about VC++ .NET. There are reams of stuff on mixed-language programming in the CVF docs.
Ciao,
Gerry T.
VC++ .NET does not integrate with DVF 6.0. Thus, you have to compile the project in DVF and link the .LIB when you compile in VC++ .NET. This is not making things more complicated than necessary. This IS what mixed-language programming is. When the IDE integrates the C++ compiler and the Fortran compiler, it simply hides the step of statically linking the library or object files all together for you. This is all I'm trying to do, except with two separate IDEs.
OK, I finally got it to work. I will post this so it may help anybody else having similar problems.
The DFOR.LIB (Fortran Run-Time Library) and LIBCMT.LIB (C Run-Time Library) files with DVF 6.0 are not compatible with the LIBCMT.LIB file included with VC++ .NET. The only reason this matters is because (I found this out thatnks to the depends.exe suggestion I received) the Fortran Run-Time DLL depends on the C Run-Time DLL. Thus, I figure that the Fortran Static Run-Time library links code with the C Run-Time Library.
To remedy this, I used my co-worker's copy of CVF 6.6 to compile the Fortran LIB, and then imported this LIB back into my VC++ .NET project. All worked beautifully. What a waste of three days of work. Now if I can only get my boss to get me my own CVF 6.6 or get my co-worker to trade versions with me, haha. :)
The DFOR.LIB (Fortran Run-Time Library) and LIBCMT.LIB (C Run-Time Library) files with DVF 6.0 are not compatible with the LIBCMT.LIB file included with VC++ .NET. The only reason this matters is because (I found this out thatnks to the depends.exe suggestion I received) the Fortran Run-Time DLL depends on the C Run-Time DLL. Thus, I figure that the Fortran Static Run-Time library links code with the C Run-Time Library.
To remedy this, I used my co-worker's copy of CVF 6.6 to compile the Fortran LIB, and then imported this LIB back into my VC++ .NET project. All worked beautifully. What a waste of three days of work. Now if I can only get my boss to get me my own CVF 6.6 or get my co-worker to trade versions with me, haha. :)
Yes, this is correct. However, I had already done this and it still didn't work. I am just postign this to be informative for other people who may have this problem.
The code will not link if the Fortran Run-Time libraries are not included in the VC .NET project options. It will complain about not finding DFOR.LIB or whichever version you are using (add MT for multi-threaded, and D for debug). However, if you do include these run-time libraries in VC .NET and you are using DVF 6.0, the code will compile but crash when it is actually run, saying the DLL could not be initialized. I am guessing this is due to incompatibilities between the C run-time (LIBC.LIB) used by VC .NET, and the C run-time used by DVF 6.0. I even tried ignoring LIBC.LIB in VC .NET and pointing it to use the LIBC.LIB that DVF uses (in the VC98/LIB directory) but it didn't like this, complaining about an undefined reference to __security_cookie or something like that. So the best solution is to use the newest version of the C run-time libraries for both the Fortran and the C code. However, this means that since DFOR.LIB uses code from LIBC.LIB, it needs to be updated as well, and it seems that the only way to do this is to upgrade the version of Visual Fortran.
The code will not link if the Fortran Run-Time libraries are not included in the VC .NET project options. It will complain about not finding DFOR.LIB or whichever version you are using (add MT for multi-threaded, and D for debug). However, if you do include these run-time libraries in VC .NET and you are using DVF 6.0, the code will compile but crash when it is actually run, saying the DLL could not be initialized. I am guessing this is due to incompatibilities between the C run-time (LIBC.LIB) used by VC .NET, and the C run-time used by DVF 6.0. I even tried ignoring LIBC.LIB in VC .NET and pointing it to use the LIBC.LIB that DVF uses (in the VC98/LIB directory) but it didn't like this, complaining about an undefined reference to __security_cookie or something like that. So the best solution is to use the newest version of the C run-time libraries for both the Fortran and the C code. However, this means that since DFOR.LIB uses code from LIBC.LIB, it needs to be updated as well, and it seems that the only way to do this is to upgrade the version of Visual Fortran.
Glad to hear it works.
If I were you, I'd try to trade VS.NET for a good ol' VS6 as well ;-).
You could try to change the C library paths in CVF6, i.e. in Tools/Options/Directories/Library files, replace the VC98 path with .NET one. No guarantees it will work (although it should -- but it's Micro$oft).
(I've heard people using similar trick with VC++ compiler -- they changed the Bin path so that new C++ .NET compiler -- about the only improvement in .NET ;-) -- was used in VS6 environment).
Jugoslav
If I were you, I'd try to trade VS.NET for a good ol' VS6 as well ;-).
You could try to change the C library paths in CVF6, i.e. in Tools/Options/Directories/Library files, replace the VC98 path with .NET one. No guarantees it will work (although it should -- but it's Micro$oft).
(I've heard people using similar trick with VC++ compiler -- they changed the Bin path so that new C++ .NET compiler -- about the only improvement in .NET ;-) -- was used in VS6 environment).
Jugoslav
> Yes, this is correct. However, I had already done
> this and it still didn't work. I am just postign
> this to be informative for other people who may have
> this problem.
>
The latest release of CVF is 6.6B. AFAIK, DVF 6.0 is long unsupported and I doubt that there is much interest in hacking its linkage to VC++.NET.
When you acquire CVF 6.6B/IFC 7.1/IVF, don't build two DLL's when one would do. The business of statically linking a DLL to another is done when you have no other choice: eg, you only have the .lib of the DLL as with IMSL that comes with CVF Pro. It has the advantages of reducing the size of whatever it's linked to and you don't have to distribute it with your app. In your case you have full control over the design of your app but you lack the right tools.
Ciao,
Gerry T.
> this and it still didn't work. I am just postign
> this to be informative for other people who may have
> this problem.
>
The latest release of CVF is 6.6B. AFAIK, DVF 6.0 is long unsupported and I doubt that there is much interest in hacking its linkage to VC++.NET.
When you acquire CVF 6.6B/IFC 7.1/IVF, don't build two DLL's when one would do. The business of statically linking a DLL to another is done when you have no other choice: eg, you only have the .lib of the DLL as with IMSL that comes with CVF Pro. It has the advantages of reducing the size of whatever it's linked to and you don't have to distribute it with your app. In your case you have full control over the design of your app but you lack the right tools.
Ciao,
Gerry T.
Gerry, I have to pun you for butting into this thread straight from Mars. All the time Jeff is trying to create a single mixed-language dll not dependent on anything. When he referred to "static linking", he meant "creating a static .lib and inserting it into a C++ .dll project".
Jugoslav
Jugoslav
Jugoslav:
I know precisely what he was trying to do. Indeed I've done likewise several times of late. This is what prompted me to ask in the forum a couple of weeks ago (Mar 28/03, CVF and VC7 thread): 'Are CVF .obj's,.lib's link(v7) compatible with unmanaged VC7 .obj's,.lib's?' to which Steve replied: 'Yes. Just be sure to use the VC7 linker to link. (You'll have to add the path to DF98LIB to the linker paths in the VC7 environment.)', essentially the same response given to the OP yesterday. I know all too well what static linking means, it advantages, and when to do it. My last post to this thread attests to that.
I reserve the nonexclusive right to question and advise on any post to this forum.
Ciao,
Gerry T.
BTW, a word to the wise. Avoid puns. They're a favorite device of the witless and their use is beneath you.
I know precisely what he was trying to do. Indeed I've done likewise several times of late. This is what prompted me to ask in the forum a couple of weeks ago (Mar 28/03, CVF and VC7 thread): 'Are CVF .obj's,.lib's link(v7) compatible with unmanaged VC7 .obj's,.lib's?' to which Steve replied: 'Yes. Just be sure to use the VC7 linker to link. (You'll have to add the path to DF98LIB to the linker paths in the VC7 environment.)', essentially the same response given to the OP yesterday. I know all too well what static linking means, it advantages, and when to do it. My last post to this thread attests to that.
I reserve the nonexclusive right to question and advise on any post to this forum.
Ciao,
Gerry T.
BTW, a word to the wise. Avoid puns. They're a favorite device of the witless and their use is beneath you.
Gerry,
I have not been creating two DLL's. I have been linking the static library I created with CVF with my VC7 project. What you were referring to is linking to LIB files which simply provide references to DLL's. I am linking to LIB files which contain all of the object code such that there need to be no external references. This is in effect the same thing as linking to object files. I have tried both with the same results. The LIb file I am creating is simply a collection of object files. It does not reference a DLL.
Anyways, this brings me back to my original point of this entire post:
Yes, you need to link to the the Fortran Run-Time libraries (DF98/LIB).
Yes, you need to use the VC7 linker to linkt eh project.
Yes, the libraries included with CVF 6.6 will let you compile a single DLL or EXE file containing both Fortran and C++ object files and their corresponding Run-Time libraries such that there are no external dependencies (other than kernel and ntdll of course).
No, following all of these steps correctly still will not let you produce these results if you are using DVF 6.0 because the Fortran Run-Time libraries depend on a different version of the C Run-Time libraries than the VC7 linker uses and expects. This does not matter if you are dynamically linking the Fortran to the C because then each DLL can either reference or statically contain it's own version of the runtime. However, when BOTH the Fortran and the C are included in the same DLL or EXE, only one C Run-Time can be included. Thus, to link these two together into one file, the version of the Fortran Run-Time must be used which depends on the same C Run-Time library used by VC7.
I hope this clears things up a bit. In a nutshell, if you have CVF 6.6 and VC7, just create a static library (with the static version of the run-time) in CVF 6.6. Then add this library to the dependencies of the VC7 linker when you compile the C++. Also, include the DF98/LIB directory to the include object directories so that DFOR.LIB, DFORD.LIB, DFORMT.LIB, or DFORMTD.LIB can be found. Specifify to statically link the C Run-Time in VC7 and compile. You should have a standalone DLL or EXE which will execute both C++ and Fortran functions.
The last important point to remember is to use the same version of the run-time libraries in both CVF and VC7 (single-threaded, single-threaded debug, multi-threaded, or single-threaded debug). These are all static version of the run-time. You can use the DLL versions as well, but then users will need DFOR.DLL and MSVCR70.DLL in their system directory. This seems less desirable to me, but will produce a much smaller file, so if your users deifnitely will hve these DLL's (or the program is for your own use) this may be a good option. Remember that it is possible to statically link the Fortran code into your C++ DLL or EXE but still dynamically reference the respective run-times.
I have not been creating two DLL's. I have been linking the static library I created with CVF with my VC7 project. What you were referring to is linking to LIB files which simply provide references to DLL's. I am linking to LIB files which contain all of the object code such that there need to be no external references. This is in effect the same thing as linking to object files. I have tried both with the same results. The LIb file I am creating is simply a collection of object files. It does not reference a DLL.
Anyways, this brings me back to my original point of this entire post:
Yes, you need to link to the the Fortran Run-Time libraries (DF98/LIB).
Yes, you need to use the VC7 linker to linkt eh project.
Yes, the libraries included with CVF 6.6 will let you compile a single DLL or EXE file containing both Fortran and C++ object files and their corresponding Run-Time libraries such that there are no external dependencies (other than kernel and ntdll of course).
No, following all of these steps correctly still will not let you produce these results if you are using DVF 6.0 because the Fortran Run-Time libraries depend on a different version of the C Run-Time libraries than the VC7 linker uses and expects. This does not matter if you are dynamically linking the Fortran to the C because then each DLL can either reference or statically contain it's own version of the runtime. However, when BOTH the Fortran and the C are included in the same DLL or EXE, only one C Run-Time can be included. Thus, to link these two together into one file, the version of the Fortran Run-Time must be used which depends on the same C Run-Time library used by VC7.
I hope this clears things up a bit. In a nutshell, if you have CVF 6.6 and VC7, just create a static library (with the static version of the run-time) in CVF 6.6. Then add this library to the dependencies of the VC7 linker when you compile the C++. Also, include the DF98/LIB directory to the include object directories so that DFOR.LIB, DFORD.LIB, DFORMT.LIB, or DFORMTD.LIB can be found. Specifify to statically link the C Run-Time in VC7 and compile. You should have a standalone DLL or EXE which will execute both C++ and Fortran functions.
The last important point to remember is to use the same version of the run-time libraries in both CVF and VC7 (single-threaded, single-threaded debug, multi-threaded, or single-threaded debug). These are all static version of the run-time. You can use the DLL versions as well, but then users will need DFOR.DLL and MSVCR70.DLL in their system directory. This seems less desirable to me, but will produce a much smaller file, so if your users deifnitely will hve these DLL's (or the program is for your own use) this may be a good option. Remember that it is possible to statically link the Fortran code into your C++ DLL or EXE but still dynamically reference the respective run-times.
Somebody has to ask the dumb questions, and it sounds like the people who can answer mine about DLLs are certainly the ones posting in this thread.
As background, I know the difference between statically linking in a library to a program versus a program calling a DLL.
Why is it that when you create a DLL you get at least three files: x.DLL, x.EXP, and x.LIB? What are the x.EXP and x.LIB files for?
Whenever I create a DLL and run the program that calls it, all I have to do is be sure that the x.DLL file is in a place where the system can find it; I don't have to do that with the x.EXP or x.LIB files. Why not?
Mike
As background, I know the difference between statically linking in a library to a program versus a program calling a DLL.
Why is it that when you create a DLL you get at least three files: x.DLL, x.EXP, and x.LIB? What are the x.EXP and x.LIB files for?
Whenever I create a DLL and run the program that calls it, all I have to do is be sure that the x.DLL file is in a place where the system can find it; I don't have to do that with the x.EXP or x.LIB files. Why not?
Mike
When you deploy your application to the end user, you indeed need only the .dll. Lib and Exp are sort of "intermediate" files that may -- but need not -- be used to link the calling .exe.
This .lib is referred to as "import library" and contains no meaningful "code" -- just references to actual Dll symbols. You can use it to link the calling .exe, provided the linker is MS-compatible. This technique is called "static binding"; when used, dll is automatically loaded along with the .exe. However, another technique, "dynamic binding", requires no linking with the .lib -- you can load/unload the .dll at any run-time using LoadLibrary/FreeLibrary and GetProcAddress APIs. Delphi and VB, for example, use this technique by default, "behind the scenes", and you cannot even link the import .lib with a Delphi or VB .exe.
.exp file is similar to .lib; I've never used it myself. MSDN states that it should be used instead of .lib when two modules share each other's exports.
Jugoslav
This .lib is referred to as "import library" and contains no meaningful "code" -- just references to actual Dll symbols. You can use it to link the calling .exe, provided the linker is MS-compatible. This technique is called "static binding"; when used, dll is automatically loaded along with the .exe. However, another technique, "dynamic binding", requires no linking with the .lib -- you can load/unload the .dll at any run-time using LoadLibrary/FreeLibrary and GetProcAddress APIs. Delphi and VB, for example, use this technique by default, "behind the scenes", and you cannot even link the import .lib with a Delphi or VB .exe.
.exp file is similar to .lib; I've never used it myself. MSDN states that it should be used instead of .lib when two modules share each other's exports.
Jugoslav
In your original post, you claim that at one stage you were using two dll's and this worked fine but you wanted only one and the rest is ... Take a look at:
http://msdn.microsoft.com/library/en-us/dnsetup/html/sidebyside.asp?frame=true
and
http://msdn.microsoft.com/library/en-us/dnsetup/html/dlldanger1.asp?frame=true
as an alternative strategy to one you adopted.
One hack that you didn't consider is to see if VC7 integrates into VS6. Well it does in a fashion, at least to the extent that you can do mixed CVF-VC7 programming within the VS6 IDE, static linking and .NET be damned, though check the .NET EULA before doing anything naughty to MS. YMMV. Keep in mind that VC7 is a mere C++ compiler with .NET extensions which you don't appear to be using anyways. You might also want to look at
http://support.microsoft.com/default.aspx?scid=KB;en-us;q312383
if you ever want to ditch VS.NET 2002.
HTH,
Gerry T.
http://msdn.microsoft.com/library/en-us/dnsetup/html/sidebyside.asp?frame=true
and
http://msdn.microsoft.com/library/en-us/dnsetup/html/dlldanger1.asp?frame=true
as an alternative strategy to one you adopted.
One hack that you didn't consider is to see if VC7 integrates into VS6. Well it does in a fashion, at least to the extent that you can do mixed CVF-VC7 programming within the VS6 IDE, static linking and .NET be damned, though check the .NET EULA before doing anything naughty to MS. YMMV. Keep in mind that VC7 is a mere C++ compiler with .NET extensions which you don't appear to be using anyways. You might also want to look at
http://support.microsoft.com/default.aspx?scid=KB;en-us;q312383
if you ever want to ditch VS.NET 2002.
HTH,
Gerry T.
