wine-devel September 2005

wine-devel@winehq.org

136 participants
273 discussions

Re: wine/ programs/Makeprog.rules.in include/wine/ ...
by Dimi Paun 29 Sep '05

29 Sep '05

> Declare debug channels as static variables so that we > don't need to generate an external .dbg.c file to define them. Way cool, thanks for fixing this, it was really bothering me that we had that additional pass over the source... I think our toolchain looks pretty good now! -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: Unused function in regedit/treeview.c
by Krzysztof Foltman 29 Sep '05

29 Sep '05

> If that function is supposed to be useful, then scream or re-add it > later. Re-adding would be a good idea. I thought it will be useful for finding an item in the tree, but then managed to do the same without using it. --- Krzysztof

1 0

FW: Help debugging a problem!
by Ann & Jason Edmeades 29 Sep '05

29 Sep '05

Ok, more information... The routine (slightly modified to allow code before the return) is ATOM WINAPI RegisterClass16( const WNDCLASS16 *wc ) { WNDCLASSEX16 wcex; ATOM fred; wcex.cbSize = sizeof(wcex); : fred = RegisterClassEx16( &wcex ); return fred; } This fails for the application as it stands. Adding in char temp[8]; before the WNDCLASSEX16 and it still fails Adding in char temp[9]; and the program starts working... Adding in char temp[9]; after the WNDCLASSEX16 and it still fails (Yes, temp is unused...) So that would agree heap corruption of some sort Next question... how to pin this down. I've tried the following 1. Use DebugBreak before and after the RegisterClassEx16 call with no temp defined - Stacks are identical as far as winedbg traces (0x60 bytes) - registers are nearly identical, only difference is ESI after 2. Initialize temp to 0x00's (still works @ 9 and fails @ 8). Then adding an 'if' statement before the return to query the bytes... a. If I put a stream of if statements it always works b. If I put a single statement it works@9 / fails@8. Manually, I have confirmed chars 0->11 are not touched (3 longs). c. I changed temp to be 8192 in size, memset it to 0x00 and then post call checked each byte to see if it had changed - it hadn't, they were all still 0x00 => I don't think the actual values are important, size matters (so they say!) 3. I recompiled user.c with -O0 and got different results. With char temp; in it works, with it removed it fails! 4. I compared the assembler output produced with temp[8] and temp[9] and as expected they are identical except for some offsets in that routine. ARGH... Advice please.... Anyone... Jason

4 3

Re: winspool/tests: New Testsuite
by Detlef Riekenberg 29 Sep '05

29 Sep '05

Changelog: - New Testsuite for winspool.drv for GetPrinterDriverDirectoryA and GetDefaultPrinterA The "W" - Versions and more Functions will follow. BTW: I'm offline / disconected from the mailing-lists for a week. -- By By ... ... Detlef

2 1

Problem with D3D9 CreateDevice
by Mark Hatsell 29 Sep '05

29 Sep '05

Hello I am trying to get an application I have written working under Wine. My application uses Direct3D v.9 which is causing a problem. I am using the latest CVS version of Wine under Mandriva Linux 10.2. The problem I have is that when I try to create the 3D device using CreateDevice, it fails and I get the following output from Wine debugging: fixme:d3d:IWineD3DImpl_GetDeviceCaps Caps support for directx9 is nonexistent at the moment! fixme:d3d:IWineD3DImpl_CheckDeviceMultiSampleType Quality levels unsupported at present trace:d3d:IWineD3DImpl_CreateDevice Created WineD3DDevice object @ 0x79b7ec78 trace:d3d:IWineD3DImpl_AddRef (0x7bcb1890) : AddRef increasing from 1 trace:d3d:IWineD3DImpl_CreateDevice (0x7bcb1890)->(Adptr:0, DevType: 1, FocusHwnd: 0x50060, BehFlags: 42, PresParms: 0x7baeb0ec, RetDevInt: 0x78d56ea8) trace:d3d:IWineD3DImpl_CreateDevice (0x7bcb1890)->(DepthStencil:(80,WINED3DFMT_D16), BackBufferFormat:(23,WINED3DFMT_R5G6B5)) trace:d3d:IWineD3DImpl_CreateDevice (0x7bcb1890) : Creating stateblock trace:d3d:IWineD3DImpl_CreateDevice (0x7bcb1890) : Created stateblock (0x79bbf6a0) trace:d3d:IWineD3DStateBlockImpl_AddRef (0x79bbf6a0) : AddRef increasing from 1 trace:d3d:IWineD3DImpl_CreateDevice Creating implicit swapchain trace:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain (0x79b7ec78) : Created Aditional Swap Chain trace:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain Using a display of 0x7c017628 0x4284 warn:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain Failed to get a valid XVisuial ID for the window 0x50060 fixme:d3d9:IDirect3DDevice9Impl_CreateAdditionalSwapChain (0x78d56ea0) call to IWineD3DDevice_CreateAdditionalSwapChainfailed warn:d3d:IWineD3DImpl_CreateDevice Failed to create implicit swapchain trace:d3d:IWineD3DStateBlockImpl_Release (0x79bbf6a0) : Releasing from 2 trace:d3d:IWineD3DStateBlockImpl_Release (0x79bbf6a0) : Releasing from 1 fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock I have located the source of the error in device.c which seems to be something to do with it not having a valid X11 window. However, at this point my lack of Wine knowledge prevents me from getting any further. Has anyone any idea what might be causing this problem and what I can do to fix it? Any help much appreciated. Mark

3 7

Re: wine/ programs/winedbg/info.c programs/taskmgr ...
by Vincent Béron 29 Sep '05

29 Sep '05

Le mer 28/09/2005 à 11:21, Alexandre Julliard a écrit : > ChangeSet ID: 20474 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)winehq.org 2005/09/28 10:21:48 > > Modified files: > programs/winedbg: info.c > programs/taskmgr: dbgchnl.c > libs/wine : wine.map wine.def loader.c debug.c > include/wine : debug.h > > Log message: > New scheme for keeping track of debug channels that doesn't require > maintaining a list of all loaded dlls. This patch causes compilation with gcc 3.2 to issue some warnings about null format strings whenever a TRACE_ON() (or other) is used. I know there's a check in wine_dbg_log() for !format, but the warning is still annoying. I guess you don't want an empty line (except for type and class) to be printed everytime TRACE_ON is tested, so changing the 0 for "" wouldn't work out ok... Vincent

2 1

xcursor and wine
by Vijay Kiran Kamuju 29 Sep '05

29 Sep '05

Hi all, I any body wants tp implement Xcursor support in wine, for loading color cursors. What should be implemented, how it should be implemented? any details regarding this would be helpful. Thanks, Vijay

1 1

winehq at the CIA Open Source Notification System
by Detlef Riekenberg 28 Sep '05

28 Sep '05

Hi. There are no updates listed for wine at the CIA Open Source Notification System: http://cia.navi.cx/stats/project/winehq Is this our fault? -- By By ... ... Detlef

2 1

Re: fixme:win:LockWindowUpdate
by James Hawkins 28 Sep '05

28 Sep '05

On 9/28/05, Esko Woudenberg <wanderbored(a)yahoo.com> wrote: > > > fixme:win:LockWindowUpdate (0x2002a), partial > > stub! > > > > > Stubbed functions aren't usually the cause of > > crashes. > I take it that wine would just "ignore" the request to > not update the window...?? > I'm not really sure what functionality is missing from LockWindowUpdate. Maybe someone on wine-devel will know. > > There are a > > couple pieces of information that can help us spot > > the problem. What > > version of wine are you using? > 20050830 on SuSe 9.2 under vmWare 5.0.0 > Could you update to CVS and see if the problem still exists? > > Can you provide the > > output of the > > crash and the stack backtrace? > Is running with WINEDEBUG=+relay enough to provide > that? > We might need that information later, but the most important piece we need is the crash and backtrace. This information everything after the following: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8. > > You said it was an app you are working on; can you > > provide the source? > I have full access to source. I would most likely > only be able to provide relevant portions of the app > source. > Having access to the source will help figure out what is going wrong. We won't know what we need until we know where it's crashing. > > Just knowing that stubs are not supposed to result in > a wine crash is already helpful... > No problem, a good bug report helps Wine the most. P.S. Make sure to use 'Reply to All' or cc wine-devel so others can be a part of the process. -- James Hawkins

1 0

riched20.dll asserts
by Aric Stewart 28 Sep '05

28 Sep '05

Hello, So looking into an issue with IE6 i found the following problem. If I install IE6, and then go to a japanese web site. (for example http://www.mainichi.co.jp) I get given the option to download and install the Japanese Text Display Support. However if i click Download then the download reports as a failure (a message about having to set your security settings from High to Medium, but that is a red herring) The issue is that the assert in riched20/run.c line 115 is being hit during a call to RichEditANSIWndProc for the message EM_LINELENGTH. If i change the assert to instead to return 0, then the certificate dialog is displayed and the download progresses without issue. (there is still an issue with the install but that is not richedit related) Does someone with richedit experience want to help figure out what to do with that assert beyond just changing it to an error trace and returning 0? thanks -aric

3 2

← Newer
1
2
3
4
5
6
7
...
28
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 September 2005