views:

1613

answers:

7

Is it possible to use a C++ static library (.lib) compiled using Visual Studio 6 in Visual Studio 2008?

+2  A: 

I shouldn't think why not - as long as you keep the usual CRT memory boundaries (ie if you allocate memory inside a library function, always free it from inside the library - by calling a function in the lib to do the freeing).

this approach works fine for dlls compiled with all kinds of compilers, statically linked libs should be ok too.

gbjbaanb
+1  A: 

Yes. There should be no issues with this at all. As gbjbaanb mentioned, you need to mind your memory, but VS2008 will still work with it. As long as you are not trying to mix CLR, (managed) code with it. I'd recommend against that if at all possible. But, if you are talking about raw C or C++ code, sure, it'll work.

What exactly are you planning on using? (What is in this library?) Have you tried it already, but are having issues, or are you just checking before you waste a bunch of time trying to get something to work that just wont?

LarryF
I am just asking before wasting a bunch of time trying to get it working. I have a compiled .lib library and only the header files necessary to use it, so I would not have been able to re-compile the whole library
A: 

Sure it'll work.

Are you asking where in VS2008 to code the references?

If so, go to proj props -> Linker -> Input on Configuration properties on the property pages. Look for "additional dependencies" and code the .LIB there.

Go to proj props -> Linker -> General and code the libs path in "Additional Library Directories".

That should do it!!

Lou
A: 

There are cases were the answer is no, when we moved from VS6 to VS2k5 we had to rebuild all our libraries, as the memory model had changed, and the CRT functions where different.

Simeon Pilgrim
hence my point - if you keep all CRT calls inside the lib, then you'll have no problems. Even between mixing release and debug builds. If you call a CRT fn inside the lib, pass the memory outside and then let your app manipulate it, expect trouble. Simple encapsulation is the answer.
gbjbaanb
While I get what you mean for memory allocations, VS2K5 refused to use our VS6 libraries. That was two years ago, so the exact error it gave me I cannot remember. We had to track down code for libraries not recompiled for years and rebuild them in VS2K5.
Simeon Pilgrim
+2  A: 

It really depends. Does the lib expose only 'extern "C"' functions where memory is either managed by straight Win32 methods (CoTaskMemAlloc, etc) or the caller never frees memory allocated by the callee or vice-versa? Do you only rely on basic libraries that haven't changed much since VS 6? If so, you should be fine.

There are 2 basic things to watch for. Changes to global variables used by 3rd-party libraries, and changes to the structure of structs, classes, etc defined by those 3rd-party libraries. For example, the CRT memory allocator has probably changed its hidden allocation management structures between the 2 versions, so having one version of the library allocate a piece of memory and having another free it will probably cause a crash.

As another example, if you expose C++ classes through the interface and they rely on MS runtime libraries like MFC, there's a chance that the class layout has changed between VS 6 and VS 2008. That means that accessing a member/field on the class could go to the wrong thing and cause unpredictable results. You're probably hosed if the .lib uses MFC in any capacity. MFC defines and internally uses tons of globals, and any access to MFC globals by the operations in the .lib could cause failures if the MFC infrastructure has changed in the hosting environment (it has changed a lot since VS 6, BTW).

I haven't explored exactly what changes were made in the MFC headers, but I've seen unpredictable behavior between MFC/ATL-based class binaries compiled in different VS versions.

On top of those issues, there's a risk for functions like strtok() that rely on static global variables defined in the run-time libraries. I'm not sure, but I'm concerned those static variables may not get initialized properly if you use a client expecting the single-threaded CRT on a thread created on the multi-threaded CRT. Look at the documentation for _beginthread() for more info.

David Gladfelter
A: 

There were a handful of breaking changes between VC6, VS2003, VS2005 and VS2008. Visual C++ (in VS2005) stopped support for single-threaded, statically linked CRT library. Some breaking changes enumerated here and here. Those changes will impact your use of VC6 built libs in later versions.

sean e
A: 

I have a library(developed in VS 6.0) to linked to my C++/CLI prject in VS 2008. I am getting compiler errors for the header files when I Include them in my C++\CLI project VS 2008. Is there a way to compile those header files in older version?. The contain some class defenition and the implimentation of some methods as well. All the errors are to Porting (Migration) errors

Josepheena