December 2007 - Wine-devel - list.winehq.org

directX 10 and hlsl2glsl
by Sònia Xapellí Brú 10 Dec '07

10 Dec '07

I know there was some discussion concerning the use of hlsl2glsl and that it is not directly useful as it seems that the conversion to assembler is necessary in d3d9. Nevertheless, when it comes to d3d10,Shader Model 4 relies only in source code and forbids the programmers from implementing directly the assembler tokens. Therefore, I think that in this case the best solution, maximising the use of the graphic card capabilities goes mandatory to the use of the trasnlator and leaving up to the graphic card driver the compilation of GLSL. What do you think?

2 1

Re: wined3d: improve thread safety in IWineD3DSurfaceImpl_BltOverride
by Roderick Colenbrander 10 Dec '07

10 Dec '07

Hi, The patch itself could be correct in the sense that indeed there might be a missing ActivateContext. But we should avoid making recursive ENTER_GL's. Between the ENTER_GL block there is a call to IWineD3DDevice_Clear which also calls ENTER_GL. You could put a LEAVE_GL before it and an ENTER_GL after it but there is something else which you couldn't have known. A number of places in surface.c are messing with glDrawBuffer. These days activatecontext is also handling this, so in a number of places glDrawBuffer is redundant. This might be one of those places but I haven't checked that in detail. Stefan might be able to answer that. Regards, Roderick -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

1 0

Read RAM from Process
by Kai Lauterbach 10 Dec '07

10 Dec '07

Hi, at the moment I'm writing a little Linux based program to read some variables from a Windows application. But my problem is, that i can't access to the virtual memory of the Win App running under wine. I don't know how to do this. c/c++ isn't the problem but the right way to do it. I've already read the wineserver's main.c and fd.c but I think that it's not a good way to put a code into, which give's me the chance to read something. I need sth to connect, like /dev/mem or a network port. My second idea was the wine debugger. Is it possible to get access the application memory at runtime from this? I mean, without stopping the application? I hope you can help me and I've described my problem as clear as possible ;) Greetings, Kai -- Kai Lauterbach <lauterbach.kai(a)web.de>

2 1

Re: wined3d: improve thread safety in IWineD3DSurfaceImpl_BltOverride
by Stefan Dösinger 10 Dec '07

10 Dec '07

Am Montag, 10. Dezember 2007 12:39:51 schrieb Alexander Dorofeyev: > Fixes crash in Aliens vs Predator 2 loading screen (bug # 4513 > http://bugs.winehq.org/show_bug.cgi?id=4513) > > --- > dlls/wined3d/surface.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) Looks good to me

1 0

[press] Phoronix compares 7 versions of Wine
by Jonathan Ernst 09 Dec '07

09 Dec '07

Hello, What do you think about their tests and results ? http://www.phoronix.com/vr.php?view=11539 "The performance in the fourteen 3DMark 2001 SE and 3DMark 2003 tests were fairly consistent in the releases between WINE 0.9.44 and WINE 0.9.50 -- generally only swaying a few frames in either direction -- though the performance overall has slightly declined and we were surprised by a few of the results."

4 4

GetMessage related Jagged Alliance 2 regression
by Alexander Dorofeyev 09 Dec '07

09 Dec '07

Hello. I get freezes in Jagged Alliance 2 (seems to be tied to moving the mouse). It used to work in older versions. The game doesn't lock up totally (the music and sounds continue to play normally, for example), but the screen doesn't redraw and it doesn't respond to input. Activating some other window than the game window (if it's not full screen) usually unfreezes it. Bisect pointed to this change: http://source.winehq.org/git/wine.git/?a=commitdiff;h=2896540a34a18b8aff848… server: Set the queue mask directly in get_message to avoid an extra server call. I did a bit of debugging and it looks like the game is getting stuck within a GetMessageW call. It stays in that while loop in GetMessage, mostly in MsgWaitForMultipleObjectsEx. If the mouse is moved, then it awakes, gets to PeekMessageW, from there it goes to peek_message which returns false and so PeekMessageW returns false and the game goes back to waiting within GetMessageW. peek_message returns false, because in a first call to server it gets a MSG_HARDWARE (mouse) message which it drops for some reason, then it clears PM_QS_ flags and so in a next call to server it can't get a WM_TIMER message despite an expired timer seems to be ready in the queue. I'm not sure what would be a proper fix, although I did find out that commenting out this line in peek_message() if (HIWORD(flags)) flags = PM_QS_SENDMESSAGE | LOWORD(flags); makes the game playable. Maybe this clearing of PM_QS_* flags shouldn't be done in case when the message gets dropped? Before that commit nothing was passed in flags high word, which is probably why this problem wasn't happening.

3 3

ALLUSERSPROFILE Patch
by Austin English 09 Dec '07

09 Dec '07

While looking at bug 7292 (http://bugs.winehq.org/show_bug.cgi?id=7292) I wrote a patch to implement ALLUSERSPROFILE. I looked on MSDN/Google for the dirid for this shell folder, but can only find dirids for it's subdirectories. For example: 16406 All Users\Start Menu 16407 All Users\Start Menu\Programs 16408 All Users\Start Menu\Programs\Startup 16409 All Users\Desktop 16415 All Users\Favorites 16419 All Users\Application Data Looking for an opinion on which would be better, to map ALLUSERSPROFILE to %10%\profiles\All Users (This is how my current patch does it) Or I could continue looking for the windows implementation of it, which so far hasn't proven very fruitful. Patch is attached.

2 1

msi: fix missing alloc check [try 2]
by Lionel_Debroux 09 Dec '07

09 Dec '07

Removed a level of indentation, following feedback of James Hawkins. 2007-12-09 Lionel Debroux <lionel_debroux(a)yahoo.fr> * dlls/msi/dialog.c: msi: fix missing alloc check.

1 0

msi: fix memory leaks (found by Smatch) [try 2]
by Lionel_Debroux 09 Dec '07

09 Dec '07

Fixed stupid mistake pointed by James Hawkins. 2007-12-09 Lionel Debroux <lionel_debroux(a)yahoo.fr> * dlls/msi/database.c: msi: fix memory leaks (found by Smatch).

1 0

msi: fix missing alloc check.
by Lionel_Debroux 09 Dec '07

09 Dec '07

"msi_dialog_list_box" in dlls/msi/dialog.c gets flagged by Michael Stefaniuc's unfree-wine.pl script. * As far as I can see, "info", allocated line 2203, is not used before the return that leaks it (line 2214), neither in a direct nor an indirect (macro) way. But maybe the "fail-fast" behaviour is intended (because if allocation of "info" fails, there are chances the allocation of "control" would fail, too) ? * While looking at the source of the functions called by "msi_dialog_list_box" to make sure they didn't use "info", I spotted a call to msi_alloc, whose result is not checked. Therefore, the subsequent lines may write to NULL+some_offset. The patch contains only the fix for the latter problem, because I'm not 100% sure that the memory leak can be solved by moving the allocation of info after the call to "msi_dialog_add_control", without ill side effects (e.g. msi_dialog_add_control calls msi_dialog_create_window, which calls CreateWindowExW). 2007-12-09 Lionel Debroux <lionel_debroux(a)yahoo.fr> * dlls/msi/dialog.c: msi: fix missing alloc check.

2 1