Salius wrote:
> 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.
Hm. I'm sorry, I wasn't clear enough. From MSDN on
SHGetFolderPath:
This function is a superset of SHGetSpecialFolderPath,
included with earlier versions of the Shell. On
systems preceeding those including Shell32.dll version
5.0 (Windows Millennium Edition (Windows Me) and
Windows 2000), SHGetFolderPath was obtained through
SHFolder.dll, distributed with Microsoft Internet
Explorer 4.0 and later versions. SHFolder.dll always
calls the current platform's version of this function.
If that fails, it will try to simulate the appropriate
behavior.
So, I think your patch is a good first step, to use
GetProcAddress rather than letting the linker do it.
A next step would be, I think, to do what I suggested:
if this fails, try to GetProcAddress for
SHGetSpecialFolderPath, since this was available on
older versions of shell32. You might have to search
by ordinal if searching by name fails.
So, I don't think my suggestion is that different from
Juergen's, just that I suggest an implementation of
"try to simulate the appropriate behavior" if the
function is not in fact in shell32.
--Juan
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
I'm trying to fight spam like anybody else, and first thing is to remove mail
adresses from every page on the internet.
A google search on my adress shows only 2 pages where i compare, they both
come frome wine archive:
http://www.winehq.com/hypermail/wine-devel/2003.04.txthttp://www.spinics.net/lists/wine/msg08863.html
Is there a way to make them remove from there?
Just a suggestion: i'm conscious that mail adress need to be post into such a
mailing list, but wouldn't be good to keep a script running that alter them
into something like 'myname {at} mydomain' ?
Just a little sacrifice for everybody to help fighting spam.
Think about.. pls...
--
Davide Giannotti
ITS Planet s.n.c
davide.giannotti {at} itsplanet.comwww.itsplanet.com
>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
Dmitry> Hello, installer of Quicken depends on last error values set by
Dmitry> GetFileVersionInfoSize and expects them to be set to something
Dmitry> different than ERROR_RESOURCE_DATA_NOT_FOUND set on NT
Dmitry> platforms.
Dmitry> I hope that there is no need to introduce several code paths
Dmitry> depending on the GetVersion return value.
A test programm for our test suite will easily show (and document) that
behaviour.
Bye
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes wrote:
> Changelog
> windows/winproc.c: WINPROC_wrapper
> Add some padding between saved registers and the winproc
> arguments. Some winprocs may trash the register area.
>
> As Mike Hearn suggested, adding some padding helped with my problem with
> WebPACK_42wp30_full_installer.exe. I hope, I found the right way to add that
> padding.
It may work for one application, but it doesn't look like a propper fix.
I'd suggest there's probably something else going on that's causing
stack corruption.
Mike
Shachar Shemesh <wine-patches(a)shemesh.biz> writes:
> After much talk, the patch seems ready for commit. Since there are many
> systems with slightly older glibc that have the header but do not have
> the implementation in glibc, or that have a stub implementation that is
> guaranteed to fail, we are calling the kernel functions directly. This
> also allows compiling on older systems than the code actually ships to.
>
> Accordingly, the autoconf checks for epoll_create in glibc were dropped.
That's wrong; if the libc function exists you should use it, direct
system calls should only be used as a fallback. And when using system
calls you must not depend on the libc header, you have to define the
structures yourself.
--
Alexandre Julliard
julliard(a)winehq.org
Not knowing how much off topic this would be, I just thought I paste a
link here:
http://registry.sourceforge.net/
These people seem to be implementing a kinda Windows registry clone into
Linux, but then secure, stable 'n' stuff...
Since the many registry implementation discussions here, I thought, why
not throw this into the discussion too? It might be worth to take a look
here and perhaps think about using some of their stuff.
Greetings,
Robert van Herk
Francois Gouget <fgouget(a)free.fr> writes:
> This actually calls for two more notes:
> * This looks very much what one would get by calling the corresponding
> functions in shlwapi (which seems much more complete). However in
> shell32 there is talk of sending messages around (WM_USER+2) so maybe
> it's the same concept but a different implementation?
The WM_USER+2 thing is something a specific caller was doing, it's not
part of the function itself. I think the shell32 functions should
simply forward to the shlwapi ones.
--
Alexandre Julliard
julliard(a)winehq.org
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