WinUsb VS6 C++ Compatability
-
I have a legacy app using VC 6 MFC and Codejjock 9.8 (not really relevant I don't think) The program is broken into several pieces that communicate with each other via COM. I am attempting to add USB support to a custom board. I have written a simple console test program that Uses WinUsb_WritePipe, Read Pipe. All is fine. When I incorporate the headers and calls into my legacy app I can;t get it to link. I either get duplicate symbol defined _WINUSB_TEST or unable to find uuid.lib, or a few others depending the order of the includes. I should note I am statically linking MFC, building a debug build, and the wrapper USB class is usigng overlapped IO and is Multi Threaded (a seperate thread handles the IO with Thread Safe Queues buffering the data. My gut tells me this is an incompatability with the libraries. Microsoft stopped supporting the SDK for VS6 in 2003. The DDK is 6001.1802. I see a couple of options... Seperate the WinUsb code into a dll and hope the lib generated will link in with the main program. Recompile everything using VS2008. I have been avoiding this for 2 reasons. 1. I have experimented with VS.net, 2003, 2005 and MFC support seemed to get worse as did the GUI's. 2. The real reason. THe programs combined have nearly 500KLocs of code. There are a lot of CStrings and the scope of x in for(int x=0; x < y; x++) statetents. All of which are problematic with the new compilers. Any suggestions or help where I may be missing the boat would be greatly appreciated
-
I have a legacy app using VC 6 MFC and Codejjock 9.8 (not really relevant I don't think) The program is broken into several pieces that communicate with each other via COM. I am attempting to add USB support to a custom board. I have written a simple console test program that Uses WinUsb_WritePipe, Read Pipe. All is fine. When I incorporate the headers and calls into my legacy app I can;t get it to link. I either get duplicate symbol defined _WINUSB_TEST or unable to find uuid.lib, or a few others depending the order of the includes. I should note I am statically linking MFC, building a debug build, and the wrapper USB class is usigng overlapped IO and is Multi Threaded (a seperate thread handles the IO with Thread Safe Queues buffering the data. My gut tells me this is an incompatability with the libraries. Microsoft stopped supporting the SDK for VS6 in 2003. The DDK is 6001.1802. I see a couple of options... Seperate the WinUsb code into a dll and hope the lib generated will link in with the main program. Recompile everything using VS2008. I have been avoiding this for 2 reasons. 1. I have experimented with VS.net, 2003, 2005 and MFC support seemed to get worse as did the GUI's. 2. The real reason. THe programs combined have nearly 500KLocs of code. There are a lot of CStrings and the scope of x in for(int x=0; x < y; x++) statetents. All of which are problematic with the new compilers. Any suggestions or help where I may be missing the boat would be greatly appreciated
Some suggestions if you decide to build it all in VS2008..... The VS2008 CString class has a few quirks that were not there in VC6. The new MFC CString class is a lot more strict about index parameters going into functions like Mid, Left, Right, etc. What I ended up doing is derive my own subclass from CString and implement my own Left, Right, Mid, etc. handlers where my handlers would validate the index parameter(s) before calling the base class CString functions. I also did a little compiler gymnastics in redefining CString to CMyCString so as to not need to change every reference to CString in my project. As for the for scope problem, there is a compiler switch that overrides the for scope compliance rule. Use the /Zc:forScope- compiler switch to turn off the for scope checking. Out of curiosity, why are you statically linking MFC in a debug build?
-
Some suggestions if you decide to build it all in VS2008..... The VS2008 CString class has a few quirks that were not there in VC6. The new MFC CString class is a lot more strict about index parameters going into functions like Mid, Left, Right, etc. What I ended up doing is derive my own subclass from CString and implement my own Left, Right, Mid, etc. handlers where my handlers would validate the index parameter(s) before calling the base class CString functions. I also did a little compiler gymnastics in redefining CString to CMyCString so as to not need to change every reference to CString in my project. As for the for scope problem, there is a compiler switch that overrides the for scope compliance rule. Use the /Zc:forScope- compiler switch to turn off the for scope checking. Out of curiosity, why are you statically linking MFC in a debug build?
I statically link the MFC DLL in release mode because I have found it makes deployment more robust. This program started with VS 1.52 if you can believe that, and has morphed and been factored, etc. Major Requirements creep. Over the years the differences in mfc dlls that were on win 95, 98, 98se, etc caused support issues. I am not really sure why I an doing it in the debug version to be honest other than for consistency. I have tried it both ways and it doesn't seem to make a difference. Is there a reason not to statically link the MFC DLL in debug mode? Back to the original question, I am thinking that using a dynamically linked (loaded) dll might get around the issue? Your thoughts?