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

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

Re: winedbg doesn't find source files

by Vincent Béron

Le mer 11/08/2004 à 04:50, Mike Hearn a écrit : > Saulius Krasuckas wrote: > > I have had a long period of time not using the winedbg, so I cannot tell > > whether it is a regression. I am using "./configure && make depend && > > make" to build the Wine and then something like a "sudo make install", if > > that matters. > > > > 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. 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? Vincent

Aug. 11, 2004

Re: winedbg doesn't find source files

by Mike Hearn

Saulius Krasuckas wrote: > I have had a long period of time not using the winedbg, so I cannot tell > whether it is a regression. I am using "./configure && make depend && > make" to build the Wine and then something like a "sudo make install", if > that matters. > > 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.

Aug. 11, 2004

config converting problem

by Henning Gerhardt

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. 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 ? Regards, Henning

Aug. 11, 2004

Re: Small make compatibility changes (take 2)

by Mike Hearn

Alexandre Julliard wrote: > There are some makes that don't accept ':=', yes. I don't know whether > they would accept the current way or not, but that doesn't really > matter; since the current way is not portable to BSD we need to change > it anyway. The thing is, we need to replace it with something more > portable, not with something differently non-portable. 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? <g> thanks -mike

Aug. 11, 2004

Re: Small make compatibility changes (take 2)

by Vincent Béron

Le lun 09/08/2004 à 19:05, Alexandre Julliard a écrit : > Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > > > This seems to let users build and uninstall with BSD make. > > > > Changelog: > > Evaluate variable after replacement to build with BSD make. > > Unfortunately assignments with := are not portable either, so it's > only moving the problem. We probably need to restructure the makefiles > a bit to avoid that construct. FreeBSD's and OpenBSD's make, as well as GNU's make, seem to understand it OK (both from reading the docs and personal experiments). The current way of doing it doesn't work on FreeBSD's and OpenBSD's make, although it does work on GNU's make. Is there some other make which does accept the current way of doing it and does not accept my proposed way? Vincent

Aug. 10, 2004

Re: Small make compatibility changes (take 2)

by Alexandre Julliard

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > The current way of doing it doesn't work on FreeBSD's and OpenBSD's > make, although it does work on GNU's make. > > Is there some other make which does accept the current way of doing it > and does not accept my proposed way? There are some makes that don't accept ':=', yes. I don't know whether they would accept the current way or not, but that doesn't really matter; since the current way is not portable to BSD we need to change it anyway. The thing is, we need to replace it with something more portable, not with something differently non-portable. -- Alexandre Julliard julliard(a)winehq.org

Aug. 10, 2004

Re: Different X Displays and Wine

by Alexandre Julliard

Boaz Harrosh <boaz(a)hishome.net> writes: > [Q] Is it at-all possible to run Wine on 2 different $DISPLAY s, or is > the X-Server a Wine-Server resource. Will using a different user help? > Will using desktop mode help? Has any one been successful with letting > different network users connect and run Windows Apps under wine? How > did they Setup wine? How does Codeweavers do it with their Server > Product? 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. -- Alexandre Julliard julliard(a)winehq.org

Aug. 10, 2004

Re: winedos: TSR (was MCB implementation)

by Alexandre Julliard

markus.amsler(a)oribi.org writes: > I'm trying to run a DOS application, that uses a TSR as a database driver. So I > donn't need TSR support in win32. I was just thinking how TSR support should > look like in wine, and that involves what should happen if you start a TSR > programm in a win32 shell. You can run already DOS programms in Win32 shells, > so it's naturally to try running a TSR. The problem is that launching a DOS program from a Win32 shell creates a new DOS box, so you can certainly run a TSR in there but your app won't be able to access it since it won't run in the same DOS box. So yes, you need to start the TSR from a DOS shell. But I suspect that a real DOS emulator may be a better choice for your app than Wine. -- Alexandre Julliard julliard(a)winehq.org

Aug. 10, 2004

Help with winemaker

by Veerendra Tippanagoudar

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. My project uses, C and C++ code. Thank you, Veerendra Tippanagoudar. P.S: The documentation online is not complete (especially the Makefile.in and Configure.in part). --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage!

Aug. 10, 2004

Re: Dockable Toolbar painting issue on SUSE 9.1

by Krishna Murthy

I have created a defect 2420 for this with the sample source and binary attachment. Krishna "Krishna Murthy" <krishna.murthy(a)guptaworldwide.com> wrote in message news:cfb4pt$ngt$1(a)sea.gmane.org... > I am facing the following issue on SUSe pro 9.1, but this issue is not > happening on RH 9.1. > - The MFC application has the dockable toolbar > - When I undock the toolbar to display ad popup window, the screen is not > refreshed and when I see the trace, the X11DRV_SetWindowPos() is called > ininitely. > > - Any one faced this issue? > - Could you please point me to the wine code source files related to toolbar > / dockable controls so that I could debug where the problem is occurring. > > The SUSe pro 9.1 has the follwoing library versions: > > XFree86-fonts-scalable-4.3.99.902-40 > XFree86-libs-4.3.99.902-40 > XFree86-Mesa-devel-4.3.99.902-40 > XFree86-fonts-75dpi-4.3.99.902-40 > XFree86-4.3.99.902-43.25 > XFree86-Mesa-4.3.99.902-40 > XFree86-devel-4.3.99.902-40 > XFree86-server-glx-4.3.99.902-40 > XFree86-server-4.3.99.902-43.25 > XFree86-Xvnc-4.3.99.902-40 > kdebase3-SuSE-9.1-18.1 > kdebase3-3.2.1-68.15 > > > Thanks in advance, > Krishna Murthy > Gupta Technologies LLC > TEL: (650) 596-4828 > E-mail: Krishna.Murthy(a)guptaworldwide.com > > > > >

Aug. 10, 2004

Dockable Toolbar painting issue on SUSE 9.1

by Krishna Murthy

I am facing the following issue on SUSe pro 9.1, but this issue is not happening on RH 9.1. - The MFC application has the dockable toolbar - When I undock the toolbar to display ad popup window, the screen is not refreshed and when I see the trace, the X11DRV_SetWindowPos() is called ininitely. - Any one faced this issue? - Could you please point me to the wine code source files related to toolbar / dockable controls so that I could debug where the problem is occurring. The SUSe pro 9.1 has the follwoing library versions: XFree86-fonts-scalable-4.3.99.902-40 XFree86-libs-4.3.99.902-40 XFree86-Mesa-devel-4.3.99.902-40 XFree86-fonts-75dpi-4.3.99.902-40 XFree86-4.3.99.902-43.25 XFree86-Mesa-4.3.99.902-40 XFree86-devel-4.3.99.902-40 XFree86-server-glx-4.3.99.902-40 XFree86-server-4.3.99.902-43.25 XFree86-Xvnc-4.3.99.902-40 kdebase3-SuSE-9.1-18.1 kdebase3-3.2.1-68.15 Thanks in advance, Krishna Murthy Gupta Technologies LLC TEL: (650) 596-4828 E-mail: Krishna.Murthy(a)guptaworldwide.com

Aug. 10, 2004

Different X Displays and Wine

by Boaz Harrosh

I'm trying to connect and run a remote X session from 2 different machines and I fail to run Wine applications. - I connect from Machine M1 using ssh -X (or -Y) run a wine app all is very well. - I connect from another Machine M2 using ssh -X using the same user. The second instance fails with: <message> X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 15 (X_QueryTree) Resource id in failed request: 0xa0002b Serial number of failed request: 137 Current serial number in output stream: 137 </message> Needless to say that if I exit the Wine application on M1 than M2 will run with out any problems. [Q] Is it at-all possible to run Wine on 2 different $DISPLAY s, or is the X-Server a Wine-Server resource. Will using a different user help? Will using desktop mode help? Has any one been successful with letting different network users connect and run Windows Apps under wine? How did they Setup wine? How does Codeweavers do it with their Server Product? Thanks in advance for any help (or failure reports) any one can give me. Free Life Boaz

Aug. 10, 2004

Re: Wine devel: Two MFC bugs

by Mike Hearn

Green, Shaun E. wrote: >>This is a known problem. Our edit control does not currently support the > > ES_RIGHT style at this time. > > Okay, thanks for letting me know. If you want to implement it, I suspect it wouldn't be too hard. Don't be put off by the fact that it's an API implementation, bug fixes can be done anywhere with open source!

Aug. 10, 2004

Re: USB?

by Aric Stewart

Hi, Sorry for not getting back to you all faster, i was at linux world and such. Yup i am looking hard at the setupapi device calls and cfgmgr to try to get some usb support targeted toward the iPod. I have made some progress and am beginning to have an understand of how usb is handled in windows (win2k is my target version) and how to try to handle it in Wine. I do have some difficulty figuring out how win2k is translating vender and product ids into class and interface guids. The documentation reports that they look them up in inf files, however i am finding that not to be true. I am suspecting that some may be hardcoded in the usb support somewhere. I am probably not anywhere close to having anything clean enough to start commiting to Wine. But if you really want to help we may be able to work together on some stuff. -aric

Aug. 10, 2004

Re: winedos: TSR (was MCB implementation)

by markus.amsler＠oribi.org

Quoting Alexandre Julliard <julliard(a)winehq.org>: > markus.amsler(a)oribi.org writes: > > > Now, what should happen, if you start a TSR programm in a win32 shell > (like > > wcmd,Reactos cmd.exe or Windows cmd.exe)? Spawn FreeCOM, implement TSR > somehow > > in win32 (shell or ntdll) or no TSR support in win32 shells? > > No, TSR support doesn't make sense in Win32. What do you need it for? I'm trying to run a DOS application, that uses a TSR as a database driver. So I donn't need TSR support in win32. I was just thinking how TSR support should look like in wine, and that involves what should happen if you start a TSR programm in a win32 shell. You can run already DOS programms in Win32 shells, so it's naturally to try running a TSR. Markus

Aug. 10, 2004

RE: Wine devel: Two MFC bugs

by Green, Shaun E.

>This is a known problem. Our edit control does not currently support the ES_RIGHT style at this time. Okay, thanks for letting me know. > The second bug is that when I multi-select files to perform an > operation on, nothing happens. One selected file works fine, but any > additional ones cause nothing to happen. Works fine in Windows. >What control are you using for the multi-select? ofn.Flags = OFN_ALLOWMULTISELECT | OFN_HIDEREADONLY | OFN_FILEMUSTEXIST | OFN_EXPLORER ; Here is the dialog code; szFileName[0] = '\0'; OPENFILENAME ofn; ofn.lStructSize = sizeof (OPENFILENAME); ofn.hwndOwner = this->m_hWnd; ofn.hInstance = NULL; #if _LANGUAGE==FRENCH ofn.lpstrFilter = "Fichiers TXT\0*.txt\0\0"; #elif _LANGUAGE==ENGLISH ofn.lpstrFilter = "txt (*.txt)\0*.txt\0\0"; #endif ofn.lpstrCustomFilter = NULL; ofn.nMaxCustFilter = 0; ofn.nFilterIndex = 0; ofn.lpstrFile = szFileName; ofn.nMaxFile = _MAX_PATH+50000; ofn.lpstrFileTitle = NULL; ofn.nMaxFileTitle = 0; ofn.lpstrInitialDir = pDoc->repertoire; ofn.lpstrTitle = NULL; ofn.Flags = OFN_ALLOWMULTISELECT | OFN_HIDEREADONLY | OFN_FILEMUSTEXIST | OFN_EXPLORER ; ofn.nFileOffset = 0; ofn.nFileExtension = 0; ofn.lpstrDefExt = NULL; #ifdef _DEBUG ofn.lCustData = 1L; #else ofn.lCustData = 0L; #endif ofn.lpfnHook = NULL; ofn.lpTemplateName = NULL; if (GetOpenFileName (&ofn)) { Thanks, Shaun

Aug. 10, 2004

Incoming message

by Prupe

Aug. 10, 2004

Re: Wine devel: Two MFC bugs

by Dimitrie O. Paun

> The first is a display problem of edit boxes; for some reason the text > (numbers) are displaying left justified, instead of right justified. The > edit boxes are definitely set for right justified and display fine in > Windows. This is a known problem. Our edit control does not currently support the ES_RIGHT style at this time. > The second bug is that when I multi-select files to perform an operation on, > nothing happens. One selected file works fine, but any additional ones cause > nothing to happen. Works fine in Windows. What control are you using for the multi-select? -- Dimi.

Aug. 10, 2004

(no subject)

by Dpaun

Aug. 10, 2004

winedbg doesn't find source files

by Saulius Krasuckas

When using CVS version of Wine I cannot get much debug: [s2(a)katleriai Spawn]$ WINEDEBUG=+volume winedbg winecfg fixme:console:SetConsoleCtrlHandler (0x4066a644,1) - no error checking or testing yet WineDbg starting on pid 0xa In 32 bit mode. Unable to open file /process.c Wine-dbg>br GetDriveTypeW fixme:dbghelp:elf_lookup_symtab Already found symbol add_paint_count (/usr/src/wine-cvs/wine/dlls/user/../../windows/painting.c) in symtab painting.c @00074738 and painting.c @000a026c fixme:dbghelp:elf_load_debug_info Unsupported Dwarf2 information Breakpoint 1 at 0x403be249 GetDriveTypeW [volume.c:1418] in kernel32 Wine-dbg>c fixme:winecfg:WinMain The winecfg tool is not yet complete, and does not actually alter your configuration. fixme:winecfg:WinMain If you want to alter the way Wine works, look in the ~/.wine/config file for more information. trace:volume:GetVolumeInformationW cannot open device L"\\\\.\\C:": err 2 Stopped on breakpoint 1 at 0x403be249 GetDriveTypeW [volume.c:1418] in kernel32 Unable to open file volume.c Wine-dbg>list 10 Wine-dbg>quit WineDbg terminated on pid 0xa I have had a long period of time not using the winedbg, so I cannot tell whether it is a regression. I am using "./configure && make depend && make" to build the Wine and then something like a "sudo make install", if that matters. 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.

Aug. 9, 2004