September 2005 - Wine-Devel

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