wine-devel December 2007

wine-devel@winehq.org

139 participants
264 discussions

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 10 Dec '07

10 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

ALLUSERSPROFILE Patch
by Austin English 10 Dec '07

10 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

Re: msi: fix memory leaks (found by Smatch).
by James Hawkins 09 Dec '07

09 Dec '07

On Dec 9, 2007 4:44 AM, Lionel_Debroux <lionel_debroux(a)yahoo.fr> wrote: > "msi_build_insertsql_data" and "MSI_DatabaseImport" in > dlls/msi/database.c get flagged by Michael Stefaniuc's unfree-wine.pl > script. > > It looks there are more leaks than unfree-wine.pl reports, due to > constructs of the form > ptr = msi_realloc(ptr, size); > Fixed those as well. > > 2007-12-09 Lionel Debroux <lionel_debroux(a)yahoo.fr> > * dlls/msi/database.c: > msi: fix memory leaks (found by Smatch). > - columns = msi_realloc(columns, sql_size * sizeof(WCHAR)); - if (!columns) + temp_columns = msi_realloc(columns, sql_size * sizeof(WCHAR)); + if (!temp_columns) + { + HeapFree( GetProcessHeap(), 0, columns); return NULL; + } lstrcatW(columns, expanded); This is wrong. There's no guarantee that realloc returns the same position in memory. -- James Hawkins

1 0

← Newer
1
...
17
18
19
20
21
22
23
...
27
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2007