config converting problem

[Mike Hearn]

> Ahhhh..... well, fine, I suppose we could argue all day over what "most 
> users" might do, but I myself certainly run more than "one or two apps" 
> under Wine, because 1) I play games and 2) there are currently about 4 
> apps that are more convienient for me to run under Wine atm than to try 
> to understand the Linux alternatives (assuming they exist), and at least 
> 1 that might be replaceable, but I haven't done the research yet, and it 
> is essential to maintain in its current configuration, as I still need 
> its functionality.

OK, I consider myself corrected :) I had no idea people ran so many apps 
at once in Wine.

> That would be a start, and that's a good thing. A basic "Optimal way to 
> configure and use Wine" document would be even better (and yes, I'll get 
> to work on one myself, and submit it to Bugzilla for review; I'd not say 
> "you all ought to do this" like that. I'm a Linux user). 

Sure, though post it to wine-devel or wine-patches, bugzilla isn't 
watched all that closely compared to the mailing lists. It also tends to 
kick people into action more.

> It would be 
> nice to have a clue what was going on from one month to the next, 
> especially since-- as noted here on the list-- many users are making a 
> big jump from any "last stable" version installed with their distro 
> (which may well be from late 2003 or early 2004) to the current version 
> found on the site, in which time there have been significant changes, 
> and much of the documentation on how to configure Wine they may have 
> previously seen could be obsolete.

We try and keep the docs up to date but of course once a user has read 
them (if they do at all) they tend to consider it "read" and don't do so 
again. I don't blame them, I'm just as guilty of this as anybody else!

So I don't know how we can communicate this stuff better. A brief 
summary of each months changes is put into the release notes by 
Alexandre but I do not know how many people read them.

There is also the Wine Weekly News.

> No, I can see how there might have been good reason for it originally. 
> After all, how could you expect to auto configure Wine to map drives to 
> my system when you actually know very little about important aspects of 
> my system (most notably the mount point for my CD-ROM and floppy drive, 
> which change across distributions, but are generally essential for the 
> installation and/or operation of the vast majority of Windows programs).

We need to fix that. It's not hard, parsing the fstab can tell you this. 
Marcus has some code for it I think.

> Surely the Wine and CX teams are not under the 
> impression that your userbase is so completely separate and distinct 
> from the Transgaming userbase, that it does not have similar needs, or 
> confusions? So I've gotta say, I don't get why this issue is "news" to 
> you all insofar as you're just now thinking of how to patch/rectify it. 
> It raises all kinds of questions for me as a user, which can be 
> generally summed up as, "Don't you care about me at all?" and 
> supplementally as, "Don't you all even use Wine?"

Of course we do, but there are a million little things we could to Wine 
to improve it for users - simply saying it and actually doing it are 
different. Now it's been suggested, somebody has to write a patch to 
change the default location, test it, make sure that it works, convince 
Alexandre to merge it, hope it doesn't annoy people and so on.

> Why or how, btw, is this a beneficial change? I'm a user, I just live 
> with it, but no one has actually told me why making the config more 
> inaccessible to me, and more difficult to work with, is better for me 
> than the (admittedly confusing, but at least available) configuration 
> file of the days of yore.....

We're not. Please, it's a very pretty tinfoil hat but it's not necessary 
here.

Try running "winecfg" sometime - it's in your current release. It's not 
finished, and until we flick the switch it won't change your actual 
configuration (not to mention the UI love it needs) but doing this sort 
of graphical configuration is very tricky if the config file isn't 
inside the registry. By moving it there, we allow graphical 
configuration (which is a good thing).

As explained elsewhere, take a look at the .reg files in your .wine 
directory. They are text just like the config file is. Now do an 
i-search in your favourite editor for Wine\Config : when we switch it 
over that will put your cursor on the first line of the config file 
which you can copy/paste/edit/share to your hearts content.

It also makes it easier for people to do "canned" configurations. For 
instance you could send people a foobar-app.reg file which contains 
appdefaults for FooBar 2000. Then people can install it by running 
"regedit foobar-app.reg", which means we can associate it with the .reg 
extension in file managers and so provide 100% graphical configuration 
sharing (for the importer).

The problems with upgrade aren't to do with binary vs text (Wine does 
not use binary registries). They are to do with things like 
modifications to the default configuration wiping out the users changes. 
That's why recently I've been running with no config file at all and 
submitting patches to fix bugs found in that mode. The aim is that the 
default configuration choices are all made in the code so whatever is in 
the config registry branch is the users choices - that way we can leave 
it alone.

Up until now we've always done such changes my altering the default 
config file, but users don't typically replace their config file with 
the default when they upgrade Wine so this is a poor way of doing things.

>> Currently once the users .wine is created their registry is "static" 
>> and even if we improve the default registry it'll never be recreated. 
>> Ditto for COM registrations, they are only done at wineprefixcreate 
>> time as well.

This is the other problems with upgrades. We only run wine.inf when a 
new .wine is created, so new COM servers won't be registered in the 
upgrade scenario. That can lead to the user not receiving new/fixed code.

It's a tricky problem.

> I 
> don't think I even dare to ask about the relationship between drive 
> mappings and the Registry (what if I get a new giganto HDD and want to 
> move my Wine installation over to it? Do at least changes to the 
> /dosdevices/ folder migrate into the Registry? In which case, it's not 
> totally static, and if not, how can that ability be expanded?)

dosdevices is entirely separate from the registry.

> "Please specify a location for your fake_windows directory" is 
> technical? Geez, even Windows installers let you specify a location for 
> their Start Menu entries-- they don't seem to find *that* too technical. 
> And if the install process has stopped on that question, you *have* to 
> read it. Don't you?

No, we don't control the install process (RPMs can't ask questions, for 
instance).

> Why? Yes, I know there's an answer below this, but it doesn't answer. 
> Auto-configuring doesn't much help if the auto-config is wrong (just 
> look at Samba. Is there so much as a single soul who has ever been able 
> to connect to their Windows network using the default configuration, and 
> has not needed to edit /etc/smb.conf to-- at the very least-- correct 
> the workgroup name?). I have yet to have anything but fake_windows 
> (hardcoded to a hidden directory), /tmp, / (sometimes), and ${HOME}$ 
> automatically mapped.
> 
> No CD-ROM. I have to do that myself.

That's just a bug.

> No outside partitions (one of which is the one where I commonly keep 
> Wine-installed programs, so that I can just say I want the app in D:\ 
> and know where it's going). Have to do that myself, too. Yeah, yeah, I 
> know, I could just use / and drill down, but  1) that's a pain and 2) 
> that assumes that the installer works properly and allows me to move 
> around in the "semi symlinked" directory tree, which some installers 
> barf at-- and if the installer actually requires me to type a path, I 
> have to remember the entire tree from / all the way to wherever I have 
> mounted the partition, somewhere in my home directory. Hopefully the 
> pathname is not too many characters. At least winesetuptk used to map 
> all the FAT32 partitions it found, meaning I only had to map the one 
> "extra" ext3 partition. Of course, since I'm eliminating my FAT32 
> partitions now, even that wouldn't help me anymore.

winecfg can do drive editing (in theory, it's kind of buggy right now)

> And that ${HOME}$ evar has never worked for me, in the year and a half 
> that I've been using various versions of Wine, so I have to manually 
> change it to /home/username anyway.

Really? I never used it (the default config doesn't, it seems). Why was 
this never reported?

> There are most definitely programs that do ask you one or more questions 
> during install; I guess they're mostly servers, which I'm not too 
> experienced with, but I did (by mistake) install apache or postfix or 
> something that wanted me to set a password before it would finish the 
> install.

You're probably using Debian or Gentoo. Quite a few distros can't/won't 
do this.

> I mean, fine; I can't speak for "the requirements of packaging 
> technologies" (although my impression is that none of those blasted 
> distros should be packaging Wine anyway, as they all muck it up), nor am 
> I a distro developer who specifies requirements for inclusion into 
> anybody's base package-- but why do you "have" to be a part of any 
> distro's base package? Is there something wrong with being in contrib? 
> Admittedly, Wine is usually in "unstable contrib" making it hard to 
> track down the current version under some distros, but how is 
> "stability" related to user interaction in the post-install?

Well, at least one of my personal goal is that long term Wine becomes an 
"OS subsystem" as much as the kernel or X is, and that it's always 
present so when the user clicks and EXE it magically just works. We're a 
long way from that today, but that's how I think it should be.

By definition that means it has to be auto-configuring. That means 
sensible defaults that can be easily changed later if the user desires it.

> I guess what's been confusing me for some time is just whose needs the 
> project is aiming to serve. Is Wine really just a cover for a free and 
> unregarded technological testbed for the paid project (more naievete 
> from me), and we should be quietly grateful that it's available to us at 
> all (operative word, "quietly")? Is it just an interesting exercise for 
> cross-platform developers, and we should be quietly grateful that we are 
> able to run any Windows programs that we might value at all? Where is 
> the focus? It definitely doesn't so much appear to be on those who, for 
> financial, philosophical, or intellectual (they don't know any better) 
> reasons, choose to use Wine (as opposed to the alternatives) and expect 
> it to be understandable, and-- dare I say-- relatively easy. 

<stock open source answer> It is focussed on those who focus on it. It 
works in the way the developers make it work. Some developers choose to 
try and address end-user issues like configuration, some do not. For 
instance I once worked on winecfg even though it's useless for me, 
because I think it's necessary for Wine to become easier. I'm planning 
on doing more work on it soon.

> Because that is the sort of feature that I, as just a regular user, 
> actually care about, it is the kind of thing I notice when developers 
> add all kinds of *other* features *but* that-- and that's why I'm 
> definitely confused as to who these users everybody is catering to are.
> 
> Maybe I should hang out at more Linux bars....

Well now I'm just confused. Wine already auto-configures itself to a 
massive extent, presumably you never noticed or don't care about the 
things it automatically does. Making it go all the way just makes a 
great deal of sense, it doesn't mean you have less control though.