"Dimitrie O. Paun" dpaun@rogers.com wrote:
- This code was audited for completeness against the documented features
- of Comctl32.dll version 6.0 on Oct. 3, 2004, by Dimitrie O. Paun.
"Button" is a built-in user32 control and has nothing to do with comctl32 at all. Same for all other controls in the dlls/user/ subdirectory.
Dmitry Timoshkov wrote:
"Dimitrie O. Paun" dpaun@rogers.com wrote:
- This code was audited for completeness against the documented features
- of Comctl32.dll version 6.0 on Oct. 3, 2004, by Dimitrie O. Paun.
"Button" is a built-in user32 control and has nothing to do with comctl32 at all. Same for all other controls in the dlls/user/ subdirectory.
That was true up until Windows XP. All of the built-in user32 controls have now been copied into comctl32 and extended.
Rob
"Robert Shearman" rob@codeweavers.com wrote:
"Button" is a built-in user32 control and has nothing to do with comctl32 at all. Same for all other controls in the dlls/user/ subdirectory.
That was true up until Windows XP. All of the built-in user32 controls have now been copied into comctl32 and extended.
I can't believe that a simple win32 program linked against user32 only under XP starts to depend on comctl32 as well. user32 in XP can't depend on comctl32 too. "Button", "listbox", "combobox" and others were always a part of user32, moving them into comctl32 would break a lot of apps. Perhaps comctl32 simply subclasses standard user32 controls and adds "skinning" for them?
On Mon, Oct 04, 2004 at 10:39:24PM +0900, Dmitry Timoshkov wrote:
I can't believe that a simple win32 program linked against user32 only under XP starts to depend on comctl32 as well. user32 in XP can't depend on comctl32 too. "Button", "listbox", "combobox" and others were always a part of user32, moving them into comctl32 would break a lot of apps. Perhaps comctl32 simply subclasses standard user32 controls and adds "skinning" for them?
I think they just made a copy into comctl32, but this is more of a gut feel than anything else :) Anyway, MS now documents the standard controls together with the common ones (which makes sense, logically they belong together, they are all controls after all), so my comment is OK for its purpose (which is to correctly identify the piece of documentation that the audit was against).
"Dimitrie O. Paun" dpaun@rogers.com wrote:
I think they just made a copy into comctl32, but this is more of a gut feel than anything else :) Anyway, MS now documents the standard controls together with the common ones (which makes sense, logically they belong together, they are all controls after all), so my comment is OK for its purpose (which is to correctly identify the piece of documentation that the audit was against).
No, your comment is not OK. You are documenting a user32 control, not a comctl32 one. You didn't even confirm where it resides now in XP. I bet it's still in user32.
On Mon, Oct 04, 2004 at 10:58:14PM +0900, Dmitry Timoshkov wrote:
No, your comment is not OK.
Actually, it is. Check out the URL for the button docs: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...
See? Button is under commctls.
I bet it's still in user32.
You're on. And I win: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...
Again, now MS documents all controls together, please check out the on line MSDN.
"Dimitrie O. Paun" dpaun@rogers.com wrote:
Again, now MS documents all controls together, please check out the on line MSDN.
How could that matter where MS does document things? That fact changes nothing in the actual control functionality or DLL ownership.
user32 is a low level DLL which can't depend on anything else besides ntdll/kernel32/gdi32 while comctl32 is a high level one.
On Tue, Oct 05, 2004 at 09:19:10AM +0900, Dmitry Timoshkov wrote:
"Dimitrie O. Paun" dpaun@rogers.com wrote:
Again, now MS documents all controls together, please check out the on line MSDN.
How could that matter where MS does document things? That fact changes nothing in the actual control functionality or DLL ownership.
Oh come on, I've explained that already: the comment's purpose is to identify the *documentation* that the code has been audited against. Which is the commctl 6.0 documentation. This is where MS says the standard controls reside in XP, what's the problem?
"Dimitrie O. Paun" dpaun@rogers.com wrote:
I've explained that already: the comment's purpose is to identify the *documentation* that the code has been audited against. Which is the commctl 6.0 documentation. This is where MS says the standard controls reside in XP, what's the problem?
The problem is that the documentation is misleading (intentionally or not it doesn't matter), and following a wrong doc is not what we want to do in Wine.
Dmitry Timoshkov wrote:
"Dimitrie O. Paun" dpaun@rogers.com wrote:
I've explained that already: the comment's purpose is to identify the *documentation* that the code has been audited against. Which is the commctl 6.0 documentation. This is where MS says the standard controls reside in XP, what's the problem?
The problem is that the documentation is misleading (intentionally or not it doesn't matter), and following a wrong doc is not what we want to do in Wine.
I'm sorry for butting in on this. I don't understand your problem either. Dimi didn't change the location of the code - it's still in user32. Our dependencies won't change as a result of his patch, and it therefor follows that no program will break as a result of this comment.
What he did do, however, is carefully read the docs to find out how nuances work. He then proceeded to audit our code to make sure that it conforms. When you do such an audit, you do it against the docs, wherever they may be.
In this case, Dimi used version 6.0 of the comctl32.dll documentation. It can hardly be his fault that that's where the docs for button controls are. I don't think any amount of patch sending or arguing on our part is going to persuade Microsoft to move the docs elsewhere. Personally, I also see value in documenting what version of the docs the audit was performed against, so that future mismatches can be tracked down.
Can you suggest a better way to write the comment?
Shachar
P.S. Such comments do suffer from another problem. They tend to fall out of date. For that reason alone I'm not sure this comment is a good idea. Otherwise, we get a future commit that changes something, but neglects to update the comment accordingly, and the comment turns useless or even dangerous. Maybe if we change that to contain the date or the CVS version number of the file that was audited....
"Shachar Shemesh" wine-devel@shemesh.biz wrote:
In this case, Dimi used version 6.0 of the comctl32.dll documentation. It can hardly be his fault that that's where the docs for button controls are. I don't think any amount of patch sending or arguing on our part is going to persuade Microsoft to move the docs elsewhere. Personally, I also see value in documenting what version of the docs the audit was performed against, so that future mismatches can be tracked down.
Can you suggest a better way to write the comment?
I didn't oppose a comment itself, I don't like that it confuses people by mentioning comctl32. That's simply not true. I'd suggest to omit that single line of the comment, that's all. Again, that's the user32 code, and it really doesn't matter where MS has decided to put the docs for it. As I see it, the docs for all the controls were just moved to a single place for an easy access, that place happened to be under the comctl32 section.
Dmitry Timoshkov wrote:
I didn't oppose a comment itself, I don't like that it confuses people by mentioning comctl32. That's simply not true. I'd suggest to omit that single line of the comment, that's all. Again, that's the user32 code, and it really doesn't matter where MS has decided to put the docs for it.
But how would someone reading the comment find the docs? Especially if the code is in User32 and docs are in comctl. Also, it would appear to me that you can't say "version 6" without saying version 6 of what.
Shachar
"Shachar Shemesh" wine-devel@shemesh.biz wrote:
But how would someone reading the comment find the docs?
By searching MSDN. The docs are being changed everytime, and providing even an URL one can't guarantee that the address will exist next time you try to access it.
Especially if the code is in User32 and docs are in comctl. Also, it would appear to me that you can't say "version 6" without saying version 6 of what.
Yes, that's clearly another confusion. Even you, the developer, have no idea why the words "version 6" are there. That's why they have to be removed.
On Tue, Oct 05, 2004 at 07:32:18PM +0900, Dmitry Timoshkov wrote:
I didn't oppose a comment itself, I don't like that it confuses people by mentioning comctl32. That's simply not true.
Dmitry, please stop repeating misinformation. Go read the MSDN, I've provided you with the relevant URLs. Here is the situation: -- in XP, there are *two* implementations of the standard controls: the old one in user32, and a strict superset, in comctl32. Applications can ask for the one in comctl32 by specifying so in their manifest file. This is done so that applications continue to run on older versions of Windows. -- since we don't have the same constrains as MS, and since we can't afford to maintain two versions of the standard controls, we are just going to extend the ones from user32 to the full capability of the ones in comctl32 ver. 6. As such, it make sense to audit them against the comctl32 ver. 6 documentation.
In other words, the comment is right on the money.
Dimitrie O. Paun wrote:
-- since we don't have the same constrains as MS, and since we can't afford to maintain two versions of the standard controls, we are just going to extend the ones from user32 to the full capability of the ones in comctl32 ver. 6. As such, it make sense to audit them against the comctl32 ver. 6 documentation.
How do you plan on using image lists from user32? How will you make sure that the version 6 behaviour doesn't break older programs? It's these questions that made Microsoft move the controls to comctl32. Will we get ourselves into a bigger mess by not having two separate implementations?
Rob
On Tue, Oct 05, 2004 at 02:59:35PM +0100, Robert Shearman wrote:
How do you plan on using image lists from user32? How will you make sure that the version 6 behaviour doesn't break older programs? It's these questions that made Microsoft move the controls to comctl32. Will we get ourselves into a bigger mess by not having two separate implementations?
I don't dispute that our current approach is not perfect. You are right, there may be some problems with it, and in the long term, we may have to duplicate them. However, doing so mow would imply a lot of work, and as you can see, we're way short of manpower. From what I've seen, we can safely implement most of the XP functionality into the user32 without risking of breaking stuff. That is to say, I don't see right now a big need to dupicate the controls. Let's cross that bridge when we get there.
"Dimitrie O. Paun" dpaun@rogers.com wrote:
I didn't oppose a comment itself, I don't like that it confuses people by mentioning comctl32. That's simply not true.
Dmitry, please stop repeating misinformation. Go read the MSDN, I've provided you with the relevant URLs. Here is the situation: -- in XP, there are *two* implementations of the standard controls: the old one in user32, and a strict superset, in comctl32. Applications can ask for the one in comctl32 by specifying so in their manifest file. This is done so that applications continue to run on older versions of Windows.
You still didn't provide anything to prove that comctl32 in XP simply does not subclass user32 button. I repeat that there is *one* button implementation is user32, and comctl32 most likely simply add theming to it by providing custom drawing code. That has nothing to do with statements you repeat, and the comments about comctl32 you have added to the *user32* code in Wine.
-- since we don't have the same constrains as MS, and since we can't afford to maintain two versions of the standard controls, we are just going to extend the ones from user32 to the full capability of the ones in comctl32 ver. 6. As such, it make sense to audit them against the comctl32 ver. 6 documentation.
Once you really add button support to comctl32 you can safely add comments like the one you did there. But until then that's a pure speculation based on the MS documentation which was proved wrong many times already.
Dmitry Timoshkov wrote:
"Dimitrie O. Paun" dpaun@rogers.com wrote:
I didn't oppose a comment itself, I don't like that it confuses people by mentioning comctl32. That's simply not true.
Dmitry, please stop repeating misinformation. Go read the MSDN, I've provided you with the relevant URLs. Here is the situation: -- in XP, there are *two* implementations of the standard controls: the old one in user32, and a strict superset, in comctl32. Applications can ask for the one in comctl32 by specifying so in their manifest file. This is done so that applications continue to run on older versions of Windows.
You still didn't provide anything to prove that comctl32 in XP simply does not subclass user32 button. I repeat that there is *one* button implementation is user32, and comctl32 most likely simply add theming to it by providing custom drawing code.
This is impossible. You can only subclass using a window with a different class name or a window of the same class name with the previous class unregistered and using the old window proc with identical class attributes. Since the class name is the same for both the old user32 controls and the new comctl32 controls then the first method cannot be used. Since the old window proc is not exported from user32 (and with good reason) the second cannot be used.
Rob
"Robert Shearman" rob@codeweavers.com wrote:
This is impossible. You can only subclass using a window with a different class name or a window of the same class name with the previous class unregistered and using the old window proc with identical class attributes. Since the class name is the same for both the old user32 controls and the new comctl32 controls then the first method cannot be used. Since the old window proc is not exported from user32 (and with good reason) the second cannot be used.
SetClassLongPtr(GCLP_WNDPROC) in the CBT(HCBT_CREATEWND) hook set by comctl32 on DLL attach would suffice I think.
On Tue, Oct 05, 2004 at 08:18:50AM +0200, Shachar Shemesh wrote:
Such comments do suffer from another problem. They tend to fall out of date. For that reason alone I'm not sure this comment is a good idea. Otherwise, we get a future commit that changes something, but neglects to update the comment accordingly, and the comment turns useless or even dangerous. Maybe if we change that to contain the date or the CVS version number of the file that was audited....
This is not a problem for these comments because: -- each control is implemented in one, and only one file -- each control has it's own independent audit -- the comment is at the top of the file, where it's most visible -- from the previous 3 points, it's very difficult to work on any control without stumbling upon it. -- it includes the exact version of the documentation, so when new documentation is released, we can compute the delta -- it includes the exact date when the audit took place, so we can compute deltas on the control side -- they are not open ended. That is, they list all the missing features, and such, if people forget to update them, 99% of the time this simply means they forgot to *delete* something. This is much less of a problem then not adding. It can easily get fixed when someone does a new audit, or wants to reimplement that feature. -- we had them for more then 2 years now, and there wasn't a single instance when people forgot to update them. Which means that the theory detailed this far actually works in practice. -- I've been closely watching patches againt controls myself (along with a few other people, it seems), so we have a pretty good safety net.
Hi,
On Mon, Oct 04, 2004 at 10:39:24PM +0900, Dmitry Timoshkov wrote:
"Robert Shearman" rob@codeweavers.com wrote:
That was true up until Windows XP. All of the built-in user32 controls have now been copied into comctl32 and extended.
I can't believe that a simple win32 program linked against user32 only under XP starts to depend on comctl32 as well. user32 in XP can't depend on comctl32 too. "Button", "listbox", "combobox" and others were always a part of user32, moving them into comctl32 would break a lot of apps. Perhaps comctl32 simply subclasses standard user32 controls and adds "skinning" for them?
I was also unaware of that. Whatever is the case here, it'd be useful to have it documented in button.c once it's obvious what the relationship of user32 buttons and comctl32 is.
Andreas Mohr
-
Andreas Mohr -
Dimitrie O. Paun -
Dmitry Timoshkov -
Robert Shearman -
Shachar Shemesh