[MSVC] Is it valid to link against an import .lib generated from an executable?

[pheres]

Hi,

I want to share some code which is defined inside a module from which I build an .exe. I want to reuse it in another .Exe

I know, the correct way is to factor it out into an extra lib and link it to both modules.

I discovered, that I can export the needed symbols from the .exe through a .def file, just like as it where an DLL and link it to the other exe. It compiles flawlessly. At runtime it crashes with a memory read error once it touches the linked code. So probably it's not valid what I try to do. Maybe someone is able to explain why it crashes?

Thank you!

[abachler]

Run time linking needs to use a DLL not a LIB. LIB's need to be fixed up before they are executable.

[Elysia]

I don't think you can "load" an exe, can you?

[pheres]

Using Loadlibrary()? Hm, I can try it later...

[Elysia]

Well, you either need a .lib file or do a LoadLibrary to load the actual functions into memory.

[abachler]

I don't think you can "load" an exe, can you?

You CAN load it using LoadLibrary(), but MS recommends against executing code in the module, this functionality is provided only so you can access resources in the executable.

[Elysia]

Hold crap, that code is messed up. Do you ever try to view your message before or after posting it?

[abachler]

yeah i deleted it as soon as I saw what it looked like, sorry. Suffice it to say there is a tutorial in the MSVC 6.0 help file on creating a modeless dialog box.

[matsp]

I think there are at least three different solutions that are more appealing than "using a function out of another .exe":
1. Share the source-code instead of the binary - so if "foo.c" contains your code, both project A and project B would contain a copy of "foo.c" - with the right type of source control, it should even be possible to make the source control understand that it's actually exactly the SAME FILE, just copied to two different places.

2. Create a static library for "foo.c". Link both A and B to the foo.lib file.

3. Create a proper DLL for foo.c, and link against foo.lib and distribute foo.dll.

I understand that if A is an already existing application, you may not be able to use option 3, but option 1 and 2 doesn't actually change A in any externally visible way, so it should be fine.

--
Mats

[pheres]

Ok I see.
It was just an experimental thing to me. I would had never used this in a productive environment due to the cleaner solutions matsp mentioned.