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

Re: Another tests milestone hit

by Alexandre Julliard

Greg Geldorp <ggeldorp(a)vmware.com> writes: > 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. Yes, the results page is looking incredibly good lately. It seems that 2011 will be the year where we'll finally see more green than red on that page. Many thanks to Greg and to everyone who has been helping! Happy new year to you all! -- Alexandre Julliard julliard(a)winehq.org

Dec. 31, 2010

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os

by Charles Davis

On 12/31/10 1:11 PM, Ken Thomases wrote: > I should add that this patch seem correct to me. It couldn't hurt to get Charles Davis's input, of course. I agree, for now. He should at least put a comment in to the effect of "if we got this far, there's already media in the drive." > MSDN documents that the purpose of IOCTL_*_CHECK_VERIFY is to check if the media has changed. The Linux and FreeBSD implementations basically just check if there's media in the drive. On Mac OS X, the BSD device file just plain doesn't exist unless and until there's media mounted. There's no permanent BSD device file for the drive itself. So, if CDROM_Verify() is called, which requires that the BSD device file is opened and thus is present, that by itself implies that there's media in the drive. Therefore, CDROM_Verify() should just return success. Makes sense. But the 'right' way to implement this on Mac OS is to ask DiskArbitration to tell us when the media changes. (In fact, the right way to implement this elsewhere is to ask udev or hald the same thing.) Then we can return STATUS_VERIFY_REQUIRED (as documented) when the media actually has changed. For now, though, Loïc's patch is OK. AJ wants to eventually move some (all?) of the disk/CD/DVD/storage IOCTLs into mountmgr anyway, where Wine's fake storage drivers are hosted. Mountmgr already has infrastructure in place to talk to DA on Mac OS and to hald on Linux/FreeBSD, so doing this the 'right' way will be much easier there. Chip

Dec. 31, 2010

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os

by Ken Thomases

On Dec 31, 2010, at 1:38 PM, Ken Thomases wrote: > Why does that matter? The question is, under what circumstances does it end up in CDROM_Verify()? What is the right behavior of CDROM_Verify() and how would that be implemented on Mac OS X? I should add that this patch seem correct to me. It couldn't hurt to get Charles Davis's input, of course. CDROM_Verify() is called when CDROM_DeviceIoControl() gets a IOCTL_*_CHECK_VERIFY request. CDROM_DeviceIoControl() is only called (from NtDeviceIoControlFile()) for the appropriate type of device and that's further verified (on Mac OS X) by the call to get_parent_device(). MSDN documents that the purpose of IOCTL_*_CHECK_VERIFY is to check if the media has changed. The Linux and FreeBSD implementations basically just check if there's media in the drive. On Mac OS X, the BSD device file just plain doesn't exist unless and until there's media mounted. There's no permanent BSD device file for the drive itself. So, if CDROM_Verify() is called, which requires that the BSD device file is opened and thus is present, that by itself implies that there's media in the drive. Therefore, CDROM_Verify() should just return success. Which is basically what Loïc said. :) -Ken

Dec. 31, 2010

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os

by Ken Thomases

On Dec 30, 2010, at 9:36 AM, James McKenzie wrote: > 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. Rather than arguing in sweeping generalizations, can we confine ourselves to the technical specifics of this particular case, please? When you say "this has been ... examined", are you referring specifically to CDROM_Verify()? > 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? What does the device name have to do with anything? Do you think that Loïc's patch somehow contains an implicit dependence on device names? If so, why? > 2. How can you be 100% certain that if the 'device' exists that the code will end up in CDROM_Verify()? Why does that matter? The question is, under what circumstances does it end up in CDROM_Verify()? What is the right behavior of CDROM_Verify() and how would that be implemented on Mac OS X? Can you explain which aspect of CDROM_Verify()'s behavior is not properly implemented by Loïc's patch? Regards, Ken

Dec. 31, 2010

Another tests milestone hit

by Greg Geldorp

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.

Dec. 31, 2010

Re: 64-bit Notepad2 crashes

by Hin-Tak Leung

Susan Cragin wrote: >>>> 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. for BASH, it should be export | grep LD_LIBRARY_PATH not "set".

Dec. 31, 2010

Re: sound issues (which are not cared since 1.3.1)

by wylda＠volny.cz

> > > > 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); > > > > > > goes crazy like in > > http://bugs.winehq.org/show_bug.cgi?id=25231#c2. > > well spotted, the patch incorrectly removed the = 0. > > I submitted a patch readding it. Hi again! Many thanks Marcus for the patch and getting it git-official :) I wonder if someone could write a Wiki page about different techniques how beginners like me can spot and easily test for this kind of wine's code problems. Thanks to this bug, Wine-1.3.10 + winecfg's audio tab could be taken as the example and wiki could show how to use different tools (warn+heap, valgrind, gcc options, ...) and what tools' output to expect in case of such bugs. Regards, W. PS: Marcus, i noticed "found by my overflow checking patches" in http://source.winehq.org/patches/data/69925. Are these patches publicly available? ;)

Dec. 31, 2010

Re: JanitorialProjects/ReplaceMalloc: remove malloc and free from dlls folder

by Dan Kegel

On Fri, Dec 31, 2010 at 3:48 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Maybe it's just time to remove the "replace malloc with HeapAlloc" > task from the wiki? Or, at least, add a note to explain that we expect > the current Wine code to be "compliant". Done.

Dec. 31, 2010

Re: JanitorialProjects/ReplaceMalloc: remove malloc and free from dlls folder

by Matteo Bruni

2010/12/30 Dan Kegel <dank(a)kegel.com>: > 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? That string is freed by wpp, which is a native library thus it uses free(). So the code is correct as it is now, with the malloc(). There were already a couple of times people came up with similar patches, I can't find them right now though. Maybe it's just time to remove the "replace malloc with HeapAlloc" task from the wiki? Or, at least, add a note to explain that we expect the current Wine code to be "compliant".

Dec. 31, 2010

Re: oleview: Fix a null pointer crash

by Nikolay Sivov

On 12/31/2010 13:38, Alexandre Julliard wrote: > Nikolay Sivov<nsivov(a)codeweavers.com> writes: > >> Fix a null pointer crash > This is an internal function, the caller should take care of this. True, it was wrong. Thanks.

Dec. 31, 2010