I have been creating a dll for a usb device over the past few weeks, the device came with its own dll which i used to create my own dll in VS2010, I then created a test application which uses said dll in 2010 to get it working. It works well, however I now need to use it in a VS6 project, when i use it I get access violations, I recreated the dll in VS6 to see if that would help, it allowed me to step into the code, as soon as it gets to a line in my dll that calls the 3rd party dll, it causes an access violation, I have just tried creating a factory function to create a abstract interface to my dll but I again get access violations. I am new to dlls and am completely out of ideas, and help or insight would be greatly appritiated...
相关问题
- Sorting 3 numbers without branching [closed]
- How to compile C++ code in GDB?
- Why does const allow implicit conversion of refere
- How to know full paths to DLL's from .csproj f
- thread_local variables initialization
相关文章
- vs2017wpf项目引用dll的路径不正确的问题
- How to show location of errors, references to memb
- Class layout in C++: Why are members sometimes ord
- Log4Net Multiple Projects
- How to mock methods return object with deleted cop
- Which is the best way to multiply a large and spar
- C++ default constructor does not initialize pointe
- Selecting only the first few characters in a strin
The way you can get a DLL created with a later version of Visual Studio to work with Visual Studio 6 is to code your DLL in a generic way in terms of parameters passed and returned to the DLL's exported functions.
For example, the Windows API describes certain variable types. These types include
DWORD
,LONG
,BOOL
,DWORD_PTR
, etc. Included are the various string pointer types such asLPCSTR
. Also included in this list are pointers to these various types such asLPLONG
,LPBYTE
,LPVOID
etc.If your DLL's exported functions passes or returns a type that isn't one of the above, then you're stuck -- the DLL can only be used safely in an application that was built with the same version of Visual Studio that the DLL was built with.
For example, if you're passing C++ objects (standard library objects, or even your own objects), that is a big no-no if you want that DLL to work across several versions of Visual Studio.