Hi,
Testing wine's control.exe replacements makes me show this :
If i remove/rename original control.exe, I can do : $ control and I have the Wine Control Panel as it has been installed in /usr/local/bin.
But I cannot do: $ wine control wine: cannot find 'control'
So if one app calls for example notepad, the app will try to launch "wine notepad" and fail.
Shouldn't we provide a default drive for /usr or /usrlocal/bin in the config file ? This would solve the "can't load winedbg 123456" issue that users usually include in their first reports. (the debugger cannot be launched because it's in /usr/local/bin)
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Tue, May 14, 2002 at 09:44:07PM +0200, Sylvain Petreolle wrote:
Shouldn't we provide a default drive for /usr or /usrlocal/bin in the config file ? This would solve the "can't load winedbg 123456" issue that users usually include in their first reports. (the debugger cannot be launched because it's in /usr/local/bin)
While I think that doing something like this should really be done, I don't like mixing windows/wine executables and linux (aka native os) executables. Maybe some directory like /usr/local/win (or winebin) would be better.
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Joerg Mayer jmayer@loplof.de writes:
While I think that doing something like this should really be done, I don't like mixing windows/wine executables and linux (aka native os) executables. Maybe some directory like /usr/local/win (or winebin) would be better.
My plan is to integrate that with the loadorder and builtin dll mechanism. So CreateProcess("notepad.exe") would load either the native notepad.exe or the builtin notepad.so transparently depending on your config. And the builtin would pretend to be loaded from c:/windows/system just like dlls, so you wouldn't need to configure a drive for /usr/local/bin (except if you want to launch real Unix binaries from there too).
You have exactly the same idea I had 3 months ago, but at this moment I thought this wouldn't be accepted. And this is so simple to desactivate a builtin app this way when it's not enough complete.
My plan is to integrate that with the loadorder and builtin dll mechanism. So CreateProcess("notepad.exe") would load either the native notepad.exe or the builtin notepad.so transparently depending on your config. And the builtin would pretend to be loaded from c:/windows/system just like dlls, so you wouldn't need to configure a drive for /usr/local/bin (except if you want to launch real Unix binaries from there too).
-- Alexandre Julliard julliard@winehq.com
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
-
Alexandre Julliard -
Joerg Mayer -
Sylvain Petreolle