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

Re: [Darwine] RFC: Bug Management (was: wine_ldt_copy)
by Pierre d'Herbemont July 5, 2005

July 5, 2005

Sorry for cross posting to the wine-devel but I think this may interest the whole wine community. Selon Phil Krylov <phil.krylov(a)gmail.com>: > Fine :) Could you please correct the corresponding To Do entry on the Web > site? I can't do it right now, so I'll fix that later. Any way our To Do Section is not flexible enough. So that raises a good question: how shall we handle bug reports? My propositions: 1) Every bug reports handled by darwine(a)bugzilla.opendarwin.org or the darwine(a)sf Bug Management System. 2) Every bug reports handled by bugzilla.winehq.org. 3) - Wine related bugs (including darwin port specific bugs) handled by bugzilla.winehq.org. - bugs that are darwine related and not wine specific (WineHelper bugs, installer bugs, sdk bugs, ... ) handled by darwine(a)bugzilla.opendarwin.org or darwine(a)sf. Solution 1) is the worst, since we'll have to deal with bug duplication between the darwine BMS and the winehq BMS. Solution 2) is doable but probably not desired. So I think we should go for 3). Whereas it seems to be the most confusing solution for bug reporters, the separation wine code/darwine distrib is clear. Anyway bug reporters usually read the "how to bug report" before submitting a bug, do they? Would solution 3) be acceptable? Pierre.

1 0

Re: [WINECFG] Japanese translation
by Frank Richter July 5, 2005

July 5, 2005

On 05.07.2005 09:28, Hajime Segawa wrote: > +FONT 9, "MS UI Gothic" Isn't it on Windows the case that dialogs generally use "MS Shell Dlg[ 2]", which is at runtime mapped to a font appropriate for the language (e.g. "MS UI Gothic" for Japanese)? This link, while not 100% on that topic, contains some links: http://blogs.msdn.com/michkap/archive/2005/03/20/399322.aspx -f.r.

2 1

Re: [WINECFG] Japanese translation
by Frank Richter July 5, 2005

July 5, 2005

On 05.07.2005 09:28, Hajime Segawa wrote: > +FONT 9, "MS UI Gothic" Isn't it on Windows the case that dialogs generally use "MS Shell Dlg[ 2]", which is at runtime mapped to a font appropriate for the language (e.g. "MS UI Gothic" for Japanese)? This link, while not 100% on that topic, contains some links: http://blogs.msdn.com/michkap/archive/2005/03/20/399322.aspx -f.r.

1 0

Re: http://cvs.winehq.org/patch.py?id=18650
by Paul Vriens July 5, 2005

July 5, 2005

Hi, +#define ITextServices_OnTxInplaceDeactivate(p,a) (p)->lpVtbl->OnTxInplaceActivate(p,a) shouldn't that be (p)->lpVtbl->OnTxInplaceDeactivate ? Cheers, Paul.

1 0

Re: uxtheme: also send WM_THEMECHANGED to child windows (resend)
by Alexandre Julliard July 5, 2005

July 5, 2005

Frank Richter <frank.richter(a)gmail.com> writes: > +static BOOL CALLBACK UXTHEME_broadcast_msg (HWND hWnd, LPARAM msg) > +{ > + if (hWnd == NULL) > + { > + EnumWindows (UXTHEME_broadcast_msg, msg); > + } > + else > + { > + PostMessageW(hWnd, msg, 0, 0); > + EnumChildWindows (hWnd, UXTHEME_broadcast_msg, msg); The recursion is redundant here, EnumChildWindows already enumerates all children. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: OLE32/compobj: gcc 4.0 -Wpointer-sign fixes
by Robert Shearman July 5, 2005

July 5, 2005

Mike McCormack wrote: >Index: dlls/ole32/compobj.c >=================================================================== >RCS file: /home/wine/wine/dlls/ole32/compobj.c,v >retrieving revision 1.154 >diff -u -p -r1.154 compobj.c >--- dlls/ole32/compobj.c 20 Jun 2005 14:18:04 -0000 1.154 >+++ dlls/ole32/compobj.c 4 Jul 2005 14:51:31 -0000 >@@ -787,6 +787,26 @@ HRESULT WINAPI CoCreateGuid(GUID *pguid) > return UuidCreate(pguid); > } > >+static LPBYTE validate_clsid_string( LPCSTR s ) >+{ >+ int i; >+ >+ if (strlen(s) != 38) >+ return NULL; >+ >+ if ((s[0]!='{') || (s[9]!='-') || (s[14]!='-') || (s[19]!='-') || (s[24]!='-') || (s[37]!='}')) >+ return NULL; >+ >+ for (i=1; i<37; i++) { >+ if ((i == 9)||(i == 14)||(i == 19)||(i == 24)) continue; >+ if (!(((s[i] >= '0') && (s[i] <= '9')) || >+ ((s[i] >= 'a') && (s[i] <= 'f')) || >+ ((s[i] >= 'A') && (s[i] <= 'F')))) >+ return NULL; >+ } >+ return (LPBYTE) s; >+} >+ > /****************************************************************************** > * CLSIDFromString [OLE32.@] > * IIDFromString [OLE32.@] >@@ -813,28 +833,16 @@ HRESULT WINAPI CoCreateGuid(GUID *pguid) > */ > HRESULT WINAPI __CLSIDFromStringA(LPCSTR idstr, CLSID *id) > { >- const BYTE *s = (const BYTE *) idstr; >- int i; > BYTE table[256]; >+ LPBYTE s; >+ int i; > >- if (!s) >- s = "{00000000-0000-0000-0000-000000000000}"; >- else { /* validate the CLSID string */ >- >- if (strlen(s) != 38) >- return CO_E_CLASSSTRING; >- >- if ((s[0]!='{') || (s[9]!='-') || (s[14]!='-') || (s[19]!='-') || (s[24]!='-') || (s[37]!='}')) >- return CO_E_CLASSSTRING; >- >- for (i=1; i<37; i++) { >- if ((i == 9)||(i == 14)||(i == 19)||(i == 24)) continue; >- if (!(((s[i] >= '0') && (s[i] <= '9')) || >- ((s[i] >= 'a') && (s[i] <= 'f')) || >- ((s[i] >= 'A') && (s[i] <= 'F')))) >- return CO_E_CLASSSTRING; >- } >- } >+ if (!idstr) >+ idstr = "{00000000-0000-0000-0000-000000000000}"; >+ >+ s = validate_clsid_string( idstr ); >+ if( !s ) >+ return CO_E_CLASSSTRING; > > TRACE("%s -> %p\n", s, id); > I don't think there is any need to split the function into two as you can just use 'idstr' directly, instead of 's'. Also, note that this function will soon be converted into using WCHARs, but I don't think that should change anything. -- Rob Shearman

2 1

Re: OLE32: fix gcc 4.0 -Wpointer-sign warnings
by Robert Shearman July 5, 2005

July 5, 2005

Mike McCormack wrote: > ChangeLog: > * fix gcc 4.0 -Wpointer-sign warnings > >------------------------------------------------------------------------ > >Index: dlls/ole32/antimoniker.c >=================================================================== >RCS file: /home/wine/wine/dlls/ole32/antimoniker.c,v >retrieving revision 1.25 >diff -u -p -r1.25 antimoniker.c >--- dlls/ole32/antimoniker.c 6 Jun 2005 19:50:37 -0000 1.25 >+++ dlls/ole32/antimoniker.c 4 Jul 2005 14:48:34 -0000 >@@ -49,7 +49,7 @@ typedef struct AntiMonikerImpl{ > */ > const IROTDataVtbl* lpvtbl2; /* VTable relative to the IROTData interface.*/ > >- ULONG ref; /* reference counter for this object */ >+ LONG ref; /* reference counter for this object */ > > } AntiMonikerImpl; > IUnknown_AddRef and IUnknown_Release both return ULONGs so it looks like you are just moving the problem elsewhere. I think you should be casting the values passed into Interlocked{Increment,Decrement} or find some other nicer way of preventing that warning, possibly by ignoring them or just turning off the -Wpointer-sign flag. -- Rob Shearman

2 1

Running Palm Desktop
by James Liggett July 5, 2005

July 5, 2005

Hi all, I have a palm pilot that came with a lot of different apps, but they have conduits that need windows to function. I have been experimenting with getting Palm Desktop to run with Wine. It installs OK, but it doesn't run because of a bug in WinMM. I can, however, get the Hotsync service to run. But, it doesn't see my USB cradle. Has anyone tried setting this kind of thing up to get Wine to interface with the cradle using the visor driver? I thought this might work, since it emulates a serial port. But, I don't know how to map a COM port to the device. Does anyone know how to do that with Wine 20050628? Thanks, James Liggett

3 8

Failure in gdi/tests/metafile.c
by Uwe Bonnes July 5, 2005

July 5, 2005

Hallo, ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so metafile.c failes like: metafile.c:457: Test failed: (0,0)->(10,10), expected (0,0)->(18,67) metafile.c:457: Test failed: (0,0)->(10,10), expected (0,0)->(18,67) Some discussion on #winehackers brought up some clues, but no real fix. Shouls the test be a todo_wine? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 3

Re: PATCH: olepicture without libgif/libjpeg
by Robert Shearman July 5, 2005

July 5, 2005

Marcus Meissner wrote: >Hi, > >some confused users compile WINE without libgif or libjpeg >support. > >Make sure the testcase works without this compiled in. > Here is my opinion: the test cases running in Wine are designed to make sure that any program that uses the same code paths in the tested functions will work on Wine. If the user hasn't got libgif or libjpeg support then their Wine build isn't fully functional and the failing tests should be putting up a red flag for them to fix that by adding libgif-devel or libjpeg-devel to their system. -- Rob Shearman

2 1