January 2008 - Wine-devel - list.winehq.org

Need help getting alt key remapping tips right for Photoshop users
by Dan Kegel 19 Jan '08

19 Jan '08

As of a few days ago, Photoshop CS2 activation works! IMHO the announcement for wine-0.9.54 should mention this prominently, and ask Photoshop users to test it and report bugs. In preparation for this, I'm gathering tips for users at http://wiki.winehq.org/AdobePhotoshop and will copy them into the appdb page for each version of Photoshop once I've got them together. The tough part is getting the instructions for alt key remapping right (so the window manager doesn't steal the key combinations normally used by photoshop's clone tool). I have instructions for a couple distributions there (ubuntu and suse with KDE). I'm looking for volunteers to check those instructions and correct them if they're incorrect or incomplete. Any takers? Thanks, Dan

1 0

Re: d3dx9_24: first implementation
by tony.wasserka＠freenet.de 19 Jan '08

19 Jan '08

> You need to forward all the functions of d3dx9_24 to these ones of d3dx9_36; > not only these ones that are already implemented in d3dx9_36. > > Moreover, when you create a new dll, you need to change plenty of files: > configure > configure.ac > Makefile.in > in the folder ~/wine-git/ > > You can take as example your d3dx9_36 implementation at this following > link: > http://source.winehq.org/git/wine.git/?a=commitdiff;h=87fefc7ef4eabef2b5869d > 75c7 > > David Hm, seems like I acted a little bit too hectic again... I will send a fix within the next two days. However, the configure.ac, Makefile.in etc, are autogenerated files from tools/make_makefiles, aren't they? That automatically changes these files and so I don't need to patch these manually as far as I understood. Anyways, thanks for pointing to my mistake.

1 0

Re: shdocvw: Remove unneeded cast
by Andrew Talbot 19 Jan '08

19 Jan '08

By coincidence, I've edited the same line as Jacek Caban in his patch "shdocvw: Store URL in BindStatusCallback" but in a different way. So if the two clash, please drop my patch: I shall revise it and try again after you have considered his. Thanks, -- Andy.

1 0

Re: Fix for LoadStringW
by James Hawkins 19 Jan '08

19 Jan '08

On Jan 17, 2008 1:31 AM, Christopher <raccoonone(a)procyongames.com> wrote: > This patch fixes LoadStringW when 0 is passed for buflen. LoadStringW > should now behave as described on MSDN: > http://msdn2.microsoft.com/en-us/library/ms647486.aspx > > This patch also fixes bug #10932 > > Christopher Berner > > From dfe1719df7e8cd12cc5819c647049d9f39978841 Mon Sep 17 00:00:00 2001 > From: Christopher Berner <raccoonone(a)procyongames.com> > Date: Wed, 16 Jan 2008 23:21:23 -0800 > Subject: [PATCH] Patch to fix LoadStringW when buflen is 0 > > --- > dlls/user32/resource.c | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/dlls/user32/resource.c b/dlls/user32/resource.c > index b9a51ae..148e9d1 100644 > --- a/dlls/user32/resource.c > +++ b/dlls/user32/resource.c > @@ -363,6 +363,7 @@ INT WINAPI LoadStringW( HINSTANCE instance, UINT resource_id, > WCHAR *p; > int string_num; > int i; > + int strlen; > > TRACE("instance = %p, id = %04x, buffer = %p, length = %d\n", > instance, resource_id, buffer, buflen); > @@ -379,9 +380,19 @@ INT WINAPI LoadStringW( HINSTANCE instance, UINT resource_id, > for (i = 0; i < string_num; i++) > p += *p + 1; > > + strlen = (int)*p; > TRACE("strlen = %d\n", (int)*p ); > > if (buffer == NULL) return *p; > + > + //if buflen == 0, then return a read-only pointer to the resource itself in buffer > + //it is assumed that buffer is actually a LPWSTR * > + if(buflen == 0) > + { > + *((LPWSTR *)buffer) = p + 1; > + return strlen; > + } > + > i = min(buflen - 1, *p); > if (i > 0) { > memcpy(buffer, p + 1, i * sizeof (WCHAR)); No c++ comments allowed. Also, you need to add a test case for this change. -- James Hawkins

5 6

Wine font license
by Brian Vincent 19 Jan '08

19 Jan '08

Right now on our fonts we say they're LGPL. (Look for the LangName attribute in the .sfd file.) We might want to make a modification to that. Here's what the FSF has to say about it: http://www.fsf.org/licensing/licenses/gpl-faq.html#FontException Or, to just copy and paste that info: -----------------------8<----------------- "How does the GPL apply to fonts?" Font licensing is a complex issue which needs serious consideration. The following license exception is experimental but approved for general use. We welcome suggestions on this subject—please see this this explanatory essay and write to licensing(a)gnu.org. To use this exception, add this text to the license notice of each file in the package (to the extent possible), at the end of the text that says the file is distributed under the GNU GPL: As a special exception, if you create a document which uses this font, and embed this font or unaltered portions of this font into the document, this font does not by itself cause the resulting document to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the document might be covered by the GNU General Public License. If you modify this font, you may extend this exception to your version of the font, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. -Brian

1 0

GOM player
by Dan Kegel 18 Jan '08

18 Jan '08

http://www.guardian.co.uk/technology/2008/jan/17/linux.korea says everyone in Korea uses the GOM player instead of Windows Media Player. It installs ok, but blew up when I tried to load the Sony music stream from its playlist. Free download http://www.gomplayer.com/ supposedly comes with lots of codecs. - Dan

4 4

Re: [dbghelp 10/10] Clamp minidump memory blocks to 928KB
by Eric Pouech 18 Jan '08

18 Jan '08

Jason Green a écrit : > ------------------------------------------------------------------------ > > From 1127317807ec264541e2e03e6a633cefee8f697b Mon Sep 17 00:00:00 2001 > From: Jason Green <jason(a)jave01.(none)> > Date: Thu, 17 Jan 2008 17:43:41 -0500 > Subject: [PATCH] Clamp minidump memory blocks to 928KB and improve TRACEs > WinDbg can't read minidumps with memory blocks larger than this. > From: Eric van Beurden (ericvb(a)transgaming.com) > --- > dlls/dbghelp/minidump.c | 35 +++++++++++++++++++++++++++++++++-- > 1 files changed, 33 insertions(+), 2 deletions(-) > > diff --git a/dlls/dbghelp/minidump.c b/dlls/dbghelp/minidump.c > index 564d824..f113728 100644 > --- a/dlls/dbghelp/minidump.c > +++ b/dlls/dbghelp/minidump.c > @@ -32,6 +32,13 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(dbghelp); > > + > +/* windbg isn't able to open minidump files if they contain a single memory block larger > + than 928KB. If a larger block is found, it simply reports that all following streams > + could not be loaded. This is as of WinDbg version 6.7.0005.1. */ > +#define MINIDUMP_MEMORY_BLOCK_MAX (928 * 1024) > + > + > struct dump_memory > { > ULONG base; > @@ -640,8 +647,32 @@ static void dump_threads(struct dump_context* dc, > } > if (mdThd.Stack.Memory.DataSize && (flags_out & ThreadWriteStack)) > { > - add_memory_block(dc, mdThd.Stack.StartOfMemoryRange, > - mdThd.Stack.Memory.DataSize, > + ULONG size; > + ULONG64 base; > + > + > + /* windbg only supports memory blocks up to 928KB in size. Not sure where that > + specific amount comes from, but in testing it will completely fail to load > + all minidump streams that follow a memory block that is larger than 928KB. > + Because of this, we'll clamp all of the memory blocks that we add to the > + file. */ > + if (mdThd.Stack.Memory.DataSize > MINIDUMP_MEMORY_BLOCK_MAX){ > + size = MINIDUMP_MEMORY_BLOCK_MAX; > + > + /* since this is the thread stack we'll want to save this block top-down > + instead of just clamping the buffer size */ > + base = mdThd.Stack.StartOfMemoryRange + (mdThd.Stack.Memory.DataSize - MINIDUMP_MEMORY_BLOCK_MAX); > + > + TRACE(" clamping the stack block starting at 0x%08llx {oldSize = %u bytes, newSize = %u bytes, newBase = 0x%08llx}\n", > + mdThd.Stack.StartOfMemoryRange, mdThd.Stack.Memory.DataSize, size, base); > + } > + > + else{ > + size = mdThd.Stack.Memory.DataSize; > + base = mdThd.Stack.StartOfMemoryRange; > + } > + > + add_memory_block(dc, base, size, > rva_base + sizeof(mdThdList.NumberOfThreads) + > mdThdList.NumberOfThreads * sizeof(mdThd) + > FIELD_OFFSET(MINIDUMP_THREAD, Stack.Memory.Rva)); > > ------------------------------------------------------------------------ > > > if that's really the case (and I'm even not sure we want to support this backward compatibility), a good fix would be to add several streams each up to 928k instead of clamping A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

Re: [dbghelp 7/10] Fix file searching to search only listed directories instead of the whole HD
by Eric Pouech 18 Jan '08

18 Jan '08

Jason Green a écrit : > ------------------------------------------------------------------------ > > From ad95ee9cad0df8b4e8ca35d2d5a280d755c7bf7f Mon Sep 17 00:00:00 2001 > From: Jason Green <jason(a)jave01.(none)> > Date: Thu, 17 Jan 2008 17:21:00 -0500 > Subject: [PATCH] Fix file searching to search only listed directories instead of the whole HD. > And, wrap some TRACE parameters in debugstr. > From: Eric van Beurden (ericvb(a)transgaming.com) > --- > dlls/dbghelp/path.c | 14 +++++++------- > 1 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/dbghelp/path.c b/dlls/dbghelp/path.c > index 2e191af..fac9dc0 100644 > --- a/dlls/dbghelp/path.c > +++ b/dlls/dbghelp/path.c > @@ -57,7 +57,7 @@ HANDLE WINAPI FindDebugInfoFile(PCSTR FileName, PCSTR SymbolPath, PSTR DebugFile > { > HANDLE h; > > - h = CreateFileA(DebugFilePath, GENERIC_READ, FILE_SHARE_READ, NULL, > + h = CreateFileA(FileName, GENERIC_READ, FILE_SHARE_READ, NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > you failed to set DebugFilePath to the desired value again the rest of the patch has nothing to do with the first part of the patch A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

problem with widl.
by Ivan Sinitsin 18 Jan '08

18 Jan '08

I have a question about widl. tools\widl\header.c function "write_method_macro" fprintf(header, "#define %s_", name); write_name(header,def); fprintf(header, "(p"); for (c=0; c<argc; c++) fprintf(header, ",%c", c+'a'); fprintf(header, ") "); fprintf(header, "(p)->lpVtbl->"); write_name(header, def); fprintf(header, "(p"); for (c=0; c<argc; c++) fprintf(header, ",%c", c+'a'); fprintf(header, ")\n"); This code wrong, because if my function have more then 16 parameters I receive something like this: #define Imyinterface_Open(p,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q (p)->lpVtbl->Open(p,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q) and the compiler gives out a mistake library.h:1296:63: duplicate macro parameter "p" I think that this code should be like this: Variant 1. int p=0; for (c=0; c<argc; c++) { if (p==15) p++; fprintf(header, ",%c", p+'a'); p++; } fprintf(header, ") "); fprintf(header, "(p)->lpVtbl->"); write_name(header, def); fprintf(header, "(p"); p=0; for (c=0; c<argc; c++) { if (p==15) p++; fprintf(header, ",%c", p+'a'); p++; } fprintf(header, ")\n"); or Variant 2. (Without cycles) char str[] = {'p',',','a',',','b',',','c',',','d',',','e',',','f',',','g',',','h',',','i',',','j',',','k',',','l',',','m',',','o',',','q',',','r',',','s',',','t',',','u',',','v',',','w',',','x',',','y',',','z',',',0}; str[2*argc+1] = 0; fprintf(header, "#define %s_", name); write_name(header,def); fprintf(header,"("); fprintf(header,"%s",str); fprintf(header, ") "); fprintf(header, "(p)->lpVtbl->"); write_name(header, def); fprintf(header,"("); fprintf(header,"%s",str); fprintf(header, ")\n"); What do you think about that? ---------------- Sinitsin Ivan

2 1

Debugger unhappiness blocking valgrind runs
by Dan Kegel 18 Jan '08

18 Jan '08

I just tried to do another daily valgrind run, but it got blocked because it started up an infinite number of copies of winedbg. It seems that a crash in the imagelist test in GetDibBits triggered winedbg, and winedbg crashed trying to generate a backtrace, which of course fired up winedbg, which... was bad. Some of the logs are at http://bugs.winehq.org/show_bug.cgi?id=11211 This seems to be very recent breakage, either today or yesterday. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 3