July 2006 - Wine-Devel - list.winehq.org

Re: Wine 0.9.16 and ddraw issues

by Stefan Dösinger

Am Freitag 30 Juni 2006 17:28 schrieb Christoph Frick: > On Fri, Jun 30, 2006 at 05:11:24PM +0200, Alexander Nicolaysen Sørnes wrote: > > ... > > fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock > > > > ... > > fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock > > this are also the last words of Planescape Torment when starting up > (black screen, then end right before the menu would appear) Wined3d writes them every time when the device is destroyed. I have no idea who added them and why, but I think they should be removed. I don't see anything wrong in destroying the primary stateblock when the device is destroyed :-) Stefan

July 1, 2006

Re: DDRAW: Releasing attached surfaces

by Stefan Dösinger

Hi, > as this seems already solved just for the files. this fix let Planescape > Torment crash (before it just ended silently by releasing its "primary > state block") - it worked before the ddraw patches white fine. i will > soon file a bugreport and provide a link to the demo. Can you also attach a +ddraw,+d3d7 trace? Preferably with and without the hack? There is a demo of this game? I have only seen some demo movies, no playable demo :-( Stefan

July 1, 2006

Re: Link or rename wcmd.exe to cmd.exe?

by Chris

On Saturday 01 July 2006 01:01, Alexandre Julliard wrote: > Yes, I think it should be renamed to cmd.exe, at this point it's > supposed to be a complete replacement. Not sure if this is the best place to bring this up, but I'm not sure it's "ready". The problem is it runs through the terminal the Wine was exec'd from. When Wine is run from the desktop manager's menu, or started in the background (eg. wine foo.exe &), if wcmd is subsequently exec'd, it will become completely unuseable since it has no input, and potentially no output, terminal. It then has to be killed through the kill or killall command. To be "ready", wouldn't it need to open up its own terminal window for input and output in Wine's desktop space (eg. the virtual desktop if it's in use, or the standard desktop)? It doesn't really feel like a Windows application since it relies on the currently running terminal.

July 1, 2006

RE: Win64 patch 3/5 (winedbg)

by Ge van Geldorp

> From: Eric Pouech [mailto:eric.pouech(a)wanadoo.fr] > > this one is questionnable. Now that we have stackwalk64 > implemented (I'm not saying it works flawlessly on 64bit > machines), it may be more interesting here to use the 64 bit > version of the call back That's actually a separate issue. The problem I'm trying to solve here is that the last parameter of ReadProcessMemory (which is the API that is eventually called by pcs->process_io->read()) is defined as SIZE_T *, which expands to a pointer to 8 bytes on Win64. The last parameter of the ReadMemoryRoutine callback of StackWalk is PDWORD, pointer to 4 bytes. So you can't pass the last parameter of the ReadMemoryRoutine callback on to pcs->process_io->read(), you'd write 8 bytes to a 4 byte variable. Unfortunately, switching to StackWalk64 doesn't solve this. The last parameter of the ReadMemoryRoutine callback of StackWalk is still a pointer to 4 bytes (PDWORD in Wine, LPDWORD in PSDK). Switching to StackWalk64 is ofcourse a good idea, but we still need the patch as submitted. Gé van Geldorp.

July 1, 2006

Re: Link or rename wcmd.exe to cmd.exe?

by Alexandre Julliard

"Thomas Kho" <tkho(a)ucla.edu> writes: > I'm currently looking into what would be required for something like a > symlink to wcmd.exe, but at the same time I'm wondering the historical > reasons for choosing 'wcmd' and if it should be changed to just 'cmd'. Yes, I think it should be renamed to cmd.exe, at this point it's supposed to be a complete replacement. -- Alexandre Julliard julliard(a)winehq.org

July 1, 2006

Re: Win64 patch 3/5 (winedbg)

by Eric Pouech

Ge van Geldorp wrote: >diff --git a/programs/winedbg/stack.c b/programs/winedbg/stack.c >index b976117..c2dec5f 100644 >--- a/programs/winedbg/stack.c >+++ b/programs/winedbg/stack.c >@@ -127,9 +127,14 @@ BOOL stack_get_current_symbol(SYMBOL_INF > static BOOL CALLBACK stack_read_mem(HANDLE hProc, DWORD addr, > PVOID buffer, DWORD size, PDWORD written) > { >+ SIZE_T sz; >+ BOOL ret; >+ > struct dbg_process* pcs = dbg_get_process_h(hProc); > if (!pcs) return FALSE; >- return pcs->process_io->read(hProc, (const void*)addr, buffer, size, written); >+ ret = pcs->process_io->read(hProc, (const void*)addr, buffer, size, &sz); >+ if (written != NULL) *written = sz; >+ return ret; > } > > /****************************************************************** > > this one is questionnable. Now that we have stackwalk64 implemented (I'm not saying it works flawlessly on 64bit machines), it may be more interesting here to use the 64 bit version of the call back A+

July 1, 2006

Re: Slow EULA display patch

by Krzysztof Foltman

Daniel Steven Hipschman wrote: > This patch fixes the slow EULA loading problem in > http://bugs.winehq.org/show_bug.cgi?id=5516 Well, *great* to see that solved in the Wine core, but I still think I have a bug in RichEdit, because the original (native) riched20 works fast, despite the bug you just fixed. Krzysztof

July 1, 2006