When I heard you can use original Windows dlls in Wine, I wondered if
there is a list of dlls for which that makes sense. Well, I still
wonder. Is there something like that?
Which native dlls can be safely embedded?
Which native dlls can be safely embedded?
On Tue, Mar 11, 2008 at 3:57 PM, Erik Hahn <[email protected]> wrote:
you absolutely have to". And when you have to do it,
install it using winetricks rather than copying it by hand,
if possible. You can download winetricks from
http://kegel.com/wine/winetricks
It's a shell script; just run it with
sh winetricks
to get a (bad) gui, or
sh winetricks --help
to get a usage message.
- Dan
The answer is, "never use a native Windows DLL unlessWhen I heard you can use original Windows dlls in Wine, I wondered if
there is a list of dlls for which that makes sense.
you absolutely have to". And when you have to do it,
install it using winetricks rather than copying it by hand,
if possible. You can download winetricks from
http://kegel.com/wine/winetricks
It's a shell script; just run it with
sh winetricks
to get a (bad) gui, or
sh winetricks --help
to get a usage message.
- Dan
Which native dlls can be safely embedded?
On Wednesday March 12 2008 00:40:23 Dan Kegel wrote:
it.
You may think "Why? Windows DLLs by definition have *all* functions
implemented and WINE DLLs do not. So if I use native DLL I will have less
problems in general". This myth isn't true.
For example, comctl32 (you can install it by running "winetricks cc580")
may "fix" problems in some applications... but other application may crash or
work incorrectly with native comctl32. You may install native dcom but many
application will crash because of this (including ones that work perfectly in
clean WINE prefix!). And so on... This is because of some differences in the
API between Windows and WINE.
So if you find program that don't work or work not perfectly - always try to
install it in clean WINE prefix without native overrides (for example, by
running: "mv ~/.wine{,.backup}; wineprefixcreate"; alternatively you may
create separate WINE prefix(es) and use WINEPREFIX env. variable ). If still
doesn't work - report a bug at http://bugs.winehq.org .
Year, this is true. Use native overrides *only* if you really sure you needOn Tue, Mar 11, 2008 at 3:57 PM, Erik Hahn <[email protected]> wrote:The answer is, "never use a native Windows DLL unlessWhen I heard you can use original Windows dlls in Wine, I wondered if
there is a list of dlls for which that makes sense.
you absolutely have to". And when you have to do it,
install it using winetricks rather than copying it by hand,
if possible. You can download winetricks from
http://kegel.com/wine/winetricks
It's a shell script; just run it with
sh winetricks
to get a (bad) gui, or
sh winetricks --help
to get a usage message.
- Dan
it.
You may think "Why? Windows DLLs by definition have *all* functions
implemented and WINE DLLs do not. So if I use native DLL I will have less
problems in general". This myth isn't true.
For example, comctl32 (you can install it by running "winetricks cc580")
may "fix" problems in some applications... but other application may crash or
work incorrectly with native comctl32. You may install native dcom but many
application will crash because of this (including ones that work perfectly in
clean WINE prefix!). And so on... This is because of some differences in the
API between Windows and WINE.
So if you find program that don't work or work not perfectly - always try to
install it in clean WINE prefix without native overrides (for example, by
running: "mv ~/.wine{,.backup}; wineprefixcreate"; alternatively you may
create separate WINE prefix(es) and use WINEPREFIX env. variable ). If still
doesn't work - report a bug at http://bugs.winehq.org .