SDK not working with recent Visual Studio versions
Dobit
Posts: 181
We have always made our previous plugins like anilip with Visual Studio 2010. Unfortunately, the use of other 3rd party libraries becomes more and more difficult. Most have already discontinued support for this old compiler. We tried to change the development of anilip 3 to a more recent compiler (VS 2019). However, Microsoft has changed its STL library so that STL classes now have different sizes. This results in the release of STL objects that are returned by Qt functions to crashes. The problem is actually Qt, which uses STL classes as returns or parameters very often.
The release of a new SDK version, which also supports newer compilers and a new Qt, would certainly be a solution. Maybe there are already plans here? Be open to other suggestions as well.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Any feedback would be great. After all, we also want to maintain our plugins. It would be good to know if this SDK has any future.
If you're waiting for an official answer from Daz you won't have one though the forums. Contact Daz directly via a support ticket.
PA Support would be the obvious point of contact, since you are a PA.
I use Visual Studio 2017 with Visual Studio 2010 (v100) as Platform toolset for the plugins. However, I have to do explicit linking to external libraries.
We do that too. However we would like to use the Amazon AWS SDK. This SDK uses c11 extensions in the headers that are not supported in VS 2010.
Are there instructions available for setting up the SDK with newer Visual Studio versions this way?
In your VS project settings select 'General/Platform Toolset'. By default you will see just the current one. Using the VS installer, you can add more.
Unfortunately adding support for C11 would break existing plug-ins, so not something Daz is going to do in the middle (or towards the end of) a version - so it will most likely have to wait for DS 5. In the meantime it is apparently possible to use a "shim" between DS and the desired SDK, though I'm afraid i cannot provide any instructions on how to do so.
The existing sdk headers can be used without compilation errors in VS 2019. It is just the incompatible stl which causes runtime problems, whenever a destructor is called (mainly in QT libs).
But to provide VS 2017 or even VS 2019 sdk libs and dlls in addition to VS 2010 should not break existing plugins.
I am using the tools from Visual Studio 2017 and I'm also using C++14 language features. I do not see problems with destructors crashing everywhere. I have found a single API from which Qt wants to return a QList<QModelIndex> which I cannot use and have to work around. Also there is some extra overhead in that my extra C++ runtime will have to be linked into the plugin DLL. Other than that it's been smooth sailing!
You're really lucky. I know many other QT functions that I cannot call.
This article explains the reasons for the binary Incompatibility between VS2010 and VS2015.
"..the point is that just these two different std::vector’s sizes in VS2010 and VS2015 show that the binary layout of the std::vector template has changed between the two C++ compiler versions. So there is a clear mismatch between the std::vector expected by a DLL built with one version of the VC++ compiler and the std::vector expected by an EXE built with a different version of the VC++ compiler."
If you follow the official Microsoft statement here, then libs and dlls generated with VS2010 are not binary compatible with VS2015-VS2019.
I think we don't just have a problem here due to the increased development effort with workarounds. We also have a security and stability issue with plugins created in "mixed" VS environments.
Edit to remove stupid, poorly thought-out suggestion.
But I've been using VS2019 and have not experienced any problems with any Qt calls at all.
If I remember correctly the one that crashes here was QItemSelectionModel::selectedRows(), which returns a QModelIndexList. It makes sense for that to crash when there are multiple C runtimes because the memory for the return value would get allocated in one runtime (the Daz core with the Qt libs) and then my code with the other runtime would try to free it. I'm sure there's other Qt calls with the same problem but that's the one I've run into. This is with VS2017 and C++14 enabled; it is probably possible to use VS2017 and share the runtime but I prefer to have modern C++ around.
I'm not sure why Dobit has problems with std::vector though because I'm not aware of any Qt calls that return STL containers. Qt uses their own container classes. All in all I don't see any security or stability issues.
A new SDK would still be good, if only to be able to access new DS features more easily. :-)
Could you put the AWS code in a separate .DLL that you reference in your plugin? (C# developer here so not sure if this works in C++).
We could do that, but the interfaces of the two DLLs remained incompatible (see the official Microsoft statement mentioned above).
Just an example:
Library function compiled with VC 2019:
const string & anyFunction() const;
Calling code compiled with VC 2010:
string xy=anyFunction();
This will crash or corrupt your heap, as soon as xy is released.
Therefore, more or less only atomic data types can be used in interface functions, which is not always easy (no vector, map, string).
I am not saying that it is impossible to use the DAZ SDK with newer compilers, but it is dangerous, in some cases complex to implement and not recommended by Microsoft.