February 2007 - Wine-Devel - list.winehq.org

Re: wininet: Improve FtpOpenFile()'s parameter checking and remove the corresponding todo_wines.
by Paul Vriens Feb. 16, 2007

Feb. 16, 2007

Francois Gouget wrote: > Also make test_getfile_no_open() succeed on Windows 98. > --- > > I have had some strange results with these tests. One of them was > actually succeeding in a todo_wine for a good while. > > dlls/wininet/ftp.c | 12 +++++++++++- > dlls/wininet/tests/ftp.c | 12 +++--------- > 2 files changed, 14 insertions(+), 10 deletions(-) > This was the last one for now on my list, you beat me to it. We do have some conflicting patches now in wine-patches. > diff --git a/dlls/wininet/ftp.c b/dlls/wininet/ftp.c > index 5b073cf..2bd29fd 100644 > --- a/dlls/wininet/ftp.c > +++ b/dlls/wininet/ftp.c > @@ -1011,11 +1011,21 @@ HINTERNET WINAPI FtpOpenFileW(HINTERNET hFtpSession, > debugstr_w(lpszFileName), fdwAccess, dwFlags, dwContext); > > lpwfs = (LPWININETFTPSESSIONW) WININET_GetObject( hFtpSession ); > - if (NULL == lpwfs || WH_HFTPSESSION != lpwfs->hdr.htype) > + if (NULL == lpwfs) > + { > + INTERNET_SetLastError(ERROR_INTERNET_NOT_INITIALIZED); > + goto lend; Why do a 'goto lend' you could just 'return FALSE' like I did in the other ftp functions. No need do another check for lpwfs being NULL. If you do a 'return FALSE' you could also get rid of the check for lpwfs being NULL right after lend:. > + } > + if (WH_HFTPSESSION != lpwfs->hdr.htype) > { > INTERNET_SetLastError(ERROR_INTERNET_INCORRECT_HANDLE_TYPE); > goto lend; > } > + if (dwFlags & ~(INTERNET_FLAGS_MASK|FTP_TRANSFER_TYPE_MASK)) > + { > + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); > + goto lend; > + } I think this covers the 5 in the test but not all possible combinations. I did some (loop) testing with dwFlags (also used in FtpGetFile and FtpPutFile) and it appears all boils down to the last 3 bits (see FtpGetFile). Cheers, Paul.

1 0

Re: [7/10] WineD3D: Test for supported queries
by Juan Lang Feb. 16, 2007

Feb. 16, 2007

Hi Stefan, + hr = IDirect3D9_CreateDevice( pD3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hwnd, + D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, &pDevice ); + ok(SUCCEEDED(hr), "Failed to create IDirect3D9Device (%s)\n", DXGetErrorString9(hr)); + if (FAILED(hr)) goto cleanup; (snip) + cleanup: + if(pDevice) IDirect3DDevice9_Release(pDevice); The label cleanup isn't used anywhere except in the failure to create the device. In this case, wouldn't: if (FAILED(hr)) return; be clearer, and omit the unneeded label? There's no reason to release pDevice in creating it failed. --Juan ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

2 1

DIB Engine, some summarization
by Rolf Kalbermatter Feb. 16, 2007

Feb. 16, 2007

This is getting a bit long so if you do not have time, then skip this. I've looked a little more at the issue of a DIB Engine and tried to use the feedback so far to get an idea what the possible architecture could be. First I took a look at how Windows seems to do it currently (excluding Vista). There GDI32 is mostly a wrapper around win32k.sys and the different GDI APIs call mostly into corresponding NtGdi... functions in win32k.sys. Those functions do the actual handling and call the according driver that is attached to the DC. The interface to the driver is similar to what is done now in Wine although not identical. The modern Windows display driver interface uses sometimes more or less different functions than the old one as used in Wine. A driver can either not implement certain functions, only implement them for its device specific surfaces, or hook certain calls by returning flags inside the driver initialization structure on initialization. Those hook flags tell the GDI engine that the driver wants to be called for DIB surfaces too for particular functions and bit depths. The driver will then be called for according DIB surfaces too and it can decide to do whatever it can do best and for those cases it doesn't know well how to do it, call back into the GDI engine using an according Eng... function. This calling back into the GDI engine for hooked functions is called punting by MS. If the driver didn't provide the actual function it will possibly be simulated by the GDI engine by calling other driver functions and if the driver didn't hook the function or didn't succeed and it is for a DIB surface then the GDI engine itself will call the according Eng... function. GDI32 exports most of those Eng... functions too but that are simply user space wrappers around the win32k.sys entry points for those functions. >From a design view it might be interesting to separate the actual GDI engine into a subpart that corresponds with the NtGdi... functions in win32k.sys eventhough they might stay inside GDI32 for the time being. The actual Eng... functions would be also placed inside that GDI engine and are in fact mostly the long awaited DIB engine. Such an architecture would make reuse of such a GDI32/win32k combo in other projects fairly easy. However this NtGdi API is not documented although it is presumably mostly a mirror of the GDI API. There are lists of what APIs win32k.sys does export and how many parameters each of these functions takes, extracted from the actual win32k.sys file. Eventhough Windows keeps them in the win32k.sys kernel I think it would be a good idea to keep them all in GDI32 for the time being. If that API is at some time mostly complete and separation into its own DLL or something would be desired, this could be done quite easily. But it is certainly quite a bit tedious to do and would require at least partly some sort of clean room reverse engineering and it's not really necessary for a DIB engine at all at this point. There is a little problem with those Eng.. functions however. They are modeled after the new NT display driver interface that is in so far different that it does use partly different functions and parameters to the old (I assume Win 3.1 display driver) interface used in Wine and this is even more or less all documented in the DDK, although the basic principle between the Windows driver interface and what Wine does is of course mostly the same. I can't really see however how it would be possible to change that interface to match the modern NT display driver interface in a seemless manner as it would mean a significant change in winex11.drv, winequartz.drv and the GDI32 (aka win32k.sys) that would need to be done mostly in a few big chunks to not completly break everything. So what would remain is adding the actual Eng... and object access API to GDI. These APIs are (all?) documented in the DDK and could be implemented based on MSDN information alone together with maybe some test cases. The actual driver interface might remain mostly the same as it is now with some extra addition to return to the GDI engine extra flags to indicate hooks for DIB surfaces. Then implementation of the Eng... functions would have to start and as they are fleshed out and work they get integrated into the calling logic one for one. Until this is completely done the current separations for DIBs into appstate and serverstate would have to remain, so that the X11 driver can still pass them to the X11 server for rendering of not implemented DIB engine operations. Once the DIB engine is finished (if ever :-) this could be removed as the X11 driver would not anymore hook any of the DIB operations. If winequartz.drv wants to continue hooking DIB operations it can do so of course. To start with, the actual header winddi.h defining most of the Eng.. calls could be added as ddk header to Wine. There seems to be a copyright free version of this header file from Casper S. Hornstrup that is part of the w32api package. I have thought about modifying the driver function call array instead as Alexandre has pointed out in the past as possible solution instead of adding the actual Eng... calls explicitedly into the GDI engine as fall back. But this seems not a good solution to me. The driver wants to be informed of graphic operations for device specific surfaces most often I would assume and only might want to not get called for device contexts containing a dib section. And as some have pointed out winequartz may even want to get called for DIBs too. In order to allow for such a dynamic overriding of function pointers in the driver function array, that array would have to be allocated dynamically on a device context base and I think this would make everything slower, more memory consuming and it wouldn't really be easier although I admit that adding Eng.. calls everywhere and correctly is quite some work to do. The issue about network transparency for the display driver would not be an issue IMO. Once complete the DIB engine would handle all DIB operations locally and so no need for translating direct memory access into remote calls to some display server would be necessary. And the blitting of DIBs to the display when necessary would still be done through the driver of course so everything would be transparent as far as the capabilities of the used display device itself allow for that. Rolf Kalbermatter

5 6

regression in 613998d4f6ff953a22a4455a28f77d2126642c7d
by Marcus Meissner Feb. 16, 2007

Feb. 16, 2007

Hi Shanren, your commit 613998d4f6ff953a22a4455a28f77d2126642c7d Author: Shanren Zhou <shanren(a)ucla.edu> Date: Mon Feb 12 19:53:51 2007 -0800 comctl32: Add header tests. generates a Coverity Warning in this code: ... HIMAGELIST hImageList; HIMAGELIST hImageListRetVal; hImageListRetVal = (HIMAGELIST) SendMessage(hWndHeader, HDM_SETIMAGELIST, 0, (LPARAM) &hImageList); HDM_SETIMAGELISTs parameter is used and stored, so hImageList should be: - initialized to something (likely 0 is ok, didnt check) - and not a pointer (did you add the & just to kill the warning?) Ciao, Marcus

1 0

Re: [1/4] wined3d: Fix WINED3DPRESENT_PARAMETERS and use it instead of D3DPRESENT_PARAMETERS
by Duane Clark Feb. 15, 2007

Feb. 15, 2007

H. Verbeet wrote: > It looks like the patch might be a bit large for the list, here's a > compressed version instead. > Anything over 80K just gets caught in the mail queue. It should get through eventually.

1 0

Office 2007 help wine
by Keith H. Pratt Feb. 15, 2007

Feb. 15, 2007

Hi, I went to a Microsoft Launch for their enterprise and business products this past tuesday, and they gave me a full version of Office 2007 Professional. Nice of them huh. Well, I am a linux user, and an avid evangelist for open source, and for anything that lets thw linux and windows world work together. I also have spent a considerable amount of time testing and bug reporting beta software. With all that said, here's my point. What can I do with this software to help you in the testing and development of wine? I run a dual-boot system with winxp and ubuntu linux. linux is where i work, and windows is there to make it easier to support my clients in their windows machines. If theres nothing now that applies to wine and office 2007, maybe keep this message for when the need does arise. Thanks Keith

2 1

Re: [PATCH 6/6] kernel32: Fix the GetComputerName* functions to not write to the buffer at all if there is not enough space.
by Alexandre Julliard Feb. 15, 2007

Feb. 15, 2007

Robert Shearman <rob(a)codeweavers.com> writes: > Remove the exception handlers, since testing on XP SP2 shows that > access violations are not caught. Yes, but they are caught on Win9x, and the handler was added because an app needed it. I'd suggest to keep it at least in the A function. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Symbol encoding should be always selectable
by Dmitry Timoshkov Feb. 15, 2007

Feb. 15, 2007

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: > this patch fixes a failure in the font charset test in the case when > only Arial is installed. As the test shows the symbol encoding should be > always selectable. Please do not commit this patch, it's wrong. According to GetTextFace XP selects Wingdings if SYMBOL_CHARSET was requested. I'm not sure how to make the test pass: probably SYMBOL_CHARSET should be skipped if Symbol or Wingdings are not installed. -- Dmitry.

1 0

WINSPOOL: search for a printer driver
by Vitaly Lipatov Feb. 15, 2007

Feb. 15, 2007

When wine is loading, CUPS_LoadPrinters function get printer list from CUPS and add printer and their printer drivers to registry. If printer is already exist, we do not override nor printer driver, nor printer entry. It all works fine. Note, we place printer driver in "Windows 4.0" registry entry if Wine version is win9x and use "Windows NT x86" registry entry if Wine version is win2000 and above. If we will change wine version after printer loaded, Wine printing is got failed. Wine search in empty registry entry. For example, I get such configuration after run wine in win98 mode: [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows 4.0\\Drivers\\hp] 1171461136 "Configuration File"="wineps16" "Data File"="<datafile?>" "Datatype"="RAW" "Dependent Files"=str(7):"<dependent files?>\0" "Driver"="wineps16" "Help File"="<helpfile?>" "Monitor"="<monitor name?>" "Version"=dword:00000000 [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows NT x86\\Drivers\\Version-3] 1171461821 [System\\CurrentControlSet\\Control\\Print\\Printers\\hp] 1171461818 "Attributes"=dword:00000000 "Datatype"="RAW" "Default DevMode"=hex:68,70,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ ... "Description"="WINEPS Printer using CUPS" "Location"="<physical location of printer>" "Name"="hp" "Parameters"="<parameters?>" "Port"="LPR:hp" "Print Processor"="WinPrint" "Printer Driver"="hp" ... I try to find a better way to resolve this problem. Some ideas: 1. Check if Wine version is changed and reset printer drivers. 2. Search in both registry entry in any way. 3. ... -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Direct Draw "palette_convert"
by Nathan Williams Feb. 15, 2007

Feb. 15, 2007

I'm working on some direct draw code to get Carmageddon working. I think I have found my issue in IWineD3DPaletteImpl_SetEntries Carmageddon runs in 8 bit mode, my x windows is set at 24bit. If I drop xorg to 8bit, wine refuses to load. If i set it to 16bit, the Carmageddon menus are still bad, but noticeably better then running in 24bit. In SetEntries there is a bit of code idef'd out: #if 0 /* Now, if we are in 'depth conversion mode', update the screen palette */ /* FIXME: we need to update the image or we won't get palette fading. */ if (This->ddraw->d->palette_convert != NULL) This->ddraw->d->palette_convert(palent,This->screen_palents,start,count); #endif Uncommenting the above only leads to compile errors. Dredging through the wine archives, I see that the palette convert functions haven't been there since 2000. Can anyone give me an idea on why they were removed & what might be the best way to reimplement some form of palette conversion? (Even just in a hacky way right now, so i can test my assumptions) -- Nathan

4 4

avifil32: sign-compare fixes
by Joris Huizer Feb. 15, 2007

Feb. 15, 2007

Hello As the previous time I was inserting too many casts, I want to ask whether this approach is better (introducing an ULONG version if it fixes compare warnings, and casting away remaining problems) If this is not alright, could you tell what's the best way to fix? regards, Joris ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/

1 0

Re: [05/10] wined3d: Add WINED3DTEXOPCAPS flags and use them
by Alexandre Julliard Feb. 15, 2007

Feb. 15, 2007

"H. Verbeet" <hverbeet(a)gmail.com> writes: > diff --git a/include/wine/wined3d_caps.h b/include/wine/wined3d_caps.h > new file mode 100644 > index 0000000..4bf474b > --- /dev/null > +++ b/include/wine/wined3d_caps.h > @@ -0,0 +1,49 @@ > +/* > + * Copyright 2007 Henri Verbeet > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#ifndef __WINE_WINED3D_CAPS_H > +#define __WINE_WINED3D_CAPS_H > + > +#define WINED3DTEXOPCAPS_DISABLE 0x00000001 > +#define WINED3DTEXOPCAPS_SELECTARG1 0x00000002 > +#define WINED3DTEXOPCAPS_SELECTARG2 0x00000004 > +#define WINED3DTEXOPCAPS_MODULATE 0x00000008 > +#define WINED3DTEXOPCAPS_MODULATE2X 0x00000010 > +#define WINED3DTEXOPCAPS_MODULATE4X 0x00000020 > +#define WINED3DTEXOPCAPS_ADD 0x00000040 > +#define WINED3DTEXOPCAPS_ADDSIGNED 0x00000080 > +#define WINED3DTEXOPCAPS_ADDSIGNED2X 0x00000100 > +#define WINED3DTEXOPCAPS_SUBTRACT 0x00000200 > +#define WINED3DTEXOPCAPS_ADDSMOOTH 0x00000400 > +#define WINED3DTEXOPCAPS_BLENDDIFFUSEALPHA 0x00000800 > +#define WINED3DTEXOPCAPS_BLENDTEXTUREALPHA 0x00001000 > +#define WINED3DTEXOPCAPS_BLENDFACTORALPHA 0x00002000 > +#define WINED3DTEXOPCAPS_BLENDTEXTUREALPHAPM 0x00004000 > +#define WINED3DTEXOPCAPS_BLENDCURRENTALPHA 0x00008000 > +#define WINED3DTEXOPCAPS_PREMODULATE 0x00010000 > +#define WINED3DTEXOPCAPS_MODULATEALPHA_ADDCOLOR 0x00020000 > +#define WINED3DTEXOPCAPS_MODULATECOLOR_ADDALPHA 0x00040000 > +#define WINED3DTEXOPCAPS_MODULATEINVALPHA_ADDCOLOR 0x00080000 > +#define WINED3DTEXOPCAPS_MODULATEINVCOLOR_ADDALPHA 0x00100000 > +#define WINED3DTEXOPCAPS_BUMPENVMAP 0x00200000 > +#define WINED3DTEXOPCAPS_BUMPENVMAPLUMINANCE 0x00400000 > +#define WINED3DTEXOPCAPS_DOTPRODUCT3 0x00800000 > +#define WINED3DTEXOPCAPS_MULTIPLYADD 0x01000000 > +#define WINED3DTEXOPCAPS_LERP 0x02000000 > + > +#endif /* __WINE_WINED3D_CAPS_H */ I think this could just as well go into an existing file like wined3d_types.h. We should try to keep the number of Wine-specific global includes to a minimum. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [4/10] WineD3D: Convert and load U8V8 surfaces as rgb
by Stefan Dösinger Feb. 15, 2007

Feb. 15, 2007

Am Donnerstag 15 Februar 2007 09:50 schrieb H. Verbeet: > On 15/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > GL_INDEX is definitly not the way to load U8V8 surfaces > > I think you should be using something like GL_DU8DV8_ATI or GL_DSDT_NV > instead. Thats my plan, but I think we should handle it in some way if none of the extensions is available. We can later use the extension-specific formats if they are available.

1 0

Re: [10/10] DDraw: Forward D3DRS_TEXTUREADDRESS* and D3DTSS_ADDRESS* to sampler states
by Stefan Dösinger Feb. 15, 2007

Feb. 15, 2007

Am Donnerstag 15 Februar 2007 09:51 schrieb H. Verbeet: > On 15/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > >+ case D3DTSS_ADDRESS: > >+ return IWineD3DDevice_GetSamplerState(This->wineD3DDevice, > >+ Stage, > >+ WINED3DSAMP_ADDRESSW, > >+ State); > > Is that correct? Hm. No, it isn't. I thought I fixed that sort of things. Maybe an old version of the patch got sent NULL

1 0

Regression in comctl32
by Pavel Troller Feb. 15, 2007

Feb. 15, 2007

Hi! I just found a regression in comctl32 and bisected it successfully. The following commit 369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit commit 369749dcb2ba12ce8481503543afd18ad99805d1 Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> Date: Mon Feb 12 16:47:56 2007 +0800 comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code. :040000 040000 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M dlls causes that IDA Pro shows black squares instead of its toolbar icons. With regards, Pavel Troller

3 2

Re: [07/10] wined3d: Add WINED3DPBLENDCAPS flags and use them
by Mirek Feb. 15, 2007

Feb. 15, 2007

Hi, this patch has bad attachment, it has same attachment as "[08/10] wined3d: Add WINED3DPMISCCAPS flags and use them". Mirek Slugen H. Verbeet napsal(a): > Changelog: > - Add WINED3DPBLENDCAPS flags and use them > > > ------------------------------------------------------------------------ > > --- > > dlls/wined3d/directx.c | 34 +++++++++++++++++----------------- > include/wine/wined3d_caps.h | 19 +++++++++++++++++++ > 2 files changed, 36 insertions(+), 17 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 1753ef9..cc1e0f6 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -1872,29 +1872,29 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > WINED3DDEVCAPS_DRAWPRIMITIVES2 | > WINED3DDEVCAPS_DRAWPRIMITIVES2EX; > > - *pCaps->PrimitiveMiscCaps = D3DPMISCCAPS_CULLNONE | > - D3DPMISCCAPS_CULLCCW | > - D3DPMISCCAPS_CULLCW | > - D3DPMISCCAPS_COLORWRITEENABLE | > - D3DPMISCCAPS_CLIPTLVERTS | > - D3DPMISCCAPS_CLIPPLANESCALEDPOINTS | > - D3DPMISCCAPS_MASKZ | > - D3DPMISCCAPS_BLENDOP; > + *pCaps->PrimitiveMiscCaps = WINED3DPMISCCAPS_CULLNONE | > + WINED3DPMISCCAPS_CULLCCW | > + WINED3DPMISCCAPS_CULLCW | > + WINED3DPMISCCAPS_COLORWRITEENABLE | > + WINED3DPMISCCAPS_CLIPTLVERTS | > + WINED3DPMISCCAPS_CLIPPLANESCALEDPOINTS | > + WINED3DPMISCCAPS_MASKZ | > + WINED3DPMISCCAPS_BLENDOP; > /* TODO: > - D3DPMISCCAPS_NULLREFERENCE > - D3DPMISCCAPS_INDEPENDENTWRITEMASKS > - D3DPMISCCAPS_FOGANDSPECULARALPHA > - D3DPMISCCAPS_SEPARATEALPHABLEND > - D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS > - D3DPMISCCAPS_MRTPOSTPIXELSHADERBLENDING > - D3DPMISCCAPS_FOGVERTEXCLAMPED */ > + WINED3DPMISCCAPS_NULLREFERENCE > + WINED3DPMISCCAPS_INDEPENDENTWRITEMASKS > + WINED3DPMISCCAPS_FOGANDSPECULARALPHA > + WINED3DPMISCCAPS_SEPARATEALPHABLEND > + WINED3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS > + WINED3DPMISCCAPS_MRTPOSTPIXELSHADERBLENDING > + WINED3DPMISCCAPS_FOGVERTEXCLAMPED */ > > /* The caps below can be supported but aren't handled yet in utils.c 'd3dta_to_combiner_input', disable them until support is fixed */ > #if 0 > if (GL_SUPPORT(NV_REGISTER_COMBINERS)) > - *pCaps->PrimitiveMiscCaps |= D3DPMISCCAPS_TSSARGTEMP; > + *pCaps->PrimitiveMiscCaps |= WINED3DPMISCCAPS_TSSARGTEMP; > if (GL_SUPPORT(NV_REGISTER_COMBINERS2)) > - *pCaps->PrimitiveMiscCaps |= D3DPMISCCAPS_PERSTAGECONSTANT; > + *pCaps->PrimitiveMiscCaps |= WINED3DPMISCCAPS_PERSTAGECONSTANT; > #endif > > *pCaps->RasterCaps = WINED3DPRASTERCAPS_DITHER | > diff --git a/include/wine/wined3d_caps.h b/include/wine/wined3d_caps.h > index 1cedae7..98a655d 100644 > --- a/include/wine/wined3d_caps.h > +++ b/include/wine/wined3d_caps.h > @@ -34,6 +34,25 @@ > #define WINED3DPBLENDCAPS_BOTHINVSRCALPHA 0x00001000 > #define WINED3DPBLENDCAPS_BLENDFACTOR 0x00002000 > > +#define WINED3DPMISCCAPS_MASKZ 0x00000002 > +#define WINED3DPMISCCAPS_LINEPATTERNREP 0x00000004 > +#define WINED3DPMISCCAPS_CULLNONE 0x00000010 > +#define WINED3DPMISCCAPS_CULLCW 0x00000020 > +#define WINED3DPMISCCAPS_CULLCCW 0x00000040 > +#define WINED3DPMISCCAPS_COLORWRITEENABLE 0x00000080 > +#define WINED3DPMISCCAPS_CLIPPLANESCALEDPOINTS 0x00000100 > +#define WINED3DPMISCCAPS_CLIPTLVERTS 0x00000200 > +#define WINED3DPMISCCAPS_TSSARGTEMP 0x00000400 > +#define WINED3DPMISCCAPS_BLENDOP 0x00000800 > +#define WINED3DPMISCCAPS_NULLREFERENCE 0x00001000 > +#define WINED3DPMISCCAPS_INDEPENDENTWRITEMASKS 0x00004000 > +#define WINED3DPMISCCAPS_PERSTAGECONSTANT 0x00008000 > +#define WINED3DPMISCCAPS_FOGANDSPECULARALPHA 0x00010000 > +#define WINED3DPMISCCAPS_SEPARATEALPHABLEND 0x00020000 > +#define WINED3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS 0x00040000 > +#define WINED3DPMISCCAPS_MRTPOSTPIXELSHADERBLENDING 0x00080000 > +#define WINED3DPMISCCAPS_FOGVERTEXCLAMPED 0x00100000 > + > #define WINED3DSTENCILCAPS_KEEP 0x00000001 > #define WINED3DSTENCILCAPS_ZERO 0x00000002 > #define WINED3DSTENCILCAPS_REPLACE 0x00000004 > > > ------------------------------------------------------------------------ > >

1 0

wineboot: Start items in StartUp folder on boot, includes security measures.
by Misha Koshelev Feb. 15, 2007

Feb. 15, 2007

Hi everybody, Thanks for your suggestions. I just posted a new patch on wine-patches where I tried to incorporate these and now it does the following (in addition to my previous patch which just started items in the StartUp folder): - When wineboot finds a file that it wants to start in the StartUp folder, it asks the user whether he wants to run the program. His options are: Always, Yes, No (default), and Never. - If he selects Yes the program is run, if he select No it is not. - If he selects Always or Never, I create a registry key in: HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname of the program and the value "always" or "never." When wineboot sees this program in the StartUp folder it checks this key, and if it is set it performs the appropriate action. What do you guys think? If you like the system, it would be pretty easy to incorporate this into the run key running as well (which are currently just run without any user confirmation)? Thanks Misha p.s. please please please anyone who is familiar with IShellFolder if you could look over those parts and just say yes it looks good that would make me feel better. I think it is correct but really an expert's opinion would be great.

8 15

Re: [cmd][try3] Update Russian translate (edited) [Really sorry!!]
by Detlef Riekenberg Feb. 15, 2007

Feb. 15, 2007

On Mi, 2007-02-14 at 15:16 +0300, Anatoly Lyutin wrote: > - HELP <> .\n" > + HELP <> .\n\ > + DOS http://www.citforum.ru/operating_systems/msdos/\n" > } That link is wrong in wine. Please remove from your Patch -- By by ... Detlef

2 1

Re: [Janitorial] snmpapi: Remove the last-but-one %ll printf format
by Detlef Riekenberg Feb. 14, 2007

Feb. 14, 2007

On Mi, 2007-02-14 at 15:27 -0200, Pedro Araujo Chaves Jr. wrote: > - TRACE("Counter64 %llu\n", any->asnValue.counter64.QuadPart); > + TRACE("Counter64 %su\n", > wine_dbgstr_longlong(any->asnValue.counter64.QuadPart)); > return; Did you mean "%s" ? (used "%su") -- By by ... Detlef

1 0

Re: [1/10] - [10/10] WineD3D
by Mirek Feb. 14, 2007

Feb. 14, 2007

Wow, great work!!!!! 3DMark 2006 with fbo looks realy coool!! And some Nvidia SDK demos are completly fixed! Mirek Stefan Dösinger napsal(a): > > ------------------------------------------------------------------------ > > From c59f7c4eea148cfb9a1321bbbbc587ef52194bc9 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Fri, 2 Feb 2007 15:30:34 +0100 > Subject: [PATCH] WineD3D: Properly release the converted vertex declaration > > --- > dlls/d3d9/d3d9_private.h | 5 +++++ > dlls/d3d9/device.c | 3 +++ > dlls/d3d9/vertexdeclaration.c | 5 +++++ > 3 files changed, 13 insertions(+), 0 deletions(-) > > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > index 435a37e..972945d 100644 > --- a/dlls/d3d9/d3d9_private.h > +++ b/dlls/d3d9/d3d9_private.h > @@ -179,6 +179,11 @@ typedef struct IDirect3DDevice9Impl > /* Avoids recursion with nested ReleaseRef to 0 */ > BOOL inDestruction; > > + /* A vertex declaration was converted from setFVF. > + * Keep track of it, so it can be properly freed > + */ > + IDirect3DVertexDeclaration9 *convertedDecl; > + > } IDirect3DDevice9Impl; > > > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > index 4eff550..e6ecd96 100644 > --- a/dlls/d3d9/device.c > +++ b/dlls/d3d9/device.c > @@ -62,6 +62,8 @@ static ULONG WINAPI IDirect3DDevice9Impl_Release(LPDIRECT3DDEVICE9 iface) { > > if (ref == 0) { > This->inDestruction = TRUE; > + if (This->convertedDecl != NULL) > + IUnknown_Release(This->convertedDecl); > IWineD3DDevice_Uninit3D(This->WineD3DDevice, D3D9CB_DestroyDepthStencilSurface, D3D9CB_DestroySwapChain); > IWineD3DDevice_Release(This->WineD3DDevice); > HeapFree(GetProcessHeap(), 0, This); > @@ -766,6 +768,7 @@ HRESULT WINAPI IDirect3DDevice9Impl_SetFVF(LPDIRECT3DDEVICE9 iface, DWORD FVF) > > hr = IDirect3DDevice9Impl_SetVertexDeclaration(iface, pDecl); > if (hr != S_OK) goto exit; > + This->convertedDecl = pDecl; > pDecl = NULL; > > exit: > diff --git a/dlls/d3d9/vertexdeclaration.c b/dlls/d3d9/vertexdeclaration.c > index a7f5486..c3f462e 100644 > --- a/dlls/d3d9/vertexdeclaration.c > +++ b/dlls/d3d9/vertexdeclaration.c > @@ -360,6 +360,11 @@ HRESULT WINAPI IDirect3DDevice9Impl_SetVertexDeclaration(LPDIRECT3DDEVICE9 ifa > > TRACE("(%p) : Relay\n", iface); > > + if (This->convertedDecl && This->convertedDecl != pDecl) { > + IUnknown_Release(This->convertedDecl); > + This->convertedDecl = NULL; > + } > + > hr = IWineD3DDevice_SetVertexDeclaration(This->WineD3DDevice, pDeclImpl == NULL ? NULL : pDeclImpl->wineD3DVertexDeclaration); > > return hr; > > > ------------------------------------------------------------------------ > >

2 1

Re: [Janitorial] snmpapi: Remove the last-but-one %ll printf format
by Eric Pouech Feb. 14, 2007

Feb. 14, 2007

Pedro Araujo Chaves Jr. a écrit : > case ASN_COUNTER64: > { > - TRACE("Counter64 %llu\n", any->asnValue.counter64.QuadPart); > + TRACE("Counter64 %su\n", wine_dbgstr_longlong(any->asnValue.counter64.QuadPart)); > it should read %s\n"... A+

1 0

GPU performance counters, agp usage
by Stefan Dösinger Feb. 14, 2007

Feb. 14, 2007

Hi, I've had a look at various performance counters of my nvidia card with nvperfkit and nvperfgraph while running half-life 2. The first thing I noticed was that the gpu was approximately 75% to 90% idle, while one cpu core was 100% busy and the other completely idle. More to that later. The other interesting thing was that "OGL driver waiting" was at 100% and agp usage was beyond what nvperfgraph could show. This seems to happen with any application that uses opengl in wine, including very simple d3d apps(Moto racer 2, Direct3D1) and opengl apps(Jedi academy). when the application quits the counters fall back to 0 immediately. On the other hand, a native Linux application(ut2004, 64 bit) does not cause any change in the driver waiting and the agp usage stays at zero. (makes me wonder a bit how useful those counters are). For wine it is enough to successfully create a d3d device or opengl context. Just a IDirect3D9::CreateDevice does it. Regarding the 75% idle, I think that is comparably ok. Native ut2004 shows the same behavior. So either the games are broken, or I have a way to overpowered gpu(geforce 7600) for my cpu(athlon 64 X2 dual core 3800+). Any ideas regarding the agp usage? Could a badly chosen pixel format cause the trouble? Cheers, Stefan

3 2

wined3d: The sims regression
by Alessandro Pignotti Feb. 14, 2007

Feb. 14, 2007

Hi, I've noticed that commit 12252d058914a66f40e976484cc7d8aa52ffca47 on the git tree causes a regression in the sims, making characters flipped upside down. It's seems to me that the y axis is flipped. I hope this helps Bye Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome

2 1

Re: Declare some WinXP related structures
by Dmitry Timoshkov Feb. 14, 2007

Feb. 14, 2007

"Kovács András" <andras(a)csevego.net> wrote: > --- a/include/winuser.h > +++ b/include/winuser.h > @@ -1055,6 +1055,51 @@ BOOL WINAPI SetSysColors(INT,const INT*,const COLORREF*); > #define WM_GETICON 0x007f > #define WM_SETICON 0x0080 > > + /* Windows XP messages */ > +#define WM_INPUT 0x00FF Please don't add this kind of a comment, even if it's true for this particular message, it may not belong to all messages below this one. > + /* Windows XP related raw input structures */ > +typedef struct tagRAWINPUTDEVICE { You have added a bunch of structures in the middle of the message definitions, please find a better place. -- Dmitry.

1 0

Re: opengl
by Tom Wickline Feb. 14, 2007

Feb. 14, 2007

On 2/13/07, gaosheng <gs(a)crosslight.com.cn> wrote: > Hi: > I want to use opengl with wine. > > //----Here is my glxinfo. > > server glx vendor string:SGI > server glx version string:1.2 > > client glx vendor string:SGI > client glx version string:1.2 > > OpengGL vendor string:Mesa project:www.mesa3d.org > OpengGL renderer string:Mesa GLX Indirect > OpengGL version string:1.3 Mesa 4.0.4 > //------ > > I can't init opengl. when ChoosePixel(), it failed. > Can you tell me the reason. You will need to have direct rendering, and to see if its currently activated (status) you can grep glxinfo : $ glxinfo | grep direct You will want to make sure it says Yes tom(a)prostar ~ $ glxinfo | grep direct direct rendering: Yes tom(a)prostar ~ $ You may also need to update your module section in your X.org conf file You will want to turn off dri and turn glx on. # Load "dri" Load "glx" You may also want to grep the vendor tom(a)prostar ~ $ glxinfo | grep vendor server glx vendor string: NVIDIA Corporation client glx vendor string: NVIDIA Corporation OpenGL vendor string: NVIDIA Corporation tom(a)prostar ~ $ You can run 'glxgears' before and after also, here it makes a huge difference. tom(a)prostar ~ $ glxgears 54378 frames in 5.0 seconds = 10875.471 FPS 54802 frames in 5.0 seconds = 10960.384 FPS 54775 frames in 5.0 seconds = 10954.939 FPS tom(a)prostar ~ $ Cheers, Tom > > Best regards > gao sheng >

1 0