wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Add strncpyW to unicode.h
by Jeff Latimer 26 Apr '05

26 Apr '05

I have just been reading the lists and realise that strncpyW/strncpy is bad news for some reason. Please consider this patch withdrawn. Wouldn't it be better to implement strncpyW as a wrapper for memcpy? Given that all the other string functions are implemeted with the (W) version, having strncpyW missing is a bit confusing. Jeff Latimer Jeff Latimer wrote: > An implementation of strncpyW. > > Jeff Latimer > >------------------------------------------------------------------------ > >Index: unicode.h >=================================================================== >RCS file: /home/wine/wine/include/wine/unicode.h,v >retrieving revision 1.31 >diff -u -r1.31 unicode.h >--- unicode.h 21 Apr 2005 17:18:50 -0000 1.31 >+++ unicode.h 25 Apr 2005 10:48:05 -0000 >@@ -191,6 +191,18 @@ > return dst; > } > >+static inline WCHAR *strncpyW( WCHAR *dst, const WCHAR *src, int maxlen ) >+{ >+ WCHAR *p = dst; >+ if (maxlen > 0 ) >+ { >+ maxlen--; >+ while (((*p++ = *src++) && maxlen--)); >+ } >+ if (*p) *p++ = (WCHAR) "\0"; >+ return dst; >+} >+ > static inline int strcmpW( const WCHAR *str1, const WCHAR *str2 ) > { > while (*str1 && (*str1 == *str2)) { str1++; str2++; } > >

2 3

ComboBoxEx focus bug
by felix.nawothnig＠t-online.de 26 Apr '05

26 Apr '05

Hi. I'm trying to fix PR 1114 and ran into the following problem: The listbox of WinRAR isn't updated because CBN_SELENDOK isn't sent. CBN_SELENDOK is supposed to be sent by CBRollUp() called by the LBN_SELCHANGE handler but isn't because the listbox (of the combobox) is already rolled up when LBN_SELCHANGE is received. The premature CBRollUp() is caused by a click into the combo/listbox which SetFocus()es the listbox which causes a KILLFOCUS sent to the edit control which was holding the focus before and then forwards the KILLFOCUS to it's parent (the ComboLBox) which rolls the listbox up and issues CBN_SELENDCANCEL. (This causes also a visible difference between native and builtin comctl32 - native ComboBoxEx rolls up on mouseup, ours rolls up on mousedown) So the problem is that the editbox has the focus although the listbox is rolled down - this is the case for DROPDOWN comboboxes but only possible since the listbox takes care of this special case and forwards the focus to the edit control. Since a ComboBoxEx is a DROPDOWNLIST with an edit control drawn itself the editbox has to lose the focus when the listbox is rolled down. The listbox code actually takes care of that and sets the focus to the listbox if it's not child of a DROPDOWN CB but the CBN_SETFOCUS handling in comboex.c sets the focus back to the edit control for some reason, stating: * We also need to set the focus back to the Edit control * after passing the command to the parent of the ComboEx. Putting an "case CBN_SETFOCUS:" before the CBN_SELENDOK case (making sure that the focus isn't set to the edit control after a CBN_SETFOCUS) makes WinRAR work, makes the listbox roll up on mouseup (looks exactly like native comctl32) and doesn't seem to cause any problems. However, if the ComboBoxEx receives another CBN_* (except those handled by case statements which all *don't* set the focus to the edit box) I think it will set the focus back to the edit control (although the listbox is still rolled down) and when the user then selects an item it will again roll up and send CBN_SELENDCANCEL. So would it be right to completly remove the focus-forwarding to the edit control? (Since I know nothing about Win32 programming, the comments talk about MSIE4 expecting some specific behaviour and I don't wanna cause a regression I decided to ask here first :) -flexo

1 0

Re: Bug 2904
by Juan Lang 26 Apr '05

26 Apr '05

> Hey guys, can one of you have a look at bug 2904? Isn't this the same thing? http://www.winehq.org/hypermail/wine-devel/2005/04/0494.html Whether or not the patch Michael attached is the "real" fix, it should solve the immediate problem (the assert failure.) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Exception in DefWindowProcA
by Paul Vriens 26 Apr '05

26 Apr '05

Hi, when running proces explorer (V9.0.3) and some hacks, I get an exception in DefWindowProcA: trace:message:SPY_EnterMessage (0x20022) DefWindowProc32: WM_GETTEXT [000d] wp=00000100 lp=00000000 Call kernel32.WideCharToMultiByte(00000000,00000000,6b2592e0 L"Process Explorer - Sysinternals: www.sysinternals.com",ffffffff,00000000,00000100,00000000,00000000) ret=61b8be5 Ret kernel32.WideCharToMultiByte() retval=00000000 ret=61b8be52 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x61b8be5c It somewhat boils down to this piece of code in defwnd.c: line:754 if (wndPtr->text) { if (!WideCharToMultiByte( CP_ACP, 0, wndPtr->text, -1, dest, wParam, NULL, NULL )) dest[wParam-1] = 0; result = strlen( dest ); } else dest[0] = '\0'; WIN_ReleasePtr( wndPtr ); dest = NULL in my case so I added some tests for this: if (wndPtr->text) { if (!WideCharToMultiByte( CP_ACP, 0, wndPtr->text, -1, dest, wParam, NULL, NULL )) { if (dest) dest[wParam-1] = 0; } if (dest) result = strlen( dest ); else result = 0; } This makes the GUI appear but I want to find out if the call is valid or that we indeed should check for dest being NULL. Any ideas? Cheers, Paul.

1 0

Re: OLEAUT32: (resend) Floating point locale, no negative zero
by Alexandre Julliard 26 Apr '05

26 Apr '05

Alex Villacis Lasso <a_villacis(a)palosanto.com> writes: > Changelog: > * Force Single|Double conversion to BSTR to use the decimal separator > defined by the current locale, because that is what native oleaut32 > does, and to be consistent with later parsing of floating-point > numbers, which uses current locale. Failure to apply this patch causes > vartype test to fail in non-US locales with a decimal separator other > than a period. > * The number form "-0" is *not* allowed to be returned in a > Single|Double conversion to BSTR in case of numeric undeflow, use > unsigned zero instead. Some applications depend on this. Test included. That's ugly, I think we really want to do our own formatting instead of using the system printf and hacking the string afterwards. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: PATCH: gcc4 alias fixes
by Dan Kegel 26 Apr '05

26 Apr '05

Dimitrie O. Paun wrote: >> This is the patch I use for gcc4.0 here. >> >> I am not really sure why this aliasing was introduced, >> but it will not work this way anymore. > > I still don't understand why it doesn't work. > > It was introduced because using macros it not always acceptable. > Some source uses these functions in ways that break if they are > defined as macros. > > Defining them as inline functions work, but we can't do so for > varargs, in which case we used aliases. > > What was the reason to break them, and why they don't work? > They are aliasing to things that _are_ defined, so I'm not > sure what is going on there. http://www.gnu.org/software/gcc/gcc-4.0/changes.html says (not that I really understand it totally): --- snip --- Given __attribute__((alias("target"))) it is now an error if target is not a symbol, defined in the same translation unit. This also applies to aliases created by #pragma weak alias=target. This is because it's meaningless to define an alias to an undefined symbol. On Solaris, the native assembler would have caught this error, but GNU as does not. --- snip --- - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

How to deal with different struct sizes per OS
by Paul Vriens 26 Apr '05

26 Apr '05

Hi, while dealing with the SYSTEM_PROCESS_INFORMATION struct in winternl.h I found that the struct has different sizes for NT/W2K/W2K3. How do we deal with this? Have a struct per OS and deal with it in the handling part (ntdll/nt.c in this case) for what *version* returns? Should the default one be the most extensive one? We obviously need a run-time check. While I'm at it, this struct contains another struct (VM_COUNTERS). Do we want the seperate items in SYSTEM_PROCESS_INFORMATION or a reference to VM_COUNTERS? (VM_COUNTERS looks cleaner). Cheers, Paul Vriens.

1 0

Bug 2904
by Dustin Navea 25 Apr '05

25 Apr '05

Hey guys, can one of you have a look at bug 2904? The reporter left a slightly barebones report, but I was able to find the patch that caused the problem, and posted all the relevant info I could find in my comments. Hopefully someone can write up a quick fix.. Thanks Dustin P.S. It's great to be back maintaining the database.. Now for all those bugs Ive missed over the last couple of years! ;-)

1 0

Re: avicap32 patch
by Juan Lang 25 Apr '05

25 Apr '05

Hi Maarten, > +#ifdef HAVE_LINUX_VIDEODEV_H > +#include <stdio.h> > +#include <sys/ioctl.h> > +#include <sys/stat.h> > +#include <errno.h> > +#include <asm/types.h> > +#include <linux/videodev.h> > +#include <fcntl.h> > +#include <unistd.h> > +#include "winnls.h" > +#endif You need to include "winnls.h" unconditionally, capGetDriverDescriptionW is always compiled with calls to MultiByteToWideChar. > + sprintf(device, "/dev/video%i", devnum); Why not use snprintf(device, sizeof(device) ...) instead? > + strcpy(name, caps.card); Ug. Please don't use strcpy. Even though caps.card and name happen to be declared of the same size, and caps.card is very likely null-terminated, it takes a bit of searching around to make sure that's the case. It's easier to verify it's correct if you use lstrncpyA or memcpy instead. Since you NULL-terminate in the next line, I'd suggest memcpy. > + sprintf(version, "%s v%u.%u.%u", It's also not obvious how large version is. I'd recommend passing in the length of the buffer and using snprintf instead. You might as well pass in the length of name, too. > + strncpy(lpszName, devname, cbName); You won't be able to use strncpy anymore, see Alexandre's commit: http://www.winehq.org/hypermail/wine-cvs/2005/04/0275.html --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

WoW, er Wine on Windows--Re: Still more fun?
by Augustus Saunders 25 Apr '05

25 Apr '05

I've been avidly following WWN for some time now, and now that other people have brought up this topic (using WINE dlls on Windows), I wanted to jump in. (I'm not subscribed, so please CC me on any response) My employer is vaguely considering pursuing a product idea, depending on 1) how difficult this is to do, 2) how complete WINE is in the areas we're interested in, and 3) presuming the licensing works out. But that's neither here nor there, so let me describe what we want to do. We are interested in creating an "application launcher" application, where-in you run our application, choose any other application installed on your system, and it is executed, but links against any WINE dlls that we provide instead of system dlls. So we want to put all of the WINE dlls (that we care to use) in say, "C:\Program Files\LauncherApp\WINE" or some such, and injecting that ahead of WINDOWS and SYSTEM32 directories, but only for apps run from our launcher. Anything we don't provide should just fall back on the system dlls. As for what we hope to accomplish, well, it might seem like massive overkill to try using WINE, but it's the only plausible way I've come up with. Basically, we want to substitute all the graphics/windowing/GDI etc so that we can record all the painting/rendering into some kind of WMF type thingy. The idea is to get screen captures as metafiles that are perfectly screen-accurate. There are numerous ways to grab a bitmap rendering of a window/screen, but that's useless. Also, you can (sometimes) get an application to print to your metafile, but that is for printing documents and does not show the application as it appears on screen. The end result? Essentially vector graphic screen shots. I can imagine some weird interactions caused by using wine dlls and system dlls at the same time. I can also imagine that things might go berzerk when a WINE-linked app's window's overlapped a regular app--it would probably be necessary to forward some stuff to the WIN32 system so that windows would interact and messages get sent properly. In fact, for us, it would be ok to forward everything to WIN32 versions, and have WINE maintain a "shadow" copy of all the windows in memory that we capture from, but aren't on-screen. But that could be a huge performance drain. It seems like this could be a ton of work, or practically trivial, and I can't tell which. Finally, how much is DirectDraw/D3D used outside of games? We're only interested in desktop/office type apps, and I presume we can safely ignore trapping anything sent through DirectX. I appreciate any feedback anybody has. Thanks- Augustus PS I'm not subscribed (I just read WWN), so please CC me on any responses. Thanks.

4 4

TrashCan - Day 4
by Steven Edwards 25 Apr '05

25 Apr '05

Hi, This one is much better but still far from perfect. Trashing files to ~/.Trash now works and its cleanly put in to a new function. Alexandre wants to have the default behavior to be to use C:\Recycled so I am going to add a registry entry and a option to winecfg so that the user can enable FreeDesktop trash if they wish. Any suggestions on Key/Value name and location? Thanks Steven __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: Some fixes for filtergraph.c (#2)
by Christian Costa 25 Apr '05

25 Apr '05

> > >>> >> This is not correct, you must connect all pins, not just the first >> that succeeds. > > > Asleep? ;) You can't connect an input pin more then once > (VFW_E_ALREADY_CONNECTED), anyway this function always returned S_OK, > I fixed that too now... If you still think multiple connects should > happen > http://msdn.microsoft.com/library/en-us/directshow/htm/ipinconnect.asp ;) No, no. It's not necessary. I'm convinced. :-) > > static HRESULT WINAPI Mediacontrol_Pause(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ TRACE("(%p/%p)->()\n", This, iface); > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ if (This->state == State_Paused) return S_OK; >+ >+ SendTheFilterAMessage(iface, SendPause); >+ This->state = State_Paused; > > return S_OK; > } > > Shouldn't S_FALSE be returned in the last statement? > > static HRESULT WINAPI Mediacontrol_Stop(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ TRACE("(%p/%p)->()\n", This, iface); > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ if (This->state == State_Stopped) return S_OK; >+ if (This->state == State_Running) SendTheFilterAMessage(iface, SendPause); >+ SendTheFilterAMessage(iface, SendStop); >+ This->state = State_Stopped; > > return S_OK; > } > > I think you should move the critical section out of SendTheFilterAMessage and put it in Run, Pause and Stop methods. Bye, Christian PS: SendTheFilterAMessage and FoundFilter are really odd names, no?

2 1

Re: Privilege Checks For RegLoadKey, RegUnloadKey & RegSaveKey
by Alexandre Julliard 25 Apr '05

25 Apr '05

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > - Fix access rights for RegOpenKeyEx and RegCreateKeyEx calls. > - Add privilege checks for RegLoadKey, RegUnloadKey & RegSaveKey calls. This breaks the crypt tests: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so crypt.c && touch crypt.ok crypt.c:224: Test failed: 8009000f -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: tools/widl
by Alexandre Julliard 25 Apr '05

25 Apr '05

Ge van Geldorp <gvg(a)reactos.com> writes: > + switch(var->type->type) > + { > + case RPC_FC_BYTE: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_BYTE */\n", RPC_FC_BYTE); > + break; > + case RPC_FC_CHAR: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_CHAR */\n", RPC_FC_CHAR); > + break; > + case RPC_FC_WCHAR: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_WCHAR */\n", RPC_FC_WCHAR); > + break; > + case RPC_FC_USHORT: > + case RPC_FC_SHORT: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_USHORT */\n", RPC_FC_SHORT); > + break; > + case RPC_FC_ULONG: > + case RPC_FC_LONG: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_LONG */\n", RPC_FC_LONG); > + break; > + case RPC_FC_HYPER: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_HYPER */\n", RPC_FC_HYPER); > + break; > + case RPC_FC_IGNORE: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_IGNORE */\n", RPC_FC_IGNORE); > + break; > + case RPC_FC_SMALL: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_SMALL */\n", RPC_FC_SMALL); > + break; > + case RPC_FC_FLOAT: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_FLOAT */\n", RPC_FC_FLOAT); > + break; > + case RPC_FC_DOUBLE: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_DOUBLE */\n", RPC_FC_DOUBLE); > + break; You should add some sort of get_fc_name() function instead of duplicating a big switch like that every time you want to print a name. > static void write_function_stubs(type_t *iface) > { > - func_t *cur = iface->funcs; > - char *handle_name = get_attrp(iface->attrs, ATTR_IMPLICIT_HANDLE); > + char *implicit_handle = get_attrp(iface->attrs, ATTR_IMPLICIT_HANDLE); > + int explitit_handle = is_attr(iface->attrs, ATTR_IMPLICIT_HANDLE); > + func_t *func = iface->funcs; > + var_t* var; Your patch would be a lot easier to review if you avoided renaming existing local variables. If you really think the names need to be changed please do it in a separate patch. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: Installing Mozilla
by Juan Lang 25 Apr '05

25 Apr '05

--- Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Is the Mozilla Installer Installshield or MSI based? Otherwise is it > open source? Perhaps an easier way to backtrace the problem? I believe it's open source. The crash was due to Mozilla attempting to write to a value that's exported by msvcrt.dll. It was declared in msvcrt's spec file, but never defined. Thus Mozilla was writing to a garbage pointer. It's been fixed in Wine. There's a separate issue that Mozilla probably isn't doing the right thing. It's overwriting a buffer it doesn't own and whose size is not documented, and it should be writing only four characters but is writing more. Now that Wine is fixed this is unlikely to cause anyone any trouble, but it's still not right. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

writejump purpose
by Robert Lunnon 25 Apr '05

25 Apr '05

In kthread.c there is this code that is only defined for I386 glibc, but the solaris port uses Solaris libc so the function does nothing. What is the purpose of this function and exactly what should the semantics be ? BOb static inline void writejump( const char *symbol, void *dest ) { #if defined(__GLIBC__) && defined(__i386__) unsigned char *addr = wine_dlsym( RTLD_NEXT, symbol, NULL, 0 ); if (!addr) return; /* write a relative jump at the function address */ mprotect((void*)((unsigned int)addr & ~(getpagesize()-1)), 5, PROT_READ| PROT_EXEC|PROT_WRITE); addr[0] = 0xe9; *(int *)(addr+1) = (unsigned char *)dest - (addr + 5); mprotect((void*)((unsigned int)addr & ~(getpagesize()-1)), 5, PROT_READ| PROT_EXEC); # ifdef HAVE_VALGRIND_MEMCHECK_H VALGRIND_DISCARD_TRANSLATIONS( addr, 5 ); # endif #endif /* __GLIBC__ && __i386__ */ }

2 1

Wine no longer compiles
by Ivan Gyurdiev 25 Apr '05

25 Apr '05

Haven't been able to compile cvs wine for the last few weeks. This is Fedora Rawhide with gcc4. Any suggestions? gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./.. -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o file.o file.c In file included from ../../../include/winnt.h:27, from ../../../include/windef.h:204, from ../../../include/wine/test.h:25, from file.c:21: ../../../include/msvcrt/ctype.h:72: warning: conflicting types for built-in function ‘iswalnum’ ../../../include/msvcrt/ctype.h:73: warning: conflicting types for built-in function ‘iswalpha’ ../../../include/msvcrt/ctype.h:75: warning: conflicting types for built-in function ‘iswcntrl’ ../../../include/msvcrt/ctype.h:77: warning: conflicting types for built-in function ‘iswdigit’ ../../../include/msvcrt/ctype.h:78: warning: conflicting types for built-in function ‘iswgraph’ ../../../include/msvcrt/ctype.h:79: warning: conflicting types for built-in function ‘iswlower’ ../../../include/msvcrt/ctype.h:80: warning: conflicting types for built-in function ‘iswprint’ ../../../include/msvcrt/ctype.h:81: warning: conflicting types for built-in function ‘iswpunct’ ../../../include/msvcrt/ctype.h:82: warning: conflicting types for built-in function ‘iswspace’ ../../../include/msvcrt/ctype.h:83: warning: conflicting types for built-in function ‘iswupper’ ../../../include/msvcrt/ctype.h:84: warning: conflicting types for built-in function ‘iswxdigit’ ../../../include/msvcrt/ctype.h:85: warning: conflicting types for built-in function ‘towlower’ ../../../include/msvcrt/ctype.h:86: warning: conflicting types for built-in function ‘towupper’ ../../../include/msvcrt/io.h:179: error: ‘open’ aliased to external symbol ‘_open’ ../../../include/msvcrt/io.h:180: error: ‘sopen’ aliased to undefined symbol ‘_sopen’ ../../../include/msvcrt/process.h:129: error: ‘execl’ aliased to undefined symbol ‘_execl’ ../../../include/msvcrt/process.h:130: error: ‘execle’ aliased to undefined symbol ‘_execle’ ../../../include/msvcrt/process.h:131: error: ‘execlp’ aliased to undefined symbol ‘_execlp’ ../../../include/msvcrt/process.h:132: error: ‘execlpe’ aliased to undefined symbol ‘_execlpe’ ../../../include/msvcrt/process.h:133: error: ‘spawnl’ aliased to undefined symbol ‘_spawnl’ ../../../include/msvcrt/process.h:134: error: ‘spawnle’ aliased to undefined symbol ‘_spawnle’ ../../../include/msvcrt/process.h:135: error: ‘spawnlp’ aliased to undefined symbol ‘_spawnlp’ ../../../include/msvcrt/process.h:136: error: ‘spawnlpe’ aliased to undefined symbol ‘_spawnlpe’ -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

2 1

PATCH: gcc4 alias fixes
by Marcus Meissner 24 Apr '05

24 Apr '05

Hi, This is the patch I use for gcc4.0 here. I am not really sure why this aliasing was introduced, but it will not work this way anymore. Ciao, Marcus diff -ruN -x CVS wine-20050419/include/msvcrt/conio.h marcus-wine-20050419/include/msvcrt/conio.h --- wine-20050419/include/msvcrt/conio.h 2004-07-19 13:07:44.000000000 +0200 +++ marcus-wine-20050419/include/msvcrt/conio.h 2005-04-13 13:03:23.000000000 +0200 @@ -53,7 +53,7 @@ static inline unsigned short outpw(unsigned short i, unsigned short j) { return _outpw(i, j); } #endif -#ifdef __GNUC__ +#if defined(__GNUC__) && (__GNUC__ < 4) extern int cprintf(const char*,...) __attribute__((alias("_cprintf"),format(printf,1,2))); extern int cscanf(const char*,...) __attribute__((alias("_cscanf"),format(scanf,1,2))); #else diff -ruN -x CVS wine-20050419/include/msvcrt/io.h marcus-wine-20050419/include/msvcrt/io.h --- wine-20050419/include/msvcrt/io.h 2004-07-19 13:07:44.000000000 +0200 +++ marcus-wine-20050419/include/msvcrt/io.h 2005-04-13 13:03:23.000000000 +0200 @@ -175,7 +175,7 @@ #endif static inline int write(int fd, const void* buf, unsigned int size) { return _write(fd, buf, size); } -#ifdef __GNUC__ +#if defined(__GNUC__) && (__GNUC__ < 4) extern int open(const char*,int,...) __attribute__((alias("_open"))); extern int sopen(const char*,int,int,...) __attribute__((alias("_sopen"))); #else diff -ruN -x CVS wine-20050419/include/msvcrt/process.h marcus-wine-20050419/include/msvcrt/process.h --- wine-20050419/include/msvcrt/process.h 2004-07-19 13:07:44.000000000 +0200 +++ marcus-wine-20050419/include/msvcrt/process.h 2005-04-13 13:03:23.000000000 +0200 @@ -125,7 +125,7 @@ static inline int spawnvp(int flags, const char* name, const char* const* argv) { return _spawnvp(flags, name, argv); } static inline int spawnvpe(int flags, const char* name, const char* const* argv, const char* const* envv) { return _spawnvpe(flags, name, argv, envv); } -#ifdef __GNUC__ +#if defined(__GNUC__) && (__GNUC__ < 4) extern int execl(const char*,const char*,...) __attribute__((alias("_execl"))); extern int execle(const char*,const char*,...) __attribute__((alias("_execle"))); extern int execlp(const char*,const char*,...) __attribute__((alias("_execlp")));

2 1

Debugging with GDB [was: Re: World of Warcraft - crash in game]
by Alex Woods 24 Apr '05

24 Apr '05

On Thu, Mar 03, 2005 at 08:13:41AM +1100, Troy Rollo wrote: > On Thu, 3 Mar 2005 03:43, Alex Woods wrote: > > Unfortunately, I never got to try out this method properly. WoW has > > it's own dbghelp.dll that it checks on login and that contains different > > functions to wine's dbghelp. So I got stuck there, but it's not all bad > > news. > > In that case you may be able to use GDB directly on the executable (without > winedbg) and attach after the app has started with > "gdb /usr/local/bin/wine-pthread process-id". The major drawback of this is > that it cannot tell the difference between a first chance exception and a > last chance exception, so if the app uses exception handling you may end up > using GDB's "pass" command a lot. Well, after a long break, I'm back at trying to debug wine + WoW again. Somewhere alsa stopped working for me totally in wine (multilib problem I think). Now that it's working again, running the winmm and dsound tests I don't get any crashes, which I did before. I still get crashes in WoW though, with both OSS and ALSA, so I figure I'll try to get to the bottom of the common problems first before going back to see if ALSA is still a problem. I'm attaching to the process with gdb, but it's not catching things at the point where they go wrong. Typically I am just seeing a stack like this though: #0 0x56752a01 in ?? () I might be doing something wrong. It's been a long time since I used gdb for anything threaded, and never with NTLM. I've tried attaching to wine-pthread process and the wine-preloader process, with pretty much the same results. It's a real shame that +relay slows things down too much for be to be able to get to the point where a crash occurs. Does anyone have any suggestions as to how I might get a handle on where things are going wrong? How are exceptions caught by wine? A lot of the time WoW handles the error so can I work back from there? A lot of the time I get a report like this: This application has encountered a critical error: Not enough memory Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\WorldClient\MapMem.cpp Line: 589 WoWBuild: 4341 ------------------------------------------------------------------------------ ---------------------------------------- Stack Trace (Manual) ---------------------------------------- Address Frame Logical addr Module 0064F43E 55C0F970 0001:0024E43E C:\Program Files\World of Warcraft\WoW.exe 006500A5 55C0F988 0001:0024F0A5 C:\Program Files\World of Warcraft\WoW.exe 00651464 55C0F9A8 0001:00250464 C:\Program Files\World of Warcraft\WoW.exe 006B9F82 55C0F9D0 0001:002B8F82 C:\Program Files\World of Warcraft\WoW.exe 006D8FC6 55C0FAF4 0001:002D7FC6 C:\Program Files\World of Warcraft\WoW.exe 006B16AE 55C0FB20 0001:002B06AE C:\Program Files\World of Warcraft\WoW.exe 006B13B7 55C0FB3C 0001:002B03B7 C:\Program Files\World of Warcraft\WoW.exe 00689769 55C0FB4C 0001:00288769 C:\Program Files\World of Warcraft\WoW.exe 0048E70F 55C0FC00 0001:0008D70F C:\Program Files\World of Warcraft\WoW.exe 0048E293 55C0FC8C 0001:0008D293 C:\Program Files\World of Warcraft\WoW.exe 0076DDE1 55C0FCB0 0001:0036CDE1 C:\Program Files\World of Warcraft\WoW.exe 00762520 55C0FCD8 0001:00361520 C:\Program Files\World of Warcraft\WoW.exe 00760C72 55C0FCE4 0001:0035FC72 C:\Program Files\World of Warcraft\WoW.exe 0044224E 55C0FDAC 0001:0004124E C:\Program Files\World of Warcraft\WoW.exe 0041B8E6 55C0FDE4 0001:0001A8E6 C:\Program Files\World of Warcraft\WoW.exe 004175EA 55C0FE5C 0001:000165EA C:\Program Files\World of Warcraft\WoW.exe 00416D71 55C0FE74 0001:00015D71 C:\Program Files\World of Warcraft\WoW.exe 004044B0 55C0FF14 0001:000034B0 C:\Program Files\World of Warcraft\WoW.exe 55A58B9B 55C0FFF4 0001:00057B9B c:\windows\system\kernel32.dll Am I right in thinking that the logical address is the address I should use to look up the point it's failing in kernel32.dll? Using that and an asm dump of kernel32.dll.so places it in the error section of FindFirstFileExW I think: 57b82: 00 57b83: 89 04 24 mov %eax,(%esp) 57b86: e8 91 80 00 00 call 5fc1c <HeapFree> 57b8b: 83 ec 0c sub $0xc,%esp 57b8e: 8d 45 e8 lea 0xffffffe8(%ebp),%eax 57b91: 89 04 24 mov %eax,(%esp) 57b94: e8 37 21 fe ff call 39cd0 <RtlFreeUnicodeString> 57b99: 83 ec 04 sub $0x4,%esp 57b9c: c7 45 b0 ff ff ff ff movl $0xffffffff,0xffffffb0(%ebp) 57ba3: 8b 45 b0 mov 0xffffffb0(%ebp),%eax 57ba6: 8b 5d fc mov 0xfffffffc(%ebp),%ebx 57ba9: c9 leave 57baa: c2 18 00 ret $0x18 If I attach to wine-pthread and stick a breakpoint in that function, it does indeed get called right before WoW crashes out with the Out of memory error. I guess I'll work that back, seeing as I it's something I've found out during the course of writing this email, but any suggestions as to how I can make debugging easier would be truly appreciated, as would any answers to my questions. Cheers. -- Alex

2 2

Re: Installing Mozilla
by Juan Lang 24 Apr '05

24 Apr '05

Alex wrote: > I'm encountering a crash when trying to install Mozilla 1.7.7 under > wine. I am using a fresh CVS checkout, but I've tried older revisions > with the same result. So far, this evidence points to a bug in Mozilla rather than in Wine. It may very well be triggered by a bug in Wine.. > Here is a backtrace. It's falling over trying to write to > 0x99806858. Mozilla's passing an apparently invalid pointer to WideCharToMultiByte. Question is, where does this come from? Running with WINEDEBUG=nls may give a clue what string it's trying to convert, which may give some indication of the problem. Running with WINEDEBUG=relay will probably give a better clue, but be prepared for a huge log. But since the Mozilla source is available, you may be able to hunt it down more easily using that. --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 3

Odd problem with process handles
by Robert Lunnon 24 Apr '05

24 Apr '05

I am having a problem with the attached segfault in ie6 I have attached a gdb backtrace and the last part of a relay dump. hModule is 0xffffffffe and gets dereferenced to find e_magic presumably from the psp. Obviously dereferencing 0xfffffffe is not good which raises an exception The exception is caught and appears to be ignored the first time it occurs but this seems unusual to me Can anyone shed light on this, is this normal or do I have a problem. What's going on here ? More info follows Bob ============================================================================ Starting program: /opt/cfw/wine/bin/wine iexplore Program received signal SIGSEGV, Segmentation fault. 0xd1cbfb5f in RtlImageNtHeader (hModule=0xfffffffe) at loader.c:1907 1907 if (dos->e_magic == IMAGE_DOS_SIGNATURE) (gdb) print dos $1 = (IMAGE_DOS_HEADER *) 0xfffffffe *** Aparrently in this code 1895 /*********************************************************************** 1896 * RtlImageNtHeader (NTDLL.@) 1897 */ 1898 PIMAGE_NT_HEADERS WINAPI RtlImageNtHeader(HMODULE hModule) 1899 { 1900 IMAGE_NT_HEADERS *ret; 1901 1902 __TRY 1903 { 1904 IMAGE_DOS_HEADER *dos = (IMAGE_DOS_HEADER *)hModule; (gdb) 1905 1906 ret = NULL; 1907 if (dos->e_magic == IMAGE_DOS_SIGNATURE) 1908 { 1909 ret = (IMAGE_NT_HEADERS *)((char *)dos + dos->e_lfanew); 1910 if (ret->Signature != IMAGE_NT_SIGNATURE) ret = NULL; 1911 } 1912 } 1913 __EXCEPT(page_fault) 1914 { (gdb) 1915 return NULL; 1916 } 1917 __ENDTRY 1918 return ret; 1919 } **** Relay output 00b:Ret kernel32.LoadLibraryA() retval=00000000 ret=70c2429c 000b:Call kernel32.GetLastError() ret=70c242a9 000b:Ret kernel32.GetLastError() retval=0000007e ret=70c242a9 000b:Call kernel32.InterlockedExchange(70c2bd84,ffffffff) ret=70c242f0 000b:Ret kernel32.InterlockedExchange() retval=00000000 ret=70c242f0 000b:Call kernel32.GetProcAddress(ffffffff,70c24832 "ApphelpCheckShellObject") ret=70c24399 000b:Call ntdll.RtlInitAnsiString(7fd8dc18,70c24832 "ApphelpCheckShellObject") ret=7fe1e655 000b:Ret ntdll.RtlInitAnsiString() retval=7fd80018 ret=7fe1e655 000b:Call ntdll.LdrGetProcedureAddress(ffffffff,7fd8dc18,00000000,7fd8dc20) ret=7fe1e667 **** GDB Backtrace (gdb) bt #0 0xd1cbfb5f in RtlImageNtHeader (hModule=0xfffffffe) at loader.c:1907 #1 0xd1cc0018 in RtlImageDirectoryEntryToData (module=0xfffffffe, image=0, dir=0, size=0x7fd8db3c) at loader.c:2025 #2 0xd1cbdcd1 in LdrGetProcedureAddress (module=0xffffffff, name=0x7fd8dc18, ord=0, address=0x7fd8dc20) at loader.c:1154 #3 0xd1ccabcf in call_stdcall_function (func=0xd1cbdc9b <LdrGetProcedureAddress>, nb_args=4, args=0x7fd8dc08) at relay.c:521 #4 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=2145511015) at relay.c:603 #5 0xd1d00025 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/ntdll.dll.so #6 0xd1ccab7d in call_stdcall_function (func=0x7fe1e62b <GetProcAddress>, nb_args=2, args=0x7fd8dce4) at relay.c:519 #7 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=1891779481) at relay.c:603 #8 0x7fec08dd in __wine_spec_forwards () from /opt/cfw/wine/lib/wine/kernel32.dll.so #9 0x70c23bd1 in ?? () #10 0x71191420 in ?? () #11 0x711819aa in ?? () #12 0x7118a3c9 in ?? () #13 0x71165a1c in ?? () #14 0x7fbab1af in WINPROC_wrapper () from /opt/cfw/wine/lib/wine/user32.dll.so #15 0x7fbab61d in WINPROC_CallWndProc (proc=0x71165af5, hwnd=0x20022, msg=129, wParam=0, lParam=2144920548) at ../../windows/winproc.c:418 #16 0x7fbb21a6 in CallWindowProcA (func=0x71165af5, hwnd=0x20022, msg=129, wParam=0, lParam=2144920548) at ../../windows/winproc.c:3202 #17 0x7fbea1f4 in call_window_proc (hwnd=0x20022, msg=129, wparam=0, lparam=2144920548, unicode=0, same_thread=1) at message.c:1521 #18 0x7fbec0cb in SendMessageTimeoutA (hwnd=0x20022, msg=129, wparam=0, lparam=2144920548, flags=0, timeout=4294967295, res_ptr=0x7fd8df78) at message.c:2376 #19 0x7fbec299 in SendMessageA (hwnd=0x20022, msg=129, wparam=0, lparam=2144920548) at message.c:2420 #20 0xd1ccabcf in call_stdcall_function (func=0x7fbec266 <SendMessageA>, nb_args=4, args=0x7fd8e040) at relay.c:521 #21 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=2137925787) at relay.c:603 #22 0x7fc3e3a1 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/user32.dll.so #23 0xd1cca480 in call_cdecl_function (func=0x7f6e23b6 <X11DRV_CreateWindow>, nb_args=3, args=0x7fd8e1c0) at relay.c:462 #24 0xd1ccb2c2 in RELAY_CallFrom32 (ret_addr=2142912231) at relay.c:599 #25 0x7f71a3a1 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/x11drv.dll.so #26 0x7fba4554 in CreateWindowExA (exStyle=256, className=0x7fd8e538 "IEFrame", windowName=0x7fd8e74c "Microsoft Internet Explorer", style=47120384, x=-2147483648, y=-2147483648, width=-2147483648, height=-2147483648, parent=0x0, menu=0x94, instance=0x71160000, data=0x7ff39fb8) at ../../windows/win.c:1245 #27 0xd1ccae57 in call_stdcall_function (func=0x7fba43da <CreateWindowExA>, nb_args=12, args=0x7fd8e4fc) at relay.c:535 #28 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=1891617362) at relay.c:603 #29 0x7fc3c851 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/user32.dll.so #30 0x71181c0e in ?? () #31 0x71181acf in ?? () #32 0x71181a86 in ?? () #33 0x7101f031 in ?? () #34 0x00401ecd in ?? () #35 0x00401f7d in ?? () #36 0x7fe2cbf2 in start_process (arg=0x0) at process.c:1044

2 1

Re: Odd problem with process handles
by Juan Lang 24 Apr '05

24 Apr '05

Hi Bob, > hModule is 0xffffffffe and gets dereferenced to find e_magic > presumably from the psp. Could you try the following really quick patch? I have no idea where the -1 value to GetProcAddress comes from, LoadLibraryA returned NULL. I'm also not sure whether the check belongs in here or in GetProcAddress. But this might let it get further for you. Index: dlls/ntdll/loader.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/loader.c,v retrieving revision 1.87 diff -u -r1.87 loader.c --- dlls/ntdll/loader.c 21 Mar 2005 10:52:26 -0000 1.87 +++ dlls/ntdll/loader.c 24 Apr 2005 17:09:39 -0000 @@ -2017,6 +2017,8 @@ const IMAGE_NT_HEADERS *nt; DWORD addr; + if ( module == (HMODULE)-1 ) + return NULL; if ((ULONG_PTR)module & 1) /* mapped as data file */ { module = (HMODULE)((ULONG_PTR)module & ~1); __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

More problems in ie6
by Robert Lunnon 24 Apr '05

24 Apr '05

In addition to the bad process handle I get intermittent crashes in IE6 which seems to be due to the creation of more than 8 threads or when a thread is ended (IE it occurs after thread 8 starts, then exits then another thread 8 starts (9th thread creation)) Thread 8 is the first thread that actually exited in the program. Are there any resource limits to per process thread creation in wine ? This seems to lead to a crash in temp_stacks +111 but temp stacks should not hold any executable code. The web site that seems to tickle this problem is www.gamedude.com.au Any Guesses anyone ? Bob

1 0

Copy Protection
by Dustin Navea 24 Apr '05

24 Apr '05

Guys, bug 2895 got me thinkin.. If we only support a handful of games that use copy protection, shouldnt we file a bug in Bugzilla and append that to 1434 (Get games working perfectly)? That way we can attach any copy protection related bugs to this metabug? If you are agreeable to to that, I will go ahead and file it. Dustin

2 1

Re: Some fixes for filtergraph.c
by Christian Costa 24 Apr '05

24 Apr '05

Hi Maarten, Maarten Lankhorst wrote: > This doesn't fix everything, just theroutines i called.. some other > similar functions aren't fixed because filtergraph.c is really THAT > leaky..b mostly with reference counts.. Yes, Indeed. :-) Here are some comments : > >------------------------------------------------------------------------ > >--- wine-20050310/dlls/quartz/filtergraph.c 2005-03-02 11:12:12.000000000 +0100 >+++ wine/dlls/quartz/filtergraph.c 2005-04-24 00:50:30.000000000 +0200 >@@ -556,8 +556,7 @@ > IPin_QueryDirection(ppin, &pindir); > if (pindir == PINDIR_OUTPUT) > i++; >- else >- IPin_Release(ppin); >+ IPin_Release(ppin); > } > *pppins = CoTaskMemAlloc(sizeof(IPin*)*i); > /* Retrieve output pins */ >@@ -650,6 +649,7 @@ > IPin** ppins; > IPin* ppinfilter; > IBaseFilter* pfilter = NULL; >+ BOOL HaveEnumPin = FALSE; > > Why don't you just set ppinfilter to NULL and do "if (ppinfilter) IPin_Release(ppinfilter);" at the end ? > hr = GetFilterInfo(pMoniker, &clsid, &var); > IMoniker_Release(pMoniker); >@@ -677,6 +677,7 @@ > ERR("Enumpins (%lx)\n", hr); > goto error; > } >+ > hr = IEnumPins_Next(penumpins, 1, &ppinfilter, &pin); > if (FAILED(hr)) { > ERR("Next (%lx)\n", hr); >@@ -687,6 +688,7 @@ > goto error; > } > IEnumPins_Release(penumpins); >+ HaveEnumPin = TRUE; > > See above. > hr = IPin_Connect(ppinOut, ppinfilter, NULL); > if (FAILED(hr)) { >@@ -703,17 +705,21 @@ > TRACE("pins to consider: %ld\n", nb); > for(i = 0; i < nb; i++) { > TRACE("Processing pin %d\n", i); >- hr = IGraphBuilder_Connect(iface, ppins[0], ppinIn); >+ hr = IGraphBuilder_Connect(iface, ppins[i], ppinIn); > if (FAILED(hr)) { >- TRACE("Cannot render pin %p (%lx)\n", ppinfilter, hr); >- return hr; >+ TRACE("Cannot render pin %p (%lx)\n", ppinfilter, hr); > } >+ IPin_Release(ppins[i]); >+ if (SUCCEEDED(hr)) break; > This is not correct, you must connect all pins, not just the first that succeeds. > } > CoTaskMemFree(ppins); >+ IBaseFilter_Release(pfilter); >+ IPin_Release(ppinfilter); >+ break; > } >- break; > > error: >+ if (HaveEnumPin) IPin_Release(ppinfilter); > See above. > if (pfilter) { > IGraphBuilder_RemoveFilter(iface, pfilter); > IBaseFilter_Release(pfilter); >@@ -1175,13 +1181,16 @@ > ULONG nb; > ULONG i; > PIN_INFO PinInfo; >+ BOOL HavePinInfo = FALSE; > > TRACE("%p %p %lld\n", pGraph, pOutputPin, tStart); > > hr = IPin_ConnectedTo(pOutputPin, &pInputPin); > >- if (SUCCEEDED(hr)) >+ if (SUCCEEDED(hr)) { >+ HavePinInfo = TRUE; > hr = IPin_QueryPinInfo(pInputPin, &PinInfo); >+ } > > Personally, I would set PinIno.pFilter to NULL on failure and do if (PinIno.pFilter) release... at the end. But it's just a matter of taste. > if (SUCCEEDED(hr)) > hr = GetInternalConnections(PinInfo.pFilter, pInputPin, &ppPins, &nb); >@@ -1202,6 +1211,7 @@ > * FIXME: We should prevent exploring from a pin more than once. This can happens when > * several input pins are connected to the same output (a MUX for instance). */ > ExploreGraph(pGraph, ppPins[i], tStart); >+ IPin_Release(ppPins[i]); > } > > CoTaskMemFree(ppPins); >@@ -1210,6 +1220,7 @@ > IBaseFilter_Run(PinInfo.pFilter, tStart); > } > >+ if (HavePinInfo) IBaseFilter_Release(PinInfo.pFilter); > return hr; > } > >@@ -1255,9 +1266,11 @@ > IPin_QueryDirection(pPin, &dir); > if (dir == PINDIR_INPUT) > { >+ IPin_Release(pPin); > source = FALSE; > break; > } >+ IPin_Release(pPin); > That would be simplier to do a single call to IPinRelease after IPin_QueryDirection. > } > if (source == TRUE) > { >@@ -1267,6 +1280,7 @@ > { > /* Explore the graph downstream from this pin */ > ExploreGraph(This, pPin, 0); >+ IPin_Release(pPin); > } > IBaseFilter_Run(pfilter, 0); > } > > Nice patch, BTW! :-) Bye, Christian

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel