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

Re: [18/19] WineD3D: Do not change the states if render target locking is disabled
by Stefan Dösinger Dec. 19, 2006

Dec. 19, 2006

Am Dienstag 19 Dezember 2006 23:27 schrieb Stefan Dösinger: > There is no point in messing with the states if we aren't going to draw > anything anyway. This patch will conflict slightly with Henri's multiple render target patch. (device->renderTarget vs device->renderTarget[0]). If it does not apply then its not a crucial problem for the other patches, they should still work fine.

1 0

Re: oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (try 2) (RESEND)
by Alexandre Julliard Dec. 19, 2006

Dec. 19, 2006

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > +#define HANDLE_DISPATCH(left, right) \ > + if ((V_VT(param_left) & VT_TYPEMASK) == VT_DISPATCH && \ > + (V_VT(param_right) & VT_TYPEMASK) != VT_NULL) \ > + {\ > + HRESULT hres;\ > + left = &tempLeft;\ > + hres = VARIANT_FetchDispatchValue(param_left, left);\ > + if (!SUCCEEDED(hres)) return hres;\ > + }\ > + if ((V_VT(param_right) & VT_TYPEMASK) == VT_DISPATCH &&\ > + (V_VT(param_left) & VT_TYPEMASK) != VT_NULL)\ > + {\ > + HRESULT hres;\ > + right = &tempRight;\ > + hres = VARIANT_FetchDispatchValue(param_right, right);\ > + if (!SUCCEEDED(hres)) return hres;\ > + } This macro is quite ugly. Also I don't see why you check the other variant against VT_NULL first, aren't there cases where you still need the other value? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Add a test for IDirectDrawSurface_SetColorKey
by Stefan Dösinger Dec. 19, 2006

Dec. 19, 2006

Am Montag 18 Dezember 2006 22:10 schrieb Günther Brammer: > Only tested with wine, unfortunately. Tests for the issue causing Bug 5730. I will run your test on windows, but I'd expect it to work. Can you also test which color key GetSurfaceDesc returns? > > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > index 3d70f82..74e4f28 100644 > --- a/dlls/ddraw/tests/dsurface.c > +++ b/dlls/ddraw/tests/dsurface.c > @@ -167,6 +167,7 @@ static void SrcColorKey32BlitTest(void) > LPDIRECTDRAWSURFACE lpDst; > DDSURFACEDESC ddsd; > DDSURFACEDESC ddsd2; > + DDCOLORKEY DDColorKey; > LPDWORD lpData; > HRESULT rc; > > @@ -222,6 +223,21 @@ static void SrcColorKey32BlitTest(void) > "Destination data after blitting is not correct\n"); > rc = IDirectDrawSurface_Unlock(lpDst, NULL); > ok(rc==DD_OK,"Unlock returned: %x\n",rc); > + > + /* Also test SetColorKey */ > + IDirectDrawSurface_GetColorKey(lpSrc, DDCKEY_SRCBLT, &DDColorKey); > + ok(DDColorKey.dwColorSpaceLowValue == 0xFF00FF && > DDColorKey.dwColorSpaceHighValue == 0xFF00FF, + "GetColorKey does not > return the colorkey used at surface creation\n"); + > + DDColorKey.dwColorSpaceLowValue = 0x00FF00; > + DDColorKey.dwColorSpaceHighValue = 0x00FF00; > + IDirectDrawSurface_SetColorKey(lpSrc, DDCKEY_SRCBLT, &DDColorKey); > + > + DDColorKey.dwColorSpaceLowValue = 0; > + DDColorKey.dwColorSpaceHighValue = 0; > + IDirectDrawSurface_GetColorKey(lpSrc, DDCKEY_SRCBLT, &DDColorKey); > + ok(DDColorKey.dwColorSpaceLowValue == 0x00FF00 && > DDColorKey.dwColorSpaceHighValue == 0x00FF00, + "GetColorKey does not > return the colorkey set with SetColorKey\n"); > > IDirectDrawSurface_Release(lpSrc); > IDirectDrawSurface_Release(lpDst);

1 0

Status of wine development
by Remco Dec. 19, 2006

Dec. 19, 2006

I ask it consisely, but maybe the answers could be posted as a news item on WineHQ. It would be great for Wine to get some exposure on tech sites from time to time. That requires some actual news (new minor releases aren't front-page news after all). So, what's the status/news of DX10? DX in general? the Mac-port? Wine 1.0? What's the status of anything else that has been a major thing last year? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

7 7

Conformance tests
by Michal Okresa Dec. 19, 2006

Dec. 19, 2006

Hello, wine developers guide says that conformance tests must pass successfully on all Windows platforms. I tried couple of tests in past weeks to catch wine's style of unit testing, but now I am confused. For example I run crosscompiled olefont test (oleaut32) on the windows machines (XP, 98). The test ended with 15 failures. The same test executed on my linux machine ended with 13 failures (reasons for failures are almost identical with previous runs on windows). Is this expected behaviour of conformance tests on windows platforms? thanks -- Michal Okresa

2 1

Re: Bug 50
by Pedro Araújo Chaves Jr. Dec. 19, 2006

Dec. 19, 2006

On 12/19/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > Passing the DC is not an option, that's a private gdi32 structure that > the driver doesn't know about. You shouldn't need to change the > function signature in any case, it already takes an lpDx array, all > you have to do is put better spacing values in there. Well, I had dropped that idea altogether as soon as I started working early in the morning, before reading your e-mail... besides, my next move was to play around with the spacing array, of course. Anyway, for a number of reasons, the idea of changing the function signature didn't sound well from the start to me neither. Yet I wanted to give it a shot, since it once fixed the issue. I'll keep you informed. Regards, Pedro.

1 0

Bug 50
by Pedro Araújo Chaves Jr. Dec. 19, 2006

Dec. 19, 2006

First, sorry for the blank mail I accidentally sent earlier... my bad. Ok, so I have been assigned bug 50 [1] here at my job, and I'm trying to apply the patch [2] Keith Dunwoody proposed in June 2005, which fixed the issue but was rejected for technical reasons. Right now I can't think of another way around that bug except a patch that big, but I think we could break it into two smaller ones: the first one would change what must be changed for the second one ― the actual correction ― to work. Well, that first one involves changing the signatures of the ExtTextOut functions in winex11.drv, in a similar fashion to what Keith had proposed; but, instead of adding 'INT *breakTotalExtra, INT *breakCount' to their argument lists, I suggest that we pass them the whole DC instead of just its physDev ― that way we'd have access to the relevant attributes while still being able to get its physDev (assigning it to a variable right at the beginning of the functions, in order to keep their current functionality in this first step). I'm only afraid that may bring a little overhead, so I'd really like to see some opinions, or some better ideas... [1] http://bugs.winehq.org/show_bug.cgi?id=50 [2] http://bugs.winehq.org/attachment.cgi?id=912&action=view I'll be testing that here, anyway. Cheers, Pedro. -- "People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster." (Adam Osborne)

2 1

Running winetest on Vista
by Paul Vriens Dec. 18, 2006

Dec. 18, 2006

Hi, I've started to run our winetest executable on Vista. The current output is 7.8 MB or so, so we will never be able to sent it out just yet (1.5MB limit). I will start reducing the number of test failures on Vista (if I can of course). One thing that struck me and most likely it's due to Vista security is that when I run winetest.exe it tells me that it couldn't retrieve the list for the setupapi tests. While investigating that (several hours up to now) I found (not 100% sure though) that if an executable (like our setupapi_test.exe) has the word setup in it and is not properly signed, Vista starts complaining !!! Just copying our setupapi_test.exe to paul.exe makes it possible to run 'paul.exe --list'. Any ideas about the latter? Cheers, Paul.

4 5

Re: [1] WineD3D: Add the state dirtification infrastructure
by Stefan Dösinger Dec. 18, 2006

Dec. 18, 2006

Am Montag 18 Dezember 2006 19:25 schrieb Stefan Dösinger: Another issue I stumbled uppon: This patch moves the + 1 for the array declaration to the right place. > Am Montag 18 Dezember 2006 14:06 schrieb Stefan Dösinger: > Another update, it fixes an spotted by Henri issue where the state was used > instead of the representative and uses shifting and bitmasks to calculate > the index and shift for the bitmap. > > > This is another updated version, it uses bitmaps for the isStateDirty > > member. > > > > Am Sonntag 17 Dezember 2006 14:45 schrieb Stefan Dösinger: > > > Am Freitag 15 Dezember 2006 18:31 schrieb Stefan Dösinger: > > > > This patch adds the dirty list infrastructure. A dirty marker > > > > consists of a DWORD containing the state it marks dirty, and the list > > > > structure to build the list. > > > > > > > > The wined3ddevice has 3 new members: > > > > dirtyStateList: The list of dirty states. This will be moved to a > > > > per-context stucture once we add multithreading support > > > > freeListElems: A list containing unused dirty markers to avoid > > > > unnecessary HeapAlloc/HeapFree calls. I have seen D3D games spending > > > > 15% cpu time in the Heap code, we don't want to increase that. > > > > dirtyStates: An array that tells if a state is dirty. It is used to > > > > avoid double dirtification. I do not use the > > > > stateblock->changed.XXXX[] array because this is used for different > > > > purposes in the stateblock code. Ivan, do we still need it? > > > > > > Attached is an updated patch that uses an array for dirtification > > > instead of a list. Actually there are 2 arrays, one to quickly find out > > > if a specific state is dirty, and one to quickly find all dirty states. > > > > > > Checking if a state is dirty is done very often, so we need the > > > isStateDirty. A linear search on the dirtyArray would take way too much > > > time. On the other hand, my experiance so far shows that usually not > > > more than 10-20 states are dirty at the beginning of a drawprim call, > > > so iterating over all states would be a waste of time too. That's why > > > the dirtyArray is there. > > > > > > In the end there will be around 1000 states, so the size of those > > > arrays will be 8-10 kilobytes. Even oldest games load textures in the > > > area of megabytes, with recent games it's about gigabytes, so I don't > > > think those 10 kb's are an issue :-) . I could easilly change the > > > DWORDs to shorts, but all d3d states are defined as DWORDs, so I > > > decided to use DWORDS. > > > > > > If I used a bitmap I could squeeze the same information in about 128 > > > bytes + extra size for the code dealing with the bitmap + extra runtime > > > needs for bit shifting and checking all DWORDs in the bitmap. D3D games > > > are usually cpu limited, so I prefer the more memory intensive version. > > > > > > The other patches should apply cleanly over this patch, so I do not > > > resend them.

1 0

re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.
by Dan Kegel Dec. 18, 2006

Dec. 18, 2006

Hans wrote: > These stubs make the installer happy that is common to many of the .NET apps I tried. Which apps? Now that your patches seem to have been committed, I've started trying to find and install apps that require .net, but for some reason I'm having trouble finding many. The first one I tried is Life Balance (http://appdb.winehq.org/appview.php?iAppId=2928) but even if Mono-1.2 is installed, Life Balance seems to still try to download and install the MS c# runtime. +relay shows this before the download starts: 0009:Call advapi32.RegOpenKeyExA(80000002,0042f148 "SOFTWARE\\Microsoft\\NET Framework Setup\\NDP",00000000,00020019,0033bb90) ret=0040fa26 0009:Ret advapi32.RegOpenKeyExA() retval=00000002 ret=0040fa26 And bingo, http://msdn2.microsoft.com/en-us/library/aa480243.aspx documents this as part of the check to see if .net is installed. Has somebody figured out a canned .reg file to use to fake out this install check? - Dan

3 4

Re: ws2_32: Implement the SIO_ADDRESS_LIST_QUERY ioctl.
by Dmitry Timoshkov Dec. 18, 2006

Dec. 18, 2006

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > case WS_SIO_ADDRESS_LIST_QUERY: > - FIXME("-> SIO_ADDRESS_LIST_QUERY request: stub\n"); > - break; > + { > + int fd; > + DWORD size; > + > + TRACE("-> SIO_ADDRESS_LIST_QUERY request\n"); > + > + if (!lpcbBytesReturned || (fd = get_sock_fd(s, 0, NULL)) == -1) It appears that fd is not used later at all. -- Dmitry.

1 0

Bug 50
by Pedro Araújo Chaves Jr. Dec. 18, 2006

Dec. 18, 2006

-- "People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster." (Adam Osborne)

1 0

Re: DDraw: Implement depth filling through blit. (re-resubmit) try3
by Stefan Dösinger Dec. 18, 2006

Dec. 18, 2006

Am Sonntag 17 Dezember 2006 23:24 schrieb greg87(a)online.de: > Original Author: > Elie Morisse > lachienne(a)wanadoo.fr > > Updated by: > Gregor Münch > greg87(a)online.de > > This is modified version of this patch: > http://www.winehq.org/pipermail/wine-patches/2006-September/030815.html > > With the help from Stefan Dösinger I altered 2 lines. Full credit > belongs to Elie Morisse > > fixes: http://bugs.winehq.org/show_bug.cgi?id=4306 A small issue: The indentions in IWineD3DSurfaceImpl_BltZ look a bit strange. --- a/dlls/ddraw/ddraw.c +++ b/dlls/ddraw/ddraw.c @@ -1787,7 +1787,7 @@ IDirectDrawImpl_CreateNewSurface(IDirect { Usage |= WINED3DUSAGE_OVERLAY; } - if(This->depthstencil) + if(This->depthstencil || (pDDSD->ddsCaps.dwCaps & DDSCAPS_ZBUFFER)) { Perhaps you can get rid of This->depthstencil by setting the DDSCAPS_ZBUFFER flag instead on the requested surface desc in the auto depth stencil creation callback. Mind you, this auto depth stencil creation isn't used nowadays any more, it was needed earlier to prevent wined3d from crashing. You can remove the function body and replace it by an ERR entirely I think, it shouldn't be called if everything works correctly in wined3d.

1 0

A wine success story
by Dan Kegel Dec. 18, 2006

Dec. 18, 2006

I admit, I cruise new blog posts just to see what people are writing about Wine. Today I saw one ( http://www.ubuntux.org/shockwave-player-ubuntu-linux ) that says "I have discovered a way to get Shockwave working under Linux. I am using Ubuntu 6.06 (Dapper Drake), Wine 0.99.22, Firefox 1.5.0.7, and Shockwave 10.1.4.020. 1. Install Wine. ... Wine will automatically associate .exe files with itself. More information on Wine is available at http://www.winehq.com . 2. Download the Windows version of Firefox and install. Wine will ensure the installer functions correctly. 3. Install the Windows version of Shockwave for Mozilla. I downloaded and installed it manually (slim install). After these steps, I had a working Shockwave player from within Firefox. " Now that's the kind of user story I like to see! - Dan

7 8

Re: WineD3D: paletted texture emulation using fragment shaders
by Frank Richter Dec. 17, 2006

Dec. 17, 2006

On 16.12.2006 22:24, Roderick Colenbrander wrote: > + "MUL index.x, index.x, constants.x;\n" /* Scale the index by 255/256 */ > + "ADD index.x, index.x, constants.y;\n" /* Add a bias of '0.5' in order to sample in the middle */ FWIW, this can be conflated to "MAD index.x, index.x, constants.x, constants.y;". -f.r.

1 0

usp10/tests: Testing of EnumLanguageGroupLocalesA
by Paul Vriens Dec. 17, 2006

Dec. 17, 2006

Hi, usp10/tests/usp10.c contains a test for EnumLanguageGroupLocalesA. The test that uses this function is not using any other functions. EnumLanguageGroupLocalesA is a kernel32 function and Win98 and NT4 don't have this function. The question now is should I change the usp10.c tests to check for the availability of EnumLanguageGroupLocalesA or just move the complete test to the kernel32 ones (where the availability is already tested). Cheers, Paul.

2 1

Re: WineD3D: paletted texture emulation using fragment shaders
by Chris Robinson Dec. 17, 2006

Dec. 17, 2006

On Saturday 16 December 2006 13:24, Roderick Colenbrander wrote: > Hi, > > This patch adds 8-bit paletted texture emulation support using a fragment > shader. Won't this break for programs that attempt to use paletted textures and fragment shaders itself? If you need to emulate paletted textures, IMHO, a better option would be to hold the palette and 8-bit image in RAM, and just convert it to RGB(A) when either's changed. Though hardware has dropped native support for paletted textures, so, also IMHO, that should be done on the ddraw side, instead of making all d3d apps think paletted textures are available.

3 3

Re: [1] WineD3D: Add the state dirtification infrastructure
by Stefan Dösinger Dec. 17, 2006

Dec. 17, 2006

Am Freitag 15 Dezember 2006 18:31 schrieb Stefan Dösinger: > This patch adds the dirty list infrastructure. A dirty marker consists of a > DWORD containing the state it marks dirty, and the list structure to build > the list. > > The wined3ddevice has 3 new members: > dirtyStateList: The list of dirty states. This will be moved to a > per-context stucture once we add multithreading support > freeListElems: A list containing unused dirty markers to avoid unnecessary > HeapAlloc/HeapFree calls. I have seen D3D games spending 15% cpu time in > the Heap code, we don't want to increase that. > dirtyStates: An array that tells if a state is dirty. It is used to avoid > double dirtification. I do not use the stateblock->changed.XXXX[] array > because this is used for different purposes in the stateblock code. Ivan, > do we still need it? Vitaly asked me on irc why I use a linked list instead of an array or bitmap. Well, my original plan was indeed an array, but after discussing it with Henri I decided to got for a list. See http://www.winehq.org/pipermail/wine-devel/2006-October/051868.html and following posts. The main arguments for a list were: * The shader constant code uses it too. It keeps the code somewhat simmilar * memory usage. An array has a fixed sizeof(DWORD) * STATE_HIGHEST mem usage, while a list has sizeof(DWORD) + 2*sizeof(void *) * number of dirty states memory usage. well, that was the idea In fact, the initial dirtification kills the memory usage argument. However, instead of dirtifying all the elements I could set the recording flag in the device on before initializing the initial stateblock and later apply the states instead of dirtifying them. When there are multiple contexts those can share the list of the free dirty markers. The way dirtification is done and the rest of the code are independent from each other, so it can be changed easilly when we decide to do so. I prefer to get the state management running first, and then move the initial opengl setup to Init3D().

2 2

Re: winsock.h undefined symbols ___wine_ulong_swap ___wine_ushort_swap
by Pierre d'Herbemont Dec. 16, 2006

Dec. 16, 2006

> Pierre's fix regarding use of hton and ntoh functions on Big Endian > when including from winsock2.h did not > completely resolve compilation errors. Sanjay, it did fix the compilation error, but it seems, looking at your diff, that you're wine sources are mangled : you have mixed the first patch and the second one that were sent to wine-patches. > diff -urN /Darwine/winesrc/wine-0.9.27/include/winsock.h /Darwine/ > winesrc/wine-0.9.27_compiled/include/winsock.h > --- /Darwine/winesrc/wine-0.9.27/include/winsock.h 2006-12-08 > 16:34:42.000000000 -0500 > +++ /Darwine/winesrc/wine-0.9.27_compiled/include/winsock.h > 2006-12-15 16:14:59.000000000 -0500 > @@ -516,12 +516,14 @@ Looking at the way you diff, I think you shouldn't send your patch against version release, git [1] would be more appropriate, and won't have let you send a patch that cannot be applied. [1] http://www.winehq.org/site/git http://www.winehq.org/site/sending_patches Pierre.

1 0

Re: setupapi: add SPFILENOTIFY_TARGETNEWER support to SetupDefaultQueueCallback
by Alexandre Julliard Dec. 16, 2006

Dec. 16, 2006

Robert Reif <reif(a)earthlink.net> writes: > Index: dlls/setupapi/queue.c > =================================================================== > RCS file: /home/wine/wine/dlls/setupapi/queue.c,v > retrieving revision 1.24 > diff -p -u -r1.24 queue.c > --- dlls/setupapi/queue.c 14 Nov 2006 11:15:45 -0000 1.24 > +++ dlls/setupapi/queue.c 15 Dec 2006 16:38:56 -0000 > @@ -1379,6 +1379,28 @@ UINT WINAPI SetupDefaultQueueCallbackA( > case SPFILENOTIFY_NEEDMEDIA: > TRACE( "need media\n" ); > return FILEOP_SKIP; > + case SPFILENOTIFY_TARGETNEWER: > + TRACE( "target newer? Source: %s Target: %s\n", > + debugstr_a(paths->Source), debugstr_a(paths->Target) ); > + { > + WIN32_FILE_ATTRIBUTE_DATA Source, Target; > + > + if (GetFileAttributesExA(paths->Source, GetFileExInfoStandard, &Source)) > + { > + if (GetFileAttributesExA(paths->Target, GetFileExInfoStandard, &Target)) > + { > + TRACE( "Target = 0x%08x%08x, Source = 0x%08x%08x\n", > + Target.ftCreationTime.dwHighDateTime, Target.ftCreationTime.dwLowDateTime, > + Source.ftCreationTime.dwHighDateTime, Source.ftCreationTime.dwLowDateTime ); > + > + if (CompareFileTime(&Target.ftCreationTime, &Source.ftCreationTime) == 1) > + return TRUE; > + > + return FALSE; > + } > + } > + } That doesn't make sense to me. At this point the file is known to be newer from the version info, why would you want to check creation time and overwrite a newer file? -- Alexandre Julliard julliard(a)winehq.org

1 0

Call to all packagers (especially Debian)
by Vitaliy Margolen Dec. 16, 2006

Dec. 16, 2006

It seems there is no end to how far will packagers go to brake Wine by trying to make it better I thought it's been fixed a long time ago, but it seems not. Wine packages for Debian split important Wine parts into separate packages: - wine - fonts, few not essential programs, symlinks and _premade_ content of ~/.wine directory (with ~/.wine/c as default c: drive)!!! - libwine - all the builtin dlls - wine-utils:(explorer, winecfg, winepath, cmd.exe, iexplore, winedbg) and many other packages. Also as default it's using "winelauncher" instead of standard "wine" binary. That makes it that much more complicated to troubleshoot any problems that users might have. So in case anyone having problems with Debian or Debian based distro, please check that all the "*wine*" packages installed. Also is there a way we can request packagers to follow some standard to how they package Wine? Can we ask packagers to package all parts of Wine into one single package? If they prefer, they can package optional sound drivers separately (arts, esd, jack, nas). Same for documentation, and development headers. However everything else is essential to Wine and most programs that ran under it. Also can packagers keep default method of starting Wine the same without using any additional scripts for starting Wine? And of course, if any alterations has been made, state so in the distro specific readme file. Of course I realize that this is open source and anyone can do whatever they pleased. But please, that's make it more supportable. It's such a huge PITA to waste several hours trying to find the reason why something doesn't work to realize that person doesn't have explorer. Needless to say that lots of things won't work right. Vitaliy.

6 6

Cast-qual warnings: current status
by Andrew Talbot Dec. 16, 2006

Dec. 16, 2006

Hi, Apart from any oversights, I have completed my run of cast-qual fixes for the "dlls" and "dlls/tests" directories. The one file that most distorts the picture when -Wcast-qual is applied is "unicode.h", since its wide-string functions are inlined and it is included quite widely. I have posted a patch (dated 16 Dec 2006, entitled "include: Cast-qual warnings fix using const_cast macro") that, if not accepted, you can apply locally, if you want to build with "-Wcast-qual" to see the extent of the remaining problem. For the places where we still must use casts, I propose the introduction of a macro that takes on the role of the "const_cast" in C++. My attempt at that is as follows. #ifdef __cplusplus #define const_cast(t, e) const_cast<t>(e) #else #define const_cast(t, e) (t)(ULONG_PTR)(e) #endif This will make its purpose stand out from those of other casts. So, for example, the definition of strchrW() would become: extern inline WCHAR *strchrW( const WCHAR *str, WCHAR ch ) { do { if (*str == ch) return const_cast(WCHAR *, str); } while (*str++); return NULL; } The positive point of aiming to add -Wcast-qual universally - I would argue - is that it lets the compiler watch out for inadvertent introductions of fresh violations, so I become redundant, and you proper programmers can concentrate on more interesting things. :) I invite you, please, to debate the above issues, so we can determine the way forward concerning this issue. Meanwhile, I shall move on to the few "programs" and "server" files that generate cast-qual warnings. Thanks, -- Andy.

1 0

Re: [5/5] usp10: remote todo_wine
by James Hawkins Dec. 15, 2006

Dec. 15, 2006

On 12/14/06, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > Hi, > > Part 5 of 5. > Remove many todo_wine's from the tests, now that the functions are > implemented. > You have to remove the todo_wine's in the same patch that fixes the tests, or the tests will fail for at least one commit. Patches have to be atomic and error free, and a failing test is an error. -- James Hawkins

3 4

Re: [AppDB] Add generic sound help (resend)
by Chris Morgan Dec. 15, 2006

Dec. 15, 2006

Is it ok if we link to this entry in the Wine documentation instead: http://winehq.org/site/docs/wineusr-guide/config-wine-main#AEN282 Chris On Friday 15 December 2006 12:27 pm, Alexander Nicolaysen Sørnes wrote: > (I assume this was overlooked.) > > Add a paragraph about sound problems on the bottom of the generic help page > (as most sound problem reports are due to incorrect configurations). > > Also update the outdated usage of --debugmsg. > > > Regards, > > Alexander N. Sørnes

1 0

Re: msi: Enable cab compression and delete any resulting cabs using SHFileOperation
by Alexandre Julliard Dec. 15, 2006

Dec. 15, 2006

"James Hawkins" <truiken(a)gmail.com> writes: > +static void delete_cab_files(void) > +{ > + SHFILEOPSTRUCT shfl; > + CHAR path[MAX_PATH]; > + > + lstrcpyA(path, CURR_DIR); > + lstrcatA(path, "\\*.cab\0"); > + > + shfl.hwnd = NULL; > + shfl.wFunc = FO_DELETE; > + shfl.pFrom = (LPCSTR)path; > + shfl.pTo = NULL; > + shfl.fFlags = FOF_FILESONLY | FOF_NOCONFIRMATION | FOF_NORECURSION | FOF_SILENT; > + > + SHFileOperation(&shfl); > +} If you are going to delete files with wildcards, you need to create a temp dir and do everything inside it, otherwise you risk deleting files that are not part of the test. -- Alexandre Julliard julliard(a)winehq.org

1 0