Add a VC 6 library in a VC8 project

[danip]

Hi,
Is it possible to add a VC++ 6 library ot a VC++ 8 application ? if yes
how ? is it possible to link a DLL ? how ?

-- Dani

 

[Jochen Kalmbach [MVP]]

Hi danip!

Is it possible to add a VC++ 6 library ot a VC++ 8 application ? if yes
how ? is it possible to link a DLL ? how ?

In general you can say:
It is *only* possible if it only exports C functions (and has not a
shared CRT).

In all other cases it is almost impossible to use an older LIB with a
newer VC-Version.

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Holger Grund]

In general you can say:
It is *only* possible if it only exports C functions (and has not a shared
CRT).

Um, why? Since all references from the VC6 code are resolved
when linking the full image, I don't see how it could work if you
use things like CString internally, but export C functions only.

What's wrong with the shared CRT?

In all other cases it is almost impossible to use an older LIB with a
newer VC-Version.

Elaborting on that, the ABI is supposed to be stable. I.e. the exact
same source code should be binary compatible. The real problem
is the runtime library.

The MFC, ATL, STL (CRT is safe in most cases) implementations
of different VC versions are not necessarily compatible at the binary
or object level.

So, as long as you don't use any of these (regardless of whether
it's in the interface or the implementation) you have good
chances that it just works.

Also note, that the defaults for some switches, which have an
impact on the ABI, have changed (e.g. /Zc:wchar_t).

Sometimes things can be greatly simplified by wrapping the lib
in a VC6 DLL. In that case all symbols in the .lib are resolved
against the VC6 libraries. You only have to make sure, that
your interface contract does not rely on any incompatible
types.

For example:
// OK; only fundamental types
class X { public:
void foo( const char* p );
private:
int i;
};
CString bar(); // BAD: CString binary layout & mangled
// name different in VC6 & 8

-hg

 

[Jochen Kalmbach [MVP]]

Hi Holger!

Um, why? Since all references from the VC6 code are resolved
when linking the full image, I don't see how it could work if you
use things like CString internally, but export C functions only.

What's wrong with the shared CRT?

This signatures of some CRT-function has changed... so the linker will
not be able to find it in the VC8 CRT...

Elaborting on that, the ABI is supposed to be stable.

Do you mean "Win32-API"? The Win32-API does not use the CRT.

I.e. the exact
same source code should be binary compatible. The real problem
is the runtime library.

The MFC, ATL, STL (CRT is safe in most cases) implementations
of different VC versions are not necessarily compatible at the binary
or object level.

If the CRT is safe in most cases, then it cannot be used. (it must be
safe in ALL cases to be used).

So, as long as you don't use any of these (regardless of whether
it's in the interface or the implementation) you have good
chances that it just works.

Yes, but I do not want to check if a CRT-function is safe for VC6-8!
Therefor we have a LIB for every compiler-version!

Also note, that the defaults for some switches, which have an
impact on the ABI, have changed (e.g. /Zc:wchar_t).

Sometimes things can be greatly simplified by wrapping the lib
in a VC6 DLL. In that case all symbols in the .lib are resolved
against the VC6 libraries. You only have to make sure, that
your interface contract does not rely on any incompatible
types.

And you have to be sure that you do not reply on the shared-CRT.


--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Holger Grund]

This signatures of some CRT-function has changed... so the linker will not
be able to find it in the VC8 CRT...

Ok, I see. I believe that's just one of the things I've mentioned below.
But what is different about the _shared_ CRT here? Wouldn't you
see the same issue for the static CRT?

Do you mean "Win32-API"? The Win32-API does not use the CRT.

I'm actually talking about the "Application Binary Interface", which
amongst other things specifies calling conventions, binary layout
of non-POD types and name mangling.

If the CRT is safe in most cases, then it cannot be used. (it must be safe
in ALL cases to be used).

I'm fairly certain you can just give it try. If the linker doesn't complain,
everything's fine. Also, there are far reaching provisions in the C
Standard that effectively guruantee object-level symbol names.
Yes, I know it's not 100% safe.

Yes, but I do not want to check if a CRT-function is safe for VC6-8!

Me neither.

Therefor we have a LIB for every compiler-version!

Yes sure, ideally you'd rebuild the .libs with VC8.

And you have to be sure that you do not reply on the shared-CRT.

Now, you lost me again. Since the DLL is fully (statically) linked and
remaining references are resolved against the VC6 CRT, I fail to see
any problem with the _shared_ CRT (oc, you need to respect the normal
rules such as, calling free from the same module as calling malloc etc.)

-hg