| Date: | April 12, 2007 / year-entry #129 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070412-00/?p=27263 |
| Comments: | 14 |
| Summary: | It depends on what you mean by default. As we saw earlier, the convention for Windows header files is that if you don't specify a particular version, then you get the most recent version. The shell common controls header file follows this convention, so if you include the Windows XP version of commctrl.h, you get functions,... |
It depends on what you mean by default. As we saw earlier, the convention for Windows header files is that if you don't specify a particular version, then you get the most recent version. The shell common controls header file follows this convention, so if you include the Windows XP version of On the other hand, there's the question of what version of the shell common controls you actually get at run time. Prior to Windows XP, the answer was simple: You got the most recent version installed on the machine. With Windows XP, however, the rules changed. The visuals team wanted to do something more ambitious with the common controls, but the compatibility constraints also created significant risk. The solution was to use side-by-side assemblies. For compatibility, if a program didn't specify what version of the shell common controls it wanted, it got version 5.82, which was carefully designed for extremely high compatibility with the previous version, 5.81, which came with Windows 2000 and Windows Me. Now, version 5.82 is not completely identical to 5.81, because it also needs to interoperate with version 6. More on this later. If a program wanted to use version 6 of the common controls, it had to say so explicitly in a manifest. (What we on the shell team informally call a "v6 manifest".) That way, only programs that asked for the new behavior got it. The theory being that if you asked for the new behavior, you presumably tested your program against version 6 of the common controls to verify that it behaves as you expected. This freed up the visuals team to make more substantial changes to the common controls without having to worry about some old program that relied on some strange undocumented behavior of the common controls. That old program would get version 5.82, which was designed for high compatibility. Now, on that interoperability thing. There are places where the common controls library creates an object which you can then use with other common controls. For example, you can create an image list with Another example of this cross-version interoperability is the Okay, but back to the original problem. If you don't specify what version of the header file you want, then you get the latest version (version 6 if you got the header file from the Windows XP Platform SDK). On the other hand, if you don't specify what version of the DLL you want, you get version 5.82, the compatible version of the DLL. Yes, this is a mismatch. Be on the lookout. This is what happens when a header file convention is at odds with a compatibility decision. |
Comments (14)
Comments are closed. |
Meow.
Is 6 supposed to be backwards-compatible with 5.82? I’ve had problems with using 5.82 structures with 6. It is understandable if it isn’t, since I need a manifest to get 6.
Also, what’s the common controls version in Vista? Is it still 6?
By the way, I have to applaud the plunge you guys took regarding using SxS dlls for v5 vs. v6. I especially respect the “isolation aware” stuff, as it allowed DLL’s in our tools to use v6 features, while letting us take our time on transitioning everything else to v6.
I have to wonder, management-wise, how hard of a problem was the v5/v6 interop? Was it something that really manifested as an issue late in development, or was the full scope pretty much known at the beginning?
[v5/v6 interop was a huge undertaking. Your last question presents a false dichotomy. We knew up front that it would be a lot of work, but that doesn’t mean we understood the full scope up front. Do you ever know the full scope of a large undertaking before you begin? There are always unexpected problems that arise. -Raymond]
Oh, I get that, I was just curious the level of planning that goes into an undertaking like this. Like was it “well, we’ll need some interop” or was it down to the nitty gritty of “property pages will need to be cross compatible” ? Also, was the dll-isolation-support planned from the get-go, so something that came of incompatibilities after implementation began?
To me, it could just be an interesting case-study into planning-and-consequences of things at Microsoft. And since this is relatively recent, it seems a bit more relevant given the maturity of the platform as compared to design decisions on Win16 or Win32. I’m not trying to grill you, but it seems to be one of the more impressive and risky gambits given the huge size of windows, and a peephole as to how it was pulled off so well could be a decent learning experience.
[I can’t tell whether you’re asking me to write up the case study or you’re just speculating out loud. -Raymond]
If there is a case study in the offing that would be worth the price of addmission.
Of course, when the price of admission is nothing, anything at all (including nothing itself) is worth the price of admission… usually considerably more.
I use SysInternal/Microsoft ‘s listdll to check which dll is actually loaded at runtime.
[I can’t tell whether you’re asking me to write up the case study or you’re just speculating out loud. -Raymond]
Haha, I was asking _you_. :)
Raymond I’m sure he wasn’t asking you to write a white paper, he is,
like myself, just curious about how things like this work.
Unfortunatly there arn’t many people out there with this kind of
knowledge! Anyway just an idea for a future blog post if you feel
so inclined :)
I’d have to interview people. It’s not like I attend every meeting and
read every spec. A white paper is a lot more work than a blog post.
White papers take weeks to write, review, and approve. A blog post doesn’t even have to be true! -Raymond]
I have enough spare time to write a white paper for free. Of
course the paper has to be white to start with. Guess what colour
it will be when I’m done.
Anyway Jack Mathews was teasing you. He even wrote “haha” when teasing. I can’t believe I had to write this.
Speak of the devil.
> The solution was to use side-by-side assemblies.
"Some people, faced with a problem, say ‘I know what, I’ll use regular expressions. Then they have two problems."
s/regular expressions/side-by-side/g
> you can quickly find yourself in a case where
> there is a hodgepodge of v5 and v6 components
> all inside a single process, and they all have
> to work with each other
Then maybe that’s the only case where they really work. I do have to congratulate you on getting it working.
DLL Hell .Net is worse than DLL Hell Classic.[*]
[* Yeah this is the fourth time I’ve posted this in two days, but it’s still true.]
[And people think I’m silly for thinking that comments are directed at me. It seems rather presumptuous, don’t you think, to expect somebody to write a white paper in their spare time just because you asked them to? -Raymond]
Well I’m not holding my breath, but I at least wanted the request out there. At the very least, it may be something to expand on in further blog posts if you have the time. I would hope I’m speaking for a decent amount of people that finds this sort of talk interesting. Most of us don’t have the opportunity to work on projects with an impact on literally tens of millions of people.
That’s actually one of the more interesting threads on this blog for me, is seeing the butterfly effect of a lot of seemingly small changes/change requests. Most of the posts, though, are more in the vein of “we didn’t do this because,” so it’s a nice insight to see “we knew this would hurt, but we did it anyway.”
I’m not teasing anyone. I thought the reply was funny, because yeah, re-reading it did make it just seem like pointless out-loud speculation.
What are the implications of using run-time linking with LoadLibrary (with and without manifest) to get comctl32? Because there’s no version number in LoadLibrary(TEXT(“COMCTL32.DLL”)).