Fwd: [Wine] TrackPopupMenuEx not fully implemented

Steven Woody narkewoody at gmail.com
Thu Nov 16 20:51:14 CST 2006


FYI

---------- Forwarded message ----------
From: Steven Woody <narkewoody at gmail.com>
Date: Nov 17, 2006 10:17 AM
Subject: Re: [Wine] TrackPopupMenuEx not fully implemented
To: "L. Rahyen" <research at science.su>


On 11/16/06, L. Rahyen <research at science.su> wrote:
> On Thursday November 16 2006 05:56, you wrote:
> > i've read the wine doc got a confusion unclear, some part of the doc
> > say that c:\windows\system used to place fake Dlls which are only for
> > fooling some applications of file existence checking, native Dlls will
> > rather be used when the application really call the functions
> > associated with these fake Dlls.
>
>         Personally I don't recommend you put somewhere fake dlls. I even don't know
> real-world applications that really check for existence of files without
> checking content. Typically program wants to load dll. By default builtin dll
> is loaded. If there is no builtin dll, Wine searches native ones in system or
> system32 directories (also it searches current directory and other that in
> your path for searching dlls).
>         In simple words. You may safely copy all your dlls from Windows to Wine
> directories. This will not harm anything. But Windows have dlls that Wine
> havn't yet builtin like MFC (many applications need different versions of it)
> and others. If you want to copy every dll from Windows to Wine, good idea to
> copy them to system if Windows have them in system, and to system32 directory
> otherwise (and this is right for most dlls). Theoretically you can copy dlls
> to everywhere when Wine tries to find them, including current directory. But
> in practice some stupid applications tries to load dlls from typical Windows
> location instead to use standard API for load them. That means if dll locates
> in other place that is not typical for Windows, application will fail. This
> rare case, most application use legal API. But anyway I recommend you to put
> dlls in directories where Windows have them.
>         You can edit registry to set dll overrides or use winecfg. Using winecfg is
> trivial so I tell you how edit registry - this is faster if you have
> experience. Go in console and execute:
>         nano ~/.wine/user.reg
>         This opens my favorite console text editor. If you don't like console editors
> you may use GUI-editors like kate, kwrite, kedit or anything you like. If you
> use nano like me them press Ctrl+W (for GUI-editors Ctrl+F) and type
> "overr" (without quotes) and then enter. Now you see your dlls overrides. If
> you nothing found then you may want to paste "[Software\\Wine\\DllOverrides]
> 1156473935" somewhere you like and press enter (so now cursor is on new
> line).
>         Default setting for all dlls is "builtin,native" - that means if Wine have
> builtin it will use it and ignore native dlls if you put them to system or
> system32 directory. If there is no builtin it will try to find native one.
> This work well for most cases. But sometimes you want override this. For
> example I don't like builin comctl32 because it incorectly works if you use
> non-default color theme with Wine applications. So I type
> "comctl32"="native,builtin" - (WITH quotes - this is important) that means I
> want to load native dll if it exists and use builtin only if native one isn't
> found. If you followed this instructions you now have something like this
> within user.reg:
>
> WINE REGISTRY Version 2
> ;; All keys relative to \\User\\S-1-5-4
>
> [Software\\Wine\\DllOverrides] 1156473935
> "comctl32"="native,builtin"
>
> [Control Panel\\Colors] 1156502551
>
>         Other strings shown for clarity. Now if you put comctl32.dll from Windows to
> wine system or system32 directory it will load it instead of builtin one.
>         Also to be sure that dlls searched in directories where you placed them open
> ~/.wine/system.reg and search for
> "[System\\CurrentControlSet\\Control\\Session Manager\\Environment]" (without
> quotes). You must found below it something like this:
>
> "ComSpec"="c:\\windows\\system32\\wcmd.exe"
> "NUMBER_OF_PROCESSORS"="1"
> "OS"="Windows_NT"
> "PATH"="c:\\windows\\system32;c:\\windows"
>
>         You want to change "PATH" (with quotes). For example change it like this:
>
> "PATH"="c:\\windows\\system32;c:\\windows;c:\\windows\\system"
>
>         Now Wine will search current directory, C:\windows\system32, C:
> \windows\system and C:\windows for dlls and other files. This is recommended
> settings.
>
> > and, when will the wine really load them?
>
>         Good question. Run following command:
>
> WINEDEBUG="+loaddll" wine Program.exe
>
>         Where Program.exe your program. It will show now what dlls it use with
> program: builtin ones or native. Note that some dlls always builtin no mean
> what dll overrids you set. This is normal for ntdll, kernel32, user32 because
> native ones cannot be used anyway. Using this command you may easy see what
> dlls application uses and make sure that native dlls is used where you want.
>
>         Hope my instructions are helpful to you...
>

Dear Rahyen

thank you. i now totally understand and i am happy i've also learned
about how to bypass winecfg GUI.

please ignore another mail i post hours ago, your instruction has
already answered the question.

--
woody

then sun rose thinly from the sea and the old man could see the other
boats, low on the water and well in toward the shore, spread out
across the current.


-- 
woody

then sun rose thinly from the sea and the old man could see the other
boats, low on the water and well in toward the shore, spread out
across the current.



More information about the wine-users mailing list