[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: wine-bugs(a)winehq.org ReportedBy: tarasov.igor(a)gmail.com 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #1 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-04-18 11:29:26 --- How exactly are you starting your app? With lnk? Does it work if you run it from cmd? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #2 from Igor Tarasov <tarasov.igor(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|ntdll |-unknown --- Comment #3 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #4 from Igor Tarasov <tarasov.igor(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #5 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-04-19 19:42:28 --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Igor Tarasov <tarasov.igor(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID | --- Comment #7 from Igor Tarasov <tarasov.igor(a)gmail.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Dmitry Timoshkov <dmitry(a)codeweavers.com> 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 <dmitry(a)codeweavers.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #9 from Igor Tarasov <tarasov.igor(a)gmail.com> 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 :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com --- Comment #10 from Vincent Povirk <madewokherd(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #11 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #12 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-04-19 21:17:57 --- To make this a valid bug, Igor what exactly were you trying to lunch? How was it installed? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #13 from Igor Tarasov <tarasov.igor(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #14 from Igor Tarasov <tarasov.igor(a)gmail.com> 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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #15 from Igor Tarasov <tarasov.igor(a)gmail.com> 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... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #16 from Igor Tarasov <tarasov.igor(a)gmail.com> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #17 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #18 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-04-21 20:00:31 --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Igor Tarasov <tarasov.igor(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID | --- Comment #19 from Igor Tarasov <tarasov.igor(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #20 from Igor Tarasov <tarasov.igor(a)gmail.com> 2009-05-22 14:40:11 --- Created an attachment (id=21239) --> (http://bugs.winehq.org/attachment.cgi?id=21239) test application Test application. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #21 from Igor Tarasov <tarasov.igor(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 nathan.n <saturn_systems(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |saturn_systems(a)yahoo.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 info(a)fullcircleillustration.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #22 from info(a)fullcircleillustration.com 2011-01-03 20:38:53 CST --- *** This bug has been confirmed by popular vote. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=18089 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget(a)codeweavers.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=18089 --- Comment #23 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Is this still an issue in Wine 1.7.45 or later? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org