"gerard patel" gerard.patel@asi.fr wrote:
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.
Sure. The same should be done at least for OLE dlls too.
[...]
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.
Thanks.
On the related note: Lawson Whitney reported that juno 2.0.11 checks version info of oleaut32.dll and with my recent patch (which has disabled searching of version resources if dll was loaded but version resources were not found) refuses to load.
Well, I added version info into built-in oleaut32.dll, but here another problem arised: LoadLibraryExA explicitly checks for LOAD_LIBRARY_AS_DATAFILE, and then uses SearchPathA to locate a dll. Since SearchPathA can't find built-in dlls LoadLibraryExA returns 0.
With the attached patch my test program is now able to retrieve version info for built-in oleaut32.dll, but I didn't manage to avoid resolving imports for built-in dlls, because they are register themself from the code generated by winebuild.
I tried to propagate 'flags' starting from BUILTIN_LoadLibraryExA, but failed.
Now the question: How to load built-in dll without resolving its imports?