September 2005 - Wine-Devel

Re: wine/ programs/winedbg/info.c programs/taskmgr ...

by Vincent Béron

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

Sept. 28, 2005

Re: winspool/tests: New Testsuite

by Detlef Riekenberg

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

Sept. 28, 2005

Re: Problem with D3D9 CreateDevice

by Oliver Stieber

--- Karsten Elfenbein <elfe-sysmail(a)elfe.mine.nu> wrote: > I have a game (Eve Online) that fails while detecting the direct modes. > http://bugs.winehq.org/show_bug.cgi?id=3157 > > > 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? > > Did you try the directx 2005-06-13 patch with the cvs from that day? > Eve basicly stops even before showing the login screen in current CVS > but shows the login screen with the old cvs + that patch. Almost everything is in cvs now so it shouldn't make too much difference, I'm going to post a patch in a few minutes hat works around the device texture format compatibility problems as a stop-gap until format detection is reworked and working properly. Oliver. > > > > > Any help much appreciated. > > > > Mark > > Hope it helps a bit > > Karsten > > > > > ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Sept. 28, 2005

Re: setupapi: implement SetupGetInfFileListW and SetupGetInfInformationW

by Steven Edwards

Hi Rob, This is the reply from Hervé. 1) Windows doesn't have a isspaceW method, so I tested the iswspace method, which should be equivalent. Test program: #include <stdio.h> #include <ctype.h> int main(int argc, char *argv[]) { int space; space = iswspace(0xfeff); printf("iswspace(0xfeff) = %s\n", space ? "yes" : "no"); space = iswspace(L'a'); printf("iswspace(L'a') = %s\n", space ? "yes" : "no"); space = iswspace(L' '); printf("iswspace(L' ') = %s\n", space ? "yes" : "no"); return 0; } Output on Windows XP SP2: iswspace(0xfeff) = no iswspace(L'a') = no iswspace(L' ') = yes Output on ReactOS r18023 (2005/09/24) iswspace(0xfeff) = no iswspace(L'a') = no iswspace(L' ') = yes Output on Wine 20050830 iswspace(0xfeff) = yes iswspace(L'a') = no iswspace(L' ') = yes According to these results, I'm sure that the Wine implementation of iswspace is broken for some reason. I encourage Rob to use the above simple test program to make sure it works properly in Wine. 2) 0xfeff/0xfeff at the start of an UNICODE file is a BOM (Byte Order Marking). It tells you in which byte order is written the file. See http://www.elfdata.com/plugin/unicodefaqdata.html#whatisbom You can notice that "... The BOM can only be written at the start of a text file, before any other bytes. ..." See also http://www.elfdata.com/plugin/unicodefaqdata.html#Z about the Zero-Width Non-breaking Space you were mentionning 3) - else err = parse_buffer( file, buffer, (WCHAR *)((char *)buffer + size), error_line ); + else + { + WCHAR *new_buff = (WCHAR *)buffer; + /* Some UNICODE files may start with the UNICODE marker */ + if (*new_buff == 0xfeff) + new_buff++; + err = parse_buffer( file, new_buff, (WCHAR *)((char *)new_buff + size), error_line ); + } My patch skips only the BOM (when it exists). The patch is not related to ZWNBSP, so I don't want to use iswspace. I also don't intend to change the whole parsing of .inf file, as it already seems correct to me. If you prefer, I may change the patch to skip this 0xfeff header in parse_buffer (setupapi/parser.c), but I need to add a new state like file_start_state (FILE_START). However, my proposition seems ways lighter. 4) To finish this mail, you're right when you say that the following change is incorrect: WCHAR *new_buff = HeapAlloc( GetProcessHeap(), 0, size * sizeof(WCHAR) ); if (new_buff) { - DWORD len = MultiByteToWideChar( CP_ACP, 0, buffer, size, new_buff, size ); + DWORD len = MultiByteToWideChar( CP_ACP, 0, buffer, size, new_buff, + size * sizeof(WCHAR) ); err = parse_buffer( file, new_buff, new_buff + len, error_line ); HeapFree( GetProcessHeap(), 0, new_buff ); } I shouldn't have done this change Regards, Hervé

Sept. 28, 2005

Re: Problem with D3D9 CreateDevice

by Oliver Stieber

--- Mark Hatsell <mark.hatsell(a)btinternet.com> wrote: > 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. I believe all top level windows should have a valid visual ID. Can you tell me what your passing in as the creation parameters, if your creating a window and using it's HWND when creating a device or expecting DirectX 9 to create the device for you, and if your application is MDI or not. Thanks, Oliver > > 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 > > > > > > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Sept. 28, 2005

Re: fixme:win:LockWindowUpdate

by James Hawkins

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

Sept. 28, 2005

Re: comctl32.dll: Running siap and modules under wine, first steps

by Alex Villacís Lasso

Robert Shearman wrote: > Alex Villacís Lasso wrote: > >> --- wine-20050830-cvs/dlls/oleaut32/typelib.c 2005-09-21 >> 10:39:22.000000000 -0500 >> +++ wine-20050830-cvs-patch/dlls/oleaut32/typelib.c 2005-09-24 >> 20:34:32.000000000 -0500 >> @@ -5207,9 +5207,11 @@ >> ITypeInfoImpl *This = (ITypeInfoImpl *)iface; >> HRESULT result = E_FAIL; >> >> - if (hRefType == -1 && >> + if ((hRefType == -1 && >> (((ITypeInfoImpl*) This)->TypeAttr.typekind == >> TKIND_DISPATCH) && >> - (((ITypeInfoImpl*) This)->TypeAttr.wTypeFlags & >> TYPEFLAG_FDUAL)) >> + (((ITypeInfoImpl*) This)->TypeAttr.wTypeFlags & >> TYPEFLAG_FDUAL)) || >> + ((((ITypeInfoImpl*) This)->TypeAttr.typekind == >> TKIND_DISPATCH) && >> + (((ITypeInfoImpl*) This)->TypeAttr.wTypeFlags & >> TYPEFLAG_FDISPATCHABLE))) >> { >> /* when we meet a DUAL dispinterface, we must create the >> interface >> * version of it. >> >> This patch executes the "create interface" code when typekind == >> TKIND_DISPATCH >> and wTypeFlags has TYPEFLAG_FDISPATCHABLE, regardless of the value of >> hRefType, >> in addition to the previous condition. With this patch, the native >> oleaut32 >> requirement is removed. The typelib test still passes - not that it >> actually >> tests the change in code (more on this later). > > > > This patch looks pretty good, but I can't see the difference between > TKIND_DISPATCH and TYPEFLAG_FDISPATCHABLE on MSDN. They look like they > mean the same thing. Have you seen a typelib with one and not the > other? Also, you can remove all of the casts of This while you're > changing that if statement because they are unnecessary. I need to read the Automation guide throughly. Back when I was trying to make this app work, the telltale sign was the "Can't find pRefType for ref XXX" right before the crash. Since I was at my home machine, and I don't have an Internet connection at home, I could not check whether TKIND_DISPATCH and TYPEFLAG_FDISPATCHABLE mean the same thing or should be specified together. I can send the (reverse-engineered with OLEVIEW) typelib for DBGRID32.OCX, if that might show something. I already sent the other two patches to wine-patches. I hope they get commited. Alex Villacís Lasso

Sept. 28, 2005

Re: Problem with D3D9 CreateDevice

by Karsten Elfenbein

See below > -----Ursprüngliche Nachricht----- > Von: wine-devel-bounces(a)winehq.org > [mailto:wine-devel-bounces(a)winehq.org] Im Auftrag von Mark Hatsell > Gesendet: Mittwoch, 28. September 2005 18:36 > An: wine-devel(a)winehq.com > Betreff: Problem with D3D9 CreateDevice > 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. Could you tell us what app/game you are trying to run. (trail/demo available?) I have a game (Eve Online) that fails while detecting the direct modes. http://bugs.winehq.org/show_bug.cgi?id=3157 > 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? Did you try the directx 2005-06-13 patch with the cvs from that day? Eve basicly stops even before showing the login screen in current CVS but shows the login screen with the old cvs + that patch. > > Any help much appreciated. > > Mark Hope it helps a bit Karsten

Sept. 28, 2005

Re: riched20.dll asserts

by Krzysztof Foltman

Ulrich Czekalla wrote: > Could you try the attached patch. I must admit I don't fully understand the > underlying data structures but I think this patch fixes the problem. I'll take a look at that, but can anyone give another (simple) test case? Krzysztof

Sept. 28, 2005

Problem with D3D9 CreateDevice

by Mark Hatsell

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

Sept. 28, 2005

Re: riched20.dll asserts

by Ulrich Czekalla

Hi Aric, Could you try the attached patch. I must admit I don't fully understand the underlying data structures but I think this patch fixes the problem. /Ulrich On Tue, Sep 27, 2005 at 11:36:58AM -0500, Aric Stewart wrote: > 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 > > >

Sept. 28, 2005

Re: comctl32.dll: Running siap and modules under wine, first steps

by Robert Shearman

Alex Villacís Lasso wrote: > --- wine-20050830-cvs/dlls/oleaut32/typelib.c 2005-09-21 > 10:39:22.000000000 -0500 > +++ wine-20050830-cvs-patch/dlls/oleaut32/typelib.c 2005-09-24 > 20:34:32.000000000 -0500 > @@ -5207,9 +5207,11 @@ > ITypeInfoImpl *This = (ITypeInfoImpl *)iface; > HRESULT result = E_FAIL; > > - if (hRefType == -1 && > + if ((hRefType == -1 && > (((ITypeInfoImpl*) This)->TypeAttr.typekind == > TKIND_DISPATCH) && > - (((ITypeInfoImpl*) This)->TypeAttr.wTypeFlags & TYPEFLAG_FDUAL)) > + (((ITypeInfoImpl*) This)->TypeAttr.wTypeFlags & > TYPEFLAG_FDUAL)) || > + ((((ITypeInfoImpl*) This)->TypeAttr.typekind == > TKIND_DISPATCH) && > + (((ITypeInfoImpl*) This)->TypeAttr.wTypeFlags & > TYPEFLAG_FDISPATCHABLE))) > { > /* when we meet a DUAL dispinterface, we must create the > interface > * version of it. > > This patch executes the "create interface" code when typekind == > TKIND_DISPATCH > and wTypeFlags has TYPEFLAG_FDISPATCHABLE, regardless of the value of > hRefType, > in addition to the previous condition. With this patch, the native > oleaut32 > requirement is removed. The typelib test still passes - not that it > actually > tests the change in code (more on this later). This patch looks pretty good, but I can't see the difference between TKIND_DISPATCH and TYPEFLAG_FDISPATCHABLE on MSDN. They look like they mean the same thing. Have you seen a typelib with one and not the other? Also, you can remove all of the casts of This while you're changing that if statement because they are unnecessary. > UPDATE: The OleCreateDefaultHandler routine seems to be in error in > returning > the CLASS_E_NOAGGREGATION error in the DBGRID32.OCX case. If I read > the comment > correctly (and *please* tell me so if I am not), the aggregation case > (pUnkOuter != NULL) is forbidden when riid is other than IID_IUnknown, > and > therefore the test is reversed from what it should be: > > --- wine-20050830-cvs/dlls/ole32/defaulthandler.c 2005-09-23 > 10:51:36.000000000 -0500 > +++ wine-20050830-cvs-patch/dlls/ole32/defaulthandler.c 2005-09-25 > 19:19:31.000000000 -0500 > @@ -1422,7 +1422,7 @@ > * This is necessary because it's the only time the non-delegating > * IUnknown pointer can be returned to the outside. > */ > - if (pUnkOuter && IsEqualIID(&IID_IUnknown, riid)) > + if (pUnkOuter && !IsEqualIID(&IID_IUnknown, riid)) > return CLASS_E_NOAGGREGATION; > > /* This patch is obviously correct. > > This patch allows the DBGrid test to move to the next error: the > DataCache_GetAdvise function crashes after the above patch is applied, > because > this->sinkInterface is NULL at the time of call, but it does not make > any check > for it: > > --- wine-20050830-cvs/dlls/ole32/datacache.c 2005-07-27 > 10:49:38.000000000 -0500 > +++ wine-20050830-cvs-patch/dlls/ole32/datacache.c 2005-09-25 > 19:45:48.000000000 -0500 > @@ -1390,9 +1390,11 @@ > > if (ppAdvSink!=NULL) > { > - IAdviseSink_QueryInterface(this->sinkInterface, > + if (this->sinkInterface != NULL) > + IAdviseSink_QueryInterface(this->sinkInterface, > &IID_IAdviseSink, > (void**)ppAdvSink); > + else *ppAdvSink = NULL; > } > > return S_OK; > > With the above two patches, the DBGrid test sheds all dependencies on > native > oleaut32 *and* ole32. In addition, the SIAP package is freed from the > dependence > on native ole32. I will try to investigate later the remaining > dependency on > native oleaut32. This patch is also correct. Please send all of these patches to wine-patches. -- Rob Shearman

Sept. 28, 2005

Re: comctl32.dll: Running siap and modules under wine, first steps

by Maximiliano Curia

On Monday 26 September 2005 15:00, Alex Villacís Lasso wrote: > --- wine-20050830-cvs/dlls/oleaut32/typelib.c 2005-09-21 > 10:39:22.000000000 -0500 > +++ wine-20050830-cvs-patch/dlls/oleaut32/typelib.c 2005-09-24 > 20:34:32.000000000 -0500 > This patch executes the "create interface" code when typekind == > TKIND_DISPATCH > and wTypeFlags has TYPEFLAG_FDISPATCHABLE, regardless of the value of > hRefType, > in addition to the previous condition. I backported this patch to the version 20050310. If you are willing to let the test application available I could check the successfullness. > --- wine-20050830-cvs/dlls/ole32/defaulthandler.c 2005-09-23 > 10:51:36.000000000 -0500 > +++ wine-20050830-cvs-patch/dlls/ole32/defaulthandler.c 2005-09-25 > 19:19:31.000000000 -0500 > @@ -1422,7 +1422,7 @@ > * This is necessary because it's the only time the non-delegating > * IUnknown pointer can be returned to the outside. > */ > - if (pUnkOuter && IsEqualIID(&IID_IUnknown, riid)) > + if (pUnkOuter && !IsEqualIID(&IID_IUnknown, riid)) > return CLASS_E_NOAGGREGATION; > > /* IsEqualIID was introduced after the version 20050310 that I'm using, and it seem that the: if ( (pUnkOuter!=NULL) && (memcmp(&IID_IUnknown, riid, sizeof(IID_IUnknown)) != 0) ) was replaced wrongly replaced. The (pUnkOuter && !IsEqualIID(&IID_IUnknown, riid)), should have the same efect as the previous code. > Mr. Maximiliano Curia, could you please indicate where to get sample > modules for SIAP? The default installer > doesn't seem to come with any modules inside. Of course, this might be > yet another Wine bug, so please confirm. Yes, of course, they are in: http://www.afip.gov.ar/seccion_rg.asp#programas The most used are: ftp://www.afip.gov.ar/iva40/iva_v4r1.exe (Taxes) ftp://www.afip.gov.ar/sijyp25/sijyp.25r0.exe (Pensions) Although, there are different programs for different activities (and I use 12 of these programs), these two are used by most of them. -- Saludos, /\/\ /\ >< `/

Sept. 28, 2005

Re: Help debugging a problem!

by Ivan Leo Puoti

James Hawkins wrote: > On 9/27/05, Ann & Jason Edmeades <us(a)edmeades.me.uk> wrote: > >>If I change this to >> fred = RegisterClassEx16( &wcex ); >> TRACE("Here... %d\n", fred); >> return fred; >> >>it all works.....! >> > > > This sounds like the stack is getting trashed. I agree this looks very much like a stack corruption issue. Ivan.

Sept. 28, 2005

Re: Problem Resolve

by Molle Bestefich

Molle Bestefich wrote: > j0zue(a)o2.pl wrote: > > I had a problem with Wine20050830 compilation. > > Error: error parse before "BerElement"; > > This question has been asked and answered a couple of times now. > > GMANE search: > http://search.gmane.org/?group=gmane.comp.emulators.wine.user&query=BerElem… > (USERS list, try first) > http://search.gmane.org/?group=gmane.comp.emulators.wine.devel&query=BerEle… > (DEVEL list) > > To view an entire thread in GMANE, after clicking the search result, > click the 'Subject' link. Actually, your problem is in the Wine Bugs database too: http://bugs.winehq.org/query.cgi The interface is absolutely horrid though, at least if you're a bugzilla newbie or if you're searching for known bugs..: After typing 'BerElement' in the freetext field, you have to check all of the items in the 'Status' field to make the search return anything.

Sept. 28, 2005

Re: Problem Resolve

by Molle Bestefich

j0zue(a)o2.pl wrote: > I had a problem with Wine20050830 compilation. > Error: error parse before "BerElement"; > in lines: 289, 290, 322, 323 in "wine/dlls/wldap32/winldap_private.h" file. > In file winldap.h I found declaration of BerElement type. This header is not > included in winldap_private.h. > I put declaration of BerElement type to winldap_private.h and it resolved > the problem. > > I tried add line: #include "winldap.h" to winldap.h too, but it makes double > declaration errors. > > I'm sorry if my English is horrible :) Well I hope my letter will be helpful. > Perhaps this error appear only on my computer (?) :D This question has been asked and answered a couple of times now. You could spare everybody some time by searching the list archives before blindly posting here. Please do so in the future ;-). GMANE search: http://search.gmane.org/?group=gmane.comp.emulators.wine.user&query=BerElem… (USERS list, try first) http://search.gmane.org/?group=gmane.comp.emulators.wine.devel&query=BerEle… (DEVEL list) To view an entire thread in GMANE, after clicking the search result, click the 'Subject' link. > Fun of your Wine. hehe :-).

Sept. 28, 2005

Crash in printer setup dialog if no printers in list

by Dan Kegel

I just filed http://bugs.winehq.org/show_bug.cgi?id=3415 describing a repeatable crash in Printer Setup when you have no printers. Affects all apps that have a Printer Setup menu item, I bet.

Sept. 28, 2005

Re: Trying to track down a failure in a native, non-MS DLL for which I have no source

by Mike McCormack

David D. Hagood wrote: > I'm trying to get the Delorme packages (AAA MapNGo, Street Atlas) > running under the latest Wine. They used to work back when Wine used the > MS DLLs for DCOM, but then they stopped working when Wine started > supplying their own DCOM DLLS. If you're pretty sure that the difference is because of ole, and it can't load a file, then I'd suspect ole storage or OleFont. > The FONT.FNT file is being opened (strace shows it being opened). > The mapsys32.dll file is being loaded (WINEDEBUG=+relay shows it) > The mapsys32.dll does not implement DllRegisterServer (regsvr32 says so). > The problem exists even though I've blown away my entire .wine directory > and recreated it from scratch. > The problem has been in the code for several months, and as of 19 Sept > 2005's CVS it still is. > > So, how can I see what is going on with mapsys32.dll? Try a +olerelay,+storage,+relay trace. Try to pinpoint the failure (ie. where it starts doing HeapFree(), DestroyWindow(), ExitProcess, etc, then work back from there. Try see if there's a StgOpenStorage/StgCreateStorage call, or perhaps if the IOleFont object is being used. Calls to ole interfaces don't show up in with a +relay trace, so you need +olerelay (which only shows up if somebody put a TRACE_(olerelay) macro in the ole functions). The other thing to try is a +relay,+snoop trace, which will show you the entry points being called in mapsys32.dll. Mike

Sept. 28, 2005

Problem with Magellan DataSend and COM ports

by David D. Hagood

I recently tried to install the Magellan DataSend tool to talk to my GPS, and it almost works. However, I did find one funny with it - the program did not "see" the COM ports until I added the following entries into the registry: [HKEY_LOCAL_MACHINE\hardware\devicemap\serialcomm] "COM2"="COM2" "COM1"="COM1" (these were found via a file on the Magellan install CD named win95com.reg). Perhaps these should be added to the Wine registry? Once added, then the program would run - at least right up to the point where I told it to download the data to the GPS, at which point it threw and exception and died.

Sept. 28, 2005

Trying to track down a failure in a native, non-MS DLL for which I have no source

by David D. Hagood

I'm trying to get the Delorme packages (AAA MapNGo, Street Atlas) running under the latest Wine. They used to work back when Wine used the MS DLLs for DCOM, but then they stopped working when Wine started supplying their own DCOM DLLS. Now, they show an inclination to work but for one thing. Both packages use a DLL supplied with the package, mapsys32.dll, which appears to be the main map drawing code. This DLL appears to attempt to load a file FONT.FNT, which appears to be an ASCII file describing certain vector objects used to draw maps. This DLL is failing to load the FONT.FNT file - and that's pretty much a show-stopper. So, I'd like to try to track down the problem and see if I can fix it. Now, I don't work for Delorme, I don't have the source for the DLL, and I am really not a Windows programmer (fortunately I work on embedded systems and Linux). So, I'd like a few pointers - how can I commence to begin to start on this? I know the following things: The FONT.FNT file is being opened (strace shows it being opened). The mapsys32.dll file is being loaded (WINEDEBUG=+relay shows it) The mapsys32.dll does not implement DllRegisterServer (regsvr32 says so). The problem exists even though I've blown away my entire .wine directory and recreated it from scratch. The problem has been in the code for several months, and as of 19 Sept 2005's CVS it still is. So, how can I see what is going on with mapsys32.dll?

Sept. 28, 2005

Re: fixme:win:LockWindowUpdate

by James Hawkins

On 9/27/05, Esko Woudenberg <wanderbored(a)yahoo.com> wrote: > There are several parts of a C++ Builder app I am > working on that try to call the LockWindowUpdate() > WIN32 api call it appears to result in a wine crash > with the following error: > > fixme:win:LockWindowUpdate (0x2002a), partial stub! > Stubbed functions aren't usually the cause of crashes. There are a couple pieces of information that can help us spot the problem. What version of wine are you using? Can you provide the output of the crash and the stack backtrace? This is the part starting with wine: 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? That would definitely help identify the problem. -- James Hawkins

Sept. 28, 2005

Re: Help debugging a problem!

by James Hawkins

On 9/27/05, James Hawkins <truiken(a)gmail.com> wrote: > On 9/27/05, Ann & Jason Edmeades <us(a)edmeades.me.uk> wrote: > > > > If I change this to > > fred = RegisterClassEx16( &wcex ); > > TRACE("Here... %d\n", fred); > > return fred; > > > > it all works.....! > > > > This sounds like the stack is getting trashed. I just read through your post again and saw that the app was hanging, and by hanging I'm assuming it's stuck in the code somewhere, whereas I thought the app was crashing. It might not be the case then that the stack is getting trashed, though you can still use the debugging technique mentioned. -- James Hawkins

Sept. 28, 2005

Re: Help debugging a problem!

by James Hawkins

On 9/27/05, Ann & Jason Edmeades <us(a)edmeades.me.uk> wrote: > > If I change this to > fred = RegisterClassEx16( &wcex ); > TRACE("Here... %d\n", fred); > return fred; > > it all works.....! > This sounds like the stack is getting trashed. That is usually the case when randomly added functions make it not crash. You want to look for places where local variables (on the stack of course) are being overwritten. A good example of this is copying a larger string into a smaller local char array. When looking for a stack crasher, I comment out huge sections of code until it doesn't crash anymore, and then piece by piece uncomment the next function. For example, void foo() { #if 0 a(); b(); c(); #endif } doesn't crash, but void foo() { a(); #if 0 b(); c(); #endif } does crash, then your culprit is in a(). Then you recurse into a() and repeat the process all over again till you find the stack crasher. -- James Hawkins

Sept. 28, 2005

CopyEnhMetaFile() on big endian arch

by Phil Krylov

Hi, My problem is: CopyEnhMetaFile() creates a .wmf file from a HENHMETAFILE by simple dumping of data to the file. On big-endian platforms (in my case - PowerPC) the resulting file is not a valid WMF. To make it valid, we need to convert all binary data to little-endian. I'd like to make it work. Can someone suggest where the byte order should be reversed? Should it be done in the HENHMETAFILE stored in memory, or should rather CopyEnhMetaFile parse the whole metafile and byte-reverse all data that should be dumped to disk? In any case, it seems to be a huge task. If someone is also interested, probably we should cooperate with each other? -- Ph.

Sept. 27, 2005

Help debugging a problem!

by Ann & Jason Edmeades

Hiya, I've got a weird issue and was wondering if anyone could advise on how to resolve. (Comes from a 16bit windows app, but is a more general debugging issue). The problem is ... 1) If I run the application, it just hangs - no overly helpful information at all. 2) If I add WINEDEBUG +relay trace, it runs ok :-) (Workaround...!) 3) If I add anything else on WINEDEBUG other than relay, it fails 4) Running under winedbg didn't help at all - I could code to stop it before the hang but it wouldn't step through to the failure 5) Attaching to the hung process shows code in 16 bit user app, and winedbg didn't overly help there either So - I've (painstakingly) got to the point of failure with the add of debug tracepoints and comparing the relay with the debug statements. Now the odd bit! If you look at dlls\user\wnd16.c, routine RegisterClass16 the final line is: return RegisterClassEx16( &wcex ); If I change this to fred = RegisterClassEx16( &wcex ); TRACE("Here... %d\n", fred); return fred; it all works.....! How can I debug this further? I was thinking about trying to dump the registers before and after the trace statement, but I really can't think of what could be causing the problem! Does windows guarantee any of the registers across a win16 call which we don't honour? What about i386 flags? Any suggestions please? Jason

Sept. 27, 2005