wine-devel August 2009

97 participants
276 discussions

by James Mckenzie

> >Here's the initial italian translation for write. Again, this is not acceptable. The input file should be /dev/null with the difference against your file. You are running a difference against the en_US.rc file after renaming it. Please correct and resubmit. This is the same problem that was pointed out to you with your prior rejected translations. James McKenzie

14 years, 8 months

Re: wordpad - initial italian translation

by James Mckenzie

> >Here's the initial italian translation for wordpad. This is STILL WRONG! You are not listening. If this is an initial translation, the input file should be /dev/null, not en_US.rc which is what you are using. Please correct and resubmit. James McKenzie

14 years, 8 months

Re: programs/clock: Corrected a small lexical error in the italian translation (Corrected)

by Henri Verbeet

2009/8/29 Riccardo Loti <contez(a)gmail.com>: > P.S.: For some reason the previous mail attachment showed up empty in the > archives list, even if sent mail is correct, and using Thunderbird I prefer > not to paste it int he message body. Sorry for double sending. > The archives are a bit flawed, and created a separate mail for the attachment: http://www.winehq.org/pipermail/wine-patches/2009-August/077889.html The mail itself looked ok.

14 years, 8 months

Re: [PATCH 1/3] dpwsockx: Stub implementation

by Stefan Dösinger

Yay, Dplay work! A few suggestions though: From patch 1: > +static HRESULT WINAPI DPWSCB_GetCaps( LPDPSP_GETCAPSDATA data ) > +{ > + TRACE( "(%d,%p,0x%08x,%p)\n", > + data->idPlayer, data->lpCaps, data->dwFlags, data->lpISP ); >+ return DP_OK; > +} Is there any reason this one writes a TRACE instread of a FIXME? I noticed that patch 3 implements it, perhaps you missed this when separating the patches? > +static HRESULT WINAPI DPWSCB_Open( LPDPSP_OPENDATA data ) > +{ > + FIXME( "(%u,%p,%p,%u,0x%08x,0x%08x) stub\n", > + data->bCreate, data->lpSPMessageHeader, data->lpISP, > + data->bReturnStatus, data->dwOpenFlags, data->dwSessionFlags ); > + return DP_OK; > +} Why does it return DP_OK while most other stubs return an error? Patch 2: > + /* Initialize internal data */ > + ZeroMemory( &dpwsData, sizeof(DPWS_DATA) ); I think memset(&dpwsData, 0, sizeof(DPWS_DATA)) is preferred over ZeroMemory. Patch 3: Where do the values like dwMaxLocalPlayers = 65536 come from? Since most functions are still stubs its hard to see where it comes from? Does native dpwsockx have the same limits? (If it does, that's a solid reason for using the same limits)

14 years, 8 months

Re: configure: Detect and use tools executable extensions for makefiles. (try2)

by John Klehm

On Fri, Aug 28, 2009 at 3:13 PM, Dylan Smith<dylan.ah.smith(a)gmail.com> wrote: > (used sed to get the EXEEXT from the wine-tools/Make.rules file) > > When compiling Wine on windows, the non-script tools will have an .exe > extension, but the makefile rules assumed that the tools never have an > extention, so try to incorrectly remake the tools when they are already > built. > Is this patch solving the same thing that this one did? http://www.winehq.org/pipermail/wine-cvs/2009-August/058936.html

14 years, 8 months

Re: progress of sound update -- REVISED

by Susan Cragin

>>Why do you need to install esound? >ALSA has shipped with "dmix" by default since shortly after 1.0 was >released, though I think Ubuntu's pulse config can screw with it even >after pulseaudio is removed. I'd forgotten about dmix, it's been so long. Good old dmix and dsnoop (which is what I need for incoming sound). I THINK MAYBE dmix works and dsnoop does not, because it's listed when I open Audacity. I'll have to give it a try. However, without installing esound, I don't see "dmix" and "dsnoop" but I do see "default." And "default" freezes. Perhaps that's them, and they just don't work?

14 years, 8 months

Re: Weekly cppcheck run against Aug 27 Git Tree

by chris ahrendt

Mike Kaplinskiy wrote: > On Thu, Aug 27, 2009 at 3:52 PM, chris ahrendt<celticht32(a)yahoo.com> wrote: > >> This is the result of running cppcheck 1.35 with the --all parm against >> the august 27th Git tree: >> >> [../wine-git/dlls/dbghelp/msc.c:88]: (possible error) Array index out of >> bounds >> [../wine-git/dlls/dbghelp/msc.c:89]: (possible error) Array index out of >> bounds >> > > False positive, apparently the numbers are hardcoded as: > 72 char msg[128]; > 88 msg[10 + 3 * 16] = ' '; // = 58<127 > 89 msg[10 + 3 * 16 + 1 + 16] = '\0'; // = 75<127 > > >> [../wine-git/dlls/shell32/cpanelfolder.c:562]: (error) Possible null >> pointer dereference: rgfInOut >> [../wine-git/dlls/shell32/shfldr_desktop.c:437]: (error) Possible null >> pointer dereference: rgfInOut >> [../wine-git/dlls/shell32/shfldr_fs.c:577]: (error) Possible null >> pointer dereference: rgfInOut >> [../wine-git/dlls/shell32/shfldr_mycomp.c:474]: (error) Possible null >> pointer dereference: rgfInOut >> [../wine-git/dlls/shell32/shfldr_netplaces.c:352]: (error) Possible null >> pointer dereference: rgfInOut >> > > It doesn't like the ternary operator? These lines are TRACE lines with > one of the args being ``rgfInOut ? *rgfInOut : 0''. False positive. > > >> [../wine-git/dlls/user32/tests/msg.c:63]: (error) Invalid number of >> character ({). Can't process file. >> [../wine-git/dlls/winealsa.drv/waveinit.c:745]: (possible error) Buffer >> overrun >> > > 739 char defaultpcmname[256]; > 745 sprintf(defaultpcmname, "default"); > > Something is wrong with cppcheck... False positive. > > >> [../wine-git/dlls/wined3d/arb_program_shader.c:907]: (possible error) >> Buffer overrun >> [../wine-git/dlls/wined3d/arb_program_shader.c:915]: (possible error) >> Buffer overrun >> [../wine-git/dlls/wined3d/glsl_shader.c:3416]: (possible error) Buffer >> overrun >> [../wine-git/dlls/wined3d/glsl_shader.c:3418]: (possible error) Buffer >> overrun >> [../wine-git/dlls/wined3d/glsl_shader.c:3519]: (possible error) Buffer >> overrun >> [../wine-git/dlls/wined3d/glsl_shader.c:3521]: (possible error) Buffer >> overrun >> > > Not checking those - i don't even pretend to understand how modern > graphics works. > > >> [../wine-git/dlls/wineoss.drv/mixer.c:1458]: (possible error) Buffer overrun >> > > So...it picks > 1455 char name[32]; > 1458 sprintf(name, "/dev/mixer"); > > as an error, but not: > > 1460 sprintf(name, "/dev/mixer%d", i); > > False positive. > > >> [../wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer >> dereference: dmW >> > > This one is actually a bug, the null check is below this line. All the > callers check for nulls, though. > > >> [../wine-git/programs/oleview/pane.c:152]: (error) Possible null pointer >> dereference: hWndCreated >> > > Also a bug, and a very real one. Coincidentally, the null check on the > next line is also wrong (should be if (!*hWndCreated) ) > > >> [../wine-git/programs/winetest/main.c:114]: (possible error) Buffer overrun >> [../wine-git/programs/winetest/main.c:116]: (possible error) Buffer overrun >> [../wine-git/programs/winetest/main.c:119]: (possible error) Buffer overrun >> [../wine-git/programs/winetest/main.c:121]: (possible error) Buffer overrun >> > > More of sprintf with just a string nonsense. False positive. > > >> [../wine-git/server/file.c:235]: (possible error) Buffer overrun >> > > Also sprintf nonsense, but slightly more dangerous. The buffer is > declared with [16] and the string is of length 14+1, so a few more > bytes wouldn't hurt. :) > >> Chris >> >> > > If someone could send patches for the few bugs that would be nice. > > Chris - cppcheck is clearly crazy about sprintf's and ternary > operators. You might want to report that. > > Mike. > > > Mike While yes the hard coded one above is a false positive... I would argue its still a bug that probably needs to get fixed... chris

14 years, 8 months

Recent ntdll performance information patches

by Steven Edwards

Since the last few rounds of patches to NtQuerySystemInformation I am now getting this error when trying to build with llvm-gcc from the latest Xcode nt.c: In function ‘NtQuerySystemInformation’: nt.c:1012: error: ‘struct _SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION’ has no member named ‘liIdleTime’ nt.c:1013: error: ‘struct _SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION’ has no member named ‘liKernelTime’ nt.c:1014: error: ‘struct _SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION’ has no member named ‘liUserTime’ -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

14 years, 8 months

Re: [PATCH 6/7] ws2_32: implement AcceptEx

by Juan Lang

Hi Mike, I have one minor nit on this patch: + if (wsa->read) HeapFree( GetProcessHeap(), 0, wsa->read ); Please don't check if (wsa->read) is NULL before calling HeapFree. HeapFree already does the correct thing given NULL, and we had a bunch of patches to remove checks like this. --Juan

14 years, 8 months

WINE and the LSB, or installations Picasa style

by Joe Dluzen

Hello all, any updates on the progress of compiling WINE against the LSB? I know Dan was attempting to here http://www.mail-archive.com/[email protected]/msg47916.html but there's been no recent updates. Or, does anyone have any tips or tutorials or best practices to deploy a self contained WINE installation, e.g. Picasa style? Thanks, j

14 years, 8 months

← Newer
1
2
3
4
5
6
7
...
28
Older →

Jump to page:

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 2009