- Wine-Devel - list.winehq.org

Re: rpcrt4: fix NULL pointer access
by Gregory M. Turner Nov. 20, 2003

Nov. 20, 2003

On Thursday 20 November 2003 02:26 pm, Dimitrie O. Paun wrote: > Ran into this while browsing the code, it seems to > be a NULL pointer reference waiting to happen. > Am I missing something? > > ChangeLog > Bail when we're out of memory. > > Index: dlls/rpcrt4/rpc_binding.c > =================================================================== > RCS file: /var/cvs/wine/dlls/rpcrt4/rpc_binding.c,v > retrieving revision 1.15 > diff -u -r1.15 rpc_binding.c > --- dlls/rpcrt4/rpc_binding.c 7 Oct 2003 22:54:17 -0000 1.15 > +++ dlls/rpcrt4/rpc_binding.c 20 Nov 2003 06:33:52 -0000 > @@ -516,7 +516,11 @@ > { > DWORD len = strlen(dst), slen = strlen(src); > LPSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, > (len+slen+2)*sizeof(CHAR)); - if (!ndst) HeapFree(GetProcessHeap(), 0, > dst); > + if (!ndst) > + { > + HeapFree(GetProcessHeap(), 0, dst); > + return NULL; > + } > ndst[len] = ','; > memcpy(ndst+len+1, src, slen*sizeof(CHAR)); > ndst[len+slen+1] = 0; > @@ -527,7 +531,11 @@ > { > DWORD len = strlenW(dst), slen = strlenW(src); > LPWSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, > (len+slen+2)*sizeof(WCHAR)); - if (!ndst) HeapFree(GetProcessHeap(), 0, > dst); > + if (!ndst) > + { > + HeapFree(GetProcessHeap(), 0, dst); > + return NULL; > + } > ndst[len] = ','; > memcpy(ndst+len+1, src, slen*sizeof(WCHAR)); > ndst[len+slen+1] = 0; looks like a real bug to me... but the consumers of those functions probably assume success, so maybe the right solution is really to raise an exception. There are lots of places in rpcrt4 where exceptions ought to raise on error conditions but don't, mainly due to developer laziness. I guess it's hard to justify fixing error paths when success doesn't work either ;) So, at some point there needs to be an error-handling audit of rpcrt4; until then, your patch is better than nothing, and probably should go in. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39

1 0

Re: WineX relation to Wine
by Gerhard W. Gruber Nov. 20, 2003

Nov. 20, 2003

On Thu, 20 Nov 2003 15:17:22 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: [LaunchMenu Windowsversion under Wine] >> Are hooks supported under Wine? > >What do you need? I just tried it under Wine. the dialog and everything works, but the hook doesn't respond. I would have to debug it to see whats not working, but I guess that it is the hookfunction. When the hook couldn't be installed I raise a dialog and this does not appear, so the the CreateHook appears to return something. I don't see any errormessages from wine, though. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

1 0

Further loader/pthread.c issues
by Gerald Pfeifer Nov. 20, 2003

Nov. 20, 2003

After last night's changes to loader/pthread.c,v revision 1.2 date: 2003/11/09 01:25:23; author: julliard; state: Exp; lines: +67 -11 Moved the remaining SYSDEPS_* functions to the wine_pthread interface. Let the pthread library allocate the stack itself. we have a new portability problem, namely wine/loader/pthread.c:97: undefined reference to `pthread_getattr_np' Given that loader/pthread.c is about POSIX threads, is it really correct/good to use a non-POSIX function? Gerald PS: On FreeBSD, pthread_getattr_np does not exist, but there is a function pthread_attr_get_np which seems to be equivalent. On Solaris, neither seems to exist.

3 4

Re: Reject wildcards in directory names
by Alexandre Julliard Nov. 20, 2003

Nov. 20, 2003

Hans Leidekker <hans(a)it.vu.nl> writes: > Changelog: > - Reject wildcards in directory names There's no need to check in both A and W functions since the A one calls the W one anyway. Also you should only check the part of the filename that is actually being created, and there are probably other invalid characters to check for too. -- Alexandre Julliard julliard(a)winehq.com

2 2

Redrawing windows
by flyker Nov. 20, 2003

Nov. 20, 2003

I made some experiments and I understand one thing. Exaple two windows /-------------------\ | W1 | | control1 | | | | /------------------------\ \------------- | | | | | | -----------> Move | W2 | | | \------------------------/ The window W1 is under window W2 When I move window W2 wine paint all rect of W1 window ! And it may hide control1 that inside area of W1. It is not good idea because not all rect of window need to repaint. Good idea is repaint only the part of W1 that under W2. Only rect that have any changes on screen. It will increase speed of drawing windows. But may be I mistake......

1 0

How to speed up drawing controls ?
by flyker Nov. 20, 2003

Nov. 20, 2003

The drawing speed of window controls and windows is very slow under wine. I set option "PerfectGraphics" = "Y" but it is still slow. May be it is not so good optimised ? Is there other way to improve performance ? Thanks.

2 1

QuickTime Installer/Remote Display
by Kevin Cousins Nov. 19, 2003

Nov. 19, 2003

Hello, Given that I've got a situation in which my WineLib application (thank you for your help earlier in the year) needs to run against the Win32 QuickTime components, then in my development environment (RH9), I can quite happily run the downloaded QuickTime installer QuickTimeInstaller.exe to completion (so long as I have [AppDefaults\\QuickTimeInstaller.exe\\x11drv] "Managed" = "Y" "Desktop" = "800x600" ) and all is well. Running all this, however, in a test environment (RH8 under VMWare), and the QuickTimeInstaller.exe does not run to completion. I can make "wineserver -d3" and "wine -debugmsg +all" output available on private request. Can anyone suggest a mechanism for a problem here, or even an approach to a solution? -- Kevin.

1 2

out of treee builds broken
by Marcus Meissner Nov. 19, 2003

Nov. 19, 2003

Hi, Out of tree builds are broken due to the authors.c generation: ../../tools/winebuild/winebuild -D__WINESRC__ -D_SHELL32_ -DCOM_NO_WINDOWS_H -o shell32.dll.dbg.c --debug -C/suse/meissner/projects/marcus-wine-20031016/dlls/shell32 authors.c brsfolder.c changenotify.c classes.c clipboard.c control.c dataobject.c debughlp.c dialogs.c dragdrophelper.c enumidlist.c folders.c iconcache.c memorystream.c pidl.c regsvr.c shell32_main.c shelllink.c shellole.c shellord.c shellpath.c shellreg.c shellstring.c shfldr_desktop.c shfldr_fs.c shfldr_mycomp.c shlexec.c shlfileop.c shlfolder.c shlfsbind.c shlmenu.c shlview.c shpolicy.c shv_bg_cmenu.c shv_item_cmenu.c systray.c shell.c Cannot open file '/suse/meissner/projects/marcus-wine-20031016/dlls/shell32/authors.c' It looks for authors.c in the srcdir, not in the objdir. Ciao, Marcus

2 2

question new to the group
by Nathan Hack Nov. 19, 2003

Nov. 19, 2003

Ok here's the deal. I wanted to start helping but i've been reading the auncments and stuff but i did see this topic come up. So i thought i would just through it out and see what the wine community had to say. I have build a few (simple)delphi programs test wine out to start working on it(wine that is). fixme:commctrl:FlatSB_SetScrollProp stub ok my question is this since this API is no longer in windows ( Comctl32.dll version 6 and higher do not support flat scroll bars) show i go ahead and write in the code or just go find something else more productive? If this is a stupid question just let me know like( hey it's in the doc's on wine and heres the web site.... ) that would be great. Thanks, -NH -Better living through Wine-

5 4

using glXGetProcAddressARB
by Daniel Skorka Nov. 19, 2003

Nov. 19, 2003

Hi! I am having trouble with OpenGL under wine (specifically Half-Life). The problem is some code in $(TOPDIR)/dlls/opengl32/wgl.c. The function wglGetProcAddress would like to call glXGetProcAddressARB, but can't, due to the DLL's initialisation routines, namely process_attach. process_attach calls glxQueryExtensionsString, and expects to find "GLX_ARB_get_proc_address" in the returned string. However, it does not find this string on my libGL and so deems that glXGetProcAddressARB is not available. The problem is that glXGetProcAddress is available and working. The question I'm asking me now is: Is it a bug in my libGL because it is returning a wrong string, or is it a bug in wine because it is expecting something it shouldn't (there's a configure check for glXGetProcAddress as well)? I'm running Debian 3.0r1 with an libGL built (not by me), from the dri-mach64 CVS and using the wine CVS source. Thank you for your help with this, Daniel

3 5