Reputation: 2494
I have to develop new functionality for a legacy project I'm working on and I'd prefer to do so in a modern IDE. The legacy code was developed in VC++6 and I'd like to develop this additional library in VS2013. Just for some context, this will be used in an RFID authentication system.
Will this be a problem? Conceptually, the library will only have 4 exported functions: OpenReaders()
, CloseReaders()
, and ValidateTag(int reader)
. It may have some more exported functions, but those will only be used for another, external program that I'll develop. That program would be used to configure a database that'll then be used by the library itself. Everything else will be self-contained in the DLL.
Now, I do know there's some issues with Unicode characters when migrating projects from VC++ 6.0 to newer versions of Studio. I had encountered these when I attempted to upgrade the current project to Studio 2013 and was largely successful. But after getting yelled at by a rather controlling co-worker (who is not my boss by the way, but has a beef with me and tends to get his way when he reports me to my boss; usually this happens whenever we disagree on a solution) I reverted back to VC++ 6.0. However, there must be some other complications I'm not aware of when trying to get a newer DLL to talk to an older codebase.
Upvotes: 1
Views: 148
Reputation: 35440
The main thing you need to consider are the parameter types you're sending to the DLL's exported functions and the return type of those exported functions. If the types are Windows types, i.e.
LONG, BOOL, LPCTSTR,
etc...
then there shouldn't be an issue, or if there are any issues, easily solved.
The one issue however may be that the DLL is Unicode, and your application is MBCS, and the string types get in the way. But there are ways around this, even in the old days of Visual C++ 6.0, to provide a Unicode string or receive such strings (using MultiByteToWideChar
and WideCharToMultiByte
, at least back to Windows 2000).
If on the other hand you're sending over types such as std::vector
, std::string
, then that isn't going to work very well. The reason being that these types have different internal implementations between compilers, thus the std::string
being passed to the DLL from Visual Studio 6.0 is not the same std::string
that your Visual Studio 2013 is using.
So correcting something like the last scenario becomes difficult, and would require significant changes to both the VS 6.0 code and the DLL code (like sending char buffers instead of string types, sending T*
and a size instead of std::vector<T>
, etc.)
Upvotes: 2