Mismatched Windows SDK versions
-
Google isn't really doing the needful here, plus as always it's full of arcane jargon that's only understandable if you already know the answer to the question, so even when I find something that looks relevant I'm not sure it answers my question. At least here if someone knows I'm sure I'll get a straightforward answer, even if that means being called a moron along the way
So, I'm developing a plugin for a third-party application and I'm looking at porting that to Windows (until now I've only worked with the Linux version of that app). From various sources, I've gathered that the application was compiled with the Windows 10 SDK version 10.0.15063 (somewhat old, but I don't care), whereas for my other dev needs I'm currently using 10.0.17763.
Now the obvious fix is (or rather was, since I've already done it) to install the 15063 version and work with that. No issue there, and therefore my question isn't a blocking issue at all, more of a curiosity thing.
So I'm wondering if I could actually compile my code with 17763 (or some other more recent version) and still be compatible with the third-party app? Or does linking with a given DLL (from the 3rd-party app) require using exactly the same SDK version?
-
@remi - Well, the answer is "it depends". Consider if you take on specific dependencies to 17762 and then the plug-in is run on a machine where only 15063 is installed....
-
I think the answer depends on what you do, i.e. how your plugin iteracts with the application. For example, if your plugin links (directly or indirectly) to a different version of the C runtime you can still make that work, but you must never transfer ownership through the API, i.e. there's two (or more) different heaps in your application and you have to call delete/free on the same side you called new/malloc. Similarly for everything else that's duplicated.
Basically, I think it might work as long as the two parts life mostly isolated side by side without one requiring to be ABI compatible with the other.
-
@topspin said in Mismatched Windows SDK versions:
Basically, I think it might work as long as the two parts life mostly isolated side by side without one requiring to be ABI compatible with the other.
Sounds unlikely to be the case. I mean, it depends on the plugins, some are pretty un-intrusive (with regard to the 3rd-party app) and might work, but on the whole, no, plugins aren't entirely isolated from the main application.
@TheCPUWizard said in Mismatched Windows SDK versions:
Consider if you take on specific dependencies to 17762 and then the plug-in is run on a machine where only 15063 is installed....
Good point. I should have clarified that right now I'm only looking at running on my machine (where I'm compiling), so both SDKs are installed. Packaging for redistribution... will happen one day, but it's not really my worry for now. Plus, I don't think it would be an issue as I would redistribute everything (my plugins + the 3rd-party app itself) and I guess that I could package (the redistrib of) 17763 in there as well.
-
@remi said in Mismatched Windows SDK versions:
I would redistribute everything (my plugins + the 3rd-party app itself) and I guess that I could package (the redistrib of) 17763 in there as well.
Only to Windows users? This is fine.
-
@remi said in Mismatched Windows SDK versions:
@topspin said in Mismatched Windows SDK versions:
Basically, I think it might work as long as the two parts life mostly isolated side by side without one requiring to be ABI compatible with the other.
Sounds unlikely to be the case. I mean, it depends on the plugins, some are pretty un-intrusive (with regard to the 3rd-party app) and might work, but on the whole, no, plugins aren't entirely isolated from the main application.
Then you can still make it work but have to be careful, e.g. pair allocation/dealloaction functions, use stable interfaces like C or COM API, beware not to break ODR, etc. Might not be worth the pain.
-
@topspin said in Mismatched Windows SDK versions:
Then you can still make it work but ... careful ... not ... worth the pain.
Excerpted for clarity. Care counterindicated. Release approved, deploy when ready.
-
@topspin said in Mismatched Windows SDK versions:
Might not be worth the pain.
Probably not, indeed. I have no specific reason to want to force-use the more recent version with my code, actually I don't care at all which SDK version it uses, so by far the easiest way is to simply use whatever the 3rd-party app wants (i.e. the older version).
-
@topspin said in Mismatched Windows SDK versions:
you have to call delete/free on the same side you called new/malloc
That's a very very good rule to have. You can usually get away without following it on non-Windows, but not always and it's not a good plan ever to break the rule. On Windows, it's absolutely critical that you follow the rule because having multiple heaps is more common there (due to the somewhat different way that memory allocation responsibility is distributed between the libraries in question).
