January 2005 - Wine-devel - list.winehq.org

Petzold Programming Windows Fifth Edition Section 1 Regression Tests
by Ira Krakow 24 Jan '05

24 Jan '05

I'm going through the examples in Petzold's Programming Windows Fifth Edition, to familiarize myself with Winelib and to test against Wine 20050111. I am also comparing the output against Visual C++ 6.0 compilation on Windows XP. I finished Section 1 (Chapters 1-12) and found the following differences. (I didn't want to report these as bugs until others verified them, as well as my approach.) I have the source and can narrow down the code if you think this is necessary. I will proceed to Section 2 and report when I'm finished. Ira -------------------------------------------- Chapter 3: HelloWin.c Could not compile because PlaySoundA was not found. Chapter 5: SineWave.c at runtime, after sine wave displays OK and window is dismissed, get messages: err:dc:DCE_FreeWindowDCE [0x50030] GetDC() without ReleaseDC! I rerun and get a variable number of the messages, and the address inside the brackets [] changes. Clover.c Draws the clover regions initially OK, but does not redraw when the user resizes the window. Note: The resizing works in Windows XP when compiled with Visual C++ 6.0. Chapter 8: WhatClr.c Compiles and runs, but doesn't display the correct colors all the time. For example, if the cursor is under the black letters, doesn't display FF FF FF but pulsates. ALso displays FF FF FF when on a white pixel, when it should be 00 00 00. Chapter 9: PopPad1.c Compiles and runs and works for the most part. However, if you start typing on line 1 and keep typing to beyond the end of the line, the text redisplays at the bottom. In Windows, it keeps displaying on the same line and scrolls. Head.c Compiler warning on passing NULLto ReadFile: head.c:179 warning: passing arg 4 of 'ReadFile' from incompatible pointer type. But runs OK. Chapter 10: IconDemo.c Resource compiler warning: In non MFC projects, winemaker replaces the MFC specific header 'afxres.h' with 'winres.h'. Icon resource compiles OK and program runs OK. PoePoem.c Compiles OK. Exception raised dialog: "Unhandled page fault on write access to 0x7637f17a at address 0x7637e592. Do you wish to debug it?" Goes into Winedbg if you click Yes. PoorMenu.c Compiles and runs. However, it doesn't add the additional menu choices to the System Menu. NoPopup.c Compiles and runs. However, does not display all the menu choices if you double click the File.. choice. Should have New, Open, Save, Save As, and Main. The choices are there but hidden - need to click on each choice. The Main item, when clicked, should restore the MAIN menu but does not do so. Compare with Windows version. Chapter 11: About3.c OK, except that the custom icon (III) does not replace the down arrow in the upper left corner of the window, which it does in the Windows version. HexCalc.c Compiles and calculates OK. The button display is rectangular (long and narrow). On Windows the buttons display square. PopAd3.c OK. Produces message: fixme:commdlg:GetFileName95 Flags 0x00002000 not yet implemented when invoking the File Open dialog but otherwise works fine. Chapter 12: ClipView.c Compiles and runs but does not update the clipboard when the clipboard contents changes. Run ClipText under Wine, copy or cut the text to the clipboard, ClipView does not see the clipboard contents. -----------------------------------------------------

3 5

RE: D3D9 Changes
by Ann and Jason Edmeades 24 Jan '05

24 Jan '05

Hi Oliver, I said I'd give this a review, and there's some great work here. I've had a chance to go through these changes, and some mostly trivial comments. Apologies if some of these are inaccurate, because some of the diffs look complex and I was purely reviewing the patch files! There seems a lot here, but most are simple... 1. D3DLOCK_ values, D3DUSAGE_ values --> You might as well put these in order. 2. Any of the d3drs_ (or similar) changes where you remove a value which is in d3d8 but not d3d9 - Can you please define a wined3d_ version in the wined3d private header. The problem here is wined3d is compiled with the d3d9 includes but needs to understand the d3d8 specifics. I think there's only one or two of these (d3dorder? Some d3drs_ values) 3. Stick your name in the copyright of files you do significant changes to - Theres a couple I think you missed. 4. Changes to cubetexture.c I mentioned before - You cant change - return IWineD3DResourceImpl_GetType((IWineD3DResource *)iface); + return IWineD3DResource_GetType((IWineD3DResource *)iface); As this is recursive. You must leave the Impl version in there 5. You cant do this as the size isn't a member of the surface desc in d3d9 (it is in 8) - object->currentDesc_size = ((max(Width,4) * object->bytesPerPixel) * max(Height,4)) / 2; /* DXT1 is half byte per pixel */ + object->currentDesc.Size = ((max(Width,4) * object->bytesPerPixel) * max(Height,4)) / 2; /* DXT1 is half byte per pixel */ 6. There's a number of places where whitespace have increased the patch size, or indenting is changed where it didn't need to be. Its really trivial and I wont care if it goes in, its just something I noticed Examples include - case D3DZB_FALSE: + case D3DZB_FALSE: - - TRACE("(%p) : freeing StateBlock %p\n", This, pSB); + + TRACE("(%p) : freeing StateBlock %p\n", This , pSB); and /* glDrawPixels transforms the raster position as though it was a vertex - - we want to draw at screen position 0,0 - Set up ortho (rhw) mode as - per drawprim (and leave set - it will sort itself out due to last_was_rhw */ + we want to draw at screen position 0,0 - Set up ortho (rhw) mode as + per drawprim (and leave set - it will sort itself out due to last_was_rhw */ or -DWORD WINAPI IWineD3DTextureImpl_GetPriority(IWineD3DTexture *iface) { +DWORD WINAPI IWineD3DTextureImpl_GetPriority(IWineD3DTexture *iface) { (I was trying to remove such spaces as I went along!) 7. You cant comment out d3d8 functionality - We can check the version if we have to, but we must maintain the support. This relates to (2) + +#if 0 /*FIXME: d3d8 support*/ case D3DRS_SOFTWAREVERTEXPROCESSING : There's a number of these places mostly relating to texture states, render states and stateblocks - We MUST maintain d3d8 support. 8. Be careful adding in new GL calls with new gl constants, without updating the winegl_core header - We frequently break old compiles with out of date opengl headers, and this was one attempt to avoid the issue. + glTexEnvf( GL_POINT_SPRITE_ARB, GL_COORD_REPLACE_ARB, GL_TRUE); Similarly please use the d3dcore header for + #ifndef GL_MAX_DRAW_BUFFERS_ATI + #define GL_MAX_DRAW_BUFFERS_ATI 0x00008824 + #endif 9. I'm not sure on this but does d3d9 really support 16 concurrent textures in non-shader drawing modes? (ie do we really need to reapply all the states for them?). I really haven't checked, I was just surprised by it! 10. Following on from 9, don't the changes to the sampler support break d3d8 settexturestagestate for d3d8 applications for the values like D3DTSS_MAXMIPLEVEL? 11. Can you explain the problem with the following addition please, just interested! + || (dataLocations.u.s.pSize.lpData == NULL /*My ATI9600 doesn't like this combination of nothing!*/ 12. You cant use C++ style comments +// PLIGHTINFOEL *src; 13. There is a section of code "Experemental memory management that releases the allocated memory from a surface when the texture is loaded until a lock is requested on the surface.". This needs to be a separate patch and needs confirming the memory benefits are not outweighed by the performance hit. I thought the problem was that reading the contents returned an upside down texture? 14. Again, why lines like + + +#include <math.h> +#include <stdarg.h> + +#define NONAMELESSUNION +#define NONAMELESSSTRUCT +#include "windef.h" +#include "winbase.h" +#include "winuser.h" +#include "wingdi.h" +#include "wine/debug.h" + + These are already #included in d3d9_private.h and are not required here (I had removed them in earlier patches) ---------------------------------------------------------------------------- To sum up I think there is some fabulous work in there, and we definitely need to get it into cvs. Please do not take the above as criticism, as there is so much there I wanted to give useful feedback. I would, however, suggest you split functionality into smaller patches rather than put lots of new code in at the same time. (And yes, I was guilty of that but only when it was pure cut and paste from d3d8 and no new function) If I read the patches correctly you have the following which probably could be split into separate patches - Removing the d3d9 code taking it down to stubs where there was initial dummy functionality when the skeleton was originally set up - Correcting the public d3d9* headers, and making the utils functions format out the data correctly - Using a single surface call back function (Neat, btw) - Adding point support - Adding some memory management - Support for texture sampler states - Other minor changes Jason

1 0

user32/tests/sysparams.c question
by Paul Vriens 24 Jan '05

24 Jan '05

Hi, just installed winrash on my win98 box and saw some output from the test on the web. I just had a look at the sysparams.c test for test_SPI_SETICONTITLEWRAP. On my standard Win98 SE box this registry key is not available and the tests complains about that. The bad thing though is that the registry key is created and second time the test runs it succeeds of course. Shouldn't every call: rc=SystemParametersInfoA( SPI_FOO, 0, &old_b, 0 ); be followed by a: if (rc==0 && (GetLastError()==0 || GetLastError()==ERROR_CALL_NOT_IMPLEMENTED)) instead of: ok(rc!=0,"SystemParametersInfoA: rc=%d err=%ld\n",rc,GetLastError()); The 'big problem' right now will be that every volunteer will have some registry keys created if the key didn't exist before and we don't know what default installations have. Not good for documentation purposes. I will send a patch for ICONTITLEWRAP. Cheers, Paul.

1 0

Re: Disable antialiasing in palette mode
by Alexandre Julliard 24 Jan '05

24 Jan '05

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > --- dlls/x11drv/xrender.c 30 Nov 2004 21:38:58 -0000 1.52 > +++ dlls/x11drv/xrender.c 6 Dec 2004 00:02:20 -0000 > @@ -1013,6 +1013,29 @@ > INT *deltas = NULL, char_extra; > HRGN saved_region = 0; > UINT align = GetTextAlign( hdc ); > + BOOL disable_antialias = FALSE; > + AA_Type antialias = AA_None; > + > + /* Do we need to disable antialiasing because of palette mode? */ > + do { > + BITMAPOBJ *bmp; > + HBITMAP hBitmap; > + > + hBitmap = GetCurrentObject( physDev->hdc, OBJ_BITMAP ); > + bmp = (BITMAPOBJ *)GDI_GetObjPtr( hBitmap, BITMAP_MAGIC ); You should use GetObjectW here instead of GDI_GetObjPtr. -- Alexandre Julliard julliard(a)winehq.org

1 0

Refcounting in dsound
by Paul Vriens 24 Jan '05

24 Jan '05

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é 24 Jan '05

24 Jan '05

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 24 Jan '05

24 Jan '05

>>>>> "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 24 Jan '05

24 Jan '05

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 24 Jan '05

24 Jan '05

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 24 Jan '05

24 Jan '05

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