March 2005 - Wine-Devel - list.winehq.org

Re: KERNEL: Implement undocumented SetCPGlobal API call

by James Hawkins

On Tue, 29 Mar 2005 11:37:43 +1100, Troy Rollo <wine(a)troy.rollo.name> wrote: > SetCPGlobal is the undocumented partner of GetACP - it is used to set the > current ANSI code page. > > ChangeLog: > Implement SetCPGlobal (an undocumented Win32 API) A patch would be good :) -- James Hawkins

March 29, 2005

Re: KERNEL: Implement undocumented SetCPGlobal API call

by James Hawkins

On Tue, 29 Mar 2005 11:37:43 +1100, Troy Rollo <wine(a)troy.rollo.name> wrote: > SetCPGlobal is the undocumented partner of GetACP - it is used to set the > current ANSI code page. > > ChangeLog: > Implement SetCPGlobal (an undocumented Win32 API) A patch would be good :) -- James Hawkins

March 29, 2005

Re: Dragon Naturally Speaking - working.

by wino＠piments.com

Great news. Could you give more details on your alsa setup? I have not managed to get alsa working with wine appart from putting oss in the wine config and using alsa-oss Regards, On Mon, 28 Mar 2005 13:50:08 +0200, Konstantin Goudkov <konstantin(a)goudkov.com> wrote: > I got NS7 working on Debian Sid, after running Sidenet > setup on Wine 20050310. > It took me a while to figure out that I need to raise the > Capture level, not just the Mic volume on ALSA. > Without it, it looked like NS (and Wine) didn't not pick up > the mic even though I could hear myself on the speakers. > > Also, sometimes not all buttons are clickable even through they should > be, so try "Ctrl-S" during the user setup. > > -- > Konstantin Goudkov > > > > -- Opera 7 mail on Linux

March 28, 2005

advapi: remove signature checking code.

by Michael Jung

Hi, Microsoft signs it's cryptographic service provider (csp) dlls with a private key. advapi32 will only load csp dlls with a valid signature. We will never be able to implement this, since this would mean having access to Microsoft's private keys. Above this, Microsofts scheme doesn't give real security, since there are instructions on the web to replace advapi32's _NSAKEY with an arbitrary private key (this is if you have write access to advapi32.dll), allowing you to load a csp signed by yourself. I would like to remove the (stubbed) signature checking code from advapi32. This would clean up advapi32 somewhat and remove a FIXME message, which bothers me for some time and which confused wine users in at least two occurences. Comments anyone? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

March 28, 2005

Re: msi:Fix Typelib Registration

by Huw D M Davies

On Mon, Mar 28, 2005 at 10:39:48AM -0600, Aric Stewart wrote: > make sure the GUID of the typelib we are registering matches the guid > requested from MSI. if not search the given typelib file to find the > typelib requested to register. > > > Index: dlls/msi/action.c > =================================================================== > RCS file: /home/wine/wine/dlls/msi/action.c,v > retrieving revision 1.105 > diff -u -r1.105 action.c > --- dlls/msi/action.c 28 Mar 2005 14:17:52 -0000 1.105 > +++ dlls/msi/action.c 28 Mar 2005 16:33:23 -0000 > @@ -4097,7 +4101,39 @@ > continue; > } > > + guid = load_dynamic_stringW(row,1); > res = LoadTypeLib(package->files[index].TargetPath,&ptLib); > + ITypeLib_GetLibAttr(ptLib, &attr); > + CLSIDFromString(guid, &clsid); > + if (!IsEqualGUID(&clsid,&attr->guid)) > + { > + static const WCHAR fmt[] = {'%','s','\\','%','i',0}; > + int i; > + int sz; > + > + TRACE("Initial match failure\n"); > + > + sz = strlenW(package->files[index].TargetPath)+4; > + sz *= sizeof(WCHAR); > + > + for (i = 2; i < 10; i++) > + { > + path = HeapAlloc(GetProcessHeap(),0,sz); > + sprintfW(path,fmt,package->files[index].TargetPath, i); > + TRACE("trying %s\n", debugstr_w(path)); > + res = LoadTypeLib(path,&ptLib); > + ITypeLib_GetLibAttr(ptLib, &attr); > + CLSIDFromString(guid, &clsid); > + if (IsEqualGUID(&clsid,&attr->guid)) > + break; > + HeapFree(GetProcessHeap(),0,path); > + res = E_FAIL; > + > + } > + } > + else > + path = strdupW(package->files[index].TargetPath); > + > if (SUCCEEDED(res)) > { > LPWSTR help; This doesn't look right. Maybe you need to enumerate through the typelib resources here. What information are you actually given? You're also leaking ITypeLibs and TLIBATTRs Huw.

March 28, 2005

Re: [dlls/msi/*] Strncpy elimination.

by Peter Berg Larsen

On 28 Mar 2005, Alexandre Julliard wrote: > > This memcpyies one element more than needed.. but seemed much nicer than > > memcpy( ret, p, (len - 1)*sizeof(WHCAR); > > > > I probably should have subtracted one from len, making it obvious > > that this is a strdupW, like: > > ret = HeapAlloc( GetProcessHeap(), 0, (len+1)*sizeof(WCHAR) ); > > memcpy( ret, p, len*sizeof(WCHAR) ); > > ret[len] = 0; > > If it's really a strdup it's cleaner to copy one more char and get rid > of the ret[len] = 0. Yes, and I would have done that, but in this case p is not \0 terminated. I probably left it like that because I didnt understand why it copied one byte to much in the strncpy case. That is exactly the reason for sending the patches one dll at the time: For authers/maintainers have a quick look at the replaces code. As I said in the in the beginning; if there was a bug, then it still there (but more obvious). Peter

March 28, 2005

Re: [dlls/msi/*] Strncpy elimination.

by Alexandre Julliard

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > This memcpyies one element more than needed.. but seemed much nicer than > memcpy( ret, p, (len - 1)*sizeof(WHCAR); > > I probably should have subtracted one from len, making it obvious > that this is a strdupW, like: > ret = HeapAlloc( GetProcessHeap(), 0, (len+1)*sizeof(WCHAR) ); > memcpy( ret, p, len*sizeof(WCHAR) ); > ret[len] = 0; If it's really a strdup it's cleaner to copy one more char and get rid of the ret[len] = 0. -- Alexandre Julliard julliard(a)winehq.org

March 28, 2005

Re: [libs/wine/*] Strncpy elimination.

by Alexandre Julliard

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > On 28 Mar 2005, Alexandre Julliard wrote: > > > You can't use lstrcpynA in the libs/ directory, you have to stick to > > Unix APIs. > > Ok, I just compiled and wine seemed to work. Yes, that's because they are declared inline, but we don't want to rely on that since the compiler is allowed to not inline them. -- Alexandre Julliard julliard(a)winehq.org

March 28, 2005

Re: DDRAW: Surface locking patch, take 2

by Alexandre Julliard

Matthew Mastracci <matt(a)aclaro.com> writes: > I'm just pinging the list ot see if there's any reason why this patch > hasn't been applied yet. AFAIK, it takes into account all the > feedback received so far. If you think you have taken into account the feedback then you should resubmit the patch. -- Alexandre Julliard julliard(a)winehq.org

March 28, 2005

Re: dbghelp: better module support

by Eric Pouech

Eric Pouech a écrit : > minidumps now contain more accurate information about modules, > especially information that will allow when reloading a minidump in a > debugger to check whether we're using the right modules (ELF & PE) > implemented also check for this information in SymFindFileInPath > A+ Please use this version instead (the previous had an un-wanted statement) A+ -- Eric Pouech

March 28, 2005