DLL he11 - multiple versions of Visual Studio - professional guidance needed - management of SDKs.
-
Not sure if it will fit your case but here is how I got about a similar problem: 1. make a clean virtual machine (VMware, VirtualBox, whatever you want) 2. install your DLL and use DEPENDS to find what missing SDK libraries you need 3. try to run your test app and fine tune between different versions of SDK until you make it run. The advantage of working on a VM is that you can go back to known snapshot points and not get the "it runs on my machine" situation. Going forward, I'd say the best thing would be to rebuild your DLL with as little external dependencies as possible. Link everything, including the runtime libraries, as static libraries. That way you can distribute your DLL without worrying about needed SDKs.
Mircea
This is good advice, with one caveat. Linking with static libraries will solve the problem only if the only parameters passed between the caller and the DLL are simple objects (char, int, ...), pointers to simple objects, or pointers to arrays of simple objects. If you try to pass something like a FILE*, there is no guarantee that the caller and the DLL agree on the format.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I have an ancient DLL that began life with VC++ 6. It also uses Zlib for compression, again VC++ 6. Fast forward a boat load of years and I now have a test app in VS2019. Can't load the DLL. Cannot find old debug libraries, etc. Given that you have a DLL, you don't necessarily have the ability to recompile it. Let's say we cannot for the moment. Am I left installing ancient SDKs so that those DLLs are available for my custom dll? Don't think how to fix this, I'm trying to understand how to manage MS's myriad versions of SDKS all over my laptop. What do you do to limit the insanity? Next question - best, most sane approach to move forward? Seems to me I need to rebuild the dll, the test app, etc so they all sync up. But I'm concerned about my customer elsewhere in the world. Do they need to install and SDK? I suspect I need to create an MSI that includes specific runtime kits. Appreciate any guidance.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
You could try running the code with modern libraries, and it is possible (although less probable) that it would work. But much safer to rebuild completely, since the dependencies are often hidden deep in the libraries or OS. One thing you may like to consider is whether you really need your library as a DLL rather than static. The only advantage of using a dll is in situations where you have multiple active applications that are all calling in to it. If it is only used by a single application then a static library, or even no library, is a better choice.
-
You could try running the code with modern libraries, and it is possible (although less probable) that it would work. But much safer to rebuild completely, since the dependencies are often hidden deep in the libraries or OS. One thing you may like to consider is whether you really need your library as a DLL rather than static. The only advantage of using a dll is in situations where you have multiple active applications that are all calling in to it. If it is only used by a single application then a static library, or even no library, is a better choice.
Quote:
The only advantage of using a dll is in situations where you have multiple active applications that are all calling in to it.
There are some other cases. Once I had a data collection app that needed to interface with potentially hundreds of different instruments. Having a monolithic app would have been impractical.
Mircea
-
Quote:
The only advantage of using a dll is in situations where you have multiple active applications that are all calling in to it.
There are some other cases. Once I had a data collection app that needed to interface with potentially hundreds of different instruments. Having a monolithic app would have been impractical.
Mircea
-
Well once it is in memory and the dll is loaded it will take up pretty much the same space as it would with a static library.
The thing was, in my case, that no user had all the instruments. Forcing them to load all the unused code would have been too taxing. Pretty much the same case as an OS that needs drivers (DLLs) for different devices. Loading code for all wouldn’t be a solution.
Mircea
-
Not sure if it will fit your case but here is how I got about a similar problem: 1. make a clean virtual machine (VMware, VirtualBox, whatever you want) 2. install your DLL and use DEPENDS to find what missing SDK libraries you need 3. try to run your test app and fine tune between different versions of SDK until you make it run. The advantage of working on a VM is that you can go back to known snapshot points and not get the "it runs on my machine" situation. Going forward, I'd say the best thing would be to rebuild your DLL with as little external dependencies as possible. Link everything, including the runtime libraries, as static libraries. That way you can distribute your DLL without worrying about needed SDKs.
Mircea
I admit I'm rusty here and rebuilding my knowledge base on how all of this works. I do have a clean Xp machines, excellent suggestion.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
This is good advice, with one caveat. Linking with static libraries will solve the problem only if the only parameters passed between the caller and the DLL are simple objects (char, int, ...), pointers to simple objects, or pointers to arrays of simple objects. If you try to pass something like a FILE*, there is no guarantee that the caller and the DLL agree on the format.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Truth there. The good news is that I know who my customers are and all of the data types are simple. Shudder, I cannot imagine passing a file pointer but I guess someone might do it :)
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
You could try running the code with modern libraries, and it is possible (although less probable) that it would work. But much safer to rebuild completely, since the dependencies are often hidden deep in the libraries or OS. One thing you may like to consider is whether you really need your library as a DLL rather than static. The only advantage of using a dll is in situations where you have multiple active applications that are all calling in to it. If it is only used by a single application then a static library, or even no library, is a better choice.
This is where I am struggling. Not using a DLL just won't work for this application as it allows independent applications to talk to our system. The issue at hand (I think) is that I have Visual Studio / Microsoft rot. My laptop is over 4 years old, and I just don't pay attention to the ramifications of installing of visual studio that may in fact also install an SDK. The development environment is a hodge podge mix of this stuff. It's almost certainly why everything is confused at the moment. I'm trying to clean it up. So, it's my understanding that all of these OS dlls come from the SDKs, am I correct? These SDKs tend to be generally related to OS releases. If I have a DLL, what's the best practice - make sure I always use the latest SDK? This also trails into the runtime libraries that are a necessary part of an installation package. Off to msdn...
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
This is where I am struggling. Not using a DLL just won't work for this application as it allows independent applications to talk to our system. The issue at hand (I think) is that I have Visual Studio / Microsoft rot. My laptop is over 4 years old, and I just don't pay attention to the ramifications of installing of visual studio that may in fact also install an SDK. The development environment is a hodge podge mix of this stuff. It's almost certainly why everything is confused at the moment. I'm trying to clean it up. So, it's my understanding that all of these OS dlls come from the SDKs, am I correct? These SDKs tend to be generally related to OS releases. If I have a DLL, what's the best practice - make sure I always use the latest SDK? This also trails into the runtime libraries that are a necessary part of an installation package. Off to msdn...
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
charlieg wrote:
The issue at hand ...
:omg: . That certainly needs to be fixed.
charlieg wrote:
So, it's my understanding that all of these OS dlls ...
Windows itself contains all the standard run time libraries. If you want to develop your own applications then you need a compiler and its associated SDKs (.lib and .dll files), some of which may be newer versions than the Windows versions. Once you build your application then you need to ensure that the correct .dlls are installed on any system that installs the application. That is why you need installers, rather than just copying the .exe files. Visual Studio has all the tools necessary to do this, although most people seem to prefer one of the non-Microsoft installers.
-
charlieg wrote:
The issue at hand ...
:omg: . That certainly needs to be fixed.
charlieg wrote:
So, it's my understanding that all of these OS dlls ...
Windows itself contains all the standard run time libraries. If you want to develop your own applications then you need a compiler and its associated SDKs (.lib and .dll files), some of which may be newer versions than the Windows versions. Once you build your application then you need to ensure that the correct .dlls are installed on any system that installs the application. That is why you need installers, rather than just copying the .exe files. Visual Studio has all the tools necessary to do this, although most people seem to prefer one of the non-Microsoft installers.
:thumbsup: My understanding as well. I have some clean Windows 10 Professional VMs, so I'll start with those.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I have an ancient DLL that began life with VC++ 6. It also uses Zlib for compression, again VC++ 6. Fast forward a boat load of years and I now have a test app in VS2019. Can't load the DLL. Cannot find old debug libraries, etc. Given that you have a DLL, you don't necessarily have the ability to recompile it. Let's say we cannot for the moment. Am I left installing ancient SDKs so that those DLLs are available for my custom dll? Don't think how to fix this, I'm trying to understand how to manage MS's myriad versions of SDKS all over my laptop. What do you do to limit the insanity? Next question - best, most sane approach to move forward? Seems to me I need to rebuild the dll, the test app, etc so they all sync up. But I'm concerned about my customer elsewhere in the world. Do they need to install and SDK? I suspect I need to create an MSI that includes specific runtime kits. Appreciate any guidance.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
oh the life of manufacturing systems. If I build a dll on a Windows 10 machine, is there hope for it to run under Xp? Assuming I don't do anything silly and use post Windows Xp features? I've just discovered with this inherited piece of code that the customer runs it under Xp. I'm thinking just use the Xp tools and stay there.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
oh the life of manufacturing systems. If I build a dll on a Windows 10 machine, is there hope for it to run under Xp? Assuming I don't do anything silly and use post Windows Xp features? I've just discovered with this inherited piece of code that the customer runs it under Xp. I'm thinking just use the Xp tools and stay there.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Judging by other reports I have seen the answer is: it depends. Microsoft has never tried to be backwards compatible in their systems but some applications will still work. The only way to find out would be exhaustive testing. But for a commercial product I would suggest that you should stick to XP for all development and testing.
