wine-devel July 2007

wine-devel@winehq.org

112 participants
227 discussions

Re: [3/7] WineD3D: Allocate render target management members in Init3D
by Alexandre Julliard 25 Jul '07

25 Jul '07

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > From 05154939b9123ff44c9e3ec0417c31ccba2a8716 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Mon, 16 Jul 2007 19:49:34 +0200 > Subject: [PATCH] WineD3D: Allocate render target management members in Init3D > > GL_LIMITS() is not always available in CreateDevice, thus the alloc code > has to be in Init3D. To avoid memory leaks and keep things consistent > the free calls are moved from Release to Uninit3D. ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so d3d.c && touch d3d.ok wine: Unhandled page fault on read access to 0x00000000 at address 0x61bf2a2c (thread 0019), starting debugger... WineDbg starting on pid 0017 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x61bf2a2c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:61bf2a2c ESP:0033fa10 EBP:0033fa58 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:61c8c8d8 ECX:001e8678 EDX:61c8d600 ESI:00000000 EDI:001e8678 Stack dump: 0x0033fa10: 001e8678 00000000 00000000 60917764 0x0033fa20: 00000000 00110000 00000002 61c696e1 0x0033fa30: 00001302 00340020 00000000 00000000 0x0033fa40: 00000000 00000000 61bf281b 61c8c8d8 0x0033fa50: 001e86a0 001e8678 0033fa88 61c1cbb0 0x0033fa60: 0015f1a0 001e8678 00340020 61c37ff8 Backtrace: =>1 0x61bf2a2c IWineD3DDeviceImpl_ResourceReleased+0x21c(iface=0x15f1a0, resource=0x1e8678) [/home/julliard/wine/wine/dlls/wined3d/device.c:6456] in wined3d (0x0033fa58) 2 0x61c1cbb0 IWineD3DResourceImpl_CleanUp+0x100(iface=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/wined3d/resource.c:89] in wined3d (0x0033fa88) 3 0x61c4109f IWineD3DSurfaceImpl_Release+0xbf(iface=0x1e8678) [/home/julliard/wine/wine/dlls/wined3d/surface.c:414] in wined3d (0x0033fac8) 4 0x6072e685 IDirectDrawSurfaceImpl_Destroy+0xe5(This=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/ddraw/surface.c:229] in ddraw (0x0033faf8) 5 0x6072e953 IDirectDrawSurfaceImpl_Release+0x133(iface=0x1e8580) [/home/julliard/wine/wine/dlls/ddraw/surface.c:425] in ddraw (0x0033fb48) 6 0x6072e37d IDirectDrawSurfaceImpl_DeleteAttachedSurface+0xfd(iface=0x19f6f0, Flags=0x0, Attach=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/ddraw/surface.c:991] in ddraw (0x0033fb78) 7 0x6072e664 IDirectDrawSurfaceImpl_Destroy+0xc4(This=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/ddraw/surface.c:220] in ddraw (0x0033fba8) 8 0x6072e953 IDirectDrawSurfaceImpl_Release+0x133(iface=0x19f6f0) [/home/julliard/wine/wine/dlls/ddraw/surface.c:425] in ddraw (0x0033fbf8) 9 0x606db585 func_d3d+0x1ab5() [/home/julliard/wine/wine/dlls/ddraw/tests/d3d.c:151] in ddraw_test (0x0033fe58) 10 0x606ed9c8 run_test+0x128(name=0x1103b6) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:389] in ddraw_test (0x0033fea8) 11 0x606ee05d main+0x14d(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:437] in ddraw_test (0x0033fed8) 12 0x606ee12b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ddraw_test (0x0033ff08) 13 0x6041059e start_process+0xee(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:820] in kernel32 (0x0033ffe8) 14 0x60027af7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x61bf2a2c IWineD3DDeviceImpl_ResourceReleased+0x21c [/home/julliard/wine/wine/dlls/wined3d/device.c:6456] in wined3d: cmpl 0x0(%eax,%esi,4),%ecx 6456 if (This->fbo_color_attachments[i] == (IWineD3DSurface *)resource) { -- Alexandre Julliard julliard(a)winehq.org

1 0

Comments on winefontcfg tool?
by Nigel Liang 25 Jul '07

25 Jul '07

Hi, I submitted a font configure tool a few days ago that lets the user configure system and menu fonts more easily. The tool is especially helpful to asian and middle-eastern users where the fonts installed may differ greatly from user to user and where the default font size is way too small for some users. I know that ideally we should let wine figure out all this based on fonts used in X or something, but for now, something like this is useful to prevent users from digging into the registry looking for entries to modify (and potentially breaking something.....). Any comments on this would be greatly appreciated. -Nigel

2 1

Re: [PATCH] monthcal todo_wine now passes
by Alexandre Julliard 25 Jul '07

25 Jul '07

Marcus Meissner <marcus(a)jet.franken.de> writes: > this test succeeds for me. Not for me... -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: cmd:batch: Check for a context is added
by Ann & Jason Edmeades 25 Jul '07

25 Jul '07

>I did a simple test here and it works, although I would like to test 2 >scnarios: >a calls b which runs c >a runs b runs c I test that and found the previous email was very slightly wrong. I've coded and sent my new patch into wine-patches as it corrects an identical trap to what you were seeing plus fixes the a runs b runs c case. Can you please try that and confirm it resolves the problem for you as well. Hope this helps Jason

2 1

gdiplus progress and pptview
by Evan Stade 25 Jul '07

25 Jul '07

Hi, As an update for those who don't use pptview daily (as I do), built-in gdiplus is able to render most presentations that native can render. (By native I mean native gdiplus in wine, not pptview.exe in windows.) In fact, I cannot at the moment find a presentation that native can render but built-in cannot (whereas I can find cases to the contrary, pending today's patches). So it would be helpful if people could start using built-in gdiplus for their favorite gdiplus-dependent programs and reporting bugs. Native gdiplus looks better (and probably always will, since it can do its own rendering, whereas the built-in implementation relies on gdi and the underlying drivers), but built-in should be faster. Also if you are going to try to use pptview in wine with either native or built-in gdiplus, I would start with simple presentations and work up, rather than starting with a 50-page real-world presentation. -- Evan Stade

1 0

Wine and virus security
by Alessandro Pignotti 24 Jul '07

24 Jul '07

Hi everyone, I've seen recently a discussion about securing a host running wine denying write access out of wine home using SElinux. I think that this feature would be easily enough implemented by wine itself, maybe by letting the user set access permission on wine drives "c: d: etc" and enforcing then in CreateFile calls. Are there any other APIs that should be considered apart CreateFile? Greetings, Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome

2 1

Re: cmd:batch: Check for a context is added
by Ann & Jason Edmeades 24 Jul '07

24 Jul '07

> We need to check context before than refer to context -> skip_rest . But we have just referred to it higher up, and I didn't think it was valid to get into this routine without a context. Whats the problem you are trying to fix? Jason

2 2

Re: kernel32: Additional SetThreadPriorityTest (try 6)
by James Hawkins 24 Jul '07

24 Jul '07

On 7/24/07, Matt Jones <mattj(a)google.com> wrote: > Reformatted tests to address James' email > + SetThreadPriority(curthread,min_priority); + SetLastError(0xdeadbeef); + result = SetThreadPriority(curthread,min_priority-1); Is there a reason you don't check the result from the first call to SetThreadPriority? If the call hypothetically fails (something you have to assume can happen), then the rest of the test is not valid. -- James Hawkins

2 2

Re: kernel32: Additional SetThreadPriorityTest (try 5)
by James Hawkins 24 Jul '07

24 Jul '07

On 7/24/07, Matt Jones <mattj(a)google.com> wrote: > On 7/24/07, Matt Jones <mattj(a)google.com> wrote: > > Correctly checks return code of SetThreadPriority before checking > > error (address comment by Alexandre) > > > + SetThreadPriority(curthread,min_priority); + result = SetThreadPriority(curthread,min_priority-1); + + if (!result) exitCode = GetLastError(); + else exitCode = ERROR_SUCCESS; + + todo_wine { + ok(exitCode == ERROR_INVALID_PARAMETER, You're going about this a weird way, and you're still not testing the value returned. The standard way to test return results and GetLastError value is like so: SetLastError(0xdeadbeef); r = ApiCall(...); ok(r == FALSE/ERROR/blah, "Expected blah, got %d\n", r); ok(GetLastError() == error, "Expected error, got %d\n", GetLastError()); -- James Hawkins

1 0

Re: [PATCH] fixed wrong allocation size
by Marcus Meissner 24 Jul '07

24 Jul '07

On Tue, Jul 24, 2007 at 12:38:10PM -0700, Juan Lang wrote: > Whoops. Thanks Markus. Now why on earth did the tests pass without this? It overwrote unused heap memory until now I guess. Ciao, Marcus

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
23
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 July 2007