[Bug 18089] New: import_dll should check SharedDLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Summary: import_dll should check SharedDLLs
           Product: Wine
           Version: 1.1.19
          Platform: Other
        OS/Version: other
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ntdll
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

import_dll should lookup in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls for
matching library, if it can't find it anywhere else.

Here's how I came to this: there are lots of programs that don't start in wine
unless you do special tricks, such as copying dlls to folder where the .exe
resides or to system32, or something else. If you search the bugzilla for
import_dll, you'll find a lot of bugs having this kind of errors:

err:module:import_dll Library something.dll not found

Mostly, questions arise as if software has installed correctly or something
else. But, I've made a test, installing it in windows, and launching directly,
that is without specifying "start in" parameter (as it would with .lnk files).
And in windows it works perfectly.

So, I've exported the registry from XP box and compared it to identical
installation in wine. The only mentions of dlls in question are in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls

Google says, that this registry node is supposed only to track if installed
libraries are used by any installed application or not.

But it seems, that in windows, ntdll looks up into this registry part in order
to try to find where the libraries in question are located.

This would fix quite a lot of problems.

[Bug 18089] import_dll should check SharedDLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 18089] import_dll should check SharedDLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #1 from Vitaliy Margolen   2009-04-18 11:29:26 ---
How exactly are you starting your app? With lnk? Does it work if you run it
from cmd?

[Bug 18089] import_dll should check SharedDLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #2 from Igor Tarasov   2009-04-18 11:57:25 ---
Say, we have an application, that has it's exe files located in c:\exes\ and
dlls in c:\exes\dlls. When it is being installed, all executables and libraries
from both c:\exes and c:\exes\dlls and subfolders get recoreded in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls and
nowhere else.

So, installer creates .lnk files that have "start in" parameter having
"c:\exes\dlls". Wine converts it to .desktop correctly. Which, does not work
well in some systems. See
http://www.winehq.org/pipermail/wine-devel/2009-April/074763.html

Now, if you start the app using desktop launcher, it works well. But if you
start the app by double-clicking the exe, or calling it from shell, wine won't
launch it and you get "err:module:import_dll Library something.dll not found"
errors. The only way to launch it is either to use .lnk with "wine start
link.lnk", or by cd to work dir an launching app from there, or by copying dlls
in question to some folder within PATH scope.

However, in windows application get started well with both .lnk and
double-clicking the .exe. That means that in windows import_dll somehow manages
to find dlls.

I thought that there might be some differencies in registry values. But as I
said, the only place where you can find any notice of these dlls is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls in both
wine and windows registries.

[Bug 18089] import_dll should check SharedDLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|ntdll                       |-unknown

--- Comment #3 from Dmitry Timoshkov   2009-04-19 18:51:28 ---
That's not a problem in Wine, and not particularly with import_dll().
If you start the program in Windows from a command prompt from c:\exes
it won't start either, starting from c:\exes\dlls will work just fine.

That's usually a bug in the application which depends on a particular
current directory.

[Bug 18089] import_dll should check SharedDLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #4 from Igor Tarasov   2009-04-19 19:32:33 ---
Interesting. Launched VirtualBox, yep, it does not work when running from cmd.
But how is it able to start it from explorer?

Wine lacks this functionality, since there is no way to launch application this
way from either linux desktop enviroment, by clicking exe, nor from winefile.

[Bug 18089] import_dll should check SharedDLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #5 from Dmitry Timoshkov   2009-04-19 19:42:00 ---
'wine start link.lnk' as you said is the only way. This works in Windows
explorer.exe because explorer interprets .lnk files, it won't work if you
click in explorer on an .exe instead of an .lnk.

[Bug 18089] import_dll should check SharedDLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Dmitry Timoshkov   2009-04-19 19:42:28 ---
Closing.

[Bug 18089] import_dll should check SharedDLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Igor Tarasov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |UNCONFIRMED
         Resolution|INVALID                     |

--- Comment #7 from Igor Tarasov   2009-04-19 19:53:03 ---
Dmitry, I've just tested it under VirtualBox. And it DOES work.

It DOES NOT work when you run exe from cmd.

But it DOES work when you double click the same exe (not lnk!) in explorer. I
don't know how explorer does that, but it does.

So, in windows, explorer somehow changes environment to what is required for
for that application to run. And it works with both lnk and direct exe launch.

Neither winefile nor any DE integration of wine can't do that for now.

Is it worth reopening this bug?

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|import_dll should check     |Windows explorer.exe is able
                   |SharedDLLs                  |to lunch .exe files which
                   |                            |refer another directory with
                   |                            |DLLs

--- Comment #8 from Dmitry Timoshkov   2009-04-19 19:58:49 ---
(In reply to comment #7)
> Is it worth reopening this bug?

Only if you are going to investigate how Windows explorer does it :-)
Does it work if you (re)move .lnk before clicking on an .exe?

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #9 from Igor Tarasov   2009-04-19 20:27:04 ---
Gotcha! Thanks goes to Mark Russinovich for his great Regmon ;)

Deleting links did not work, but regmon helped. All the magic is here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

There are folders per each application. And each such folder can have various
parameters, one of which is (tada!) Path.

So, that's how Explorer does that magic :)

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Vincent Povirk  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #10 from Vincent Povirk   2009-04-19 20:54:35 ---
That's reverse-engineering, isn't it?

In any case, "App Paths" is documented so I think using this hint is OK:
http://msdn.microsoft.com/en-us/library/cc144150(VS.85).aspx

According to MSDN, this needs to be implemented in ShellExecute* (component
should be shell32). Once that's implemented, double-clicking or using wine
start should work, but changing to the application directory and running "wine
program.exe" should not, as that's analogous to windows cmd.

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #11 from Vitaliy Margolen   2009-04-19 21:09:53 ---
Wine already has all that implemented. From terminal run:
cd ~; wine start program.exe

This bug is invalid. You see exactly the same behavior as on windows.

The only possible valid point - Wine doesn't create proper .lnk & .desktop
files. They always specify full path and work directory.

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #12 from Vitaliy Margolen   2009-04-19 21:17:57 ---
To make this a valid bug, Igor what exactly were you trying to lunch? How was
it installed?

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #13 from Igor Tarasov   2009-04-19 21:18:27 ---
(In reply to comment #10)
> That's reverse-engineering, isn't it?

Really? Never thought so. Anyway, I've downloaded that piece of software from
MS site: http://technet.microsoft.com/en-us/sysinternals/bb896652.aspx This is
just a logger. If this is reverse-engineering, then studying logs produced by
wine is too, since it records calls that are produced by third party software.

(In reply to comment #11)
> Wine already has all that implemented. From terminal run:
> cd ~; wine start program.exe

Nope, didn't work, I've got import_dll error, as usual.
> This bug is invalid. You see exactly the same behavior as on windows.

Then why double-clicking programs from winefile does not work (it does not
change the environment according to App Paths registry data)? Why 'wine start
app.exe' does not work?
> The only possible valid point - Wine doesn't create proper .lnk & .desktop
> files. They always specify full path and work directory.

.desktop files do work well, since they have Path specified.

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #14 from Igor Tarasov   2009-04-19 21:22:10 ---
(In reply to comment #12)
> To make this a valid bug, Igor what exactly were you trying to lunch? How was
> it installed?

It's Watchtower Library, installed via installer that worked perfectly, created
working launchers and (!) App Paths registry keys. All in place. But wine
start, or winefile doubleclick does not work.

I'll try to find another piece of software that suffers the same pain. As I've
told, I've already seen similar reports here in bugzilla (mostly ignored, since
sometimes such error are really due to bad installer or wrong user actions).

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #15 from Igor Tarasov   2009-04-19 22:30:00 ---
Ok, just a quick search:

http://bugs.winehq.org/show_bug.cgi?id=7583 (Autodesk AutoSketch)
http://bugs.winehq.org/show_bug.cgi?id=17952 (Autodesk Inventor 11)

http://bugs.winehq.org/show_bug.cgi?id=17374 (Adobe Framemaker 9)
http://bugs.winehq.org/show_bug.cgi?id=17812 (Enemy Territory: Quake Wars
EditWorld)

Not sure if all of these bugs have this exact problem, but symptoms are
similar.

And generally, users won't notice that problem, unless they try to launch
program directly, or have broken .desktop file, or use XFCE (which does not
support Path option in .desktop files). So, there won't be much bugreports.

This is common for software that has this kind of file structure and need to be
have commonfiles as working dir:

Program Files\
              Vendor\
                     CommonFiles\
                     Product A\
                     Product B\
                     Product C\
                     etc...

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #16 from Igor Tarasov   2009-04-21 12:44:08 ---
(In reply to comment #13)
> (In reply to comment #11)
> > Wine already has all that implemented. From terminal run:
> > cd ~; wine start program.exe
>
> Nope, didn't work, I've got import_dll error, as usual.

Well, I was wrong here. I typed full path and this did not work, and this does
not work in Windows too. Starting program without specifying it's full path
works.

Okay then, the only problem there really is, is in winefile. I think this might
be because winefile launches all files with full paths?

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #17 from Vitaliy Margolen   2009-04-21 20:00:08 ---
Closing invalid - everything is valid and operates as intended.

Next time do _exactly_ what asked to not waste everyone's time.

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #18 from Vitaliy Margolen   2009-04-21 20:00:31 ---
Closing.

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Igor Tarasov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |UNCONFIRMED
         Resolution|INVALID                     |

--- Comment #19 from Igor Tarasov   2009-05-22 14:39:05 ---
Reopen this bug, as I've finally took time to write simple test application and
to get enough data to prove that the problem exists.

There are two files in the attached archive: pathtest.exe and pathtest.reg. The
first one should be copied to C:\Program Files directory and the second one
should be imported into registry. Then you can start testing.

Here are tests:

tests:

1. In cmd: start pathtest
Windows: start launches new cmd window and the path is:
=PATH TEST=;C:\WINDOWS\systtem32;C:\WINDOWS;C:\WINDOWS\System32\Wbem

Wine: start can't find our program:
Application could not be started, or no application associated with the
specified file.
ShellExecuteEx failed: File not found

2. In cmd: start pathtest.exe
Windows: exactly as with test #1.

Wine: in new cmd window:
Current path is: C:\windows\system32;C:\windows;=PATH TEST=

3. Using explorer.exe locate file and double-click it.
Windows: again, does EXACTLY as the above, that is it DOES use Path option from
registry and opens new cmd window.

Wine: it does not open new cmd window, but dumps to current shell:
Current path is: C:\windows\system32;C:\windows

That is it does not use Path parameter.

So, we see at least four bugs in wine behavior:

1. Wine does not recoginze names without extension
2. Wine appends, not prepends Path value from registry. This might lead to bugs
if there are similarly named shared libraries in other folders.
3. Wine does not use Path from registry when it the program is launched from
some file manager (winefile or linux filemanager).
4. No new cmd windows for comman-line applications when launched from file
manager.

I am pretty sure that his bug is not INVALID, since I know applications that do
not start in wine just because of all this.

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #20 from Igor Tarasov   2009-05-22 14:40:11 ---
Created an attachment (id=21239)
 --> (http://bugs.winehq.org/attachment.cgi?id=21239)
test application

Test application.

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #21 from Igor Tarasov   2009-06-02 05:46:18 ---
Regarding launching files without extension:

MSDN says: "The file name can be provided without its .exe extension. If
necessary, the ShellExecute function adds the extension when searching App
Paths"
http://msdn.microsoft.com/en-us/library/cc144150(VS.85).aspx

But there is no such thing in shlexec.c. I suppose, that this option could be
added somewhere at SHELL_TryAppPathW.

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download, testcase

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

nathan.n  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #22 from [e-mail] 2011-01-03 20:38:53 CST ---
*** This bug has been confirmed by popular vote. ***

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

http://bugs.winehq.org/show_bug.cgi?id=18089

François Gouget  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 18089] Windows explorer.exe is able to lunch .exe files which refer another directory with DLLs

https://bugs.winehq.org/show_bug.cgi?id=18089

--- Comment #23 from Ken Sharp  ---
Is this still an issue in Wine 1.7.45 or later?