March 2007 - Wine-devel - list.winehq.org

Re: shell32: update Polish translation
by Jacek Caban 13 Mar '07

13 Mar '07

Hi Mikołaj, Mikołaj Zalewski wrote: > - IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\n"\ > - "If the files in the destination folder have the same names as files in the\n"\ > - "selected folder they will be replaced. Do you still want to move or copy\n"\ > - "the folder?" > + IDS_OVERWRITEFOLDER_TEXT "Ten folder ju� zawiera folder o nazwie '%1'.\n\n"\ > + "Je�eli w docelowym folderze wyst�pi� pliki o takich zamych nazwach jak\n"\ > This is a typo, it should be "samych nazwach". Jacek

1 0

Re: wordpad: update Polish translation
by Jacek Caban 13 Mar '07

13 Mar '07

Hi Mikołaj, Mikołaj Zalewski wrote: > + > +STRINGTABLE DISCARDABLE > +BEGIN > + STRING_RICHTEXT_FILES_RTF, "Tekst sformatowany - RTF (*.rtf)" > + STRING_TEXT_FILES_TXT, "Document tekstowy (*.txt)" This is a typo, it should be "Dokument". Jacek

1 0

Re: const cleanup round 1
by Eric Pouech 13 Mar '07

13 Mar '07

Mike Schaadt a écrit : > string.c: > strtolW and strtoulW - constify the endptr value. This is just an > output value to indicate where in the array we stoped processing. > Change causes this to be the same type as the first value. Reduces > number of cast-qual warnings by 6. > > lnk.c: > dump_pidl > [line 176] - switched to const. Value is never modified in > the function. Removes a cast-qual warning. > > symbol.c: > symbol_clean_string - this function is modifying the string. This > should most definitly *not* be a const parameter. It's not even > logically const as the the intent of the function is to make the type > string Wine-friendly. That requires modifications to that string. > > ------------------------------------------------------------------------ > > diff --git a/include/wine/unicode.h b/include/wine/unicode.h > index 83a7d52..4e2caa5 100644 > --- a/include/wine/unicode.h > +++ b/include/wine/unicode.h > @@ -96,8 +96,8 @@ extern int strcmpiW( const WCHAR *str1, > extern int strncmpiW( const WCHAR *str1, const WCHAR *str2, int n ); > extern int memicmpW( const WCHAR *str1, const WCHAR *str2, int n ); > extern WCHAR *strstrW( const WCHAR *str, const WCHAR *sub ); > -extern long int strtolW( const WCHAR *nptr, WCHAR **endptr, int base ); > -extern unsigned long int strtoulW( const WCHAR *nptr, WCHAR **endptr, int base ); > +extern long int strtolW( const WCHAR *nptr, const WCHAR **endptr, int base ); > +extern unsigned long int strtoulW( const WCHAR *nptr, const WCHAR **endptr, int base ); > this is wrong as you want to be able to write code as: WCHAR* str; WCHAR* p; int val = strtolW(str, &p, 10); *p = '\0'; which your modification forbids (ANSI strtol doesn't have the const modifier for endptr) the rest of the patch looks ok -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 2

Re: Add casts to tools/makedep.c
by Dmitry Timoshkov 13 Mar '07

13 Mar '07

"Gerald Pfeifer" <gerald(a)pfeifer.com> wrote: > I accidently ended up building Wine using a C++ compiler the other day, > and came across the following. > - char *p = xmalloc (size); > + char *p = (char*) xmalloc (size); That's a problem of C++ not Wine if it can't cope with casting void * to another pointer type. Polluting the whole source with useless casts buys us nothing. -- Dmitry.

2 1

Re: winedbg: Support longer thread names
by Eric Pouech 13 Mar '07

13 Mar '07

Erich Hoover a écrit : > Real Name: > Erich Hoover > Description: > The thread name length in winedbg is currently restricted to 9 > characters, this is not nearly long enough for debugging threads in > the Supreme Commander demo and results in character corruption on the > terminal. Since this particular application names one of the threads > with the map path (Map loader /maps/scmp_019/scmp_019.scmap), a > significant increase in the number of characters is necessary. This > patch ups the allowed thread name length to 100 characters and > null-terminates the string in case an application exceeds that > threshold value. > Changelog: > winedbg: Support longer thread names in that case, it would be better to dynamically allocate the string (and to create it by default at 5 bytes for the %04x value) furthermore, you need to change the comment in debugger.h in THREADNAME_INFO structure about the name's length, as it seems VC7 removed the restriction to 8 characters that existed in VC6 A+

2 2

Re: [11/19] cmd.exe: Add dir /Q support
by Alexandre Julliard 13 Mar '07

13 Mar '07

"Ann & Jason Edmeades" <us(a)edmeades.me.uk> writes: > + secBuffer = (LPBYTE) malloc(sizeNeeded * sizeof(BYTE)); > + if(!secBuffer) return; Please don't use malloc in Wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

d3drm test implementation need comments and review
by Vijay Kiran Kamuju 13 Mar '07

13 Mar '07

Hi, I have implemented some d3drm functions and made some changes. Original implementation is by David Adam. Currently I dont have a wine repository to test the patch. Before applying the patch please create the dlls/d3drm/tests directory Please send me you comments, regarding this. If there are any compilation/execution errors, please notify me. I will correct them (I dont have access to linux m/c currently) Thanks, VJ

2 1

Re: Add d3drmdef.h header - try 2
by Francois Gouget 13 Mar '07

13 Mar '07

On Tue, 13 Mar 2007, Vijay Kiran Kamuju wrote: > Changelog > --------------- > Add minimalistic d3drmdef.h > > extern LPD3DVECTOR D3DRMAPI D3DRMVectorAdd(LPD3DVECTOR, LPD3DVECTOR, LPD3DVECTOR); Two nitpicks: Wine's headers usually don't specify extern (it's implicit). If there's a large list of functions it can also be nice to sort them in alphabetical order as other forms of grouping tend to break down after a time. But this is not a hard and fast rules and it is not always followed. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

2 1

Re: Set D3DCAPS2_DYNAMICTEXTURES flag
by Mirek 13 Mar '07

13 Mar '07

Shouldn't we use WINED3DCAPS2_DYNAMICTEXTURES rather than D3DCAPS2_DYNAMICTEXTURES ? Mirek Slugen Kovács András napsal(a): > Hi, > Set D3DCAPS2_DYNAMICTEXTURES flag. > This makes Call of Duty 2 to run. Stefan told me, this function is supported, > but we don't advertise it currently. > > > > ------------------------------------------------------------------------ > > From e9398c4ee873ef8b8257fcb3db4945c858655732 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Andr=C3=A1s_Kov=C3=A1cs?= <andras(a)debian.sth.sze.hu> > Date: Tue, 13 Mar 2007 03:07:30 +0100 > Subject: [PATCH] Set D3DCAPS2_DYNAMICTEXTURES flag > > --- > dlls/wined3d/directx.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 209e745..c5898c6 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -1879,7 +1879,8 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > > *pCaps->Caps = 0; > *pCaps->Caps2 = WINED3DCAPS2_CANRENDERWINDOWED | > - WINED3DCAPS2_FULLSCREENGAMMA; > + WINED3DCAPS2_FULLSCREENGAMMA | > + D3DCAPS2_DYNAMICTEXTURES; > *pCaps->Caps3 = 0; > *pCaps->PresentationIntervals = WINED3DPRESENT_INTERVAL_IMMEDIATE; > > > > ------------------------------------------------------------------------ > >

2 1

const cleanup round 1(commentary on what I found)
by Mike Schaadt 13 Mar '07

13 Mar '07

Some of this was included in the patch submission. Some of it I had questions about. spawn.c : warnings may or may not be harmless depending on if esecvp attempts to modify the results. Specs indicate it doesn't, but the function typing doesn't indicate so(the difference is 'const char * const argv[]' and 'char *const argv[]') libs/wine/string.c: strstrW - returns the location where sub was found in str. I believe returning a non-const value is what is expected. Should this be changed to a non-const parameter, or just leave the warning as is? tools/winedump/pdb.c: pdb_exit [line 149,153,155] - freeing of const variable. Is this ok? I could imagine it *could* cause problems if what we are freeing isn't in readable/writeable memory. pdb_dump_symbols [line 293,403,409] - same as pdb_exit. pdb_dump_types [line 462] - ditto pdb_jg_dump line[514] - ditto pdb_ds_dump line[643] - ditto tools/winedump/search.c: get_type [line 305, 329] - freeing of const variable again. [line 314, 335] - both cases, set return_text to type_str. Either parsed_symbol's return_text needs to be constified, proto should be unconstified, or leave it in place as a necessary cast. Any comments on the above spots? what of these are necessary casts? what of these can/should be corrected, and what needs to be done to correct them? **patches submitted to wine-patches** the following were straight forward patches that shouldn't modify the flow of the program beyond fixing the warnings. libs/wine/string.c: strtolW and strtoulW - constify the endptr value. This is just an output value to indicate where in the array we stoped processing. Change causes this to be the same type as the first value. Reduces number of cast-qual warnings by 6. tools/winedump/lnk.c: dump_pidl [line 176] - switched to const. Value is never modified in the function. Removes a cast-qual warning. tools/winedump/symbol.c: symbol_clean_string - this function is modifying the string. This should most definitely *not* be a const parameter. It's not even logically const(as a comment tried to claim) as the the intent of the function is to make the type string Wine-friendly. That requires modifications to that string, and to the variable. Removes a cast-qual warning. Comments? questions? Current number of cast-qual warnings fixed: 8. Number deemed necessary: 0(you guys need to help me decide what of these need to remain) Number looked at: 24. Estimated number remaining: 521.

1 0