- Wine-Devel - list.winehq.org

Refcounting in dsound
by Paul Vriens Jan. 24, 2005

Jan. 24, 2005

Hi, while going through some leftover TRACE's of the Interlocked cleanup, I found the following refcounting in dsound/buffer.c and dsound.c: dsound/buffer.c: This->buffer->ref--; dsound/buffer.c: This->buffer->ref--; dsound/dsound.c: dsb->buffer->ref++; Is there a need to clean (i.e. use Interlocked*) this up? Cheers, Paul.

4 4

Regression in update region handling
by Maxime Bellengé Jan. 24, 2005

Jan. 24, 2005

Hello, This patch introduced regressions : Moved update region handling to the server http://cvs.winehq.org/patch.py?id=14725 Since this patch has been applied, I have an application with acts like a christmas tree :) The application has owner drawn objects everywhere. What I see is that every object is painted but once a first object is painted (button or whatever) when the next one is painted all the rest of the dialog box is erased and so on. So I can only see the last painted component although every button is still usable. This patch is a real nightmare to understand. I tried comparing traces with +win before and after the patch but with no luck. I would appreciate if someone can give me an hint on how to find this bug. thanks Max

5 7

Re: Use NtLoadDriver and NtUnloadDriver in StartService and ControlService
by Uwe Bonnes Jan. 24, 2005

Jan. 24, 2005

>>>>> "Ivan" == Ivan Leo Puoti <ivanleo(a)gmail.com> writes: Ivan> Note that as NtLoadDriver is a stub, no program will ever get to Ivan> call NtUnloadDriver ATM. ... Remember when Bill Gates said that 512 kByte is enough for everybody? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2

Re: rsaenh: Implemented TLS1 algorithms and tests
by Alexandre Julliard Jan. 24, 2005

Jan. 24, 2005

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > Changelog: > Support for TLS1 pseudo random function > Some helper functions for DATA_BLOB's > Computing TLS1 master secret from the pre-master secret > Deriving the master hash from the master secret > Deriving TLS1 MAC and encryption keys from the master hash > Tests for most of the above The test is failing for me: rsaenh.c:1209: Test failed: 80090016 make: *** [rsaenh.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: MSI: indentation and style cleanup
by Alexandre Julliard Jan. 24, 2005

Jan. 24, 2005

Mike McCormack <mike(a)codeweavers.com> writes: > - if(szFilePath) { > + if( szFilePath ) > + { > len = MultiByteToWideChar( CP_ACP, 0, szFilePath, -1, NULL, 0 ); > szwFilePath = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) ); > - if( !szwFilePath) > - return ERROR_OUTOFMEMORY; > MultiByteToWideChar( CP_ACP, 0, szFilePath, -1, szwFilePath, len ); > } Does your coding style also forbid proper error checking, or is there another reason for removing that check? <g> -- Alexandre Julliard julliard(a)winehq.org

6 9

Some general questions about test scripts
by Paul Vriens Jan. 24, 2005

Jan. 24, 2005

Hi, I'm currently working on the shlwapi tests and I already put something out on wine-devel for that. I tried a test on several operating systems with different dll's (out-of-the-box installation, servicepacks, Windows Update) so the end result is I have several different outputs of the test. I now more or less have the following (I'm exaggerating): ok( a < b | a == b | a > b, "Test failed\n"); So the question is how do we deal with the above? If the number of possible 'correct' output is huge, what's the benefit of testing? The second question is what should we implement in Wine? So much for the general questions. Now for the specific one: The test I'm referring to is SHQueryValueExA that I modified a bit for testing purposes: for (counter = 0; counter <= sExpLen2 ; counter++) { strcpy(buf, sEmptyBuffer); dwSize = counter; trace("Now trying with dwSize=(%lu)\n", counter); dwType = -1; dwRet = SHQueryValueExA( hKey, "Test3", NULL, &dwType, buf, &dwSize); ok( ERROR_MORE_DATA == dwRet, "Expected ERROR_MORE_DATA, got (%lu)\n", dwRet); trace("comparing (%s) with (%s)\n", buf, sEmptyBuffer); ok( 0 == strcmp(sEmptyBuffer, buf) , "Comparing (%s) with (%s) failed\n", buf, sEmptyBuffer); ok( dwSize >= nUsedBuffer2, "Buffer size (%lu) should be >= (%lu)\n", dwSize, nUsedBuffer2); ok( REG_SZ == dwType , "Expected REG_SZ, got (%lu)\n", dwType); } I tested this on 3 different versions of win98, winxp-prof, winxp-home, winnt-server, w2k-prof and w2k-server and Wine of course. I can see that winxp/w2k and winnt act the same. Win98 and Wine do it differently (Wine doesn't do it as win98 does btw). Any thoughts? Paul Vriens.

3 2

Re: Setupapi - (Take 2) implement MyFree, MyMalloc and MyRealloc
by Huw D M Davies Jan. 24, 2005

Jan. 24, 2005

On Sun, Jan 23, 2005 at 08:42:52PM -0800, Steven Edwards wrote: > Changelog: > Eric Kohl <eric.kohl(a)t-online.de> > Implement MyFree, MyMalloc and MyRealloc ... > --- /dev/null 2005-01-23 12:40:28.000000000 -0500 > +++ misc.c 2005-01-23 18:50:33.000000000 -0500 > +LPVOID WINAPI MyMalloc(DWORD dwSize) > +{ > + return HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, dwSize); > +} > + ... > +LPVOID WINAPI MyRealloc(LPVOID lpSrc, DWORD dwSize) > +{ > + if (lpSrc == NULL) > + return HeapAlloc(GetProcessHeap(), 0, dwSize); > + > + return HeapReAlloc(GetProcessHeap(), 0, lpSrc, dwSize); > +} So MyAlloc zeros the memory while MyRealloc doesn't - is this really correct? If so I think a comment, at the very least, is in order. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: MSI: indentation and style cleanup
by Rolf Kalbermatter Jan. 24, 2005

Jan. 24, 2005

On Sat, Jan 22, 2005 at 05:16:45PM +0000, Mike Hearn wrote: > Given that it can be quite complex and introduce new bugs, and given that > it's really quite a useless feature IMHO as modern Linux boxes will hang > themselves in swap hell before returning NULL from malloc I don't think > this should be a janitorial project. While I agree this may be not an easy thing to do without looking at the whole code very throughly I think saying that it doesn't help at all because on Linux you will never get this problem is a little shortsighted. Wine doesn't only compile for Linux and there might be other systems with a very straightforward swapping system which will run out of memory before the disk dies from overactivity. Also who says that the next version of Linux or some sort of stress test extension, a security hardened kernel, or a memory quota system on user basis or whatever, will not add an easy to get into out of memory situation. Couldn't Solaris for instance limit the memory available to users on a user base eventhough there are loads and loads of physical memory still available? Rolf Kalbermatter

2 1

Re: [LOSTWAGES] Update howto and downloads page (Second try)
by Tom Jan. 24, 2005

Jan. 24, 2005

Scott Ritchie wrote: > I removed the conflict in this version. I hate CVS. > > This is a rewrite of the howto to make it short and sweet and remove > some of the duplicitous information to link to the User Guide instead. > Once I finish the rewrite of the User Guide, things should look pretty > smooth and easy from a new user's perspective. > > Changelog: > +Rewrite howto to link to user's guide and mention Winetools > +Add special instruction for Debian users to howto > +Make Winetools appear further up on the download's page It looks as if you added Franks Corner back in and removed http://www.von-thadden.de/Joachim/WineTools Frank is no longer the maintainer of winetools so Joachim von Thadden should be left as the maintainer. Tom

2 1

Re: wined3d updates
by Jesse Allen Jan. 24, 2005

Jan. 24, 2005

On Thu, 20 Jan 2005 01:40:00 +0000 (GMT), Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote: > --- Oliver Stieber <oliver_stieber(a)yahoo.co.uk> > opps, it helps if I actually attach them > wrote: > > Hi, > > The attached patches: > > > > Bring d3d9.h upto date with MSDN. > > Implement DepthStencils in wined3d. > > Create STUB object for d3d9 functionality not yet > > implemented. > > Start to implement stateblocks in WineD3D. > > Implements point sprites. > > Implements ColorFill. > > Almost fix reference counting. > > And implement some very basic memory management. > > > > > > I'm sorry the patch is so big, it's taken a couple > > of > > days to merge with Jasons changes and perform > > regression testing. > > Hi Oliver, I tried your patches against CVS as of 2004-01-21. I don't believe they have been applied yet. There was one rejection, so I hacked it back in where I could see it. I could have done it wrong, as I only have a crash when loading Pirates -- it follows. So maybe you ought to take a look at rediffing your patch. Thanks for your help, and I'll keep at testing. Jesse fixme:system:SystemParametersInfoW Unimplemented action: 55 (SPI_SETMOUSEKEYS) fixme:system:SystemParametersInfoW Unimplemented action: 59 (SPI_SETSTICKYKEYS) fixme:d3d:IWineD3DImpl_GetDeviceCaps Caps support for directx9 is non-existent at the moment! fixme:d3d:IWineD3DImpl_GetDeviceCaps Caps support for directx9 is non-existent at the moment! fixme:d3d:IWineD3DImpl_GetDeviceCaps Caps support for directx9 is non-existent at the moment! wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x4a18bd19 in 32-bit code (0x4a18e98a). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:0000 EIP:4a18e98a ESP:4068fa94 EBP:4068f9c0 EFLAGS:00210246( - 00 -RIZP1) EAX:4a1b2e68 EBX:4a1b2314 ECX:000000ad EDX:4a181131 ESI:42800000 EDI:403ec130 Stack dump: 0x4068fa94: 00000000 00000000 00000000 00000000 0x4068faa4: 00000000 00000000 00000000 00000000 0x4068fab4: 00000000 00000000 00000000 00000000 0x4068fac4: 00000000 00000000 00000020 00000320 0x4068fad4: 00000258 00000000 00000000 00000000 0x4068fae4: 00000000 00000000 00000000 00000000 Backtrace: =>1 0x4a18e98a IWineD3DStateBlockImpl_InitStartupStateBlock+0x5ba(iface=0x4a181131) [stateblock.c:171] in wined3d (0x4068f9c0) 2 0x4a181131 IWineD3DDeviceImpl_SetTextureStageState+0x11(iface=0xffffd4b3, Stage=0x806f6ff, Type=0xf147d8b, Value=0x1ac685) [/home/jesse/wine/dlls/wined3d/device.c:3011] in wined3d (0x4a181131) 0x4a18e98a IWineD3DStateBlockImpl_InitStartupStateBlock+0x5ba [stateblock.c:171] in wined3d: movl $0x0,0xabe8(%edx) Unable to open file stateblock.c Wine-dbg>

1 0