March 2008 - Wine-Devel - list.winehq.org

Re: midl question

by Robert Shearman

Alistair Leslie-Hughes wrote: > Hi Rob, > > What work would need to be done to get widl to support __stdcall? The issue is that widl doesn't support functions in typedefs. Further issues are that widl doesn't support writing out the function typedef once parsed and widl doesn't store the calling convention for the function and so it currently can't be written out correctly. -- Rob Shearman

March 31, 2008

Re: user32: Implement BroadcastSystemMessage, try 5.1

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > >> I remember sending the patch for this exact thing a while back, which you of >> course refused under the same pretense - showing a real life app that >> depends on it. So if tests are not a real life app that shows a difference >> between Wine and windows - then why do we bother with Wine at all? At least >> should change the moto to "might run some apps with loads of problems and >> never be 100% compatible". >> >> One for sure will find an app that in one way or another depends on >> undocumented windows behavior. So if a test can be written to show a >> difference between Wine and windows. Then this difference should be fixed in >> Wine. > > It all comes down to where we want to spend our efforts. It's very easy > to write a million last error tests, and then we'd have to spend months > fixing Wine by adding save/restore of last error all over the place, for > no benefit at all. Our time is much better spent fixing things that > actually matter, and not making the code uglier for things that don't. > But that's the thing. How can you definitively say that there isn't a program that affected by this? And this sort of difference might affect number of programs in a ways that really hard to catch. Vitaliy.

March 31, 2008

Some considerations about the Wine FUSE project for GSoC

by Kai Blin

Hi folks, after another chat about Wine's goals in respect to FUSE file systems on IRC, I just wanted to point the students who applied for this project already (I've Bcced them) at the goals Wine has for this GSoC project. For Wine, the goal is to create prototype FUSE file systems so we can figure out if this approach is useful to Wine at all. There is no immediate goal to include the file systems into Wine in the near future, we first want to know if they're what we need. I think it's important to be clear and outspoken about this so nobody starts working on this under the wrong assumptions. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

March 31, 2008

Re: Direct3D shader compiler infrastructure

by H. Verbeet

On 31/03/2008, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > How do we call this library? wineshader.dll? > Sounds ok to me.

March 31, 2008

Re: Direct3D shader compiler infrastructure

by Stefan Dösinger

Am Montag, 31. März 2008 13:17:49 schrieb H. Verbeet: > Our current intermediate representation is essentially a list of > SHADER_OPCODE and SHADER_OPCODE_ARG elements. We probably want to move > the bytecode parsing into the shader library and then generalize the > intermediate representation a bit. It would also mean separating > parsing and code generation a bit more than it currently is. Yes, this is my idea. > It doesn't compile the shaders, but it certainly generates shader > source. I'm not sure what it does in terms of configuring GL state? > Wrt state like vertex declarations, bound textures etc, there's no > reason we can't pass that to the code generator (and it's probably a > good idea to pass that state a bit more explicitly anyway). At this > point there isn't a real reason to move shader code generation into > this library, but it should certainly be possible. You're right, we could just pass the GL state to the shader lib. Generating a shader with ATI_fragment_shader or NV_texture_shader requires opengl calls though, so I don't think it is desireable to move that to the shader utility lib. How do we call this library? wineshader.dll?

March 31, 2008

Re: Direct3D shader compiler infrastructure

by Stefan Dösinger

Am Montag, 31. März 2008 13:17:49 schrieb H. Verbeet: > Our current intermediate representation is essentially a list of > SHADER_OPCODE and SHADER_OPCODE_ARG elements. We probably want to move > the bytecode parsing into the shader library and then generalize the > intermediate representation a bit. It would also mean separating > parsing and code generation a bit more than it currently is. Yes, this is my idea. > It doesn't compile the shaders, but it certainly generates shader > source. I'm not sure what it does in terms of configuring GL state? > Wrt state like vertex declarations, bound textures etc, there's no > reason we can't pass that to the code generator (and it's probably a > good idea to pass that state a bit more explicitly anyway). At this > point there isn't a real reason to move shader code generation into > this library, but it should certainly be possible. You're right, we could just pass the GL state to the shader lib. Generating a shader with ATI_fragment_shader or NV_texture_shader requires opengl calls though, so I don't think it is desireable to move that to the shader utility lib. How do we call this library? wineshader.dll?

March 31, 2008

Re: Direct3D shader compiler infrastructure

by H. Verbeet

On 31/03/2008, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Montag, 31. März 2008 08:54:18 schrieb H. Verbeet: > > Looks reasonable enough in general. I guess it would make sense to > > create some kind of "shader utilities" library that can be used from > > both wined3d and d3d9x. > > Right, that is my plan. Although I am not sure yet in which way wined3d would > use it. It might be best off by just parsing the asm tree itself. > Our current intermediate representation is essentially a list of SHADER_OPCODE and SHADER_OPCODE_ARG elements. We probably want to move the bytecode parsing into the shader library and then generalize the intermediate representation a bit. It would also mean separating parsing and code generation a bit more than it currently is. > > You could in principle even move GLSL/ARB code > > generation in there, although that isn't required of course. > > Not really, because the GLSL/ARB code generator doesn't compile shaders, it > configures the GL pipeline. As such, it depends on many other things like the > textures that are bound, the vertex declaration, etc. > It doesn't compile the shaders, but it certainly generates shader source. I'm not sure what it does in terms of configuring GL state? Wrt state like vertex declarations, bound textures etc, there's no reason we can't pass that to the code generator (and it's probably a good idea to pass that state a bit more explicitly anyway). At this point there isn't a real reason to move shader code generation into this library, but it should certainly be possible.

March 31, 2008

Firefox 3 beta 4 working, only a couple bugs...

by Dan Kegel

I tried Firefox 3 beta 4 just now, and there were a few bugs that stood out in the first few minutes: 12305 Firefox 3 beta 4 font problem: colon displayed as 0038 unicode glyph-missing glyph 12306 Firefox 3 beta shows one-pixel-high black line when rendering some images 12307 firefox 3 beta 4 crash on some web pages Youtube seemed slow and hangy on the first video I tried, http://www.youtube.com/watch?v=jwMj3PJDxuo although it was fine in native firefox at the same time; perhaps the Windows version of the flash plugin is less resistant to network errors -- or Wine doesn't support some network feature that only matters during bad internet weather. That same video was fine later, as was a different video http://www.youtube.com/watch?v=OGxdgNJ_lZM (both worth watching, btw). It also output quite a few messages like fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:font:ExtTextOutW flags ETO_NUMERICSLOCAL | ETO_NUMERICSLATIN | ETO_PDY unimplemented Firefox 3 rc1 will be out in May, and release will be in early June, according to http://blog.wired.com/monkeybites/2008/03/mozilla-final-v.html Given that a lot of people have in the past used windows Firefox in wine to run native plugins, maybe we should get firefox 3 working well. Probably only five or six main issues. - Dan

March 31, 2008

Re: Direct3D shader compiler infrastructure

by Stefan Dösinger

Am Montag, 31. März 2008 08:54:18 schrieb H. Verbeet: > On 31/03/2008, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > With WineD3D working on the same language, we have to share the language > > definition between the shader library and WineD3D, or put the shader > > compiler into WineD3D as well. I do not like the 2nd way, as it puts > > things together that don't have to be in one lib, and wastes runtime > > memory. A 3rd way I have to consider was a SlReadShader() function with > > callbacks which takes over the current role of shader_generate_main() in > > WineD3D. I am not quite convinced by this either. > > Looks reasonable enough in general. I guess it would make sense to > create some kind of "shader utilities" library that can be used from > both wined3d and d3d9x. Right, that is my plan. Although I am not sure yet in which way wined3d would use it. It might be best off by just parsing the asm tree itself. > You could in principle even move GLSL/ARB code > generation in there, although that isn't required of course. Not really, because the GLSL/ARB code generator doesn't compile shaders, it configures the GL pipeline. As such, it depends on many other things like the textures that are bound, the vertex declaration, etc.

March 31, 2008

Re: [1/2] WineD3D: Support clipplanes with GLSL shaders

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > From 1cb24469eb0f53f7e67dea2c7659ad070b86f21d Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Fri, 28 Mar 2008 16:11:06 +0100 > Subject: [PATCH] WineD3D: Support clipplanes with GLSL shaders > > This patch removes the shader clipplane disabling code from the > common/fixed function state table and enables GLSL shaders to write to > the clipcoord output attribute. The ARB specific clipplane disabling is > handled in the ARB shader backend. It doesn't work for me: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:4738: Test failed: vs_3_0 returned color 0x00110000, expected 0x00203366 visual.c:4743: Test failed: vs_1_1 returned color 0x00110000, expected 0x00808080 visual.c:4748: Test failed: vs_2_0 returned color 0x00110000, expected 0x00000000 visual.c:4929: Test failed: ps_3_0 returned color 0x00193300, expected 0x0080ffe5 make[2]: *** [visual.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

March 31, 2008