wine-devel August 2004

wine-devel@winehq.org

122 participants
273 discussions

wine metacity and ctrl-alt-del binding - ctrl sticks
by Grant Williamson 03 Aug '04

03 Aug '04

Curious if there is a patch somewhere for this. Running rhel3, gnome-2.2 with metacity. 1) Start notepad, type a few characters 2) hit the keyboard combination ctrl-alt-del ... "gnome-session-kill --save" is started. 3) Cancel this option. 4) Now try typing in Notepad, i.e. hit the keys "s" or "f", its just like ctrl-s or ctrl-f have been held in. 5) Hitting ctrl once cancels this. Anyone have a patch, to stop this happening?

2 1

Re: cleanup a->w cross calls in advapi32/crypt.c
by Mike McCormack 03 Aug '04

03 Aug '04

James Hawkins wrote: > + PWSTR keyname; > > - keyname = CRYPT_Alloc(strlen(KEYSTR) + strlen(pProvName) +1); > + keyname = CRYPT_Alloc((strlenW(KEYSTR) + strlenW(pProvName) + 1) * sizeof(WCHAR)); > if (keyname) > { > - strcpy(keyname, KEYSTR); > - strcpy(keyname + strlen(KEYSTR), pProvName); > + strcpyW(keyname, KEYSTR); > + strcpyW(keyname + strlenW(KEYSTR) * sizeof(WCHAR), pProvName); > } else > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > return keyname; > } This doesn't look right.... when using pointer arithmetic, you do so in increments of the pointer's type (eg. WCHAR). The following two lines are the same, and are both wrong: strcpyW(keyname + strlenW(KEYSTR) * sizeof(WCHAR), pProvName); strcpyW(&keyname[strlenW(KEYSTR) * sizeof(WCHAR)], pProvName); The right version would be: strcpyW(&keyname[strlenW(KEYSTR)], pProvName); but how about just using: strcatW( keyname, pProvname ); Mike

4 4

Re: cleanup a->w cross calls in advapi32/crypt.c
by Jeroen Janssen 02 Aug '04

02 Aug '04

James Hawkins wrote: > I'm wasn't exactly sure on this one so it would be great if you could > help me on this one. When using pointer arithmetic, do the operations > such as --, ++... increment or decrement by the size of the pointer > type? Yes, if you have a char (1byte) pointer and you ++, you'll get one byte further. If you have a short (2byte) you'll get two bytes further in memory. If you have a long (4byte) pointer, you'll get 4 bytes further in memory if you ++. It is simular to dealing with arrays (looking at the memory layout) If you have an array of structs and need to get to the next struct in the array then you will need to look sizeof(struct) further in memory to find the next item in the array. --- Jeroen

1 0

Dynamic memory management in CryptAcquireContext
by Michael Jung 02 Aug '04

02 Aug '04

Alexandre, I've noticed that you applied a modified version of my patch, which tries to fix a potential double free of the "temp" variable in dlls/advapi32/crypt.c's CryptAcquireContextA function. However, I think that the modified version does not fix the problem. Here is a code snippet from the current cvs versionc of crypt.c: CRYPT_Free(temp); ... if (pProv->pFuncs->pCPAcquireContext(&pProv->hPrivate, (CHAR*)pszContainer, dwFlags, pProv->pVTable)) { ... return TRUE; } /* FALLTHROUGH TO ERROR IF FALSE - CSP internal error! */ error: ... CRYPT_Free(temp); ... return FALSE; If the CSP's CPAcquireContext function fails, which is quite common (e.g. because the user specified key container does not exist), the "temp" variable is still free'd twice. I'm aware that my original patch was pretty ugly, due to a lot of redundancy, but I think this is due to fact that the CryptAcquireContext function seems not to be very well structured. I've submitted a patch two weeks ago, which basically was a reimplementation of CryptAcquireContext, but which was not committed (http://www.winehq.org/hypermail/wine-patches/2004/07/0213.html). Rob Shearman commented on this patch and felt that it is overkill to add both a helper function and a new struct type. Is this the reason the patch was not applied? I would be glad to rework the patch, if you give me some hints about what you did not like. However, I would prefer to wait until James Hawkins got his a->w cross call cleanup patch committed, in order not to break his work. Greetings, Michael -- Michael Jung, MSc Be liberal in what you accept, Integrated Circuits and Systems Lab and conservative in what you send. University of Technology, Darmstadt -- Jonathan Postel, Internet Pioneer phone: +49(6151)16-6692 / email: mjung(a)iss.tu-darmstadt.de

2 1

Re: RESEND: Try to avoid loading 16-bit DLLs into memory for accessing version info
by Alexandre Julliard 02 Aug '04

02 Aug '04

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Try to avoid loading 16-bit DLLs into memory for accessing > version info, this might lead to undesired side effects like > loading a bunch of other 16-bit DLLs. The problem I see is that this will bypass the loadorder config, and retrieve the version of the native dll in all cases. I think it would be better to try to take loadorder into account, though I admit it's not trivial to do. -- Alexandre Julliard julliard(a)winehq.org

2 2

Anyone writing COM tests?
by Duane Clark 02 Aug '04

02 Aug '04

Howdy, Debugging a problem I am having in COM (mentioned a few weeks ago), I think I know what the problem is but not where. So I figured some COM test would help me to understand how things should work. I was a bit surprised to see no COM tests, or at least I didn't find any in the ole* directories. So I figured if no one else is working on them, I might take a shot at it over the next few weeks/months. And maybe this would encourage some updates to the COM implementation.

2 2

Fwd:Advertising Enquiry
by Ivan Leo Puoti 02 Aug '04

02 Aug '04

Not sure if I ever forwarded this. Ivan.

2 1

Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered
by Marcus Meissner 02 Aug '04

02 Aug '04

On Sat, Jul 31, 2004 at 12:51:01PM +0200, Jeroen Janssen wrote: > This change will make sure that if a proxy/stub dll was already registered, > it is not overwritten by the TypeLib Marshaller if we're not registering > an ole automation interface. > I think we (always?) want to use a 'real' available proxy/stub > implementation when available, instead of simply 'overruling' to the > typelib marshaller. Did you verify that this patch does not break InstallShield? Ciao, Marcus

3 5

debugging a dll
by Dan Timis 02 Aug '04

02 Aug '04

Hi, Someone sent me a debug version of a Windows dll and a map file. I'm not a Windows programmer, and I'm not sure how to use the map fiile. For instance, I get a runtime error dialog. With backtrace in winedbg I get this: ... 29 0x400bf58d (NTDLL.DLL.RtlRaiseException+0x5 in NTDLL.DLL) (ebp=4083f9dc) 30 0x100771e9 (LIBDEBUG.DLL.EntryPoint+0x1609 in LIBDEBUG.DLL) (ebp=4083fa1c) 31 0x10097138 (LIBDEBUG.DLL.NIUIAEntry+0x1ad8 in LIBDEBUG.DLL) (ebp=4083fa8c) 32 0x100012b2 (LIBDEBUG.DLL..text+0x2b2 in LIBDEBUG.DLL) (ebp=4083fbf8) ... I assume that everything above NTDLL.DLL.RtlRaiseException is just code to put up the dialog box, and that the problem is at 0x100771e9 (LIBDEBUG.DLL.EntryPoint+0x1609... If I look for 0x100771e9 in the map file, the closest thing I find is this: 0001:00076ed0 _realloc 10077ed0 f LIBCMTD:dbgheap.obj 0001:00076f00 __realloc_dbg 10077f00 f LIBCMTD:dbgheap.obj 0001:000774b0 __expand 100784b0 f LIBCMTD:dbgheap.obj 0001:000774e0 __expand_dbg 100784e0 f LIBCMTD:dbgheap.obj Am I correct to assume that realloc_dbg throws an exception? If I look for 0x100012b2 (LIBDEBUG.DLL..text+0x2b2), the closest I find is: 0001:000011d0 ?_Grow@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAE_ NI_N@Z... That would make sense, we are trying to grow a string, calling realloc, etc. The entry in the middle: 31 0x10097138 (LIBDEBUG.DLL.NIUIAEntry+0x1ad8 in LIBDEBUG.DLL) (ebp=4083fa8c) points to: 0001:00097140 ?onEvent@Application@UIA@NI@@MAE_NIPAVEventData@23@@Z ... I don't understand how this relates to the other two. Are there any tools that could help understand better what's going on? Are there any tools to demangle the C++ names? I tried c++filt and not surprisingly it did not understand these symbols. Thanks, Dan Timis Muse Research, Inc.

4 3

Re: cleanup a->w cross calls in advapi32/crypt.c
by Dmitry Timoshkov 02 Aug '04

02 Aug '04

"James Hawkins" <truiken(a)gmail.com> wrote: > Full rewrite. If you have any questions, I'll be happy to answer them. > > Changelog > * clean up cross-call functions > - strcpy(keyname, KEYSTR); > - strcpy(keyname + strlen(KEYSTR), pProvName); > + strcpyW(keyname, KEYSTR); > + strcpyW(keyname + strlenW(KEYSTR) * sizeof(WCHAR), pProvName); Why did you add '* sizeof(WCHAR)' here? > - user ? strcpy(keyname, USERSTR) : strcpy(keyname, MACHINESTR); > - ptr = keyname + strlen(keyname); > - *(--ptr) = (dwType % 10) + '0'; > - *(--ptr) = ((dwType / 10) % 10) + '0'; > - *(--ptr) = (dwType / 100) + '0'; > + user ? strcpyW(keyname, USERSTR) : strcpyW(keyname, MACHINESTR); > + ptr = keyname + strlenW(keyname) * sizeof(WCHAR); And here? Did you ever test the resulting code? -- Dmitry.

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 August 2004