December 2010 - Wine-devel - list.winehq.org

USB Device Support
by James Mckenzie 19 Feb '11

19 Feb '11

Alexander: Before I go off and try to update your USB device support for the latest Wine release, are you continuing to maintain this code current to the Wine Development and Wine Stable trunks? Also, the USB Device Support in Wine Wiki page needs an update. The code at snicky.com is no longer available. Thank you for your efforts to support USB devices in Wine. James McKenzie

6 5

Re: Improve handling of invalid input in dlls/comctl32/datetime.c
by Nikolay Sivov 19 Jan '11

19 Jan '11

On 12/25/2009 14:18, Gerald Pfeifer wrote: > Otherwise max_count will be undefined in the following loop may do > interesting things it seems. (Does Coverity diagnose similar items?) > > Gerald > > ChangeLog: > Improve handling of invalid input in DATETIME_ReturnFieldWidth. > > diff --git a/dlls/comctl32/datetime.c b/dlls/comctl32/datetime.c > index c240d4f..08c7082 100644 > --- a/dlls/comctl32/datetime.c > +++ b/dlls/comctl32/datetime.c > @@ -38,6 +38,7 @@ > * -- FORMATCALLBACK > */ > > +#include<assert.h> > #include<math.h> > #include<string.h> > #include<stdarg.h> > @@ -619,6 +620,9 @@ DATETIME_ReturnFieldWidth (const DATETIME_INFO *infoPtr, HDC hdc, int count, SHO > lctype = LOCALE_SMONTHNAME1; > max_count = 12; > break; > + default: > + assert(0); > + max_count=0; > } > > cx = 0; > Hi, Gerald. This can't even happen. spec if filtered later with: --- case THREECHARMONTH: case FULLMONTH: case THREECHARDAY: case FULLDAY: --- So no default case here.

3 6

Re: wined3d: don't set cube and volume POW2 caps if np2 textures are supported
by Alexandre Julliard 17 Jan '11

17 Jan '11

Stefan Dösinger <stefan(a)codeweavers.com> writes: > From aa344834084ef89c654011804e6e2faccafe1e5e Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)codeweavers.com> > Date: Sun, 21 Nov 2010 18:08:41 +0100 > Subject: [PATCH] wined3d: don't set cube and volume POW2 caps if np2 textures are supported It doesn't work here: ../../../tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p d3dx9_36_test.exe.so texture.c && touch texture.ok texture.c:236: Test failed: Returned mipmaps 9, expected 10 texture.c:242: Test failed: Returned mipmaps 6, expected 7 texture.c:381: Test failed: Returned mipmaps 9, expected 10 make: *** [texture.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

4 7

ntdll/cdrom : implement CDROM_Verify to work on Mac Os
by maury loïc 09 Jan '11

09 Jan '11

Hello, it's my first patch, and it implement the CDROM_Verify() to work on Mac Os. merci Loïc --- dlls/ntdll/cdrom.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/dlls/ntdll/cdrom.c b/dlls/ntdll/cdrom.c index 59f85a0..185f397 100644 --- a/dlls/ntdll/cdrom.c +++ b/dlls/ntdll/cdrom.c @@ -1121,6 +1121,8 @@ static NTSTATUS CDROM_Verify(int dev, int fd) return STATUS_SUCCESS; else return STATUS_NO_MEDIA_IN_DEVICE; +#elif defined(__APPLE__) + return STATUS_SUCCESS; #else FIXME("not supported on this O/S\n"); return STATUS_NOT_SUPPORTED; -- 1.7.3.2

3 3

Re: ws2_32: Add default case for family in debugstr_wsaioctl.
by Juan Lang 08 Jan '11

08 Jan '11

Hi Gerald, > This mimicks what we already do a few lines above for buf_type. It's also unneeded: switch(ioctl & 0x18000000) There are only 4 possible combinations of ioctl & 0x18000000. Three are covered in this switch statement, and the fourth is eliminated due to the outer switch statement. You'd be adding dead code. --Juan

2 1

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os
by James Mckenzie 01 Jan '11

01 Jan '11

maury loïc <lmaury(a)gmail.com> wrote: > >Hello Ken and the Wine community, > Please bottom post or post directly to a question. Please do not top post. > >On Thu, Dec 30, 2010 at 12:51 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > >> Hi Loïc, >> >> On Dec 30, 2010, at 4:20 AM, maury loïc wrote: >> >> > it's my first patch, and it implement the CDROM_Verify() >> > to work on Mac Os. >> >> I think most people are going to need more explanation for why this is a >> legitimate way to implement this function on Mac OS X. :) >> >> Cheers, >> Ken >> >> >For what i understood, The function CDROM_Verify(), verify if the media is >present on the device, and Wine try to open >the device(in Mac Os case), before call the CDROM_Verify(). > >But Mac Os manage the device differently from the other Os. It create the >device, only if the media >is already present. Logically, CDROM_Verify() return success, because when >we are in CDROM_Verify() >we already know the device. > >What do you think ? > This has been critically examined by several people and if the solution were this simple it would have been put in place a long time ago. Charles Davis has spend over a year looking at how to implement CDROM functionality for MacOSX. So, here is my question: How can the community be 100% certain that: 1. The device has EXACTLY the same name on every available MacOSX installation? 2. How can you be 100% certain that if the 'device' exists that the code will end up in CDROM_Verify()? James McKenzie (Another Mac User/Wine Tester.)

5 6

Re: 64-bit Notepad2 crashes
by Susan Cragin 01 Jan '11

01 Jan '11

>>> Does this 'path' exist in LD_LIBRARY_PATH or equivilent? >>> >>> Otherwise ld might not be able to 'find' it when starting the program. >>> >>> James McKenzie >>> >> James... >> You've just exhausted my technical knowledge. How do I do / find that? >Susan: > >For the BASH shell: >Type in set and look for the LD_LIBRARY_PATH line. >for the CSH/KSH shell: >Type in env >Look for the LD_LIBRARY_PATH line. > >Hopefully, /usr/local/lib is there. > >BTW, to make Wine work on a Mac, I have to add this line.... > >James McKenzie Typed "set" Did word search on "library." Nothing.

4 3

Another tests milestone hit
by Greg Geldorp 31 Dec '10

31 Dec '10

Today we hit another milestone: the first 0-failure run of the 64-bit tests. All tests passed on both the WXPX64 and W2K3R2SEX64 machines. Sadly I missed my personal goal of having all tests pass on at least one VM for every Windows version by the end of the year, we still don't have a Win7 machine that passes all tests. I have a partial fix for msctf:inputprocessor (put a "Sleep(2000);" after the call to test_RegisterCategory()) but in spite of spending quite a bit of time on it haven't made much further progress. So anyone with msctf expertise: your help would be greatly appreciated. Same for ole32:clipboard and ole32:usrmarshal. A big thank you to all the people who contributed tests and fixed existing tests. I think a lot of progress has been made in the month since WineConf and the tests are in much better shape now. Greg.

2 1

sound issues (which are not cared since 1.3.1)
by wylda＠volny.cz 31 Dec '10

31 Dec '10

Hi guys, there are bug reports showing random crashes with audio on, during winecfg etc. I was bit by those too... There is probably something wrong how regressions are handled here, which goes on and thus there are unneeded bugreports which cost everyone's time to read, evaluate, search, mark, retest... Why don't you use revert more offen like kernel guys? Back to the sound issue - my zero programming skill standing just on sound despair, i guess in dlls/winealsa.drv/mixer.c ALSA_MixerInit() should be int card, err, capcontrols=0 otherwise things like: mixdev[mixnum].chans += capcontrols; mixdev[mixnum].lines = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(line) * mixdev[mixnum].chans); mixdev[mixnum].controls = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(control) * CONTROLSPERLINE*mixdev[mixnum].chans); goes crazy like in http://bugs.winehq.org/show_bug.cgi?id=25231#c2. Could someone review this piece of code, please? Thanks, W.

2 2

re: JanitorialProjects/ReplaceMalloc: remove malloc and free from dlls folder
by Dan Kegel 31 Dec '10

31 Dec '10

Yegor wrote: > it's my first contribution to wine... Welcome! > so I wanted to start with some simple task. Changing memory allocation might not be simple. Your patch touches two different DLLs. You should probably split this patch up, one patch per dll. Also, the fact that your change to d3dcompiler_43 only changes a malloc and not a corresponding free is interesting. Is there a leak? Better run this past the author of that code. > The source code could be compiled without problems after applying the patch. Verifying that it compiles isn't enough. You also have to verify by eye that this change doesn't introduce any alloc/free mismatches, and check that it doesn't introduce any conformance test regressions. Since not all tests pass, you need to run the tests first without your change, and then with your change, and understand any differences in the results. Since you're messin' with malloc, you should also do that with WINEDEBUG=+heap. - Dan

2 2