Re: [PATCH] Version info for comctl32.dll
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.
1. 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
"gerard patel" <gerard.patel(a)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?
On Thu, 15 Mar 2001, Dmitry Timoshkov wrote:
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?
Where's the harm in resolving the imports of the builtin? In this case, the app has already loaded and used oleaut32 before it gets around to asking about its version.
I tried this patch, and unreverted the GetFileVersionInfo(Size) patch, but juno still isn't happy. With the native dll present, the app asks for its version info and gets the builtin. The ver trace looks a little strange to me - maybe it will make sense to you? About.exe returns the builtin oleaut32 version, but _only_ if the native oleaut32 is present (if I move it away, About.exe gets size 0), and only if it is given the native dll's filename. Give it the builtin filename and it gets size 0. I think the latter is probably not a problem, but it seems strange to me. It always astounds me how worked up msdose windose programs get about versions... Hmmm, msdose has a fairly systematic facility to lie to programs - IIRC, even to a different lie for each program - about version information. Maybe we need something along those lines (gaaa!). I am afraid juno actually wants to see verbatim the whole version block from oleaut32 - the install program for it does install one, right over whatever was there, for all it cares, so it may well consider any deviation fatal. I haven't looked at it in depth yet, but I may have to. Lawson This message is brought to you by Wine-20010305, junopine-2.0.2, Juno 2.0.11, and pine-4.10 ---cut here
<lawson_whitney(a)juno.com> wrote:
Now the question: How to load built-in dll without resolving its imports?
Where's the harm in resolving the imports of the builtin?
In this case, the app has already loaded and used oleaut32 before it gets around to asking about its version.
If the dll already loaded, then there is no harm at all. But if not, there is huge penalty in performance and memory usage. Take into account that currently built-in dlls are never unloaded. In the case of oleaut32, ole32 and advapi32 also will be loaded. If an application doesn't use them, but simply does query its version, there is more harm, than the good.
I tried this patch, and unreverted the GetFileVersionInfo(Size) patch, but juno still isn't happy. With the native dll present, the app asks for its version info and gets the builtin. The ver trace looks a little strange to me - maybe it will make sense to you?
About.exe returns the builtin oleaut32 version, but _only_ if the native oleaut32 is present (if I move it away, About.exe gets size 0), and only if it is given the native dll's filename. Give it the builtin filename and it gets size 0. I think the latter is probably not a problem, but it seems strange to me.
Strange, I tested my patch with About.exe and it worked for me. You could try replace version.rc by the following version resource, and to see if it will help (even better try to use both and report the result): oleaut32.dll from the original win95: FILEVERSION 2,10,3024,1 PRODUCTVERSION 2,10,3024,1 FILEFLAGSMASK 0x3F FILEFLAGS 0x0 FILEOS VOS_NT | VOS__WINDOWS32 FILETYPE VFT_DLL FILESUBTYPE 0x0 { BLOCK "StringFileInfo" { BLOCK "040904E4" { VALUE "CompanyName", "Microsoft Corporation" VALUE "FileDescription", "Microsoft OLE 2.1 for Windows NT(TM) Operating System" VALUE "FileVersion", "2.1" VALUE "InternalName", "OLEAUT32.DLL" VALUE "LegalCopyright", "Copyright c Microsoft Corp. 1993-1995." VALUE "LegalTrademarks", "MicrosoftR is a registered trademark of Microsoft Corporation. Windows NT(TM) is a trademark of Microsoft Corporation." VALUE "ProductName", "Microsoft OLE 2.1 for Windows NT(TM) Operating System" VALUE "ProductVersion", "2.1" VALUE "Comments", "Microsoft OLE 2.1 for Windows NT(TM) Operating System" } } BLOCK "VarFileInfo" { VALUE "Translation", 0x409, 1252 } } oleaut32.dll from the win2000 SP1: FILEVERSION 2,40,4514,1 PRODUCTVERSION 2,40,4514,1 FILEFLAGSMASK 0x3F FILEFLAGS VS_FF_PRERELEASE FILEOS VOS_NT | VOS__WINDOWS32 FILETYPE VFT_DLL FILESUBTYPE 0x0 { BLOCK "StringFileInfo" { BLOCK "040904E4" { VALUE "CompanyName", "Microsoft Corporation" VALUE "FileVersion", "2.40.4514" VALUE "InternalName", "OLEAUT32.DLL" VALUE "LegalCopyright", "Copyright c Microsoft Corp. 1993-1998." VALUE "ProductVersion", "2.40.4514" } } BLOCK "VarFileInfo" { VALUE "Translation", 0x409, 1252 } }
On Fri, 16 Mar 2001, Dmitry Timoshkov wrote:
Strange, I tested my patch with About.exe and it worked for me.
You could try replace version.rc by the following version resource, and to see if it will help (even better try to use both and report the result):
oleaut32.dll from the original win95:
I am sorry, I can't work out just now how to get this into the source and make it compile. Maybe tomorrow I will be a bit cleverer. Regards, Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
<lawson_whitney(a)juno.com> wrote:
Strange, I tested my patch with About.exe and it worked for me.
From the trace you sent me directly my patch works just fine.
You could try replace version.rc by the following version resource, and to see if it will help (even better try to use both and report the result):
oleaut32.dll from the original win95:
I am sorry, I can't work out just now how to get this into the source and make it compile. Maybe tomorrow I will be a bit cleverer.
I can send a patch if you wish :-). Basically you should add #include "winver.h" as the very first line and then copy completely all other strings starting with FILEVERSION 2,10,3024,1 ... etc. Since juno doesn't query some specific version value (according to your trace), but wants to get complete version info ... Ret version.1: GetFileVersionInfoA() retval=00000001 ret=12032703 fs=008f Call version.12: VerQueryValueA(40dd0f40,1207c090 "\\",40576db4,40576d6c) ret=12032750 fs=008f trace:ver:VerQueryValueA (0x40dd0f40,"\\",0x40576db4,0x40576d6c) Ret version.12: VerQueryValueA() retval=00000001 ret=12032750 fs=008f Call user32.226: GetActiveWindow() ret=120300c4 fs=008f Ret user32.226: GetActiveWindow() retval=00000000 ret=120300c4 fs=008f it would be great if you could experiment with changing version numbers: FILEVERSION 2,10,3024,1 ---> (in Wine it is 1,0,0,0) VALUE "FileVersion", "2.1" ---> (in Wine it is "1.0") and VALUE "ProductVersion", "2.1" ---> (in Wine it is "1.0") Make sure to change them all simultaneously.
On Fri, 16 Mar 2001, Dmitry Timoshkov wrote:
I can send a patch if you wish :-). Basically you should add #include "winver.h" as the very first line and then copy completely all other strings starting with FILEVERSION 2,10,3024,1 ... etc.
Nuts! Parse errors still, until I added VS_VERSION_INFO VERSIONINFO before it, then it compiles clean, but all values except Translation are null. So I tried with this dlls/oleaut32/version.rc, and it works (if you get this letter): #define WINE_FILEVERSION 2,20,4054,1 #define WINE_FILEVERSION_STR "2.20.4054" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" Those numbers I lifted from the output of wine --dll oleaut32=n About.exe oleaut32.dll I am still not easy in my mind with --dll directly controlling version in this way. Hmm, now About.exe is able to get the builtin version even if there is no native dll present. Maybe I was mistaken in that observation before. Probably I fat-fingered something.
Since juno doesn't query some specific version value (according to your trace), but wants to get complete version info ...
I guess it doesn't look at all of it though. I will try later with 2.20.4055 if this is a minimum or it wants the one it installed. Lawson First shoot the arrow. Then draw the bulls-eye. - J. A. Soucy ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
<lawson_whitney(a)juno.com> wrote:
Nuts! Parse errors still, until I added VS_VERSION_INFO VERSIONINFO before it, then it compiles clean, but all values except Translation are null. So I tried with this dlls/oleaut32/version.rc, and it works (if you get this letter):
#define WINE_FILEVERSION 2,20,4054,1 #define WINE_FILEVERSION_STR "2.20.4054" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll"
#include "wine/wine_common_ver.rc"
Very good! Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth?
Those numbers I lifted from the output of
wine --dll oleaut32=n About.exe oleaut32.dll
I am still not easy in my mind with --dll directly controlling version in this way.
--dll controls dll loading. Is it so hard to understand? Version info is retrieved from resources of the already loaded dll then.
On Sat, 17 Mar 2001, Dmitry Timoshkov wrote:
Very good! Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth?
Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on shortly.
--dll controls dll loading. Is it so hard to understand? Version info is retrieved from resources of the already loaded dll then.
I understand. I am a (pre GUI) programmer by nature. I just think we might have some trouble with it as more people try to use Wine and murkosloth tries harder to stop 'em. It looks lime in this case the app just doesn't want its oleaut32 reverted to an earlier version on it, which is reasonable, so maybe we won't. Lawson
---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
<lawson_whitney(a)juno.com> wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth?
Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on shortly.
Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
<lawson_whitney(a)juno.com> wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth?
Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on shortly.
Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
<lawson_whitney(a)juno.com> wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth?
Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on shortly.
Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
<lawson_whitney(a)juno.com> wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth?
Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on shortly.
Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
On Sat, 17 Mar 2001, Dmitry Timoshkov wrote:
I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
Yes. I can't promise it will work for other apps, and maybe in time we will have to go to "255.0" or something, but for now, 10.0 works for me. #define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" If you get this letter, it works. Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
<lawson_whitney(a)juno.com> wrote:
I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
Yes. I can't promise it will work for other apps, and maybe in time we will have to go to "255.0" or something, but for now, 10.0 works for me.
Great!
#define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll"
#include "wine/wine_common_ver.rc"
If you get this letter, it works.
I'm sorry, I didn't focus you on the subject that FILEVERSION and PRODUCTVERSION are distinctly different things? How about to experiment with different WINE_FILEVERSION and PRODUCTVERSION (WINE_FILEVERSION_STR and WINE_PRODUCRVERSION_STR) numbers? Sorry, if it is not the same as you expected from me...
On Sat, 17 Mar 2001, Dmitry Timoshkov wrote:
Great!
#define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll"
#include "wine/wine_common_ver.rc"
If you get this letter, it works.
I'm sorry, I didn't focus you on the subject that FILEVERSION and PRODUCTVERSION are distinctly different things? How about to experiment with different WINE_FILEVERSION and PRODUCTVERSION (WINE_FILEVERSION_STR and WINE_PRODUCRVERSION_STR) numbers?
Sorry, if it is not the same as you expected from me...
I am sorry, I am not understanding some thing[s]. I changed only WINE_FILEVERSION and WINE_FILEVERSION_STRING. All else is as it was set in include/wine/wine_common_ver.rc. I can't see that this includes any provision to make PRUDUCTVERSION variable. Shoukd I make one, in the manner of FILEVERSION? I don't think the app cares about it, at least it is content with 1,0,0,0 and "1.0", if I am reading this right. I will experiment with it anyway, in case it might help, and also test Gerard's patch shortly. Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
On Sat, 17 Mar 2001, Dmitry Timoshkov wrote:
I'm sorry, I didn't focus you on the subject that FILEVERSION and PRODUCTVERSION are distinctly different things? How about to experiment with different WINE_FILEVERSION and PRODUCTVERSION (WINE_FILEVERSION_STR and WINE_PRODUCRVERSION_STR) numbers?
Sorry, if it is not the same as you expected from me...
With wine_common_ver.rc changed as attached, and dlls/oleaut32/version.rc #define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_PRODUCTVERSION 10,1,0,0 #define WINE_PRODUCTVERSION_STR "10.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" Tha app still works, and I can't see that it matters to About.exe either. Is that what you meant? Regards, Lawson ---cut here
On Sat, 17 Mar 2001 lawson_whitney(a)juno.com wrote:
With wine_common_ver.rc changed as attached, and dlls/oleaut32/version.rc
#define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_PRODUCTVERSION 10,1,0,0
Oops, where did that ____________^ come from?
#define WINE_PRODUCTVERSION_STR "10.0"
It also still works with this as version.rc: #define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_PRODUCTVERSION 10,0,0,0 #define WINE_PRODUCTVERSION_STR "10.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
On Sat, 17 Mar 2001, Dmitry Timoshkov wrote:
Very good! Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth?
I think this is about as simple as I can get it: #define WINE_FILEVERSION 3,0,0,0 #define WINE_FILEVERSION_STR "3.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" Here is a test log: 2.20.4053 no 2.3 no 2.20.4054 yes 2.21 yes 3.0 yes 3 yes Just plain 3,0,0,0 "3" did work, but I have done enough debugging of other people's COBOL programs and enough other unrelated activity to have a dread of missing periods, so I would rather use "3.0", if it is all the same to you. Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
On Fri, 16 Mar 2001 lawson_whitney(a)juno.com wrote:
#define WINE_FILEVERSION 2,20,4054,1 #define WINE_FILEVERSION_STR "2.20.4054" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll"
#include "wine/wine_common_ver.rc"
I guess it doesn't look at all of it though. I will try later with 2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053, so I guess 2.20.2054 is its minimum oleaut32. Will you submit a patch for that, or should I? I haven't really looked at what you were doing with loader/module.c, but I've applied it and I don't see any harm from it, I think. Regards, Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
<lawson_whitney(a)juno.com> wrote:
I guess it doesn't look at all of it though. I will try later with 2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053, so I guess 2.20.2054 is its minimum oleaut32.
Will you submit a patch for that, or should I? I haven't really looked at what you were doing with loader/module.c, but I've applied it and I don't see any harm from it, I think.
Well, you can of course submit a patch for the oleaut32 version info. But it completely useless without loader/module.c modification if the requested built-in library was not yet loaded :-( I'll look at my patch ones more, split it into two distinct patches and submit them tomorrow.
<lawson_whitney(a)juno.com> wrote:
I guess it doesn't look at all of it though. I will try later with 2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053, so I guess 2.20.2054 is its minimum oleaut32.
Will you submit a patch for that, or should I? I haven't really looked at what you were doing with loader/module.c, but I've applied it and I don't see any harm from it, I think.
Well, you can of course submit a patch for the oleaut32 version info. But it completely useless without loader/module.c modification if the requested built-in library was not yet loaded :-( I'll look at my patch ones more, split it into two distinct patches and submit them tomorrow.
<lawson_whitney(a)juno.com> wrote:
I guess it doesn't look at all of it though. I will try later with 2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053, so I guess 2.20.2054 is its minimum oleaut32.
Will you submit a patch for that, or should I? I haven't really looked at what you were doing with loader/module.c, but I've applied it and I don't see any harm from it, I think.
Well, you can of course submit a patch for the oleaut32 version info. But it completely useless without loader/module.c modification if the requested built-in library was not yet loaded :-( I'll look at my patch ones more, split it into two distinct patches and submit them tomorrow.
<lawson_whitney(a)juno.com> wrote:
I guess it doesn't look at all of it though. I will try later with 2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053, so I guess 2.20.2054 is its minimum oleaut32.
Will you submit a patch for that, or should I? I haven't really looked at what you were doing with loader/module.c, but I've applied it and I don't see any harm from it, I think.
Well, you can of course submit a patch for the oleaut32 version info. But it completely useless without loader/module.c modification if the requested built-in library was not yet loaded :-( I'll look at my patch ones more, split it into two distinct patches and submit them tomorrow.
participants (3)
-
Dmitry Timoshkov -
gerard patel -
lawson_whitney＠juno.com