Re: ddraw: Allow creating back buffer for pre-DirectX 7 interfaces.
2010/7/20 Roderick Colenbrander : > 2010/7/20 Oldřich Jedlička : >> Hi Stefan, >> >> On Tuesday 20 July 2010 00:01:13 Stefan Dösinger wrote: >>> Am 19.07.2010 um 21:24 schrieb Oldřich Jedlička: >>> > Hi Stefan, >>> > >>> > On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote: >>> >> Allowing the creation of the surface is most likely not enough, the >>> >> backbuffer has to be useable after it has been created. Specifically, >>> >> when the app attaches the backbuffer to the frontbuffer(assuming this >>> >> works, needs a test) wined3d has to be made aware of the change - >>> >> there's a SetFrontBackBuffers method in the wined3d device to >>> >> reconfigure the primary swapchain. >>> > >>> > There is at least one game verified to work with CreateSurface method >>> > that allows creation of back buffers - Bulanci (Combat Pillows, bug >>> > #9008). But I have to admit that I don't know the internals of WineD3D, >>> > nor DirectX. >>> >>> You probably get away with not dealing with AddAttachedSurface by luck. >>> With the GDI 2D renderer ddraw passes the attached backbuffer explicitly >>> to wined3d. With the GL renderer you may not be so lucky because it may >>> render to an offscreen texture instead of the backbuffer. >> >> I've analysed the usage by the game and read something about >> AddAttachedSurface. >> >> MSDN says that AddAttachedSurface might work, but should not be used on the >> flipping chain (i.e. to attach back buffers to front buffers). Thus I think >> there >> is no change necessary at the moment. > > Sounds like a test is needed there since MSDN is not the most reliable > source of information. I found a comment on MSDN which says > AddAttachedSurface can work on a swapchain but it is an unsupported > feature. > >> I've downloaded the "bulanci" game (Combat Pillows) and analysed how it is >> used. The created BACKBUFFER is always Blt'ed onto the FRONTBUFFER (see >> attachment), there is no call to AddAttachedSurface. I don't know if there is >> any additional action (=coding) needed. >> >> @all: Can anybody please have look at the attached log snippet if there is >> something wrong? It looks to me that everything works. I've used wine with >> original patch removing the backbuffer check. >> > > If it is really true that AddAttachedSurface won't work then a patch > like this might be fine (wait for Stefan's confirmation though). I > wonder can you perform any 3D rendering to this type of extra > backbuffer (it would need FBOs then) or is it just a 'helper' buffer? > Might require testing too... > > Roderick > Just something else I thought about before going to bed, the game only requests that the surface is a 'back buffer'. CreateNewSurface in DirectDraw sets video memory related flags. It might be useful to add some tests what type of memory, Windows selects for a standalone backbuffer. Who knows it might select system memory. Roderick
Re: wined3d: Add Nvidia 8800GTX detection
On Tuesday, July 20, 2010 2:54:24 pm Luke Bratch wrote: > The attached uses that experimental extension [1] to report the correct > total memory for cards that support it, while sticking with the existing > hard coded values and code layout for those that don't. I think the extension should be checked regardless of the card type. Especially with the open source drivers, there's no reason ATi or Intel cards can't pick it up. And with the Nouveau driver, even older nVidia cards can get it. I'd also think the wrapping function should be generically named, so it can be extended to use other extensions, in case alternative ones come up. On a technical note, it looks like you're checking the extension incorrectly. You're checking the address of the extension array entry, instead of the array entry value.
Re: dmusic: remove unused variable
On 7/21/2010 08:31, Austin English wrote:
HRESULT WINAPI DMUSIC_CreateDirectMusicPortImpl (LPCGUID lpcGUID, LPVOID
*ppobj, LPUNKNOWN pUnkOuter, LPDMUS_PORTPARAMS pPortParams, LPDMUS_PORTCAPS
pPortCaps) {
IDirectMusicPortImpl *obj;
- HRESULT hr = E_FAIL;
UINT j;
TRACE("(%p,%p,%p)\n", lpcGUID, ppobj, pUnkOuter);
@@ -381,7 +380,6 @@ HRESULT WINAPI DMUSIC_CreateDirectMusicPortImpl (LPCGUID
lpcGUID, LPVOID *ppobj,
obj->caps = *pPortCaps;
obj->pDirectSound = NULL;
obj->pLatencyClock = NULL;
- hr = DMUSIC_CreateReferenceClockImpl(&IID_IReferenceClock,
(LPVOID*)&obj->pLatencyClock, NULL);
if(0)
{
I doubt you could remove a call here. And probably return value should
be used to exit earlier on a failure.
Re: ddraw: Allow creating back buffer for pre-DirectX 7 interfaces.
2010/7/20 Oldřich Jedlička : > Hi Stefan, > > On Tuesday 20 July 2010 00:01:13 Stefan Dösinger wrote: >> Am 19.07.2010 um 21:24 schrieb Oldřich Jedlička: >> > Hi Stefan, >> > >> > On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote: >> >> Allowing the creation of the surface is most likely not enough, the >> >> backbuffer has to be useable after it has been created. Specifically, >> >> when the app attaches the backbuffer to the frontbuffer(assuming this >> >> works, needs a test) wined3d has to be made aware of the change - >> >> there's a SetFrontBackBuffers method in the wined3d device to >> >> reconfigure the primary swapchain. >> > >> > There is at least one game verified to work with CreateSurface method >> > that allows creation of back buffers - Bulanci (Combat Pillows, bug >> > #9008). But I have to admit that I don't know the internals of WineD3D, >> > nor DirectX. >> >> You probably get away with not dealing with AddAttachedSurface by luck. >> With the GDI 2D renderer ddraw passes the attached backbuffer explicitly >> to wined3d. With the GL renderer you may not be so lucky because it may >> render to an offscreen texture instead of the backbuffer. > > I've analysed the usage by the game and read something about > AddAttachedSurface. > > MSDN says that AddAttachedSurface might work, but should not be used on the > flipping chain (i.e. to attach back buffers to front buffers). Thus I think > there > is no change necessary at the moment. Sounds like a test is needed there since MSDN is not the most reliable source of information. I found a comment on MSDN which says AddAttachedSurface can work on a swapchain but it is an unsupported feature. > I've downloaded the "bulanci" game (Combat Pillows) and analysed how it is > used. The created BACKBUFFER is always Blt'ed onto the FRONTBUFFER (see > attachment), there is no call to AddAttachedSurface. I don't know if there is > any additional action (=coding) needed. > > @all: Can anybody please have look at the attached log snippet if there is > something wrong? It looks to me that everything works. I've used wine with > original patch removing the backbuffer check. > If it is really true that AddAttachedSurface won't work then a patch like this might be fine (wait for Stefan's confirmation though). I wonder can you perform any 3D rendering to this type of extra backbuffer (it would need FBOs then) or is it just a 'helper' buffer? Might require testing too... Roderick
Re: wined3d: Add Nvidia 8800GTX detection
On Wed, Jul 21, 2010 at 3:59 AM, Roderick Colenbrander wrote: > On Tue, Jul 20, 2010 at 11:54 PM, Luke Bratch wrote: >> --- On Tue, 20/7/10, Henri Verbeet wrote: >> >>> Negative on using experimental extensions I'm afraid. >>> Writing a proof >>> of concept patch is ok, of course, and I'd be willing to >>> review that, >>> but it can't go in until the extension is finalized. Note >>> that this >>> wouldn't allow you to get rid of the current code though, >>> you still >>> need a fallback. It would just allow for more accurate >>> reporting on >>> cards that do support that extension. >> >> The attached uses that experimental extension [1] to report the correct >> total memory for cards that support it, while sticking with the existing >> hard coded values and code layout for those that don't. >> >> I would appreciate any comments. >> >> Thanks >> >> Luke Bratch >> >> [1] >> http://developer.download.nvidia.com/opengl/specs/GL_NVX_gpu_memory_info.txt > > Actually I wrote a GL_NVX_gpu_memory_info patch as well, didn't have > time to send the mail to here yet. The patch I wrote is a bit > different and I think that's how it should work. You have to keep the > current code as it is. After the gpu / amount of video memory have > been selected AND if no gpu memory override is set in the registry > (there can be good reasons for not exposing all video memory) then if > the nvidia extension is around, the amount of video memory should be > overridden. Let me dig up the stuff I made. > > Roderick > I just had a look at the old stuff I made but it was quite hacky and not what I remembered from it (thought it was a bit nicer). After thinking about it a bit, I think it is not an easy 'few lines' patch but it requires more changes. First the issues and what I don't like about adding it to the current mechanism. You could reason that we should query the amount of video memory from within each 'guess_card' function. The problem right now is that each function 'returns' when the right card has been found but we would like to do the override after the card has been found but before we return from the call. The code could be changed to do this but I think I find it nicer to make some bigger changes to the code. I think 'select_card_*' should just return the pci device id and the default amount of video memory should be stored in lets say the driver version table (a different name for the table might make sense). It would also avoid us from duplicating some of the logic for open source nvidia/ati drivers (if they ever become useful for 3D gaming apart from Quake3). I think I was against such a change a few months ago when some of the code was restructured. If I was against it was likely because it was harder to add comments which can be useful for memory info. Once all video memory is in the table, we could grab the default amount of video memory from this table from 'wined3d_guess_card'. In order to override the amount of video memory we could add an (optional) 'select_nvidia_gpu_memory' to 'vendor_card_select_table' to override the default amount of video memory. It would be easy to add other GL_*_memory_info extensions as selectors. Before the memory info can be moved to the table, Intel driver information has to be added to there (there is none now but we have memory info in the selector functions). Then all the memory info can be moved. I'm a little tired now, so might have missed something. I will likely play with this since I have a need for it as well. It is not so hard, but Henri I promise that the next WineD3D thing I hack on again is the blit_shader... Hopefully I have time for that by the end of this week. Roderick
Re: wined3d: Add Nvidia 8800GTX detection
On Wed, Jul 21, 2010 at 1:57 AM, Seth Shelnutt wrote: > For ati there is also GL_ATI_mem_info [1] or WGL_AMD_gpu_association [2] . I > believe that [1] is now obsolete as from reading some of the wine-dev > mailing list [3], and some other site it seems AMD is now pushing the using > of WGL_AMD_gpu_association instead. A patch could be written in the exact > same manor as your nvidia patch for ati. There doesn't appear to be an intel > or via extension to get video memory, although it's much less of a problem > for those integrated graphics. > The WGL/GLX_AMD_gpu_association extension exports the amount of video memory but the extension itself is more meant to divide the load between multiple (even different) GPUs. The GL_ATI_mem_info extension is fancier and like the Nvidia one it also exports the amount of free video memory. The downside is that older drivers don't support the (undocumented) total amount of video memory. Looking at the past most Nvidia extensions at some point become ARB extensions or serve as the start of one. I wouldn't be surprised if there would come some EXT/ARB specification. The few GL games out there right now all uses hacks to get this information (WoW for instance uses ddraw when running using OpenGLon Windows, recent ID software games use extensions like NV-CONTROL on Linux). Roderick
Re: wined3d: Add Nvidia 8800GTX detection
On Tue, Jul 20, 2010 at 11:54 PM, Luke Bratch wrote: > --- On Tue, 20/7/10, Henri Verbeet wrote: > >> Negative on using experimental extensions I'm afraid. >> Writing a proof >> of concept patch is ok, of course, and I'd be willing to >> review that, >> but it can't go in until the extension is finalized. Note >> that this >> wouldn't allow you to get rid of the current code though, >> you still >> need a fallback. It would just allow for more accurate >> reporting on >> cards that do support that extension. > > The attached uses that experimental extension [1] to report the correct total > memory for cards that support it, while sticking with the existing hard coded > values and code layout for those that don't. > > I would appreciate any comments. > > Thanks > > Luke Bratch > > [1] > http://developer.download.nvidia.com/opengl/specs/GL_NVX_gpu_memory_info.txt Actually I wrote a GL_NVX_gpu_memory_info patch as well, didn't have time to send the mail to here yet. The patch I wrote is a bit different and I think that's how it should work. You have to keep the current code as it is. After the gpu / amount of video memory have been selected AND if no gpu memory override is set in the registry (there can be good reasons for not exposing all video memory) then if the nvidia extension is around, the amount of video memory should be overridden. Let me dig up the stuff I made. Roderick
Re: [2/2] user32: Prevent resize of minimized windows from SetWindowPos (Bug 1719).
On Tue, Jul 20, 2010 at 8:34 PM, Marvin wrote: > === W7PRO (32 bit win) === > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 006E01AE > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 007001AE > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000501A0 > fg 00030050 in hook HCBT_SETFOCUS > win.c:2664: Test failed: GetActiveWindow() = > win.c:2664: Test failed: GetFocus() = > win.c:2690: Test failed: GetActiveWindow() = > win.c:2690: Test failed: GetFocus() = > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000601A0 > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000501A2 > fg 00030050 in hook HCBT_SETFOCUS > win.c:2749: Test failed: GetActiveWindow() = > win.c:2749: Test failed: GetFocus() = > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 00040146 > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 002E01A2 > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 002F01A2 > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 007101AE > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 007501AE > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 007601AE > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 001801A0 > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000401A8 > fg 00030050 in hook HCBT_SETFOCUS > win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 00040146 > fg 00030050 in hook HCBT_SETFOCUS > These failures seems identical to results of the last patch committed to this file, and seem unrelated to my patchset.
Re: [2/2] user32: Prevent resize of minimized windows from SetWindowPos (Bug 1719).
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3631 Your paranoid android. === W7PRO (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 006E01AE fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 007001AE fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000501A0 fg 00030050 in hook HCBT_SETFOCUS win.c:2664: Test failed: GetActiveWindow() = win.c:2664: Test failed: GetFocus() = win.c:2690: Test failed: GetActiveWindow() = win.c:2690: Test failed: GetFocus() = win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000601A0 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000501A2 fg 00030050 in hook HCBT_SETFOCUS win.c:2749: Test failed: GetActiveWindow() = win.c:2749: Test failed: GetFocus() = win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 00040146 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 002E01A2 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 002F01A2 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 007101AE fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 007501AE fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 007601AE fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 001801A0 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000401A8 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 00040146 fg 00030050 in hook HCBT_SETFOCUS
Re: [1/2] user32/tests: Minimized windows shouldn't be resizable.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3630 Your paranoid android. === W7PRO (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 006E01AE fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 007001AE fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000501A0 fg 00030050 in hook HCBT_SETFOCUS win.c:2664: Test failed: GetActiveWindow() = win.c:2664: Test failed: GetFocus() = win.c:2690: Test failed: GetActiveWindow() = win.c:2690: Test failed: GetFocus() = win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000601A0 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000501A2 fg 00030050 in hook HCBT_SETFOCUS win.c:2749: Test failed: GetActiveWindow() = win.c:2749: Test failed: GetFocus() = win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 00030144 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 009901AE fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 009A01AE fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000601A2 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000A01A2 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000B01A2 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 001801A0 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 000401A8 fg 00030050 in hook HCBT_SETFOCUS win.c:823: Test failed: wrong dwWindowStatus: != 0001 active 00030144 fg 00030050 in hook HCBT_SETFOCUS
Re: wined3d: Add Nvidia 8800GTX detection
For ati there is also GL_ATI_mem_info [1] or WGL_AMD_gpu_association [2] . I believe that [1] is now obsolete as from reading some of the wine-dev mailing list [3], and some other site it seems AMD is now pushing the using of WGL_AMD_gpu_association instead. A patch could be written in the exact same manor as your nvidia patch for ati. There doesn't appear to be an intel or via extension to get video memory, although it's much less of a problem for those integrated graphics. One thing with your patch is that only since 190.x drivers has the extension been introduced. So any card that is older than the 6xxx series won't support the extension. So you could remove the code for the FX card and below. Besides that I think your implementation is good; but I'm no dev, so I'll let Roderick and Henri make the real comments. [1] http://www.opengl.org/registry/specs/ATI/meminfo.txt [2] http://www.opengl.org/registry/specs/AMD/wgl_gpu_association.txt [3] http://www.mail-archive.com/wine-devel@winehq.org/msg57060.html On Tue, Jul 20, 2010 at 9:54 PM, Luke Bratch wrote: > --- On Tue, 20/7/10, Henri Verbeet wrote: > > > Negative on using experimental extensions I'm afraid. > > Writing a proof > > of concept patch is ok, of course, and I'd be willing to > > review that, > > but it can't go in until the extension is finalized. Note > > that this > > wouldn't allow you to get rid of the current code though, > > you still > > need a fallback. It would just allow for more accurate > > reporting on > > cards that do support that extension. > > The attached uses that experimental extension [1] to report the correct > total memory for cards that support it, while sticking with the existing > hard coded values and code layout for those that don't. > > I would appreciate any comments. > > Thanks > > Luke Bratch > > [1] > http://developer.download.nvidia.com/opengl/specs/GL_NVX_gpu_memory_info.txt > > >
Re: [PATCH] shlwapi: Be less strict on which type of IShellFolder can be enumerated
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3623 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:595: Test failed: GetShellSecurityDescriptor should fail ordinal.c:618: Test failed: returned value is not valid SD No test summary line found === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1768: Test failed: got 28 ordinal.c:1818: Test failed: got 28 ordinal.c:1826: Test failed: got 28 ordinal.c:1834: Test failed: got 39, length 40 ordinal.c:1845: Test failed: got 42 === W7PROX64 (32 bit ordinal) === ordinal.c:1762: Test failed: got 9 ordinal.c:1768: Test failed: got 25 ordinal.c:1783: Test failed: got 6 ordinal.c:1796: Test failed: got 9 ordinal.c:1804: Test failed: got 9 ordinal.c:1818: Test failed: got 25 ordinal.c:1826: Test failed: got 25 ordinal.c:1856: Test failed: got 19 ordinal.c:1867: Test failed: got 22
Re: wined3d: Add Nvidia 8800GTX detection
--- On Tue, 20/7/10, Henri Verbeet wrote: > Negative on using experimental extensions I'm afraid. > Writing a proof > of concept patch is ok, of course, and I'd be willing to > review that, > but it can't go in until the extension is finalized. Note > that this > wouldn't allow you to get rid of the current code though, > you still > need a fallback. It would just allow for more accurate > reporting on > cards that do support that extension. The attached uses that experimental extension [1] to report the correct total memory for cards that support it, while sticking with the existing hard coded values and code layout for those that don't. I would appreciate any comments. Thanks Luke Bratch [1] http://developer.download.nvidia.com/opengl/specs/GL_NVX_gpu_memory_info.txt Allow-accurate-Nvidia-memory-detection.patch Description: Binary data
Re: [3\4] d3d9: Partially implement GetAdapterDisplayModeEx
On Tuesday, July 20, 2010 2:28:44 pm Louis Lenders wrote:
> +TRACE("iface %p, adapter %u, mode %p.\n", iface, adapter, mode);
> +TRACE("iface %p, adapter %u, mode %p, rotation %p\n", iface, adapter,
> mode, rotation);
This doesn't look right. You probably only need the second TRACE statement,
there.
It also looks like adapterinfo is being leaked. Any reason you HeapAlloc one
to pass in, instead of passing a pointer to a stack object? Eg:
struct wined3d_adapter_info_ex adapterinfo;
...
hr = IWineD3D_GetAdapterDisplayMode(This->WineD3D, adapter, &m, &adapterinfo);
Re: [PATCH 4/4] wined3d: Use a more consistent name for the normalized texrect "extension".
Am 20.07.2010 um 18:51 schrieb Henri Verbeet: > -|| gl_info->supported[WINE_NORMALIZED_TEXRECT]) > +|| gl_info->supported[WINED3D_GL_NORMALIZED_TEXRECT]) I understand the WINE->WINED3D part - it's a wined3d specific thing, nothing wine global. But why did you add GL to the name?
Re: ddraw: Allow creating back buffer for pre-DirectX 7 interfaces.
Hi Stefan,
On Tuesday 20 July 2010 00:01:13 Stefan Dösinger wrote:
> Am 19.07.2010 um 21:24 schrieb Oldřich Jedlička:
> > Hi Stefan,
> >
> > On Monday 19 July 2010 20:56:35 Stefan Dösinger wrote:
> >> Allowing the creation of the surface is most likely not enough, the
> >> backbuffer has to be useable after it has been created. Specifically,
> >> when the app attaches the backbuffer to the frontbuffer(assuming this
> >> works, needs a test) wined3d has to be made aware of the change -
> >> there's a SetFrontBackBuffers method in the wined3d device to
> >> reconfigure the primary swapchain.
> >
> > There is at least one game verified to work with CreateSurface method
> > that allows creation of back buffers - Bulanci (Combat Pillows, bug
> > #9008). But I have to admit that I don't know the internals of WineD3D,
> > nor DirectX.
>
> You probably get away with not dealing with AddAttachedSurface by luck.
> With the GDI 2D renderer ddraw passes the attached backbuffer explicitly
> to wined3d. With the GL renderer you may not be so lucky because it may
> render to an offscreen texture instead of the backbuffer.
I've analysed the usage by the game and read something about
AddAttachedSurface.
MSDN says that AddAttachedSurface might work, but should not be used on the
flipping chain (i.e. to attach back buffers to front buffers). Thus I think
there
is no change necessary at the moment.
I've downloaded the "bulanci" game (Combat Pillows) and analysed how it is
used. The created BACKBUFFER is always Blt'ed onto the FRONTBUFFER (see
attachment), there is no call to AddAttachedSurface. I don't know if there is
any additional action (=coding) needed.
@all: Can anybody please have look at the attached log snippet if there is
something wrong? It looks to me that everything works. I've used wine with
original patch removing the backbuffer check.
Regards,
Oldrich.
wine: created the configuration directory '/home/oldium/.wine'
trace:ddraw:DllMain (0x7dda,1,(nil))
trace:ddraw:DllRegisterServer
trace:ddraw:DllMain (0x7dda,0,(nil))
trace:ddraw:DllMain (0x7dd8,1,(nil))
trace:ddraw:DllRegisterServer
trace:ddraw:DllMain (0x7dd8,0,(nil))
trace:ddraw:DllMain (0x7daa,1,(nil))
trace:ddraw:DllMain (0x7daa,0,(nil))
fixme:system:SetProcessDPIAware stub!
fixme:dwmapi:DwmIsCompositionEnabled 0x33d12c
fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented
fixme:advapi:SetNamedSecurityInfoW L"C:\\windows\\system32\\gecko\\1.0.0\\wine_gecko\\components\\xpti.dat" 1 536870916 (nil) (nil) 0x1b460c (nil)
fixme:iphlpapi:NotifyAddrChange (Handle 0x27be8f8, overlapped 0x27be900): stub
fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented
fixme:advapi:SetNamedSecurityInfoW L"C:\\windows\\system32\\gecko\\1.0.0\\wine_gecko\\components\\compreg.dat" 1 536870916 (nil) (nil) 0x1e82414 (nil)
wine: configuration in '/home/oldium/.wine' has been updated.
trace:ddraw:DllMain (0x7e6d,1,0x1)
trace:ddraw:DirectDrawCreate ((null),0x4be96c,(nil))
trace:ddraw:DDRAW_Create ((null),0x4be96c,(nil))
fixme:win:EnumDisplayDevicesW ((null),0,0x32f620,0x), stub!
trace:ddraw:DDRAW_Create WineD3D created at 0x1256d0
trace:ddraw:device_parent_WineD3DDeviceCreated iface 0x1242ec, device 0x12ba00
trace:ddraw:DDRAW_Create wineD3DDevice created at 0x12ba00
trace:ddraw:IDirectDrawImpl_QueryInterface (0x1242c8)->({6c14db80-a733-11ce-a521-0020af0be560},0x4be96c)
trace:ddraw:IDirectDrawImpl_QueryInterface (0x1242c8) Returning IDirectDraw interface at 0x1242d8
trace:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x1242c8)->(0x30036,0011)
trace:ddraw:DDRAW_dump_cooperativelevel - DDSCL_FULLSCREEN DDSCL_EXCLUSIVE
trace:ddraw:IDirectDrawImpl_SetCooperativeLevel SetCooperativeLevel retuning DD_OK
fixme:mixer:ALSA_MixerInit No master control found on HDA ATI HDMI, disabling mixer
fixme:mixer:ALSA_MixerInit No master control found on SAA7134, disabling mixer
err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x135de8,0x135d48): stub
trace:ddraw:IDirectDrawImpl_SetDisplayModeNoOverride (0x1242c8)->(800,600,32,0,0): Relay!
trace:ddraw:IDirectDrawImpl_CreateSurface (0x1242c8)->(0x32fbd8,0x32fbb0,(nil))
trace:ddraw:IDirectDrawImpl_CreateSurface (0x1242c8) Requesting surface desc :
trace:ddraw:DDRAW_dump_members - DDSD_CAPS : DDSCAPS_PRIMARYSURFACE
trace:ddraw:PixelFormat_WineD3DtoDD Converting WINED3DFORMAT 115 to DDRAW
trace:ddraw:PixelFormat_WineD3DtoDD Returning: ( DDPF_RGB , RGB bits: 32, R 00ff G ff00 B 00ff)
trace:ddraw:IDirectDrawImpl_CreateNewSurface (0x1242c8) Requesting surface desc :
trace:ddraw:DDRAW_dump_members - DDSD_CAPS : DDSCAPS_FRONTBUFFER DDSCAPS_PRIMARYSURFACE
trace:ddraw:DDRAW_dump_members - DDSD_HEIGHT : 600
trace:ddraw:DDRAW_dump_members - DDSD_WIDTH : 800
trace:ddraw:DDRAW_dump_members - DDSD_PIXELFORMAT : ( DDPF_RGB , RGB bits: 32, R 00ff G ff00 B 00ff)
trace:ddraw:IDirectD
Re: Quick legal question... teapot related
On 20 July 2010 20:20, Avery Pennarun wrote: > On Tue, Jul 20, 2010 at 10:35 AM, David Gerard wrote: >> On 20 July 2010 14:52, Dan McDonald wrote: >>> On 07/20/2010 06:44 AM, Misha Koshelev wrote: If I take a publicly available teaset: http://www.sjbaker.org/teapot/teaset.tgz And run it through a Microsoft function: http://msdn.microsoft.com/en-us/library/bb205470%28v=VS.85%29.aspx D3DXTesselateRectPatch for example And then copy the vertex buffer and index buffer and save them... Do I have the rights to use the vertex and index buffers? >>> I would think that the output of the function does not pass the >>> threshold of originality requirement in U.S. copyright law. We will see >>> what the higher powers decide. >> It absolutely In does not create a new copyright in US law. (Bridgeman v. >> Corel.) No machine transformation of a public domain object can create >> a new copyright, no matter who built the machine. > So if the original file was under an acceptable license, then the > output file still will be, right? Technically, per US copyright: http://en.wikipedia.org/wiki/Bridgeman_Art_Library_v._Corel_Corp. That said, Alexandre might want to be more paranoid. And I still like the wine glass idea;-) - d.
Re: Fyi patch submission information on wiki updated for GitHub
On Mon, 2010-07-19 at 22:48 -0600, Vitaliy Margolen wrote: > On 07/19/2010 08:59 PM, Misha Koshelev wrote: > > Unfortunately, the more intuitive > > git format-patch -k --stdout HEAD~79..HEAD~78> /tmp/patch.old > > > > does not seem to result in patches that can be properly applied onto a > > different (upstream) remote (see below). > > Works fine here. You must have had some additional changes between upstream > and HEAD~79. Or your tree diverged from the origin (you had some of your > patches merged and not rebased) which is the same as above. > > And you should really be using "--attach". It's always the better option, > especially for the series of patches. > > Vitaliy Dear Vitaliy and all: I have spent some time investigating this. I have created an entirely new GitHub fork and, indeed, the two statements: a) git format-patch -n --attach --stdout HEAD~80..HEAD~79 b) git format-patch -k -o out upstream/stable..origin seem to result in patches that apply to wine-git in this case. I have also spent some time updating the GitHub information on the GitWine wiki, and I believe it should now be streamlined and correct: http://wiki.winehq.org/GitWine#head-0e6d3133a16d3a26de956c500675e5e623462a9e I am still not quite sure why I had this divergence between patches generated using (a) and (b) in my previous GitHub fork, but my guess is that this comes from using git merge rather than git rebase when updating my repository to match upstream Wine. In any case, I will have to wait and see whether this happens again. Finally, thanks to some helpful comments from others, I will try to contain my enthusiasm and not send so many emails to wine-devel. I will restrict myself to major milestones & such. Thank you all for your help! Misha
Re: Quick legal question... teapot related
On Tue, Jul 20, 2010 at 10:35 AM, David Gerard wrote: > On 20 July 2010 14:52, Dan McDonald wrote: >> On 07/20/2010 06:44 AM, Misha Koshelev wrote: >>> If I take a publicly available teaset: >>> http://www.sjbaker.org/teapot/teaset.tgz >>> And run it through a Microsoft function: >>> http://msdn.microsoft.com/en-us/library/bb205470%28v=VS.85%29.aspx >>> D3DXTesselateRectPatch for example >>> And then copy the vertex buffer and index buffer and save them... >>> Do I have the rights to use the vertex and index buffers? >>> I am assuming yes... but wanted to double check first. > >> I would think that the output of the function does not pass the >> threshold of originality requirement in U.S. copyright law. We will see >> what the higher powers decide. > > It absolutely does not create a new copyright in US law. (Bridgeman v. > Corel.) No machine transformation of a public domain object can create > a new copyright, no matter who built the machine. So if the original file was under an acceptable license, then the output file still will be, right? Avery
Re: [PATCH 7/7] d3d10: Implement D3D10ReflectShader().
Am 20.07.2010 11:26, schrieb Henri Verbeet: 2010/7/19 Rico Schüller: +e[i].SemanticName = get_semantic(data + name_offset); I'm not sure this will work, I was under the impression semantics can be arbitrary strings. (Which is also why d3d10core goes through the trouble of copying the string data.) Yeah, you are right. Not sure why I changed this. The problem is when I release the shader reflection the element signature semantic name could have garbage (when the memory is overwritten). I'll recheck that one.
Re: wined3d: Add Nvidia 8800GTX detection
On 20 July 2010 19:46, Roderick Colenbrander wrote: > It is quite easy to add some basic support for it (I > would not use the free video memory code yet) but I'm not sure if we > want to support this yet since the extension is experimental. If it is > fine by Henri, I can add it as it would help a lot of users. > Negative on using experimental extensions I'm afraid. Writing a proof of concept patch is ok, of course, and I'd be willing to review that, but it can't go in until the extension is finalized. Note that this wouldn't allow you to get rid of the current code though, you still need a fallback. It would just allow for more accurate reporting on cards that do support that extension.
Re: wined3d: Add Nvidia 8800GTX detection
On Tue, Jul 20, 2010 at 1:54 PM, Henri Verbeet wrote: > On 20 July 2010 15:49, Luke Bratch wrote: >> Adds detection for the Nvidia 8800GTX card and sets its video memory >> correctly. >> >> I have sent this patch in the past but it got rejected, as this method of >> calculating video card type/memory wasn't supposed to stay around forever, >> but another similar patch got accepted yesterday so I'm trying again. >> > I mostly let Roderick worry about card detection, but at the very > least this patch has a trailing tab and a driver version number that's > inconsistent with the other entries. I think the main reason you want to add the 8800 GTX is because of GPU memory detection (the fact that it is detected as a slightly slower 8800 is not a real issue). I would rather not add all different types of GPU models. In the long term we might want to change our GPU detection logic. In case of Nvidia it would make sense to use NV-CONTROL which is an X11 extension for that we would have to move the logic to winex11.drv (and that might also be better since some apps want to see the proper driver name). For other vendors there is no good mechanism. ATI has ATIFGLEXTENSION but they discourage using it. I emailed with a few months ago and they would rather see us using 'libatiadlxx.so / atiadlxx.dll' but I believe it doesn't go through X11 which isn't nice. For other vendors there is no mechanism at all. As a short term solution we might want to use GL_NVX_gpu_memory_info. It provides the total amount of memory info, the amount of free texture memory and some more things. I have used this extension in some projects and it works fine but the extension is still experimental. It is quite easy to add some basic support for it (I would not use the free video memory code yet) but I'm not sure if we want to support this yet since the extension is experimental. If it is fine by Henri, I can add it as it would help a lot of users. Roderick
Re: dlls/kernel32/volume
On 20/07/10 14:54, Stephen Mark Smith wrote:
On 20/07/10 14:00, Alexandre Julliard wrote:
stephenmsm...@blueyonder.co.uk writes:
diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c
index 7596864..4908739 100644
--- a/dlls/kernel32/volume.c
+++ b/dlls/kernel32/volume.c
@@ -526,10 +526,17 @@ BOOL WINAPI GetVolumeInformationW( LPCWSTR
root, LPWSTR label, DWORD label_len,
}
else
{
-if (!root[0] || root[1] != ':' || root[lstrlenW(root)-1] !=
'\\' )
+if (!isalphaW(root[0]) || root[1] != ':' ||
root[lstrlenW(root)-1] != '\\')
{
-SetLastError( ERROR_INVALID_NAME );
-return FALSE;
+WCHAR curpath[MAX_PATH],winpath[MAX_PATH];
+GetCurrentDirectoryW(MAX_PATH,curpath);
+GetWindowsDirectoryW(winpath,MAX_PATH);
+
+if(lstrlenW(curpath)> 3&& root[0] == winpath[0])
+{
+SetLastError( ERROR_INVALID_NAME );
+return FALSE;
+}
This clearly makes no sense, path syntax doesn't depend on the windows
directory.
I agree it makes no sense however it seems to match windows behavior,
results from my own vista box:
Current directory is C:\Users\Administrator\Documents\Visual Studio
2010\Projects\volumeandfiletests\Debug
GetVolumeInformation succeds with no trailing backslash for E:
Current directory is C:\
GetVolumeInformation succeds with no trailing backslash for C:
GetVolumeInformation succeds with no trailing backslash for E:
Current directory is E:\
GetVolumeInformation succeds with no trailing backslash for E:
Current directory is E:\data
moved executable off C: to see if it was using executables path not
windows path produces more confusing results:
Current directory is F:\
GetVolumeInformation succeds with no trailing backslash for E:
GetVolumeInformation succeds with no trailing backslash for F:
Current directory is C:\
GetVolumeInformation succeds with no trailing backslash for C:
GetVolumeInformation succeds with no trailing backslash for E:
GetVolumeInformation succeds with no trailing backslash for F:
Current directory is E:\
GetVolumeInformation succeds with no trailing backslash for E:
GetVolumeInformation succeds with no trailing backslash for F:
Current directory is E:\data
GetVolumeInformation succeds with no trailing backslash for F:
Attached simpler patch that does not error when CWD is a root dir passes
one additional test case this does not help bug 20887 and does not match
behavior above. My original patch does not cover second set of results
either.
Help greatly welcomed.
Stephen M Smith
>From 2f3b38e0d7f02352d07b4c14201808feba45b599 Mon Sep 17 00:00:00 2001
From: Stephen M Smith
Date: Tue, 20 Jul 2010 15:32:14 +0100
Subject: GetVolumeInformationW no error on no trailing \ when current dir is
root dir
---
dlls/kernel32/tests/volume.c |1 -
dlls/kernel32/volume.c | 12 +---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/dlls/kernel32/tests/volume.c b/dlls/kernel32/tests/volume.c
index b3b4429..4e5240c 100644
--- a/dlls/kernel32/tests/volume.c
+++ b/dlls/kernel32/tests/volume.c
@@ -337,7 +337,6 @@ static void test_GetVolumeInformationA(void)
ok(ret, "SetCurrentDirectory: error %d\n", GetLastError());
ret = pGetVolumeInformationA(Root_Dir0, vol_name_buf, vol_name_size, NULL,
NULL, NULL, fs_name_buf, fs_name_len);
-todo_wine
ok(ret, "GetVolumeInformationA failed, last error %u\n", GetLastError());
/* check for error on no trailing \ when current dir is windows dir */
diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c
index 7596864..3198421 100644
--- a/dlls/kernel32/volume.c
+++ b/dlls/kernel32/volume.c
@@ -526,10 +526,16 @@ BOOL WINAPI GetVolumeInformationW( LPCWSTR root, LPWSTR
label, DWORD label_len,
}
else
{
-if (!root[0] || root[1] != ':' || root[lstrlenW(root)-1] != '\\' )
+if (!isalphaW(root[0]) || root[1] != ':' || root[lstrlenW(root)-1] !=
'\\')
{
-SetLastError( ERROR_INVALID_NAME );
-return FALSE;
+WCHAR curpath[MAX_PATH];
+GetCurrentDirectoryW(MAX_PATH,curpath);
+
+if(lstrlenW(curpath) > 3)
+{
+SetLastError( ERROR_INVALID_NAME );
+return FALSE;
+}
}
device[4] = root[0];
}
--
1.7.0.4
Re: dlls/kernel32/volume
On 20/07/10 14:00, Alexandre Julliard wrote:
stephenmsm...@blueyonder.co.uk writes:
diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c
index 7596864..4908739 100644
--- a/dlls/kernel32/volume.c
+++ b/dlls/kernel32/volume.c
@@ -526,10 +526,17 @@ BOOL WINAPI GetVolumeInformationW( LPCWSTR root, LPWSTR
label, DWORD label_len,
}
else
{
-if (!root[0] || root[1] != ':' || root[lstrlenW(root)-1] != '\\' )
+if (!isalphaW(root[0]) || root[1] != ':' || root[lstrlenW(root)-1] !=
'\\')
{
-SetLastError( ERROR_INVALID_NAME );
-return FALSE;
+WCHAR curpath[MAX_PATH],winpath[MAX_PATH];
+GetCurrentDirectoryW(MAX_PATH,curpath);
+GetWindowsDirectoryW(winpath,MAX_PATH);
+
+if(lstrlenW(curpath)> 3&& root[0] == winpath[0])
+{
+SetLastError( ERROR_INVALID_NAME );
+return FALSE;
+}
This clearly makes no sense, path syntax doesn't depend on the windows
directory.
I agree it makes no sense however it seems to match windows behavior,
results from my own vista box:
Current directory is C:\Users\Administrator\Documents\Visual Studio
2010\Projects\volumeandfiletests\Debug
GetVolumeInformation succeds with no trailing backslash for E:
Current directory is C:\
GetVolumeInformation succeds with no trailing backslash for C:
GetVolumeInformation succeds with no trailing backslash for E:
Current directory is E:\
GetVolumeInformation succeds with no trailing backslash for E:
Current directory is E:\data
Re: kernel32: Enhance EndUpdateResource
Andrey Turkin writes: > Fixes bugs 12017 and 22812 > --- > dlls/kernel32/resource.c | 113 +++ > dlls/kernel32/tests/resource.c | 307 > +++- > 2 files changed, 326 insertions(+), 94 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so package.c && touch package.ok package.c:7660: Test failed: Expected "", got "Z:\home\julliard\wine\wine\dlls\msi\tests\FileName9.dll" package.c:8289: Test failed: Expected "", got "Z:\home\julliard\wine\wine\dlls\msi\tests\FileName4.dll" package.c:8626: Test failed: Expected "", got "Z:\home\julliard\wine\wine\dlls\msi\tests\FileName3.dll" package.c:8905: Test failed: Expected "Z:\home\julliard\wine\wine\dlls\msi\tests\FileName3.dll", got "" make: *** [package.ok] Error 4 -- Alexandre Julliard julli...@winehq.org
Re: [1/5] msi: Add a test for MsiSetFeatureState.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=3600
Your paranoid android.
=== W7PROX64 (32 bit package) ===
package.c:7603: Test failed: Expected "C:\winetest\FileName1", got ""
package.c:7609: Test failed: Expected "C:\winetest\FileName2", got ""
package.c:7615: Test failed: Expected "C:\winetest\FileName3", got ""
package.c:7627: Test failed: Expected "C:\winetest\FileName5", got ""
package.c:7633: Test failed: Expected "C:\winetest\", got ""
package.c:7639: Test failed: Expected "C:\winetest\", got ""
package.c:7655: Test failed: Expected "C:\winetest\FileName8.dll", got ""
package.c:7666: Test failed: Expected "C:\winetest\FileName10.dll", got ""
package.c:11679: Test failed: Expected
"{295F085F-224B-4C34-9A18-C7DBA5A9AC1A}", got "apple"
package.c:11706: Test failed: Expected first 3 chars of
"{295F085F-224B-4C34-9A18-C7DBA5A9AC1A}", got "apple"
package.c:11716: Test failed: Expected first 37 chars of
"{295F085F-224B-4C34-9A18-C7DBA5A9AC1A}", got "apple"
package.c:11726: Test failed: Expected
"{295F085F-224B-4C34-9A18-C7DBA5A9AC1A}", got "apple"
package.c:11758: Test failed: Expected
"{295F085F-224B-4C34-9A18-C7DBA5A9AC1A}", got "apple"
=== W7PROX64 (64 bit package) ===
package.c:8212: Test failed: Expected "C:\winetest\FileName1", got ""
package.c:8223: Test failed: Expected "C:\winetest\", got ""
package.c:8234: Test failed: Expected "C:\winetest\", got ""
package.c:8284: Test failed: Expected "C:\winetest\FileName3.dll", got ""
package.c:8295: Test failed: Expected "C:\winetest\FileName5.dll", got ""
package.c:8304: Test failed: Expected "C:\", got ""
package.c:8310: Test failed: Expected "C:\winetest\", got ""
package.c:8331: Test failed: Expected "C:\winetest\FileName1", got ""
package.c:8340: Test failed: Expected "C:\winetest\FileName1", got ""
NPTL and kthreads in the developer guide
Since kthreads has now been removed, references to it in the developer's guide should presumably be removed. What about NPTL? Should discussion comparing it to kthreads be removed? Peter
Re: D3DXCreateTeapot
On 07/20/2010 01:39 PM, Reece Dunn wrote: On 19 July 2010 19:54, Ian Macfarlane wrote: Following the question as to how to implement D3DXCreateTeapot, might I suggest making it in the form of a wine glass? Given that is unlikely to negatively affect anything (indeed the entire method does border on the ridiculous) I think it would make a nice hidden touch. Sounds like a good idea. The DXDiag application could then use this API to render a nice Wine glass :) A 3D Wine glass rotating in the winecfg About tab should be cool but I guess it needs some work. If I were you, I would start with a simple sphere (kind of 3D stub) fixing the bug. Then you could freely work on it and let your imagination soar !
Re: [2/2] winhttp: Handle errors from SSL_read.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3599 Your paranoid android. === W2K3R2SESP2 (32 bit winhttp) === winhttp.c:219: Test failed: WinHttpSendRequest failed: 12007
Re: Quick legal question... teapot related
On 20 July 2010 14:52, Dan McDonald wrote: > On 07/20/2010 06:44 AM, Misha Koshelev wrote: >> If I take a publicly available teaset: >> http://www.sjbaker.org/teapot/teaset.tgz >> And run it through a Microsoft function: >> http://msdn.microsoft.com/en-us/library/bb205470%28v=VS.85%29.aspx >> D3DXTesselateRectPatch for example >> And then copy the vertex buffer and index buffer and save them... >> Do I have the rights to use the vertex and index buffers? >> I am assuming yes... but wanted to double check first. > I would think that the output of the function does not pass the > threshold of originality requirement in U.S. copyright law. We will see > what the higher powers decide. It absolutely does not create a new copyright in US law. (Bridgeman v. Corel.) No machine transformation of a public domain object can create a new copyright, no matter who built the machine. I still like the wine glass idea better ;-) - d.
Re: [1/2] winhttp: Add a partial implementation of WINHTTP_OPTION_SECURITY_CERTIFICATE_STRUCT.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3598 Your paranoid android. === W2K3R2SESP2 (32 bit winhttp) === winhttp.c:219: Test failed: WinHttpSendRequest failed: 12007 winhttp.c:301: Test failed: WinHttpSendRequest failed: 12007 winhttp.c:317: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:318: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:317: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:318: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:317: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:318: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:317: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:318: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:317: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:318: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:317: Test failed: Expected ERROR_INVALID_PARAMETER got 12019. winhttp.c:318: Test failed: Expected bytes_rw to remain unchanged. winhttp.c:323: Test failed: WinHttpReceiveResponse failed: 12017. winhttp.c:327: Test failed: WinHttpReadData failed: 12019. winhttp.c:329: Test failed: Read 0 bytes instead of 15. winhttp.c:795: Test failed: failed to send request 12007 === W7PRO (32 bit winhttp) === winhttp.c:810: Test failed: failed to send request 12030
Re: [PATCH 4/8] include: Add INameSpaceTreeControlCustomDraw interface declaration. (try 2)
David Hedberg writes:
> +/*
> + * INameSpaceTreeControlCustomDraw interface
> + */
> +[
> + object,
> + uuid(2D3BA758-33EE-42D5-BB7B-5F3431D86C78),
> + local
> +]
> +
> +interface INameSpaceTreeControlCustomDraw : IUnknown
> +{
> +typedef DWORD NSTCCUSTOMDRAW; /*FIXME*/
Why aren't you defining this properly?
--
Alexandre Julliard
julli...@winehq.org
Re: [2/4] d3dx9: Add shift modifiers parsing to the shader assembler.
On 20 July 2010 15:11, Matteo Bruni wrote:
> +const char *shiftstrings[] = {
Minor, but you should probably declare that as "static const char *
const shiftstrings[]".
Re: wined3d: Add Nvidia 8800GTX detection
On 20 July 2010 15:49, Luke Bratch wrote: > Adds detection for the Nvidia 8800GTX card and sets its video memory > correctly. > > I have sent this patch in the past but it got rejected, as this method of > calculating video card type/memory wasn't supposed to stay around forever, > but another similar patch got accepted yesterday so I'm trying again. > I mostly let Roderick worry about card detection, but at the very least this patch has a trailing tab and a driver version number that's inconsistent with the other entries.
Re: Quick legal question... teapot related
On 07/20/2010 06:44 AM, Misha Koshelev wrote: > If I take a publicly available teaset: > http://www.sjbaker.org/teapot/teaset.tgz > > And run it through a Microsoft function: > http://msdn.microsoft.com/en-us/library/bb205470%28v=VS.85%29.aspx > D3DXTesselateRectPatch for example > > And then copy the vertex buffer and index buffer and save them... > > Do I have the rights to use the vertex and index buffers? > > I am assuming yes... but wanted to double check first. I would think that the output of the function does not pass the threshold of originality requirement in U.S. copyright law. We will see what the higher powers decide. Dan
Re: user32: warnings (around uninitialized variables).
Gerald Pfeifer writes:
> @@ -388,6 +388,8 @@ static int DIB_GetBitmapInfo( const BITMAPINFOHEADER
> *header, LONG *width,
> *compr = header->biCompression;
> return 1;
> }
> +
> +*width = *height = 0;
> ERR("(%d): unknown/wrong size for header\n", header->biSize );
> return -1;
> }
0 is not valid for a bitmap, these should never be used in the error
case.
--
Alexandre Julliard
julli...@winehq.org
Re: mmio: Wrap TRACE strings with debugstr_a / debugstr_an (try 2)
2010/7/20 Tim Cadogan-Cowper : > Fixes bug 10280 (http://bugs.winehq.org/show_bug.cgi?id=10280). Thanks to > Eric > Pouech for some feedback on previous attempt and to Maarten Lankhorst for > pointing out a more appropriate way to solve the mmio TRACE buffer overflow > problem. > > IDs of the previous attempt and discussion (now redundant) are 63620, 63625 > and > 63725. > > Tim > > Hi Tim, Format specifiers shouldn't be necessary now that you use debugstr_an. -- Nicolas Le Cam
Re: [5/5] msi: Set feature states to the installed state if the Preselected property is not set.
Please ignore this one.
Re: [PATCH 1/7] msvcp90: Added stub dll
On 07/20/10 14:53, Alexandre Julliard wrote: Piotr Caban writes: @@ -0,0 +1,3189 @@ +#stub ??$?5du?$char_tra...@d@std@@@std@@yaaav?$basic_istr...@du?$char_traits@d...@std@@@0...@aav10@a...@z +#stub ??$?5du?$char_tra...@d@std@@@std@@yaaav?$basic_istr...@du?$char_traits@d...@std@@@0...@aav10@p...@z +#stub ??$?5du?$char_tra...@d@std@@v?$alloca...@d@1@@std@@yaaav?$basic_istr...@du?$char_traits@d...@std@@@0...@aav10@aav?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@0@@Z +#stub ??$?5gu?$char_tra...@g@std@@@std@@yaaav?$basic_istr...@gu?$char_traits@g...@std@@@0...@aav10@a...@z +#stub ??$?5gu?$char_tra...@g@std@@@std@@yaaav?$basic_istr...@gu?$char_traits@g...@std@@@0...@aav10@p...@z +#stub ??$?5gu?$char_tra...@g@std@@v?$alloca...@g@1@@std@@yaaav?$basic_istr...@gu?$char_traits@g...@std@@@0...@aav10@aav?$basic_str...@gu?$char_traits@g...@std@@v?$alloca...@g@2@@0@@Z Why are they commented out? Why not define real stubs? There's no reason to comment it out. I'll change it.
Re: dlls/kernel32/volume
stephenmsm...@blueyonder.co.uk writes:
> diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c
> index 7596864..4908739 100644
> --- a/dlls/kernel32/volume.c
> +++ b/dlls/kernel32/volume.c
> @@ -526,10 +526,17 @@ BOOL WINAPI GetVolumeInformationW( LPCWSTR root, LPWSTR
> label, DWORD label_len,
> }
> else
> {
> -if (!root[0] || root[1] != ':' || root[lstrlenW(root)-1] != '\\' )
> +if (!isalphaW(root[0]) || root[1] != ':' || root[lstrlenW(root)-1]
> != '\\')
> {
> -SetLastError( ERROR_INVALID_NAME );
> -return FALSE;
> +WCHAR curpath[MAX_PATH],winpath[MAX_PATH];
> +GetCurrentDirectoryW(MAX_PATH,curpath);
> +GetWindowsDirectoryW(winpath,MAX_PATH);
> +
> +if(lstrlenW(curpath) > 3 && root[0] == winpath[0])
> +{
> +SetLastError( ERROR_INVALID_NAME );
> +return FALSE;
> +}
This clearly makes no sense, path syntax doesn't depend on the windows
directory.
--
Alexandre Julliard
julli...@winehq.org
Re: ntdll: Add an error code
André Hentschel writes: > @@ -670,7 +670,7 @@ static const DWORD table_c001[411] = > 0, /* c116 > (STATUS_ABIOS_INVALID_SELECTOR) */ > ERROR_INVALID_THREAD_ID,/* c117 (STATUS_NO_LDT) */ > 0, /* c118 > (STATUS_INVALID_LDT_SIZE) */ > - 0, /* c119 > (STATUS_INVALID_LDT_OFFSET) */ > + ERROR_INVALID_LDT_OFFSET, /* c119 > (STATUS_INVALID_LDT_OFFSET) */ > 0, /* c11a > (STATUS_INVALID_LDT_DESCRIPTOR) */ > ERROR_BAD_EXE_FORMAT, /* c11b > (STATUS_INVALID_IMAGE_NE_FORMAT) */ > ERROR_RXACT_INVALID_STATE, /* c11c > (STATUS_RXACT_INVALID_STATE) */ You should add the other LDT ones while you are at it. -- Alexandre Julliard julli...@winehq.org
Re: ole32: Implement cross-process drag and drop.
On Mon, Jul 19, 2010 at 04:42:40PM +0100, Huw Davies wrote: > Fix a typo in a comment spotted by Detlef. > --- > dlls/ole32/ole2.c | 199 > 1 files changed, 168 insertions(+), 31 deletions(-) Sorry, this is still broken, please ignore. Huw.
Re: [PATCH 1/7] msvcp90: Added stub dll
Piotr Caban writes: > @@ -0,0 +1,3189 @@ > +#stub > ??$?5du?$char_tra...@d@std@@@std@@yaaav?$basic_istr...@du?$char_traits@d...@std@@@0...@aav10@a...@z > +#stub > ??$?5du?$char_tra...@d@std@@@std@@yaaav?$basic_istr...@du?$char_traits@d...@std@@@0...@aav10@p...@z > +#stub > ??$?5du?$char_tra...@d@std@@v?$alloca...@d@1@@std@@yaaav?$basic_istr...@du?$char_traits@d...@std@@@0...@aav10@aav?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@0@@Z > +#stub > ??$?5gu?$char_tra...@g@std@@@std@@yaaav?$basic_istr...@gu?$char_traits@g...@std@@@0...@aav10@a...@z > +#stub > ??$?5gu?$char_tra...@g@std@@@std@@yaaav?$basic_istr...@gu?$char_traits@g...@std@@@0...@aav10@p...@z > +#stub > ??$?5gu?$char_tra...@g@std@@v?$alloca...@g@1@@std@@yaaav?$basic_istr...@gu?$char_traits@g...@std@@@0...@aav10@aav?$basic_str...@gu?$char_traits@g...@std@@v?$alloca...@g@2@@0@@Z Why are they commented out? Why not define real stubs? -- Alexandre Julliard julli...@winehq.org
Re: [1/2] shlwapi/ordinal: Partially implement SHGetShellKey
Nikolay Sivov writes:
> @@ -2398,6 +2457,7 @@ START_TEST(ordinal)
> {
> hShlwapi = GetModuleHandleA("shlwapi.dll");
> is_win2k_and_lower = GetProcAddress(hShlwapi, "StrChrNW") == 0;
> +is_win9x = (GetVersion() & 0x8000);
You should never check the version, check for features instead.
--
Alexandre Julliard
julli...@winehq.org
Re: Fyi patch submission information on wiki updated for GitHub
On Mon, 2010-07-19 at 22:48 -0600, Vitaliy Margolen wrote: > On 07/19/2010 08:59 PM, Misha Koshelev wrote: > > Unfortunately, the more intuitive > > git format-patch -k --stdout HEAD~79..HEAD~78> /tmp/patch.old > > > > does not seem to result in patches that can be properly applied onto a > > different (upstream) remote (see below). > > Works fine here. You must have had some additional changes between upstream > and HEAD~79. Or your tree diverged from the origin (you had some of your > patches merged and not rebased) which is the same as above. Just to double check, I have the following layout: origin g...@github.com:misha680/wine.git (fetch) origin g...@github.com:misha680/wine.git (push) upstreamhttp://github.com/mirrors/wine.git (fetch) upstreamhttp://github.com/mirrors/wine.git (push) wine-gitgit://source.winehq.org/git/wine.git (fetch) wine-gitgit://source.winehq.org/git/wine.git (push) And the following patches: mi...@misha-d630:~/src/wine-d3dx9$ git log wine-git/master | head -n 5 commit 15c6057ce1454004ac8120fc079ef581fa0efb9c Author: Andrew Nguyen Date: Sun Jul 18 19:35:43 2010 -0500 shlwapi: Implement StrStrNIW. mi...@misha-d630:~/src/wine-d3dx9$ git log HEAD~79 | head -n 15 commit 8e7a26b5926c9246d7d33930ccffd27c8fb66cfe Author: Misha Koshelev Date: Wed Jul 7 09:59:52 2010 -0500 d3dx9: Test number of vertices for D3DXCreateSphere, retrieve vertex buffer. commit 15c6057ce1454004ac8120fc079ef581fa0efb9c Author: Andrew Nguyen Date: Sun Jul 18 19:35:43 2010 -0500 shlwapi: Implement StrStrNIW. Is there a better command to use? (fyi my upstream is called wine-git as per reference in my previous post and what I had added on wiki yesterday - I actually have it point to wine git rather than GitHub mirror). > > And you should really be using "--attach". It's always the better option, > especially for the series of patches. Duly noted. > > Vitaliy Misha
Quick legal question... teapot related
If I take a publicly available teaset: http://www.sjbaker.org/teapot/teaset.tgz And run it through a Microsoft function: http://msdn.microsoft.com/en-us/library/bb205470%28v=VS.85%29.aspx D3DXTesselateRectPatch for example And then copy the vertex buffer and index buffer and save them... Do I have the rights to use the vertex and index buffers? I am assuming yes... but wanted to double check first. Thank you Misha
Re: [PATCH 4/9] include: Add INameSpaceTreeControl, INameSpaceTreeControl2 and INameSpaceTreeControlEvents interface declarations.
David Hedberg writes:
> +HRESULT OnItemClick(
> +[in, annotation("__in")] IShellItem *psi,
> +[in, annotation("__in")] NSTCEHITTEST nstceHitTest,
> +[in, annotation("__in")] NSTCECLICKTYPE nstceClickType);
> +
> +HRESULT OnPropertyItemCommit(
> +[in, annotation("__in")] IShellItem *psi);
Please don't add these annotations, that's redundant. If we want that
sort of things in the generated headers one day we can make widl
generate them.
--
Alexandre Julliard
julli...@winehq.org
Re: [1/3] winemenubuilder: use windowscodecs for some ICO to PNG conversion
Damjan Jovanovic writes:
> +dosPNGFileName = wine_get_dos_file_name(pngFileName);
> +if (dosPNGFileName == NULL)
> +{
> +WINE_ERR("error converting %s to DOS file name\n", pngFileName);
> +goto end;
> +}
You can't rely on having a valid DOS name here. You should use the
\\?\unix format, or maybe better fix wine_get_dos_file_name() to do
that.
--
Alexandre Julliard
julli...@winehq.org
Re: D3DXCreateTeapot
On 19 July 2010 19:54, Ian Macfarlane wrote: > Following the question as to how to implement D3DXCreateTeapot, might I > suggest making it in the form of a wine glass? > > Given that is unlikely to negatively affect anything (indeed the entire > method does border on the ridiculous) I think it would make a nice hidden > touch. Sounds like a good idea. The DXDiag application could then use this API to render a nice Wine glass :). - Reece
Re: D3DXCreateTeapot
On 19 July 2010 19:54, Ian Macfarlane wrote: > Following the question as to how to implement D3DXCreateTeapot, might I > suggest making it in the form of a wine glass? > Given that is unlikely to negatively affect anything (indeed the entire > method does border on the ridiculous) I think it would make a nice hidden > touch. +1 :-D - d.
Re: [PATCH 1/2] include/shell32: Shell_MergeMenus should be declared in shlobj.h and exported by name. (try 2)
On Tue, Jul 20, 2010 at 10:51 AM, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=3576 > > Your paranoid android. > > > === WNT4WSSP6 (32 bit shlfileop) === > shlfileop.c:2195: Test failed: SHGetNewLinkInfoA succeeded > This is apparently not random chance, but as I can't reproduce it with my own crosscompiled binaries I guess that the issue is with how the test bot compiles the tests in this case.
Re: [PATCH 7/7] d3d10: Implement D3D10ReflectShader().
2010/7/19 Rico Schüller : > +e[i].SemanticName = get_semantic(data + name_offset); I'm not sure this will work, I was under the impression semantics can be arbitrary strings. (Which is also why d3d10core goes through the trouble of copying the string data.)
Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]
On 20 July 2010 04:37, Dan Kegel wrote: > Quoth Linus: > > "Ask the Wine people what strange open-function-from-hell they are > interested in." > > Full message follows. Discussion archived at e.g. > http://marc.info/?l=linux-kernel&m=127955270231189&w=2 > > That link didn't work for me, it's on the LKML archive here: http://lkml.org/lkml/2010/7/19/103 Luke.
Re: [PATCH 1/2] include/shell32: Shell_MergeMenus should be declared in shlobj.h and exported by name. (try 2)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3576 Your paranoid android. === WNT4WSSP6 (32 bit shlfileop) === shlfileop.c:2195: Test failed: SHGetNewLinkInfoA succeeded
Re: shell32_test64.exe shlexec: 5-6 DDE tests always fail on testbot W7PROX64
2010/7/20 Ilya Basin : > M> VM Status Number of test failures > M> WINEBUILD completed > M> W98SE completed 0 > M> WNT4WSSP6 completed 0 > M> W2KPROSP4 completed 0 > M> WXPPROSP3 completed 0 > M> W2K3R2SESP2 completed 0 > M> WVISTAADM completed 0 > M> W2K8SE completed 0 > M> W7PRO completed 0 > M> W7PROX64 completed 0 > M> W7PROX64 completed 5 > > M> === WINEBUILD (build) === > M> No build failures found > > M> === W98SE (32 bit shlexec) === > M> No test failures found > > M> === WNT4WSSP6 (32 bit shlexec) === > M> No test failures found > > M> === W2KPROSP4 (32 bit shlexec) === > M> No test failures found > > M> === WXPPROSP3 (32 bit shlexec) === > M> No test failures found > > M> === W2K3R2SESP2 (32 bit shlexec) === > M> No test failures found > > M> === WVISTAADM (32 bit shlexec) === > M> No test failures found > > M> === W2K8SE (32 bit shlexec) === > M> No test failures found > > M> === W7PRO (32 bit shlexec) === > M> No test failures found > > M> === W7PROX64 (32 bit shlexec) === > M> No test failures found > > M> === W7PROX64 (64 bit shlexec) === > > M> shell32: > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > M> shlexec.c:1738: Test failed: ShellExecuteEx(null, > "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) > failed: rc=29 err=2 > > Hi! I sent multiple different patches for shlexec and ever since > W7PROX64 (64 bit shlexec) is used by testbot, 5 DDE tests always fail > on it. I can't reproduce it on local W7PROX64: No shlexec tests fail. > > test.winehq.org has the same problem > http://test.winehq.org/data/d494bda30f1b5b9bc37f094bd8874d3aeeaf8840/win7_wtb-w7prox64-64/shell32:shlexec.html > > Another question: winetest64-latest.exe extracts individual test > binaries to the temp folder and runs them. How do you extract the > binaries without running? > > -- > > > > winetest64-latest.exe -x DIR (use --help or have a look in programs/winetest/main.c to see other possibilities). -- Nicolas Le Cam
Re: shell32_test64.exe shlexec: 5-6 DDE tests always fail on testbot W7PROX64
On 07/20/2010 07:51 AM, Ilya Basin wrote: Another question: winetest64-latest.exe extracts individual test binaries to the temp folder and runs them. How do you extract the binaries without running? winetest -x Usage: winetest [OPTION]... [TESTS] --helpprint this message and exit --version print the build version and exit -cconsole mode, no GUI -d DIRUse DIR as temp directory (default: %TEMP%\wct) -epreserve the environment -hprint this message and exit -m MAIL an email address to enable developers to contact you -pshutdown when the tests are done -qquiet mode, no output at all -o FILE put report into FILE, do not submit -s FILE submit FILE, do not run tests -t TAGinclude TAG of characters [-.0-9a-zA-Z] in the report -x DIRExtract tests to DIR (default: .\wct) and exit -- Cheers, Paul.
