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

Re: iostream and msvcrt?

by Dimitrie O. Paun

On Wed, Aug 18, 2004 at 11:32:33AM +0300, Boaz Harrosh wrote: > >I have used STLport before > >so the idea sounds feasable to me. I imagine I have to change the > >gcc-linux.mak by: > > > >replacing the call to gcc with winegcc, > >removing references to GLIBC, > > > > > 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. > > > > > > > Yes exactly. You'll see that you end up with a complete xxx-wine set of > makefiles and headers. 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

Re: Wine Status - User Interface

by Dimitrie O. Paun

On Tue, Aug 17, 2004 at 07:31:33AM -0400, Tom wrote: > I haven't done the changelog so just view this againt > http://www.winehq.org/site/status_ui for changes or diff. > > commits, suggestions, and flames are welcomed Looks good! -- Dimi.

Aug. 19, 2004

Re: gethostbyname on local host returns 127.0.0.1 for address

by Juan Lang

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 __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

Aug. 19, 2004

gethostbyname on local host returns 127.0.0.1 for address

by Robert Reif

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? #include <stdio.h> #ifdef _WIN32 #include <winsock2.h> #include <ws2tcpip.h> #else #include <netdb.h> #endif int main(int argc, char* argv[]) { char host_name[1024]; char ** alias; struct hostent * host; unsigned int i = 0; #ifdef _WIN32 WSADATA wsaData; WORD wVersionRequested = MAKEWORD(2, 2); int error = WSAStartup(wVersionRequested, &wsaData); if (error != 0) { fprintf(stderr, "WSAStartup failed\n"); return 1; } // Confirm that the Windows Sockets DLL supports 2.2. // Note that if the DLL supports versions greater // than 2.2 in addition to 2.2, it will still return // 2.2 in wVersion since that is the version we // requested. if (LOBYTE(wsaData.wVersion) != 2 || HIBYTE(wsaData.wVersion) != 2) { fprintf(stderr, "couldn't find dll\n"); return 1; } #endif if (gethostname(host_name, sizeof(host_name)) != 0) { fprintf(stderr, "gethostname failed\n"); return 1; } printf("host: %s\n", host_name); host = gethostbyname(host_name); if (host == 0) { fprintf(stderr, "gethostbyname failed\n"); return 1; } printf("name of host: %s\n", host->h_name); for (alias = host->h_aliases; *alias != NULL; alias++) printf("alias: %s\n", *alias); printf("length of address: %d\n", host->h_length); while (host->h_addr_list[i] != 0) { struct in_addr n_addr; memcpy(&n_addr, host->h_addr_list[i], sizeof(struct in_addr)); printf("%d: %s\n", i, inet_ntoa(n_addr)); i++; } return 0; }

Aug. 19, 2004

Re: Fixed some ref handling

by Alexandre Julliard

Jacek Caban<jack(a)itma.pwr.wroc.pl> writes: > I attached two test. The first is simple and shows a problem > that the patch fixes but the second one is a more complex test. Could you please merge the test into the existing test framework? -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2004

Re: Removed slovenian translation

by Alexandre Julliard

Jacek Caban<jack(a)itma.pwr.wroc.pl> writes: > Changelog: > Removed slovenian translation If the translation is not complete it should be fixed, or at worse commented out. Removing it doesn't make sense, we'll need to add it back someday anyway. -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2004

Re: KERNEL: pull WINDIR and WINSYSDIR from config before using hardcoded defaults (possible fix for WWN #234, #235 c:\\windows is not accessible Error)

by Alexandre Julliard

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > Changelog: > * if windir or winsysdir environment vars are undefined, pull values > from config file before falling to hardcoded values This of course defeats the whole purpose of the use of environment variables, which is to get rid of the config file. If the environment variables are not set it's because the user's config is wrong, they should be set in HKLM\System\CurrentControlSet\Control\SessionManager or (preferably) in HKCU\Environment. The code is supposed to migrate them automatically, but this may not always work if the registry already contains other values, in which case it needs to be fixed by hand. Going back to the config file is definitely not the right way. -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2004

bug

by Ivan Leo Puoti

Since futimes is used instead of utime the installer of word viewer 97 has had a few installation issues. For a start, when the setup looks for installed components, it goes into a non infinite loop that lasts a few minutes. This only took a few seconds previously. I don't know what is causing this slow performance. The changelog of the patch that caused this regression says "so that it can be done on the client side.", maybe doing the call on client side makes it slow because the call has to go trough wineserver? I don't know. Also the graphics aren't redrawn until the loop ends. A relay log of the loop follows. I'm not very confident that I'll be able to fix this myself, but any help/hints are welcome. Interestingly the loop doesn't occur during a call to kernel.dll.SetFileTime() that's the function modified by the patch. The patch that causes the problem is http://cvs.winehq.org/patch.py?id=11722 Subsequent patches have obviously modified the function, but this hasn't solved the problem. MAybe the subsequent patches avoid an infinite loop (I don't remember the loop finishing with wine from a few months ago). Ivan.

Aug. 18, 2004

Re: Backtrace Dumps

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Alexandre Julliard wrote: > >>Well, I can also imagine a lot of cases where the in-process backtrace >>won't work right, the main one being that since the code will never be >>used unless you want a backtrace, when you try to use it you'll >>realize that it no longer works, or doesn't even compile anymore. If >>we call the debugger instead, it will use the standard backtrace code >>which is always compiled in, and regularly used by a lot of people. > > Do you want me to write a unit test that uses it then? No, the backtrace should be done by the debugger. -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2004

New Fun Project - Winelib port of Allegiance

by Steven Edwards

Hi all, Microsoft Research has released a Shared Source version of the game Allegiance. This is a hefty 512 meg download and of course the license that it is under would prevent anyone from sharing the changes but this would really allow us to improve Winelib by porting such a massive game. http://research.microsoft.com/research/allegiance/ Grab your copy quick before they pull it down. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

Aug. 18, 2004

Re: Backtrace Dumps

by Robert Shearman

Alexandre Julliard wrote: >Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > > > >>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, ... >> >> > >Well, I can also imagine a lot of cases where the in-process backtrace >won't work right, the main one being that since the code will never be >used unless you want a backtrace, when you try to use it you'll >realize that it no longer works, or doesn't even compile anymore. If >we call the debugger instead, it will use the standard backtrace code >which is always compiled in, and regularly used by a lot of people. > > Do you want me to write a unit test that uses it then? Rob

Aug. 18, 2004

Re: OLEAUT32: implementation for IPersistPropertyBag_Load for OLEFont

by Robert Shearman

Alex Villacís Lasso wrote: > This implementation is enough to satisfy VB6 when loading font objects > from property bags in projects. > > Changelog: > * Added implementation for IPersistPropertyBag_Load on OLEFont Looks good, but a few comments below: ... >+ V_VT(&valueAttr) = VT_EMPTY; > > It is probably better practice to use VariantInit here. >+ iRes = IPropertyBag_Read(pPropBag, sAttrName, &valueAttr, pErrorLog); >+ switch (iRes) { > > >+ case S_OK: >+ if (V_VT(&valueAttr) == VT_BSTR) { >+ /* Type is BSTR, use for name directly */ >+ OLEFontImpl_put_Name(this, V_BSTR(&valueAttr)); >+ >+ /* FIXME: Leaking memory here? */ >+ } else { >+ /* Don't know how to handle this type */ >+ FIXME("Name has type %d, not implemented\n", V_VT(&valueAttr)); >+ iRes = E_NOTIMPL; >+ } > Perhaps use VariantChangeType here? >+ break; >+ case E_POINTER: >+ FIXME("\tiResult = [E_POINTER]\n"); >+ break; >+ case E_INVALIDARG: >+ FIXME("\tiResult = [undef]\n"); >+ iRes = S_OK; >+ break; >+ case E_FAIL: >+ FIXME("\tiResult = [E_FAIL]\n"); >+ break; >+ } > Catch the errors you need to (why is E_INVALIDARG ok?) and either move these common debug statements to the end of the function (they should also be ERR's, not FIXME's). Also, you other unexpected errors, which is bad. >+ } >+ >+ if (iRes == S_OK) { >+ CY iSize; >+ iSize.s.Hi = 0; >+ iSize.s.Lo = 0; >+ >+ V_VT(&valueAttr) = VT_EMPTY; >+ iRes = IPropertyBag_Read(pPropBag, sAttrSize, &valueAttr, pErrorLog); >+ switch (iRes) { >+ case S_OK: >+ switch (V_VT(&valueAttr)) { >+ case VT_I2: >+ iSize.s.Lo = V_I2(&valueAttr) * 10000UL; >+ break; >+ case VT_UI2: >+ iSize.s.Lo = V_UI2(&valueAttr) * 10000UL; >+ break; >+ case VT_I4: >+ iSize.s.Lo = V_I4(&valueAttr) * 10000UL; >+ break; >+ case VT_UI4: >+ iSize.s.Lo = V_UI4(&valueAttr) * 10000UL; >+ break; >+ case VT_R4: >+ iSize.s.Lo = (ULONG)(V_R4(&valueAttr) * 10000UL); >+ break; >+ case VT_R8: >+ iSize.s.Lo = (ULONG)(V_R8(&valueAttr) * 10000UL); >+ break; > > Again, perhaps use VariantChangeType here? >+ default: >+ /* Don't know how to handle this type */ >+ FIXME("Size type %d, not implemented\n", V_VT(&valueAttr)); >+ iRes = E_NOTIMPL; >+ break; >+ } >+ if (iRes != E_NOTIMPL) IFont_put_Size(this, iSize); >+ break; >+ case E_POINTER: >+ FIXME("\tiResult = [E_POINTER]\n"); >+ break; >+ case E_INVALIDARG: >+ FIXME("\tiResult = [undef]\n"); >+ iRes = S_OK; >+ break; >+ case E_FAIL: >+ FIXME("\tiResult = [E_FAIL]\n"); >+ break; >+ } > Same comment as before about errors. >+ } >+ if (iRes == S_OK) { >+ signed short iCharset = 0; >+ >+ V_VT(&valueAttr) = VT_EMPTY; >+ iRes = IPropertyBag_Read(pPropBag, sAttrCharset, &valueAttr, pErrorLog); >+ switch (iRes) { >+ case S_OK: >+ switch (V_VT(&valueAttr)) { >+ case VT_I2: >+ if (V_I2(&valueAttr) < 0) { >+ FIXME("Unexpected value for Font Charset (%hd), using 0\n", V_I2(&valueAttr)); >+ } else { >+ iCharset = V_I2(&valueAttr); >+ } >+ break; >+ case VT_UI2: >+ if (V_UI4(&valueAttr) > 32767L) { >+ FIXME("Unexpected value for Font Charset (%ld), using 0\n", V_UI4(&valueAttr)); >+ } else { >+ iCharset = V_UI2(&valueAttr); >+ } >+ break; >+ case VT_I4: >+ if (V_I4(&valueAttr) < 0 || V_I4(&valueAttr) > 32767L) { >+ FIXME("Unexpected value for Font Charset (%ld), using 0\n", V_I4(&valueAttr)); >+ } else { >+ iCharset = V_I4(&valueAttr); >+ } >+ break; >+ case VT_UI4: >+ if (V_UI4(&valueAttr) > 32767L) { >+ FIXME("Unexpected value for Font Charset (%ld), using 0\n", V_UI4(&valueAttr)); >+ } else { >+ iCharset = V_UI4(&valueAttr); >+ } >+ break; >+ default: >+ /* Don't know how to handle this type */ >+ FIXME("Charset type %d, not implemented\n", V_VT(&valueAttr)); >+ iRes = E_NOTIMPL; > > Use VariantChangeType here and you will get all the bounds checking for free. >+ } >+ if (iRes != E_NOTIMPL) IFont_put_Charset(this, iCharset); >+ break; >+ case E_POINTER: >+ FIXME("\tiResult = [E_POINTER]\n"); >+ break; >+ case E_INVALIDARG: >+ FIXME("\tiResult = [undef]\n"); >+ iRes = S_OK; >+ break; >+ case E_FAIL: >+ FIXME("\tiResult = [E_FAIL]\n"); >+ break; >+ } >+ } >+ >+ if (iRes == S_OK) { >+ signed short iWeight = FW_NORMAL; >+ >+ V_VT(&valueAttr) = VT_EMPTY; >+ iRes = IPropertyBag_Read(pPropBag, sAttrWeight, &valueAttr, pErrorLog); >+ switch (iRes) { >+ case S_OK: >+ switch (V_VT(&valueAttr)) { >+ case VT_I2: >+ if (V_I2(&valueAttr) < 0) { >+ FIXME("Unexpected value for Font Weight (%hd), using FW_NORMAL\n", V_I2(&valueAttr)); >+ } else { >+ iWeight = V_I2(&valueAttr); >+ } >+ break; >+ case VT_UI2: >+ if (V_UI4(&valueAttr) > 32767L) { >+ FIXME("Unexpected value for Font Weight (%ld), using FW_NORMAL\n", V_UI4(&valueAttr)); >+ } else { >+ iWeight = V_UI2(&valueAttr); >+ } >+ break; >+ case VT_I4: >+ if (V_I4(&valueAttr) < 0 || V_I4(&valueAttr) > 32767L) { >+ FIXME("Unexpected value for Font Weight (%ld), using FW_NORMAL\n", V_I4(&valueAttr)); >+ } else { >+ iWeight = V_I4(&valueAttr); >+ } >+ break; >+ case VT_UI4: >+ if (V_UI4(&valueAttr) > 32767L) { >+ FIXME("Unexpected value for Font Weight (%ld), using FW_NORMAL\n", V_UI4(&valueAttr)); >+ } else { >+ iWeight = V_UI4(&valueAttr); >+ } >+ break; >+ default: >+ /* Don't know how to handle this type */ >+ FIXME("Weight type %d, not implemented\n", V_VT(&valueAttr)); >+ iRes = E_NOTIMPL; >+ } > Again, use VariantChangeType. >+ if (iRes != E_NOTIMPL) IFont_put_Weight(this, iWeight); >+ break; >+ case E_POINTER: >+ FIXME("\tiResult = [E_POINTER]\n"); >+ break; >+ case E_INVALIDARG: >+ FIXME("\tiResult = [undef]\n"); >+ iRes = S_OK; >+ break; >+ case E_FAIL: >+ FIXME("\tiResult = [E_FAIL]\n"); >+ break; >+ } >+ } >+ >+ if (iRes == S_OK) { >+ BOOL bUnderline = FALSE; >+ >+ V_VT(&valueAttr) = VT_EMPTY; >+ iRes = IPropertyBag_Read(pPropBag, sAttrUnderline, &valueAttr, pErrorLog); >+ switch (iRes) { >+ case S_OK: >+ switch (V_VT(&valueAttr)) { >+ case VT_I2: >+ bUnderline = V_I2(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_I4: >+ bUnderline = V_I4(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_UI2: >+ bUnderline = V_UI2(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_UI4: >+ bUnderline = V_UI4(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_BOOL: >+ bUnderline = V_BOOL(&valueAttr); >+ break; >+ default: >+ /* Don't know how to handle this type */ >+ FIXME("Underline type %d, not implemented\n", V_VT(&valueAttr)); >+ iRes = E_NOTIMPL; >+ break; >+ } > Again, VariantChangeType. >+ if (iRes != E_NOTIMPL) IFont_put_Underline(this, bUnderline); >+ break; >+ case E_POINTER: >+ FIXME("\tiResult = [E_POINTER]\n"); >+ break; >+ case E_INVALIDARG: >+ FIXME("\tiResult = [undef]\n"); >+ iRes = S_OK; >+ break; >+ case E_FAIL: >+ FIXME("\tiResult = [E_FAIL]\n"); >+ break; >+ } >+ } >+ >+ if (iRes == S_OK) { >+ BOOL bItalic = FALSE; >+ >+ V_VT(&valueAttr) = VT_EMPTY; >+ iRes = IPropertyBag_Read(pPropBag, sAttrItalic, &valueAttr, pErrorLog); >+ switch (iRes) { >+ case S_OK: >+ switch (V_VT(&valueAttr)) { >+ case VT_I2: >+ bItalic = V_I2(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_I4: >+ bItalic = V_I4(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_UI2: >+ bItalic = V_UI2(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_UI4: >+ bItalic = V_UI4(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_BOOL: >+ bItalic = V_BOOL(&valueAttr); >+ break; >+ default: >+ /* Don't know how to handle this type */ >+ FIXME("Italic type %d, not implemented\n", V_VT(&valueAttr)); >+ iRes = E_NOTIMPL; >+ break; >+ } > Again, use VariantChangeType. >+ if (iRes != E_NOTIMPL) IFont_put_Italic(this, bItalic); >+ break; >+ case E_POINTER: >+ FIXME("\tiResult = [E_POINTER]\n"); >+ break; >+ case E_INVALIDARG: >+ FIXME("\tiResult = [undef]\n"); >+ iRes = S_OK; >+ break; >+ case E_FAIL: >+ FIXME("\tiResult = [E_FAIL]\n"); >+ break; >+ } >+ } >+ >+ if (iRes == S_OK) { >+ BOOL bStrikethrough = FALSE; >+ >+ V_VT(&valueAttr) = VT_EMPTY; >+ iRes = IPropertyBag_Read(pPropBag, sAttrStrikethrough, &valueAttr, pErrorLog); >+ switch (iRes) { >+ case S_OK: >+ switch (V_VT(&valueAttr)) { >+ case VT_I2: >+ bStrikethrough = V_I2(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_I4: >+ bStrikethrough = V_I4(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_UI2: >+ bStrikethrough = V_UI2(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_UI4: >+ bStrikethrough = V_UI4(&valueAttr) ? TRUE : FALSE; >+ break; >+ case VT_BOOL: >+ bStrikethrough = V_BOOL(&valueAttr); >+ break; >+ default: >+ /* Don't know how to handle this type */ >+ FIXME("Strikethrough type %d, not implemented\n", V_VT(&valueAttr)); >+ iRes = E_NOTIMPL; >+ break; >+ } > > Again, use VariantChangeType. >+ if (iRes != E_NOTIMPL) IFont_put_Strikethrough(this, bStrikethrough); >+ break; >+ case E_POINTER: >+ FIXME("\tiResult = [E_POINTER]\n"); >+ break; >+ case E_INVALIDARG: >+ FIXME("\tiResult = [undef]\n"); >+ iRes = S_OK; >+ break; >+ case E_FAIL: >+ FIXME("\tiResult = [E_FAIL]\n"); >+ break; >+ } >+ } >+ return iRes; > } > > static HRESULT WINAPI OLEFontImpl_IPersistPropertyBag_Save( > > Thanks, Rob

Aug. 18, 2004

Re: Backtrace Dumps

by Alexandre Julliard

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > 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, ... Well, I can also imagine a lot of cases where the in-process backtrace won't work right, the main one being that since the code will never be used unless you want a backtrace, when you try to use it you'll realize that it no longer works, or doesn't even compile anymore. If we call the debugger instead, it will use the standard backtrace code which is always compiled in, and regularly used by a lot of people. -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2004

Re: Some more hardcoded c:\windows paths

by Juan Lang

Vincent wrote: > Any idea why CSIDL_PROGRAMS was HKEY_DISALLOWED? That, apparently, was my mistake. I introduced it here: http://www.winehq.org/hypermail/wine-patches/2004/04/0106.html Thanks for fixing it. --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

Aug. 18, 2004

Re: WineSetupTk...

by Ivan Leo Puoti

> I doubt there's a one maintainer Nobody maintains it because it's obsolete and isn't used with current versions of wine. Ivan.

Aug. 18, 2004