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

Is wine reporting the right value for MaxVertexBlendMatrices?

by Julio Fernandez

Hi, I don't know if this is the right place to post this, but sorry if not, and I'd like to be pointed to the right one I have been working last weeks on making the game Everquest to work under wine, since 0.9.49 it was working flawlesly, but most models were not shown properly. This corresponds with bug http://bugs.winehq.org/show_bug.cgi?id=8357. These are my findings: The main executable is eqgame.exe it typically accesses D3D through a custom dll eqgraphicsdx9 which interacts with D3D itself or through d3dx9_30.dll Using channels and adding some extra messages into certain source files I got to track a possible reason: The game was declaring vertex lists with a vertex of type '0xfe' and +189 offset Sadly, I could not get any extra information tracking just from source code, so I had to run the game under Windows on a computer and using windbg to debug it, while running the same time on another computer the game under Debian etch using winedbg to debug, and so tracing both programs in assambler (I burnt my eyelashes there!), the fact that I could have d3d dll symbols availables on the windows box was the key here, I really missed winedbg to be able to read pdb files :( After many hours I was able to track down the reason, and to my surprise it seems its not wine's fault (for the most of it) The 'troublesome' vertexes are apparently blended ones in mesh declarations. When d3dx9_30 calls ConvertToIndexedBlendedMesh, it calls GetDeviceInfo to get the device capabilites, in the end wine returns the capabilites through IWineD3DImpl_GetDeviceCaps in wine/dlls/wined3d/directx.c Here comes the fun thing, the attribute MaxVertexBlendMatrices in D3DCAPS9, from (MSDN): "Maximum number of matrices that this device can apply when performing multimatrix vertex blending. For a given physical device, this capability may vary across Direct3D devices depending on the parameters supplied to IDirect3D9::CreateDevice." At the moment is set in wine as *pCaps->MaxVertexBlendMatrices = GL_LIMITS(blends) which results in a value of 0 (at least in my Linux computer/build), while under Windows (XPSP2 DX9c) results in a value of 4 d3dx9_30 has a check right after the capabilites are returned comparing that value with 2, resulting in different code paths for the remaining of MaxVertexBlendMatrices function, when the value was 0 both Linux and Windows (hacking the returned value to be 0) make those odd '0xfe' vertexes to be inserted (in Linux that makes the models to not be shown, in Windows it makes eqgame.exe to crash) I proceeded then to try to 'hack' wine to return a value of 4, adding the line pCaps->MaxVertexBlendMatrices=0x4; Before returning from function IDirect3DDevice9Impl_GetDeviceCaps(LPDIRECT3DDEVICE9 iface, D3DCAPS9* pCaps) at wine/dlls/d3d9/directx.c The result: MaxVertexBlendMatrices runs the same path as Windows does, the odd '0xfe' vertexes are not generated and the models work are now shown as expected My apologies for the long post, but I thought it would be handy to tell the full story to justify calling your atention on this - d3dx9_30 ConvertToIndexedBlendedMesh shows an 'odd' behavior when MaxVertexBlendMatrices capabilites in D3DCAPS9 is 0 - Is wine reporting the right value for MaxVertexBlendMatrices ??? As it seems the game works flawlesly in wine when it's hacked to be 4 (I don't know if this 'hack' would affect other programs in any other way

Feb. 9, 2008

No win95 tests after commit "tests: Add a helper routine to wait for a child process and propagate its result correctly."

by Paul Vriens

Hi, This commit: 05c7174909e975fc7d0ebf9a59bb07160c09d66d introduces a new helper script but uses InterlockedExchangeAdd that is not available on win95. This means that none of the tests run on win95 anymore. -- Cheers, Paul.

Feb. 9, 2008

Re: Code quality (was Re: comctl32: Fix invalid syntax)

by Stefan Dösinger

Am Samstag, 9. Februar 2008 02:13:34 schrieb L. Rahyen: > On Friday February 8 2008 04:41:28 Bang Jun-young wrote: > > That's the main reason why Wine keeps crashing every time I give it a > > try with my Windows apps. > > ... > > I see something fundamentally wrong with development process. > > I think that current development process isn't a problem at all. In fact > AJ is very good at what he is doing! > As far as I understand your patch ("comctl32: Fix invalid syntax.") was > rejected just because you forgot to add proper (descriptive) changelog > entry. What is the real problem is the lack of testers (who report > regressions and bugs) and developers. This is why WINE still has a lot of > bugs, regressions are quite common thing to happen, etc. To fix this, more > people should read wine-patches and test patches before they are committed, > more people should write bug reports, more people should be involved in the > development, and so on. Unfortunately, not all people have enough time for > such tasks. However, WINE is pretty usable today. I'd say we need more tests. Any patch that breaks a test from our testsuite when AJ runs them prior to committing is rejected

Feb. 9, 2008

Re: Bugzilla: Remove obsolete components

by Jan Zerebecki

On Mon, Jan 28, 2008 at 11:52:56PM -0600, James Hawkins wrote: > On Jan 28, 2008 1:12 PM, Austin English <austinenglish(a)gmail.com> wrote: > > I just finished moving over the last of the obsolete components. > > _obsolete_binary, _obsolete_directx, and _obsolete_gui can all be > > removed now. Done. > rename: > > wineps-driver -> wineps.drv > x11-driver -> winex11.drv > > add: > > wintab32 > msacm32 > wintrust > rasapi32 > msvfw32 Done, except: > winmm&mci -> winmm This was discussed on IRC and the agreement was to have them both in the same component because they are so tightly integrated. Jan

Feb. 9, 2008

Re: msvcrt: Fix EOF behavior on read from pipe

by Damjan Jovanovic

On Feb 8, 2008 8:03 PM, Dan Kegel <dank(a)kegel.com> wrote: > Damjan wrote > > The problem is more general: consoles *also* break on short reads > > (Java 1.4.1's gdb takes 1 command then quits because it thinks it's > > the end of file) > > Try my patch, it should help that case. It only helps if I change + if (type != FILE_TYPE_PIPE) { to + if (type != FILE_TYPE_PIPE && type != FILE_TYPE_CHAR) { > > I'm sure short read != end of file for ordinary > > files either, especially in *nix where read() can easily be > > interrupted by a signal. > > If you can come up with an example of a real > app or even a test case that is currently broken, > I'll gladly try to fix it. Well, if the MSDN is correct about ReadFile() returning only when the requested number of bytes is read unless an error occurs (it's a big if :-), then it would be an NTDLL NtReadFile() issue where pread() returns too soon due to a signal. But I haven't been able to get a signal to interrupt pread() in my tests, maybe wine handles signals. > - Dan > Thank you Damjan

Feb. 9, 2008

Re: user32: Implement GetWindowModuleFileName with tests

by Dmitry Timoshkov

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > I've tried to do the GetWindowLongPtr GWLP_HINSTANCE thing but it > seems to always return 0 in wine, which according to msdn means error, > but it could just be not set in wine. Perhaps GWLP_HINSTANCE needs to > be set when the window is being created? It works just fine in Wine, have a look at dlls/user32/tests/class.c, test_instances(). -- Dmitry.

Feb. 9, 2008

Re: Code quality (was Re: comctl32: Fix invalid syntax)

by L. Rahyen

On Friday February 8 2008 04:41:28 Bang Jun-young wrote: > That's the main reason why Wine keeps crashing every time I give it a > try with my Windows apps. > ... > I see something fundamentally wrong with development process. I think that current development process isn't a problem at all. In fact AJ is very good at what he is doing! As far as I understand your patch ("comctl32: Fix invalid syntax.") was rejected just because you forgot to add proper (descriptive) changelog entry. What is the real problem is the lack of testers (who report regressions and bugs) and developers. This is why WINE still has a lot of bugs, regressions are quite common thing to happen, etc. To fix this, more people should read wine-patches and test patches before they are committed, more people should write bug reports, more people should be involved in the development, and so on. Unfortunately, not all people have enough time for such tasks. However, WINE is pretty usable today. > Since 1993, Wine has never gotten to the > point where everybody could rely on it for his daily work. It has as > awfully many bugs as Win95. WINE can work reliably even with very complex programs (such as Photoshop CS - I use it pretty often). And if you don't see BIG improvement in last years you either tried very few Windows programs or you are very unlucky... In my practice WINE run most of the programs I try (well, I didn't tried thousands of Windows programs and there is no "hardcore" gamers in my family so my statistic may be biased). In fact, it is so good that I typically can rely on it to run any program I'm downloading from the Internet (success rate for me is more than 85% for "small" and "average" programs/games downloadable for free from the Internet). And if Windows program(s) work correctly on WINE, cases of "random" crashes are very rare. They (generally) do exist but most of Windows programs aren't affected by such bugs - much more often you find repeatable crashes after specific sequence(s) of steps. And your statement "Wine has never gotten to the point where everybody could rely on it for his daily work" is strange. In fact it is true for Windows too (Windows never gotten to the point where everybody could rely on it for his daily work). Maybe you just mean that WINE doesn't work well for you and some (or maybe even most) other people? But working well for some people or for nobody is very different things... There is a lot of people who use WINE for their daily tasks. For example, I and whole my family use Linux and WINE on daily basis (because of dependency on some Windows software and Windows games). There is no Windows installed on our computers (only I have Windows XP in VMWare for my very specific purposes to run Autodesk products). In my practice WINE and Linux are absolutely stable (if no bugs in WINE triggered by the program of course). In fact, I have trading station for Windows working 24 hours per day on my Linux server with WINE (if trading station fail or crash, I potentially can lose real money). And for this purpose (which by definition requires high stability) WINE+Linux works MUCH better than Windows XP. And your comparison of WINE with Windows 95 isn't true at all. Did you actually ever tried to use Windows 95? It will fail MUCH more often than WINE, and WINE can run more Windows programs than Windows 95 (I have it in VMWare so I really tested this with some programs year ago or so, "just for fun"). Even Windows 98 cannot run many important programs such as Photoshop (it require at least Windows 2000). And Windows 95/98 have a LOT of "random" crashes; WINE is much better - for many programs it can work for months 24 hours per day without problems, and even if it crashes in some cases, other programs aren't affected (especially if they are launched from different prefix). Everything above is my personal experience, and for some users it may be worse. But for me, WINE work good enough for daily use, even for very important applications. So you can consider my story as yet-another-success-story-of-using-WINE. Obviously, this doesn't mean that WINE is good enough for everyone... But at least it is good enough for me, my family and some of my friends. There is some minor problems (for example, my brother have some games that don't work on WINE at all but he doesn't care very much about this) so WINE isn't perfect of course... But I just want to say that it is good enough for daily work and gaming at least for some people, and a lot of Windows software is usable on Linux with WINE. Personally, I think that AJ and all other WINE developers are doing very great and important work! Big thanks to all of them...

Feb. 9, 2008

Re: user32: Implement GetWindowModuleFileName with tests

by Maarten Lankhorst

Hi folks, 2008/2/8, Dmitry Timoshkov <dmitry(a)codeweavers.com>: > "Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: > > >> + hproc = OpenProcess(PROCESS_QUERY_INFORMATION, 0, pid); > > > > After reading MSDN and guessing from the API name shouldn't it > > simply fetch GWL_HINSTANCE and call GetModuleFileName on it? > > And after looking at GetModuleFileNameW implementation, shouldn't it > treat hModule == 0 as GetModuleHandle(0) and not be 16-bit specific? > Guess this all needs a test case. I've tried to do the GetWindowLongPtr GWLP_HINSTANCE thing but it seems to always return 0 in wine, which according to msdn means error, but it could just be not set in wine. Perhaps GWLP_HINSTANCE needs to be set when the window is being created? Cheers, Maarten.

Feb. 8, 2008

AppDB Issues

by Jeremy Newman

As many of you have noticed we've been having a bit of server trauma this past month. The issue boils down to a bug somewhere in mysqld. We are still trying to find the exact cause of the bug. We do have some leads. I just wanted to do a brain dump on wine-devel here before I go on Vacation for a week. The problem: mysqld will randomly eat up all resources on the system until the server is completely unresponsive to anything but pings. My band-aids thus far: 1. mysql is now running at a nice of 1. This should allow us to at least ssh in and kill it if it gets out of control again. 2. I've removed InnoDB table support to save on memory. Not many tables where using it anyway, and nothing is using transaction support at this time. 3. I've patched the appdb to use memcached for session management. This will reduce some load on the DB as the session table was busiest and slowest table of the appdb. These fixes should give longer uptime, but they are not solving the core issue. While I'm gone, if the server goes offline again, please contact Alexandre or Jeremy White. They can kick proverbial butt of the server to get it going again. Lastly, sorry for the issues. -Newman "We do what we must because we can" - GLaDOS

Feb. 8, 2008

re: msvcrt: Fix EOF behavior on read from pipe

by Dan Kegel

Damjan wrote > The problem is more general: consoles *also* break on short reads > (Java 1.4.1's gdb takes 1 command then quits because it thinks it's > the end of file) Try my patch, it should help that case. > I'm sure short read != end of file for ordinary > files either, especially in *nix where read() can easily be > interrupted by a signal. If you can come up with an example of a real app or even a test case that is currently broken, I'll gladly try to fix it. - Dan

Feb. 8, 2008