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

Re: Take monospace fonts into account in default font selectionalgorithm.

by Mike Hearn

On Thu, 2004-08-19 at 12:06 +0100, Huw D M Davies wrote: > This also wouldn't work as you expect. The way to create a fixed > pitch font is to use FIXED_PITCH not MONO_FONT. Which app was > setting this flag? There wasn't one, I assumed MONO_FONT meant monospace, which is what I was trying to stop Wine selecting. I didn't have MSDN handy at the time though so it was basically just a guess ...

Aug. 19, 2004

Re: gethostbyname on local host returns 127.0.0.1 for address

by Juan Lang

--- Robert Reif <reif(a)earthlink.net> wrote: > It's gethostbyname that has the problem. Oops, you're right, I didn't read your code that closely. What I said earlier is still appropriate though: you can call something in iphlpapi, like GetAdaptersInfo, or perhaps GetIpAddrTable. You could also use WSAIoctl. Take a look at dlls/winsock/socket.c; you'd want to modify WS_gethostbyname, and it already calls GetAdaptersInfo to implement WSAIoctl. Do you have an app that depends on this, or are you just trying to get the network interface addresses? --Juan __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

Aug. 19, 2004

Re: Backtrace Dumps

by Eric Pouech

> Indeed. > I'm sure every semi-involved Wine developer can imagine dozens of > "reasons of the day" why winedbg doesn't launch properly on error again... > Failure in wine exception handling code, failure to look up winedbg > (both registry and disk), failure to pass winedbg cmdline parameters properly, > failure to get winedbg started up properly, failure to get winedbg to > parse the current modules and stack frame properly, ... > > That's why a "no frills" debugging mechanism is a good idea IMHO. > > Andreas Mohr > > P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, > and when considering how many fatal architecture changes winedbg had > to go through, it's amazing that it still works pretty well. :-) > No offense taken. If I look to your list of potential issues, most of them fall into Alexandre's private garden... <g> A+

Aug. 19, 2004

Re: gethostbyname on local host returns 127.0.0.1 for address

by Robert Reif

Juan Lang wrote: >Robert wrote: > > >>On windows gethostbyname for the local host returns >>the addresses of the available network interfaces. >>On wine and unix, it only returns the localhost >>127.0.0.1. >> >>Any ideas on how to get the windows behavior? >> >> > >I assume you're referring to gethostname (as in your >sample code), not gethostbyname (as in your email). > >Well, I guess you'd have to modify winsock/socket.c's >WS_gethostname function, maybe to call GetAdaptersInfo >or some such. That'll get you the addresses, anyway. >If you want a name other than localhost you may want >to call GetNetworkParams too. > >--Juan > > > It's gethostbyname that has the problem. gethostname is just used to find the name of the machine that the program is running on and is what is passed to gethostbyname. gethostbyname should return a host structure which contains an array of addresses associated with the host. On windows, the addresses are the addresses of the network interfaces. On wine and unix, the address returned is 127.0.0.1 which is localhost, not the actual interface address.

Aug. 19, 2004

Re: Take monospace fonts into account in default font selectionalgorithm.

by Huw D M Davies

On Sat, Aug 07, 2004 at 04:20:11PM +0100, Mike Hearn wrote: > @@ -1717,9 +1719,12 @@ > } > } > > + /* match on charset and style */ > if(!family) { > for(family = FontList; family; family = family->next) { > - if(csi.fs.fsCsb[0] & family->FirstFace->fs.fsCsb[0]) > + > + if((csi.fs.fsCsb[0] & family->FirstFace->fs.fsCsb[0]) && > + (family->FirstFace->fixed_width == (lf.lfPitchAndFamily & MONO_FONT ? TRUE : FALSE))) > if(family->FirstFace->scalable || can_use_bitmap) > break; > } This also wouldn't work as you expect. The way to create a fixed pitch font is to use FIXED_PITCH not MONO_FONT. Which app was setting this flag? Huw. -- Huw Davies huw(a)codeweavers.com

Aug. 19, 2004

Re: Info on debugging requested: trying to run "Hearts of Iron"

by Andreas Mohr

Hi, On Thu, Aug 19, 2004 at 09:31:24AM +0200, Andreas Mohr wrote: > You should at least have used pipes as described in the User Guide... > (not sure whether that ultimately helps then, though...) Doh, make that Developers Guide, I think. Andreas Mohr

Aug. 19, 2004

Re: Info on debugging requested: trying to run "Hearts of Iron"

by Andreas Mohr

Hi, On Thu, Aug 19, 2004 at 06:43:14PM +1200, Simon Kitching wrote: > Backtrace: > =>1 0x004191fb (0x406bfe94) > 2 0x005af5b2 (0x406bff20) All in app space, most likely. Not very useful, I'm afraid. > And then is there a way to step through at the source rather than > assembly level? --> only if you have the game source ;-) > It's apparent here that %ecx is null when not expected to be, resulting > in a bad access to memory address 0x00000006. Yup, most likely. > I also tried the "WINEDEBUG=+relay" option as recommended in the wine > docs. However after leaving the program running overnight, and having > generated 3 gigabytes of log output, the point where the bug occurs > hadn't been reached. I think that what's happening is that there is a > thread (0011) which is driven by timer ticks [probably doing GUI or > sound stuff], and that because HoI is running much more slowly under > +relay, that the thread doing the load-game work (0009) isn't actually > getting any CPU time at all. NB: the log was only 3GB because I used > grep to discard output about RtlEnterCriticalSection and > RtlLeaveCriticalSection. Without that, the log would be closer to 30GB! You should at least have used pipes as described in the User Guide... (not sure whether that ultimately helps then, though...) > Any suggestions on how to make progress on this issue are welcome. If a relay trace doesn't help, then the next thing would be to disas surrounding code at 0x004191fb and walk back the code flow to find out where the NULL %ecx was coming from. > PS: Congrats to the Wine team. I was most impressed how well HoI ran on > wine. Thanks! Andreas Mohr

Aug. 19, 2004

Re: Info on debugging requested: trying to run "Hearts of Iron"

by Izak Burger

Simon Kitching wrote: > There is then no response to the keyboard; no debugger prompt or > anything. Is this meant to start a debugger interactive session here, or --- snip --- > Backtrace: > =>1 0x004191fb (0x406bfe94) > 2 0x005af5b2 (0x406bff20) > 3 0x404ff9f2 start_process+0xf2(arg=0x0) [process.c:995] in kernel32 > (0x406bfff4) > 4 0x4002c151 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) > 0x004191fb: movl 0x6(%ecx),%ecx > Wine-dbg> This ^^^^^ here is the debugger prompt. > </output> > Qn: is there any way of getting function names in that backtrace rather > than just addresses? I've tried "CFLAGS=-g ./configure" when rebuilding > wine, but haven't had time to test the resulting wine binaries. Yes, recompile wine with debugging enabled. I think it is a ./configure option but it comes down to adding -g to the gcc options. > And then is there a way to step through at the source rather than > assembly level? Same as above. > I also tried the "WINEDEBUG=+relay" option as recommended in the wine --- snip--- > sound stuff], and that because HoI is running much more slowly under > +relay, that the thread doing the load-game work (0009) isn't actually > getting any CPU time at all. NB: the log was only 3GB because I used Yes, the observer changes the nature of the observed. I absolutely hate that. But the fact that it happens sometimes points to some kind of race condition that no longer occurs when it is slowed down somewhat, this is at least true when you're programming at the hardware level :-) > By the way, I'm an experienced c/c++ developer on unix/linux, but know > very little about Windows programming (and frankly would prefer to leave > it that way :-). It's been a while since I've used gdb and friends, but > can brush up on that if it's useful. You and me both. Actually, I wasn't even much of a C++ coder until someone at work told me to make an app work on wine, which is how I landed on this list. And then, shortly afterwards, I was thrown into Symbian c++ development :-) Talk about being thrown in on the deep end. > PS: Congrats to the Wine team. I was most impressed how well HoI ran on > wine. Sounds almost too good to be true, I must admit :-) Cheers, Izak

Aug. 19, 2004

Info on debugging requested: trying to run "Hearts of Iron"

by Simon Kitching

Hi, I recently tried to run the MS-Windows WWII strategy game "Hearts of Iron" using Wine on Linux. And it *very nearly* works. In fact, it's so close I'm trying to debug the problem in the hope of getting it working. I hope that someone here can give me a few wine debugging tips. Actually, the game runs perfectly - absolutely "gold" standard. I gave it a 5-hour "stress test" ;-) and did not experience a single problem. There are some minor problems on startup, but there are reasonable workarounds for those. The problem, though, is that saved games cannot be loaded. Unfortunately, this is a show-stopper as a game of HoI typically takes several days to play! Fortunately the problem is 100% repeatable. FYI: I'm running Debian Sarge on x86, no native windows partition. I first tried the latest debian wine package, and then rebuilt from CVS HEAD code of Fri 13 August (possibly a bad day to choose :-). Exactly the same behaviour occurred. Info on the game can be found here: http://www.heartsofiron-game.com/. It's a WWII strategy game with pleasant but not intensive graphics. When running "wine HoI.exe" and trying to load a saved game, a message is output: wine: Unhandled exception (thread 0009), starting debugger.. Usage: winedbg [--auto] [--gdb] comdline There is then no response to the keyboard; no debugger prompt or anything. Is this meant to start a debugger interactive session here, or am I supposed to somehow start a debugger and point it at the wine process? If so, info on how to do so would be appreciated. I ran "winedbg HoI.exe" and got exactly the same behaviour, though with a bit more info: <output> First chance exception: page fault on read access to 0x00000006 in 32-bit code (0x004191fb). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:004191fb ESP:406bf4ec EBP:406bfe94 EFLAGS:00210206( - 00 - RIP1) EAX:48258e60 EBX:00000000 ECX:00000000 EDX:007e5f44 ESI:418736c0 EDI:45ae16e3 Stack dump: 0x00000000: 00000000 00000000 00000000 00000000 0x00000010: 00000000 00000000 00000000 00000000 0x00000020: 00000000 00000000 00000000 00000000 0x00000030: 00000000 00000000 00000000 00000000 0x00000040: 00000000 00000000 00000000 00000000 0x00000050: 00000000 00000000 00000000 00000000 0x00000060: Backtrace: =>1 0x004191fb (0x406bfe94) 2 0x005af5b2 (0x406bff20) 3 0x404ff9f2 start_process+0xf2(arg=0x0) [process.c:995] in kernel32 (0x406bfff4) 4 0x4002c151 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x004191fb: movl 0x6(%ecx),%ecx Wine-dbg> </output> Qn: is there any way of getting function names in that backtrace rather than just addresses? I've tried "CFLAGS=-g ./configure" when rebuilding wine, but haven't had time to test the resulting wine binaries. And then is there a way to step through at the source rather than assembly level? It's apparent here that %ecx is null when not expected to be, resulting in a bad access to memory address 0x00000006. I also tried the "WINEDEBUG=+relay" option as recommended in the wine docs. However after leaving the program running overnight, and having generated 3 gigabytes of log output, the point where the bug occurs hadn't been reached. I think that what's happening is that there is a thread (0011) which is driven by timer ticks [probably doing GUI or sound stuff], and that because HoI is running much more slowly under +relay, that the thread doing the load-game work (0009) isn't actually getting any CPU time at all. NB: the log was only 3GB because I used grep to discard output about RtlEnterCriticalSection and RtlLeaveCriticalSection. Without that, the log would be closer to 30GB! Any suggestions on how to make progress on this issue are welcome. Pointers to documentation on debugging this sort of thing are very welcome. By the way, I'm an experienced c/c++ developer on unix/linux, but know very little about Windows programming (and frankly would prefer to leave it that way :-). It's been a while since I've used gdb and friends, but can brush up on that if it's useful. Cheers, Simon PS: Congrats to the Wine team. I was most impressed how well HoI ran on wine.

Aug. 19, 2004

RE: iostream and msvcrt?

by Scott Snell

Hi Dimi, Thanks for helping out. I made the changes you suggested to the gcc-mingw.mak file for STLPort. When I go make it does a: wineg++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -mno-cygwin -O2 -D_STLP_USE_DYNAMIC_LIB dll_main.cpp -c -o ../lib/obj/MINGW32/ReleaseD/dll_main.o which throws up a world of errors, such as: In file included from ../stlport/cstdlib:25, from ../stlport/stl/debug/_debug.c:160, from ../stlport/stl/debug/_debug.h:418, from ../stlport/utility:40, from dll_main.cpp:35: /usr/include/c++/3.3.2/cstdlib:97: error: `div' not declared /usr/include/c++/3.3.2/cstdlib:102: error: `ldiv' not declared /usr/include/c++/3.3.2/cstdlib: In function `ldiv_t std::div(long int, long int)': I'm sure its something simple but I'm still not comfortable around gcc/winegcc. thanks, Scott. > -----Original Message----- > From: Dimitrie O. Paun [SMTP:dpaun(a)rogers.com] > > On Wed, Aug 18, 2004 at 11:32:33AM +0300, Boaz Harrosh wrote: > > > > > Better go with gcc-mingw.mak, as threading and OS is more Windows than > > Linux. See if they have a -nocygwin variant. > > Yes, it should work with the gcc-mingw.mak by changing > gcc -> winegcc > g++ -> wineg++ > > > >adding a path pointing to /include/wine/MSVCRT. > > > > > No, you shouldn't need that. You just need to make sure you pass > the -mno-cygwin flag to winegcc/wineg++. > > -- > Dimi.

Aug. 19, 2004