Saulius wrote:
Lets try. I am not sure about many things:
1, whether is better to duplicate code SHGetFolderPathW() or to try finding it by an ordinal its value (the case for the older versions of SHELL32.DLL) as it was stated by Juergen?
What are you trying to accomplish? For example, it seems reasonable to assert that you must use the builtin shell32 and shfolder.dll in combination, or not at all, as Alexandre once suggested. Or, in order for Wine's shfolder.dll to succeed on older (native) versions of shell32.dll, it seems reasonable to have it call SHGetSpecialFolderPath* from SHGetFolderPath*, as MS' version does.
In other words, why do you need the combination of native shell32 and builtin shfolder.dll?
--Juan
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
On Sun, 29 Aug 2004, Juan Lang wrote:
1, whether is better to duplicate code SHGetFolderPathW() or to try finding it by an ordinal its value (the case for the older versions of SHELL32.DLL) as it was stated by Juergen?
What are you trying to accomplish? For example, it seems reasonable to assert that you must use the builtin shell32 and shfolder.dll in combination, or not at all, as Alexandre once suggested.
Maybe it really sounds reasonable for those who know that there are only two functions exported by shlfolder.dll. Yesterday I wasn't aware of this and I was annoyed when Wine failed to run with "shfolder=n" set.
Or, in order for Wine's shfolder.dll to succeed on older (native) versions of shell32.dll, it seems reasonable to have it call SHGetSpecialFolderPath* from SHGetFolderPath*, as MS' version does.
I am sure shfolder.dll from win98se installation calls GetProcAddress() to get the address of SHGetFolderPathW @ shell32.dll. Moreover, my shell32.dll doesn't export SHGetSpecialFolderPath* by a name, also. Versions of the dlls I have are:
shfolder: 6.00.2600.000 shell32: 4.72.3812.600
What versions do you mention, Juan?
In other words, why do you need the combination of native shell32 and builtin shfolder.dll?
I would like to optimize Wine setup, where the optimization criterion is achieving as small amount of native dll code used as it can be possible (without loosing some required functionality).
And combination of native shell32+shdocvw+shlwapi dlls are needed for mIRC and TotalCommander to function more properly.
On Sun, 29 Aug 2004, Filip Navara wrote:
1, whether is better to duplicate code SHGetFolderPathW() or to try finding it by an ordinal its value (the case for the older versions of SHELL32.DLL) as it was stated by Juergen?
ShFolder is redistributable. I believe the best solution would be to move the code from Shell32 to ShFolder and then making the Shell32 exports forwarders to ShFolder.
=) Now there are 4 possible solutions to get mixing work:
1, try linking to SHGetFolderW @ shell32 dynamically - search it by a name or an ordinal value. Kind of smart autodetection (suggested by Juergen).
2, to copy the SHGetFolder* code from shell32.dll (Alexandre).
3, to move the SHGetFolder* code from shell32.dll (Filip).
4, try linking to SHGetSpecialFolderPath* @ shell32 dynamically (Juan).
IMHO the 3rd and the 4th solutions would fail when using native shell32.dll from win98se. Or maybe only the 4th case will do so.
Where I am wrong? What direction to go? Feel free to explain it.
Saulius Krasuckas saulius2@ar.fi.lt writes:
I would like to optimize Wine setup, where the optimization criterion is achieving as small amount of native dll code used as it can be possible (without loosing some required functionality).
And combination of native shell32+shdocvw+shlwapi dlls are needed for mIRC and TotalCommander to function more properly.
Then the proper way is to fix shell32 etc. so that these apps can run with the builtins. I don't think there's any reason to spend effort to allow all the shell dlls to be native except shfolder, that's not a meaningful configuration.
On Mon, 30 Aug 2004, Alexandre Julliard wrote:
Saulius Krasuckas saulius2@ar.fi.lt writes:
I would like to optimize Wine setup, where the optimization criterion is achieving as small amount of native dll code used as it can be possible (without loosing some required functionality).
And combination of native shell32+shdocvw+shlwapi dlls are needed for mIRC and TotalCommander to function more properly.
Then the proper way is to fix shell32 etc. so that these apps can run with the builtins.
You know it can take quite a long time, maybe several years. And I want to run the apps right now.
I don't think there's any reason to spend effort to allow all the shell dlls to be native except shfolder,
Lets say I am running out of space just for this 22 kBytes occupied by the native shfolder.dll. :-P
that's not a meaningful configuration.
So, you basically disagree with moving SHGetFolder[AW] code from shell32.dll to shfolder.dll, right?
Saulius Krasuckas saulius2@ar.fi.lt writes:
You know it can take quite a long time, maybe several years. And I want to run the apps right now.
Then use native shfolder. And no, I don't think it would take several years to fix the builtins, a lot of apps work fine with them today, they are not that bad.
So, you basically disagree with moving SHGetFolder[AW] code from shell32.dll to shfolder.dll, right?
I don't think it's going to solve the problem. Pretty much the only way to make it work right in all cases is to duplicate the whole thing, and I don't see any good reason to do that.
On Mon, 30 Aug 2004, Alexandre Julliard wrote:
Saulius Krasuckas saulius2@ar.fi.lt writes:
You know it can take quite a long time, maybe several years. And I want to run the apps right now.
Then use native shfolder. And no, I don't think it would take several years to fix the builtins, a lot of apps work fine with them today, they are not that bad.
OK, I agree and hope I was too desperate here.
So, you basically disagree with moving SHGetFolder[AW] code from shell32.dll to shfolder.dll, right?
I don't think it's going to solve the problem. Pretty much the only way to make it work right in all cases is to duplicate the whole thing, and I don't see any good reason to do that.
I'm having problem with the aesthetics of using native dlls. The less dlls are needed for me the better. Just it, pretty personal. And thanks for taking your time to explain this. Jumping to the native shell32.dll.
On Mon, 30 Aug 2004, Saulius Krasuckas wrote:
Jumping to the native shell32.dll.
Builtin, builtin. =)
-
Alexandre Julliard -
Juan Lang -
Saulius Krasuckas