At 10:10 AM 15/03/2001 +0800, you wrote:
I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls in ONE place.
Getting the common controls to the 4.72 version at least is the *whole* purpose of the patch. There are applications testing the version number of the common controls - tons of them : all the apps written with modern Borland tools. Their behaviour change accordingly because Ms changed things quite a lot with 4.72. Wine does not emulate the old behaviour, so it's needed to return a recent version number to get some apps to work correctly.
Unless the version number of winsock.dll, richedit.dll, version.dll, or unrelated dlls like that is always identical to the version number of common controls ? I did not check but that seems unlikely.
- I believe that version numbers should be equal in both numerical field and
in the string value (0.01 != 4.72 and 1.00 != 4.72). 2. There is no need for excessive \000 at the end of the string value. 3. All well behaving programs do read "VarFileInfo"/"Translation" before retrieving other version information. LANGUAGE does nothing here. 4. Did you try to use my sample application showing version info? 5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve as an example of adding version resources into built-in dlls.
Well, all right I'll do like it's done in include/wine. I did not search far enough, I used the file in commdlg as an example :-)
I found another problem you missed btw, there is a special function to retrieve the dll version directly, it returns hard coded values; I'll add code to retrieve these from the resource.
Gerard