On 16 Jan 2005 at 18:55, Scott Ritchie <scott@xxxxxxxxxxxxx> wrote:
> What really matters is not whether Wine has a Windows drive and
> filesystem to sit on top of, but whether or not Wine can use native
> Windows DLLs instead of its builtin ones. Some DLLs in Wine are so
> perfect that they can be used in Windows - no benefit will be gained
> from running an app that uses these natively. Some of Wine's DLLs are
> buggy or incomplete - using stock native Windows ones was a way around
> this, however a lot of work has been done on the problem areas.
So you're saying the vague message is really suggesting that the user start
toggling DLLOverides between 'native' and 'builtin', and thus enter into
'wine's own circle of trial-and-error ".DLL Hell". Yech! One reason we like
Debian better is that '.deb' files do away with most of that.
You should already know what wine's .DLL hell entails, but it's new to me, and
for other new readers here's an outline of my recent studies...
Consider Pegasus Mail. How many .DLLs does it depend on?
WINEDEBUG=+loaddll wine ../pmail/winpm-32.exe | grep dll | wc -l
29 # the answer
Supposing all 29 .DLLs can be set to "native" (windows version), or "builtin"
(wine's version) and we don't know in advance which ones work better. 29
combinations of two makes for 2^29=536,870,912 variants to try. Brute force is
absurd. We can eliminate certain choices because their 'native' versions will
never work with 'wine'. We can eliminate others because 'wine' has no
'builtin' equivalents. Suppose those two rounds of elimination remove 80% of
the 29 .DLLs. Leaving 6 .DLLs we're not sure about. 6 .DLLs means 2^6=64
combinations to test. Some of those 64 combinations might work. A 'wine'
expert might be able to narrow it down using the debugger.
Those particular combinations could change between versions of 'wine' and
'Pegasus', which further complicates matters. Up to 536 million possibilities,
which might be lowered to 64 or under, depending on one's expertise. Said wide
range of possibilities is CASUALLY ALLUDED to as "ONE change you can make that
will dramatically effect Wine's behaviour..."
Third try:
Note to sophisticated experimenters: you may be able to
dramatically improve Wine's behaviour by editing your
'.wine/config' file and toggling its many [DLLOverides]
between 'native' and 'builtin'. There can be millions
of combinations, so this is only recommended for experts.
It's incredible to suggest ordinary users do that. It's a waste of expert time
if every expert keeps reconfiguring every program they use.
Therefore what's needed is a proper dependency system for 'wine'. I'm thinking
it would be a database of popular or useful DLLOverrides that would include
'wine' versions, and unambiguous program and DLL names and versions. Anytime
an expert figured out how to get 'Foo v13 for Windows' to work in 'wine' he'd
make a little program specific [AppDefaults\\Foov13\\DllOverrides] thingee and
add it to the database. Users would look up those Overrides, (or an automated
loader would), and 'wine' would use them, and it might work better than MS
Windows ever did, because it'd function with conflicting DLLs.
How a 'wine' (or a loader program) would use a DLLOverrride database. 1) Check
if the correct DLLs existed. If not, advise user. Example: "you need foo.DLL
version 28 to run Foo v13, it's in Foo's installer archive .EXE. Put it in the
'foo' directory, then try running 'wine foo' again." 2) If the correct DLLs
exist, use them.
A Bug Tracking System for these Override patches would be needed.
A tall order, but what else can be done? Non-experts toggling DLLOverrides is
nuts. Windows by it's own chaotic nature needs Overrides. 'wine' experts are
already doing the needed work, so what's needed is to organize and harness
their redundant labors.
> ...I highly recommend you don't use a windows drive and instead let
> Wine create its own fake windows drive automatically, and you then
> supply some of the missing DLLs using Winetools. A link to Winetools
> can be found on the Wine downloads page, along with packages for the
> latest release of Wine.
Thanks for the tip, but scavenger hunt advice is such a halfway measure.
Please consider providing a URL next time you cite a file.
So it's at 'the Wine downloads page'? Here perhaps:
http://www.winehq.com/site/download
...which has a 'winetools' URL to:
http://www.von-thadden.de/Joachim/WineTools/
...which has no .deb files, only a .tgz and this .rpm:
http://ds80-237-203-29.dedicated.hosteurope.de/wt/winetools-2.1.0-jo.i386.rpm
Well it seems that can be converted to a '.deb' file with 'alien', but the
result has a dependency on the 'xdialog' package that 'alien' doesn't notice.
"apt-get install xdialog". 'wt' still won't work until a symlink to 'Xdialog'
is made:
ln -s `which Xdialog` /usr/local/winetools/Xdialog
THEN 'wt' works. (Haven't used it much yet -- the installation exhausted me.)
HTH...
_______________________________________________
wine-users mailing list
wine-users@xxxxxxxxxx
http://www.winehq.org/mailman/listinfo/wine-users
