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

Re: config converting problem

by Vincent Béron

Le mer 11/08/2004 à 08:58, Mike Hearn a écrit : > > And lose fake_windows???? > > Yes. Do users keep anything important there? (Answer is: they shouldn't > do). Data files they create/use should be in their unix home dir, so rm > ~/.wine -rf shouldn't be seen as drastic, they can just reinstall. Don't forget that My Documents is on c: by default. Also, reinstalling all apps just because you upgraded Wine seems a bit overkill, no? > > I blow away ~/.wine all the time. I do the same, but as you develop Wine, I'd expect it. Vincent

Aug. 11, 2004

responses

by Patrick C McKelvey

I am responding to the italicized note in the user manual (pdf). 1) Your early adopters probably do not look at the user manual any more. 2) Having written some documents like this, I do not believe that most people realize how difficult it is to make a process simple and clear without making it insulting. A company I used to work for had a 5 day course on writing user manual and procedures that they marketed nation wide. I do not know if the still do so. I went through that course and it was amazingly difficult. All you need to do is write down what to do and no one will understand you. 3) Those who are into Linux are into the bleeding edge of technology and want to make it run, not tell others how to make it run. An audience of true nerds, and I will raise my hand, will like to see the thing work. Documentation is in last place. I appreciate what you run into on the thankless task of documentation and keeping it current. My guess is that this is the one thing that is the major weak spot in Linux. If anything except perhaps support, will kill Linux, it will be lousy documentation. Having been a Unix system administrator for a long while, I have seen great systems go away because of documentation or support. Legato nearly went under because of support. The system is good, I chose it to back up 25 production Unix boxes into a tape silo over a 1G fiber network. After I left, I understand they went with another system because they could no longer get any answers to their questions and the documentation was not clear. I am retired on disability now. I have heard rumors that Legato has turned the problems around and is recovering some of it's lost market share. I have just started trying to use Wine on Fedora Core2 and I will be reading all the documentation. What I have seen so far has been well done. I will be finding out if it still applies, and applies to Quicken 2004 Deluxe. Sincerely yours, Patrick C. McKelvey PE Cincinnati, Ohio pmckelvey(a)zoomtown.com

Aug. 11, 2004

Re: config converting problem

by Mike Hearn

> Don't forget that My Documents is on c: by default. Hmm, that's true. That should definitely be fixed. I don't even think we map the home directory in wineprefixcreate by default, do we? I think Marcus' patch adds that. > Also, reinstalling all apps just because you upgraded Wine seems a bit > overkill, no? Well, yeah, but over time I think it becomes necessary as the contents of the initial registry/config file change etc ... it's hard to know exactly what you need to do so reinstalling is the easiest way. It sucks, I agree.

Aug. 11, 2004

Re: config converting problem

by Vincent Béron

Le mer 11/08/2004 à 08:38, Mike Hearn a écrit : > > 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 And lose fake_windows???? > > 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. Vincent

Aug. 11, 2004

Re: winedbg doesn't find source files

by Saulius Krasuckas

On 11 Aug 2004, Vincent Béron wrote: > Le mer 11/08/2004 à 04:50, Mike Hearn a écrit : > > Saulius Krasuckas wrote: > > > I need an advice on how to setup winedbg the right way or an explanation, > > > whether this is a bug or an advanced feature. TIA. > > > > Nope, it's a bug, something to do with STABS parsing I think. I have > > reported it once to Eric but I think I didn't have enough info to help him. And what do you think, Mike, is he being very busy recently? Would it be OK to try to contact him directly? > The original message had this line: > fixme:dbghelp:elf_load_debug_info Unsupported Dwarf2 information > > So I suspect your Wine is compiled with Dwarf2 debug symbols rather than > stabs+. Which gcc version was used? How should I check that? And gcc version is 3.2: [s2(a)katleriai d3d8]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit Thread model: posix gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

Aug. 11, 2004

Re: config converting problem

by Mike Hearn

> And lose fake_windows???? Yes. Do users keep anything important there? (Answer is: they shouldn't do). Data files they create/use should be in their unix home dir, so rm ~/.wine -rf shouldn't be seen as drastic, they can just reinstall. I blow away ~/.wine all the time. thanks -mike

Aug. 11, 2004

Re: winedbg doesn't find source files

by Mike Hearn

> The original message had this line: > fixme:dbghelp:elf_load_debug_info Unsupported Dwarf2 information > > So I suspect your Wine is compiled with Dwarf2 debug symbols rather than > stabs+. Which gcc version was used? Yep but I see this problem even without that fixme, so I think it's generic ...

Aug. 11, 2004

Re: config converting problem

by Mike Hearn

> 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'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.

Aug. 11, 2004

Re: Different X Displays and Wine

by Boaz Harrosh

Alexandre Julliard wrote: >That's not supported at the moment. You can run apps on two different >displays by using a different WINEPREFIX for each, so that they don't >share the same wineserver. Using different users would work too. > > Since I started to research this I was terrified this would be the answer. I Thinks It should be stated, in bold letters, at the beginning of the user guide. I kind of have my neck on the line here. The reason I was contracted for this job was so we can run 100s of users off of a modest Linux Server room. With cheap x-terminals and old Win98 machines running an X-Server. What about the todo page is that on the todo for 1.0? Is it on any todo List? Back to business: What you are saying is that I need to run a separate wineserver instance for each different $DISPLAY I want to support. This can only be done with WINEPREFIX or with a different user. Now, I need this to have the minimum Impact on the server so I have some questions if any one can help me I will most appreciate it: [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. [2] If yes for 1 would the Linux Kernel share my code segments across wineservers? (Probably yes). [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. [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) [5] How much effort is it to Implement such a support? Where do I start? Did any one have any thoughts on how this should be implemented? I was always in the notion that the x11drv was an In-process implementation creating a relationship between the wine-process and the x subsystem it is running under, only registering information under the server. Proof of that, I thought, was the current lack of cross process windowing. Well I was wrong. What is the basic flaw in Windows API that prevents it? [(DWORD)-1] What does Codweavers do on their Server product. How do they server concurrent Office users? Free Life Boaz

Aug. 11, 2004

Re: config converting problem

by Vincent Béron

Le mer 11/08/2004 à 04:40, Henning Gerhardt a écrit : > Hi all, > > a friend of me would update the wine package (20030813) from his SuSE 9.0 system > to the latest availabe package for this system (20040716). After the update following > error message appears on each start of wine: > > .... > Warning: the specified Windows directory L"C:\\Windows" is not accessible. > Warning: the specified System directory L"C:\\Windows\\System" is not accessible. Mike, we might have one of the situations causing this error here. > > He get me also an output of the first wine start: > > Created symlink /home/julian/.wine/dosdevices/c: -> ../${HOME}/.wine/fake_windows > .... > Created symlink /home/julian/.wine/dosdevices/y: -> ../${HOME} > .... > Warning: the specified Windows directory L"C:\\Windows" is not accessible. > Warning: the specified System directory L"C:\\Windows\\System" is not accessible. > > > After my advise to get me the content of his "~/.wine/dosdevices", he send me > the following output: > > .... > lrwxrwxrwx 1 julian users 28 10. Aug 18:50 c: -> ../%HOME%/.wine/fake_windows > .... > lrwxrwxrwx 1 julian users 9 10. Aug 18:50 y: -> ../%HOME% > .... > > and he send me also his config file (snipped content): > > [Drive C] > "Path" = "${HOME}/.wine/fake_windows" > "Type" = "hd" > "Label" = "fake_windows" > "Filesystem" = "win95" > > ... > > [Drive Y] > "Type" = "network" > "Path" = "${HOME}" > "Label" = "Home" > "FS" = "win95" > > .... > > (I translated the german dialog with him to english) > > I think the problem is the ${HOME} variable which is not parsed / correct replaced > during the convert process. > > Have anyone an idea to solve this problem ? Or is it only a problem of the > SuSE distribution ? It's not SuSE specific. It's a problem from upgrading from a (somewhat) old to a newer Wine version. Wine used to understand ${HOME}-style vars in config. This was then changed to %HOME%-style vars. Current Wine doesn't use config anymore for drives but uses dosdevices, which is created on the fly from config if it doesn't exist. So the problem comes from 2 changes, with only the latter being acted on automatically. 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: Vincent

Aug. 11, 2004