30 Aug
2004
30 Aug
'04
2:04 a.m.
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
30 Aug
30 Aug
7:43 a.m.
New subject: mixing SHELL32.DLL and SHFOLDER.DLL
On Sun, 29 Aug 2004, Juan Lang wrote:
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.
=) 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.
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.
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. 
3:21 p.m.
New subject: mixing SHELL32.DLL and SHFOLDER.DLL
Saulius Krasuckas <saulius2(a)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.
--
Alexandre Julliard
julliard(a)winehq.org
4:25 p.m.
New subject: mixing SHELL32.DLL and SHFOLDER.DLL
On Mon, 30 Aug 2004, Alexandre Julliard wrote:
Saulius Krasuckas <saulius2(a)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.
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,
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?
4:42 p.m.
New subject: mixing SHELL32.DLL and SHFOLDER.DLL
Saulius Krasuckas <saulius2(a)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.
--
Alexandre Julliard
julliard(a)winehq.org
6:32 p.m.
New subject: mixing SHELL32.DLL and SHFOLDER.DLL
On Mon, 30 Aug 2004, Alexandre Julliard wrote:
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.
Saulius Krasuckas <saulius2(a)ar.fi.lt> writes:
OK, I agree and hope I was too desperate here.
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.
7202
days inactive
7202
days old
6 comments
3 participants
participants (3)
-
Alexandre Julliard -
Juan Lang -
Saulius Krasuckas