August 2004 - Wine-Devel - list.winehq.org

Re: appdb dump

by Jeremy Newman

Finally got around to this. This should update nightly now. ftp://ftp.winehq.org/pub/wine/wine-appdb-20040811.tar.gz File name changes as the date changes, blah blah. :-) Enjoy! On Mon, 2004-07-19 at 16:48, Joel Konkle-Parker wrote: > Jeremy Newman wrote: > > This is getting to be a common request. I think what I am going to do is > > make a script that tars up the appdb every night and puts it up for > > download. The only table it will not dump will be the userdb, for > > privacy reasons. I'll email you all again when I have something whipped > > up. > > Has there been any action on this front? I haven't heard anything for a > while, just checking. -- _ _ WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1711553 Yahoo: laxdragon

Aug. 11, 2004

Re: config converting problem

by Holly Bostick

Thanks for posting this back to the list, Mike; I post here so rarely that I forget that this is a "Reply All" list, and not just a "Reply" list :-) Mike Hearn wrote: > PS I've added wine-devel back as from the wording it sounded like it > was meant to go there: wine-devel is one of these annoying old-skool > lists which don't rewrite Reply-To, but that rant is something for > another time :) > > Holly Bostick wrote: > >> Yeah, fine, "it sucks"-- and I admit that I myself never install to >> "C:\Program Files", under Windows or Wine, but geez guys-- who do you >> think your users are when you say things like this? >> >> They're *Windows users*. And that means they probably use the >> defaults, and that means that their whole data tree is in ./wine. And >> if that data tree meant so much to them that they installed Wine in >> the first place, it's kinda cold to say "just blow it away". > > > Well, I'd guess that most users run perhaps one or two apps in Wine at > the most, 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. And while I may not be representative of the "majority" of migrating Linux users (certainly not on the corporate desktop), I do think I'm fairly well representative of a significant portion of the home user migration. I have a list of about 20 or so games that I either play myself, or need to test to see if they are playable, because my boyfriend plays them, and I want to encourage him to switch. Oh, make that 21, since I just heard that people got Doom3 running (under Wine, no less), and I certainly have to check that. And no, I don't want to blow away my savegames in Icewind Dale 2 just because Wine needs a refresh, nor do I want to blow away my mIRC server list (the scripts I use don't seem transferrable to Kvirc, so I still use mIRC), or my PSP custom brushes or "tubes" or whatever. And heaven knows I wouldn't want to try to reinstall my Morrowind plugins (I'm using a backup Windows install to replace the Wine-installed game-- or I will, when I get to attempting to install it, as I'm repartitioning at the moment), as it was hard enough getting them installed the first time (and that was under Windows). I can see that in such a world as you suggest, blowing away the .wine folder is not a big deal. I'm just not sure that that world is the world that "most users", or even "a large number of users" actually live in. > unlike Windows users who run lots and lots of apps. So every so often > reinstalling these programs is not such a big deal, unless you have > things like the Office XP activation scheme which don't like that. > >> They're non-technical (a behaviour encouraged by being a Windows >> user). So while I'm sure they're used to "blowing away" their Windows >> installation regularly (due to the "non-technical" nature of things >> like My Documents rather than putting your bloody docs on another >> partition rather than C:\, for example), since half the reason to >> move to Linux is to put an end to that necessity, it seems a bit odd >> to reinstate it here. > > > Yeah, I agree that at minimum we should force My Documents elsewhere, > and maybe have wineprefixcreate link H: to $HOME along with putting a > label on that drive saying "Save Your Files Here" (or whatever). 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). 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. > >> Wouldn't it just make more sense to *separate the config files from >> the (wine) system files*?? Why in the heck is fake_windows in the >> ./wine directory anyway??? > > > Good question. I suspect the answer is "because it's always been > there" :) 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). The only way to succeed would be to force me (the user) into a configuration that you know to exist (which is how it's been done up to this point), yet that's got a huge number of drawbacks as well-- most notably, removing choice, which is something many Linux users consider to be the best thing about Linux. In the early days of Wine, when you had far more important things to worry about (like getting the programs to work at all), I can see how you'd set the issue aside. But now that there is a little bit of "wiggle room" (insofar as a wide variety of the Wine base functions work well enough that one doesn't have to watch them every single minute, and many of the major programs that people could be expected to want to run work relatively well), it may be time to pay a bit of attention to some things that were set on the back burner a while ago. > >> 1) it's hidden, so if I'm inexperienced and non-technical, I don't >> even know where my programs are; > > > Yes this is a fairly common question. TransGaming put a > ~/Transgaming_Drive symlink in the home dir. > > Proposal: patch wineprefixcreate to build "~/Virtual C Drive" as the > users fake windows tree (notice the lack of ugly underscores)? Cons: > > - Some users may not like it (really there's not much useful stuff in > there except the program EXEs) Except save states (think games), customized config/ini files (think FTP programs, Trillian, and many games), possibly password information, and of course possibly data files created by the user with the program-- there are still any number of programs (especially older ones, which are the most likely type to be run under Wine, since they won't be ported) that don't default to "My Documents", but instead to the program directory, to save files created by the program. Users who can't be bothered to browse their tree to find an appropriate and "secure" (in the sense of "safe from deletion if you have to reinstall") location are going to be using the first location found by the "Save" dialog. Again, without hard data about what programs real users are using Wine to run, you can't just say "there's not much useful stuff in there". It's overgeneralizing, and it risks my data (and I hate to risk my data :-) ). But again (thinking of my incomplete and thus unsent response to our previous conversation, Mike), you say "this is a fairly common question". If a large proportion of the users that actually contact you by various, and often somewhat complicated, means, have this question, then one can only wonder how many users who were unable to contact you ("you" in the sense of the devel team, as well as you personally) have this question. And that points to a user need that you (the team) are capable of knowing about, since you already realize that it's a "fairly common question", and have further noted the response of Transgaming to this 'problem'. 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?" > > - Are there issues with spaces in the paths used for these drives? I > don't think we want to have underscores here > > - Localization: do we really want to translate "Virtual C Drive" into > a bazillion languages? If so is the support hassle of having > everybodies C drive in a different place worth it? OTOH you can say > "the C drive is always in ~/.wine/dosdevices/c:/*" and be done with it. > >> 2) there is no reason I should have to "blow away" my data just >> because I have to blow away the config. Reinstalling a program over >> itself is far far easier than reinstalling it from scratch, and that >> doesn't even cover the pure data that might be in "C:\My Documents". > > > Well by "config" we mean: > > * Drive mappings > * Registry > * Config file, or what's left of it :) > > In future the config file will disappear and you'll only have the > registry. 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..... > The problem is we don't have a good way to upgrade it. ....Especially if it's less functional than the configuration files of the days of yore (insofar as it's at least possible to upgrade ~/.wine/config, even with a diff, if necessary). > 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 comes back to the discussions me, Dimi and Alexandre were having > a while ago. > > So for now the easiest way to make sure you're up to date is just to > reinstall stuff because if you delete the registry, you also lose app > settings and quite a few programs don't like their registry trees > disappearing. Yes, I'm certainly familiar with the response of applications to their Registry keys going bye-bye. But how can the Registry be a static entity, when I can upgrade Wine every month? So even if you improve the default Registry, I'll never know, unless I blow everything away? 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?) > > >> And I don't see why we don't gently educate the users in the >> importance of this issue (as a dedicated dialog would certainly do), >> but instead just let them keep on doing things the same old crummy >> Windows way, as if it was ever a good idea. > > > Many users don't read info/error dialogs especially when technical, "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? Or am I just naive? I didn't think I've been using Linux *that* long to become jaded. > likewise Wine has to be auto-configuring. 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. 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. 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. > Not only is it required by most packaging technologies (they don't > allow user interaction, often by design) but if we want Wine to ever > stabilise and become a part of most distros base sets again it has to > involve zero user interaction to setup. 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. X.org is only partially self-configuring. The drivers for my ATI video card most certainly are not; I have to run an included script to configure them. Proprietary apps like the Microsoft fonts, the Acrobat Reader, and the Flash plugin make you stop and accept the license before they will install. And in the case of Wine, this isn't even install we're talking about, this is *post-install* (first-time program access). K3b tells me about config errors on first access, and makes me run K3b setup (or it did, before I blew away KDE, so now I have to fix the permissions on cdrecord and cdrdao manually). If the default configuration (codec and plugin choices) of mPlayer or XMMS are wrong, and the media file won't play, then I have to re-configure them (using the easily-accessed dialogs). There are very few complex programs that I can think of that don't either require or strongly prefer that the user explicitly configure them on first access. Even MS Office wants you to put in your initials and all that minor configuration stuff (or it did; I haven't used it in years). 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? I'm just a user, and if I find Wine unstable, it's because 1) it doesn't work properly under some circumstances (which you all knew, and is a completely separate issue), and 2) it does not interact with me, even so far as to tell me what needs to be done, much less what it has in fact done, much less letting me/telling me how to correct any of the operations it has done if they are not to my satisfaction. Now, in my experience, I'm installing from a terminal (Debian, Slackware, Gentoo), where it's fairly easy to see that the process is stopped because there is a y/n question on-screen. Fine, fine, maybe I'm installing from YAST/YOU (yeah, I tried SuSE for 3 days at some point) or KPackage (once) or RPMDrake (plenty). Don't know so much about those (except RPMDrake); I do know Synaptic has a terminal window where you might have to answer such a question; I would imagine (in my innocence) that YOU and KPackage would have a similar facility. OK, I can see that RPMDrake might be a problem (no terminal window or tab that I can recall, and maybe Mandrake doesn't want to make a little popup dialog). A secondary script after the install that opens an xterm is out of the question? If we assume this config *has* to be done during install and not during first program access, which will always occur in a terminal? OK, maybe it won't... maybe the user is going to double-click some *.exe in Konqueror. Windows users. Right. Whatever, brings me right back to a firstrun script that opens an xterm (to be safe; we can pretty much bet that the user has xterm, but not necessarily Konsole or gnome-terminal or eterm or aterm or what-have-you). Is there something more needed to implement this than some kind of variable along the lines of "firstrun=1" which changes to 0 after the first time Wine is run? Mandrake and KDE must specify that their First-Time Wizards should be run somehow; it doesn't seem like the implementation should be so horribly inaccessible that the project couldn't figure it out (but then, I am not a coder, so I may be talking out of my butt for all I know). What you're saying is that there is no way for you to allow me choice in how I want to configure Wine to best utilize my partition layout and personal needs, because the packaging technologies and the distros won't allow you to code your app in such a way that I the user might have a say in the configuration process? And that, further, once I have been "configured" to the tastes of all of these forces, that I can't update that without blowing my whole, carefully-constructed house of cards away and starting from scratch? Uh-huh. About the only person I can see such a completely hands-off setup being beneficial to is some sysadmin who's trying to migrate multiple seats to Linux and has to configure all the dozens or hundreds or thousands of workstations to use CXOffice (or something) to run Outlook, but even in my ignorance, I'd have to say that that person should be looking for an alternative organizational setup (like running Wine/CX and MS Office from an application server instead of from each workstation), and in any case, they're using CXOffice, for which they have paid, and/or for which the distribution that included it has paid (thus if they want to demand that the config be set up in a certain way, they can vote with their dollars to pay for the R&D needed to target the application to their specialized needs). It's a completely different issue from the large number of home users that are only dealing with 1-3 machines, using a freely-downloadable distro and Wine. In such a case there presumably is not some horrific constraint that specifies that you "simply don't have the time" to interact with the post-install, because "time is money". So I don't get why users having to answer a few questions is absolutely a no-go, or why you even care that the user must fly in such perfect comfort, since they aren't paying for Wine anyway (so it's not like you're losing your best customer if they object to having to brown-bag it a bit). Or are we even still talking about Wine? 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. Auto-configuration is not necessarily either one. *You* need it, for the reasons stated above, but do *I*? This is starting to remind me of the reasons I stopped upgrading (and eventually, using) Microsoft Office-- they made a big noise about adding "more and better web integration"-- a completely useless "feature" for me-- but all the revisions (from Word/Excel/Powerpoint to Office 95 to Office 97 to Office 2000) have never bothered to redesign the menu structure so that the tools to completely format a single page of text are not scattered across three different menus, even though that would be an improvement that would be useful to everybody (including me). 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.... Holly

Aug. 11, 2004

Re: Different X Displays and Wine

by Alexandre Julliard

Boaz Harrosh <boaz(a)hishome.net> writes: > [1] Can I Just "ln -s" the .wine folder and than point WINEPREFIX to > the new link so a new wineserver Instance will be lunched? Or do I > need a separate copy. > (something like> ln -s .wine .wine$DISPLAY ;WINEPREFIX=.wine$DISPLAY > wine ...) > OK, I tried, this does not work! what does work is (# mkdir > .wine$DISPLAY ;ln -s .wine/* .wine$DISPLAY/) have a real directory > with every thing there linked to the real thing. You need a full copy with different registry files, you can't use symlinks. > [2] If yes for 1 would the Linux Kernel share my code segments across > wineservers? (Probably yes). Of course. > [3] When is the $DISPLAY sampled by the wineserver. On first > application startup, on first window created, or on server load? If I > make the wineserver stay in memory (-p) will it re sample the $DISPLAY > when a new app is started after all the old ones exit. wineserver doesn't care about $DISPLAY at all. If you mean $WINEPREFIX it is evaluated at server startup. > [4] Can I pre-run a wineserver and than on connection point wine to > use a specific (next) wineserver Instance? IF not will it be hard to > implement and will it be accepted into the tree? If yes and it is > accepted can it be made automatic when ever $DISPLAY is changed > (different). (Instead of bailing out a few moments later) I don't see how you would do that. The right fix is to make the windowing code support windows created on different displays. > [(DWORD)-1] What does Codweavers do on their Server product. How do > they server concurrent Office users? We don't support having the same user run from different displays at the same time. I don't think that's a common setup at all. -- Alexandre Julliard julliard(a)winehq.org

Aug. 11, 2004

Re: Small make compatibility changes (take 2)

by Alexandre Julliard

Mike Hearn <m.hearn(a)signal.qinetiq.com> writes: > Devils advocate: seeing as quite a few BSD users (at least the ones I > know) already have gmake installed, it's free software and easily > available in ports, why are we putting effort into portability to BSD > make? Is there ever a situation where a user will have BSD make but be > unable to use gmake? Maybe not, but that's not a reason not to be portable. You can make the same argument with gcc, of course we could require everybody to install gcc, but it's better to make the code portable. It's even more important for makefiles, because if someone wants to port to a new platform and they can't even start to build they won't get anywhere; while if it builds except for some compilation errors there's a good chance they can fix them and submit patches. -- Alexandre Julliard julliard(a)winehq.org

Aug. 11, 2004

Re: Do more tests in non-interactive mode (resubmit)

by Francois Gouget

On Fri, 6 Aug 2004, Alexandre Julliard wrote: [...] > The capture test takes about 80 seconds here with the ALSA driver, > which is a bit long. That's strange. Could you run it (with or without the patch but without the -q flag) and send me the output? I guess it's either that Alsa has multiple capture devices or that there's a bug somewhere. If needed we can still speed up the test by reducing the capture time, e.g. from 0.1 second to 0.05 seconds. > It also fails with the OSS driver: > > capture.c:128: Test failed: WaitForSingleObject failed for header > capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags > capture.c:130: Test failed: frag.dwBytesRecorded=512, should be 800 [...] This looks like a bug that needs to be fixed. To confirm, could you run the test in interactive mode without the patch? If you get the same errors then it means there's a bug in wineoss. [...] > Also the wave test makes a lot of noise here, both with ALSA and OSS > drivers. Yes it makes some sort of clicking noises here too, but iirc only in Alsa or OSS, not both (I don't remember which and my tree is too hacked to test right now). I'll recheck on Windows, and then in Wine. Currently I suspect it's a bug in one of: wineoss, the OSS driver, winealsa or the Alsa driver. -- Francois Gouget fgouget(a)codeweavers.com

Aug. 11, 2004

Re: Help with winemaker

by Vincent Béron

Le mar 10/08/2004 à 19:39, Veerendra Tippanagoudar a écrit : > Hi, > > I am trying to port a project from windows to unix. I have installed redhat 7.0. > After installing wine, i tried using winemaker on a set of modules that are interdependent. > By modules, I mean sub-programs. When I run winemaker from the top of the project directory, it creates only Makefile and no configure, configure.in and Makefile.in scripts. Therefore I am not able to use ./configure --with-wine=/usr/local/wine. > Since, I cannot run the ./configure command, I am not able to run the make command. > Why are the configure and other files not being generated? Any help would really be appreciated. If you're using the Wine version which came with RedHat 7.0, the current documentation (on the website) doesn't apply to it anymore. Specifically, winemaker doesn't generate a configure script anymore but directly some Makefiles. Try running make directly if you already have the Makefiles. Vincent

Aug. 11, 2004

Re: config converting problem

by Henning Gerhardt

Hi Marcus, you wrote: >> > I'm not sure what to do about this, except maybe to add back in support >> > for ${HOME} style vars. It's clear that people are "using" (at least, >> > installing) much older versions than we anticipated. >> > >> >> The problem comes when upgrading from an old version (still supporting >> ${HOME}) to a newer version (supporting either %HOME% or dosdevices). >> >> The older version, by itself, still works correctly. > >On SUSE: > >mv away the fake_windows directory (mv ~/.wine ~/.wine.old). > >run wineprefixcreate, it will create a new setup. I have a question: Why create wineprefixcreate the "Program Files" and "Program Files/Common Files" as a subdirectory of the windows directory instead of the root directory ? I attached a patch to prevent this behaviour. Bye, Henning

Aug. 11, 2004

Re: config converting problem

by Lionel Ulmer

> wine-devel is one of these annoying old-skool lists > which don't rewrite Reply-To, but that rant is something for another time :) Which is exactly how it should be configured :-) > > Wouldn't it just make more sense to *separate the config files from the > > (wine) system files*?? Why in the heck is fake_windows in the ./wine > > directory anyway??? > > Good question. I suspect the answer is "because it's always been there" :) Well, on my box, it's not the case: the fake Windows directory is certainly not in the .wine directory. This seems to be a 'bug' in either the Wine packages or the install script (which I never used :-) ). On the other hand, the registry is, so even if you keep the programs and the documents, you will loose the registry. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 11, 2004

Re: config converting problem

by Mike Hearn

PS I've added wine-devel back as from the wording it sounded like it was meant to go there: wine-devel is one of these annoying old-skool lists which don't rewrite Reply-To, but that rant is something for another time :) Holly Bostick wrote: > Yeah, fine, "it sucks"-- and I admit that I myself never install to > "C:\Program Files", under Windows or Wine, but geez guys-- who do you > think your users are when you say things like this? > > They're *Windows users*. And that means they probably use the defaults, > and that means that their whole data tree is in ./wine. And if that data > tree meant so much to them that they installed Wine in the first place, > it's kinda cold to say "just blow it away". Well, I'd guess that most users run perhaps one or two apps in Wine at the most, unlike Windows users who run lots and lots of apps. So every so often reinstalling these programs is not such a big deal, unless you have things like the Office XP activation scheme which don't like that. > They're non-technical (a behaviour encouraged by being a Windows user). > So while I'm sure they're used to "blowing away" their Windows > installation regularly (due to the "non-technical" nature of things like > My Documents rather than putting your bloody docs on another partition > rather than C:\, for example), since half the reason to move to Linux is > to put an end to that necessity, it seems a bit odd to reinstate it here. Yeah, I agree that at minimum we should force My Documents elsewhere, and maybe have wineprefixcreate link H: to $HOME along with putting a label on that drive saying "Save Your Files Here" (or whatever). > Wouldn't it just make more sense to *separate the config files from the > (wine) system files*?? Why in the heck is fake_windows in the ./wine > directory anyway??? Good question. I suspect the answer is "because it's always been there" :) > 1) it's hidden, so if I'm inexperienced and non-technical, I don't even > know where my programs are; Yes this is a fairly common question. TransGaming put a ~/Transgaming_Drive symlink in the home dir. Proposal: patch wineprefixcreate to build "~/Virtual C Drive" as the users fake windows tree (notice the lack of ugly underscores)? Cons: - Some users may not like it (really there's not much useful stuff in there except the program EXEs) - Are there issues with spaces in the paths used for these drives? I don't think we want to have underscores here - Localization: do we really want to translate "Virtual C Drive" into a bazillion languages? If so is the support hassle of having everybodies C drive in a different place worth it? OTOH you can say "the C drive is always in ~/.wine/dosdevices/c:/*" and be done with it. > 2) there is no reason I should have to "blow away" my data just because > I have to blow away the config. Reinstalling a program over itself is > far far easier than reinstalling it from scratch, and that doesn't even > cover the pure data that might be in "C:\My Documents". Well by "config" we mean: * Drive mappings * Registry * Config file, or what's left of it :) In future the config file will disappear and you'll only have the registry. The problem is we don't have a good way to upgrade it. 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 comes back to the discussions me, Dimi and Alexandre were having a while ago. So for now the easiest way to make sure you're up to date is just to reinstall stuff because if you delete the registry, you also lose app settings and quite a few programs don't like their registry trees disappearing. > And I don't see why we don't gently educate the users in the importance > of this issue (as a dedicated dialog would certainly do), but instead > just let them keep on doing things the same old crummy Windows way, as > if it was ever a good idea. Many users don't read info/error dialogs especially when technical, likewise Wine has to be auto-configuring. Not only is it required by most packaging technologies (they don't allow user interaction, often by design) but if we want Wine to ever stabilise and become a part of most distros base sets again it has to involve zero user interaction to setup.

Aug. 11, 2004

Re: config converting problem

by Henning Gerhardt

Hi Mike, you wrote: >> If you want to fix it, the simplest way would be to create the following >> symlinks in ~/.wine/dosdevices: >> >> ln -s ../fake_windows c: >> ln -s /home/julian y: > >Or to delete ~/.wine I think this is not a good idea because of all your own documents or installed programs. >I'm not sure what to do about this, except maybe to add back in support >for ${HOME} style vars. It's clear that people are "using" (at least, >installing) much older versions than we anticipated. Personally I would prefer to merge back the support for ${HOME} variables because I think many other people have the same problem if they want to upgrade wine. Regards, Henning

Aug. 11, 2004