Scott Ritchie
2005-Jan-16 20:55 UTC
[Wine]Re: Bug#181699: #181699 Re: #181699 wine: vague error message: "dramatically effect" in what way?
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. These days, the easiest way to get native DLLs that are still helpful is by installing a few Microsoft applications that provide those DLLs for Wine. DCOM98, a provider of the rather hard to do ole DLLs, is the easiest way to get the important files to run Install Shield. Some applications also require installing Internet Explorer. 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, Scott Ritchie On Sun, 2005-01-16 at 19:06 -0500, Alfie Costa wrote:> I was rereading old bugs and thought I'd have another go at this one. > The story so far: > > Current: > > Note that one change you can make that will dramatically > effect Wine's behaviour is to change whether or not > Wine uses a true Windows partition, mounted under Linux, > or whether it uses an empty Windows directory. > > First (failed) attempt at revising it: > > Note to experimenters: one change you can make that may > dramatically improve Wine's behaviour is to change whether or not > Wine uses a true Windows partition, mounted under Linux, > or whether it uses an empty Windows directory. > > ...and that's where I got mixed up about one change between two choices, > or two binary choices with four possible outcomes. > > Anyway it occurs to me that 'wine' either runs off a directory or a > partition, one or the other. Therefore "or not" and the second > "whether" don't belong. > > Second try: > > Note to experimenters: one change you can make that may > dramatically improve Wine's behaviour is to change whether > Wine uses a true Windows partition mounted under Linux, > or an empty Windows directory. > > Well that's better, but something still puzzles me. What the heck is an > "EMPTY Windows directory"??? A plain old "Windows directory" is where > MS Windows is stored, that's clear. But an EMPTY one would seem to be > where MS Windows WAS stored but is now erased -- and one empty directory > is just like another, so there'd be no reason to have once been a > 'Windows' directory. An "EMPTY OS/2 directory" could do the same job. > > Should it say "an empty directory"? No, because 'wine' would find > nothing to emulate in an empty directory. So despite progress, the > intended meaning remains elusive. > > More questions. In "whether wine uses", the verb 'uses' applies to > which variable or variables in the '.wine/config' file? I'm guessing > these two but it's better to make sure: > > [wine] > "Windows" = "C:\\windows" > "System" = "C:\\windows\\system" > > So case #1, "a true Windows partition, mounted under Linux", would also > require something like: > > [Drive C] > "Path" = "/mnt/c" # where /mnt/c might be /dev/hda2 > "Type" = "hd" > "Label" = "/mnt/c" > "Filesystem" = "win95" > > And case #2 "an empty Windows directory" (shrug!) would require > something like: > > [Drive C] > "Path" = "/home/foo/c" > "Type" = "hd" > "Label" = "psuedo C drive" > "Filesystem" = "win95" > > Is the above correct? > > >
Alfie Costa
2005-Jan-20 02:44 UTC
[Wine]Re: #181699 wine: vague error message: "dramatically effect" in what way?
On 16 Jan 2005 at 18:55, Scott Ritchie <scott@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...