[Wine]Re: #181699 wine: vague error message: "dramatically effect" in what way?

[Alfie Costa]

On 16 Jan 2005 at 18:55, Scott Ritchie <scott at open-vote.org> 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...