Re: comctl32.dll: Running siap and modules under wine, first steps
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.0 -0500 +++ wine-20050830-cvs-patch/dlls/oleaut32/typelib.c 2005-09-24 20:34:32.0 -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.c2005-09-23 10:51:36.0 -0500 +++ wine-20050830-cvs-patch/dlls/ole32/defaulthandler.c2005-09-25 19:19:31.0 -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, /\/\ /\ `/
Re: comctl32.dll: Running siap and modules under wine, first steps
Alex Villacís Lasso wrote:
--- wine-20050830-cvs/dlls/oleaut32/typelib.c 2005-09-21
10:39:22.0 -0500
+++ wine-20050830-cvs-patch/dlls/oleaut32/typelib.c 2005-09-24
20:34:32.0 -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.c2005-09-23
10:51:36.0 -0500
+++ wine-20050830-cvs-patch/dlls/ole32/defaulthandler.c2005-09-25
19:19:31.0 -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.c2005-07-27
10:49:38.0 -0500
+++ wine-20050830-cvs-patch/dlls/ole32/datacache.c2005-09-25
19:45:48.0 -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
Re: comctl32.dll: Running siap and modules under wine, first steps
Robert Shearman wrote:
Alex Villacís Lasso wrote:
--- wine-20050830-cvs/dlls/oleaut32/typelib.c 2005-09-21
10:39:22.0 -0500
+++ wine-20050830-cvs-patch/dlls/oleaut32/typelib.c 2005-09-24
20:34:32.0 -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
Re: comctl32.dll: Running siap and modules under wine, first steps
Maximiliano Curia wrote:
Hi,
I'm trying to use a program called siap[1] under wine. It's the required
program to pay taxes that the Argentinian government uses.
So, it's quite important for the free software community in Argentina to be
able to use it in a free software environment. However, I haven't heard
of any real success on it, so far.
I've been trying to make it run using winetools[2], and differents versions of
wine. The furthest I've gone, has been with version 20050310 and all the
plugins that winetools provides, installed.
I found some free time to investigate the SIAP program issue. As I can
remember,
the SIAP package is a software program to prepare and submit taxes for the
government of Argentina. This software is written in MS Visual Basic 5.
When an attempt is made to run the program without any overrides with the
current CVS (2005/09/23), the following messages appear (with
WINEDEBUG=+ole):
...
trace:ole:ITypeLib2_fnRelease (0x7cb9f198)-(1)
trace:ole:WINE_StringFromCLSID
0x2311b940-{00028C01----0046}
trace:ole:LoadTypeLib (LC:\\ARCHIVOS DE
PROGRAMA\\S.I.AP\\AFIP\\DBGRID32.OCX,0x7fa5f658)
trace:ole:LoadTypeLibEx (LC:\\ARCHIVOS DE
PROGRAMA\\S.I.AP\\AFIP\\DBGRID32.OCX,0,0x7fa5f658)
trace:ole:LoadTypeLibEx File LC:\\ARCHIVOS DE
PROGRAMA\\S.I.AP\\AFIP\\DBGRID32.OCX index 1
trace:ole:TLB_ReadTypeLib cache hit
trace:ole:ITypeLib2_fnAddRef (0x7cb9f198)-ref was 1
trace:ole:LoadTypeLibEx returns
trace:ole:LoadRegTypeLib (IID: {00028c01----0046})
load SUCCESS (0x7cb9f198)
trace:ole:ITypeLib2_fnGetTypeInfoOfGuid (0x7cb9f198)
guid:{00028c02----0046})
trace:ole:ITypeLib2_fnGetTypeInfoOfGuid -- found (0x7cbb3bd8,
LIMsDgridCtrl)
trace:ole:ITypeLib2_fnAddRef (0x7cb9f198)-ref was 2
trace:ole:ITypeInfo_fnAddRef (0x7cbb3bd8)-ref is 3
trace:ole:ITypeLib2_fnRelease (0x7cb9f198)-(2)
trace:ole:ITypeInfo_fnGetTypeAttr (0x7cbb3bd8)
trace:ole:ITypeInfo_fnReleaseTypeAttr (0x7cbb3bd8)-(0x7fdb8e58)
trace:ole:ITypeInfo_fnGetFuncDesc (0x7cbb3bd8) index 0
trace:ole:ITypeInfo_fnReleaseFuncDesc (0x7cbb3bd8)-(0x7cbb3d48)
trace:ole:ITypeInfo_fnGetFuncDesc (0x7cbb3bd8) index 1
...
trace:ole:ITypeInfo_fnReleaseFuncDesc (0x7cbb3bd8)-(0x7cbb4eb8)
trace:ole:ITypeInfo_fnGetFuncDesc (0x7cbb3bd8) index 12
fixme:ole:ITypeInfo_fnGetRefTypeInfo Can't find pRefType for ref 19
trace:ole:ITypeInfo_fnGetRefTypeInfo (0x7cbb3bd8) hreftype 0x0019 loaded
FAILURE (0x7ca52dc8)
wine: Unhandled exception (thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled exception: page fault on read access to 0x0010 in 32-bit
code (0x230f4f61).
In 32 bit mode.
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033
EIP:230f4f61 ESP:7fa5f5bc EBP:7fa5f624 EFLAGS:00010202( - 00 - -RI1)
EAX:0004 EBX:0020 ECX:7fa5f5d0 EDX:7ca52dc8
ESI:7ca52ddc EDI:7ca52b70
Stack dump:
0x7fa5f5bc: 7ca52dc8 7fa5f5d0 7ca52df8 7cbb3bd8
0x7fa5f5cc: 7ca52dc8 7fa5f624 230f4ae8 7cbb3bd8
0x7fa5f5dc: 7ca52ddc 7cbb5048 7ca52b70 7ca505a0
0x7fa5f5ec: 7f6bb480 7f6857a0 7f686444
0x7fa5f5fc: 7fdb8e58 000c 0032 0011
0x7fa5f60c: 7ca52b88 7ca52b70 7cbb5028 7fa5f660
0200: sel=1007 base=7fe9a000 limit=1fff 32-bit rw-
Backtrace:
=1 0x230f4f61 in dbgrid32.ocx (+0x34f61) (0x7fa5f624)
2 0x230e9c2f in dbgrid32.ocx (+0x29c2f) (0x7fa5f66c)
3 0x230e7573 in dbgrid32.ocx (+0x27573) (0x7fa5f6b4)
4 0x230c3bee in dbgrid32.ocx (+0x3bee) (0x7fa5f6e8)
5 0x230cd0a9 in dbgrid32.ocx (+0xd0a9) (0x7fa5f754)
err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file MSVBVM50.dbg
(MSVBVM50.dbg)
6 0x0f045840 in msvbvm50 (+0x45840) (0x7fa5f7a4)
7 0x0f046096 in msvbvm50 (+0x46096) (0x7fa5f7b4)
8 0x0f0293dd in msvbvm50 (+0x293dd) (0x7fa5f7f4)
9 0x0f028f7b in msvbvm50 (+0x28f7b) (0x7fa5f824)
10 0x0f028e6e in msvbvm50 (+0x28e6e) (0x7fa5f858)
11 0x0f028ed5 in msvbvm50 (+0x28ed5) (0x7fa5f890)
12 0x0f029feb in msvbvm50 (+0x29feb) (0x7fa5f8c8)
13 0x0f029b4e in msvbvm50 (+0x29b4e) (0x7fa5f928)
14 0x0f029a57 in msvbvm50 (+0x29a57) (0x7fa5f94c)
15 0x0f0299e9 in msvbvm50 (+0x299e9) (0x7fa5f96c)
16 0x0f023e77 in msvbvm50 (+0x23e77) (0x7fa5f9a4)
17 0x0f027329 in msvbvm50 (+0x27329) (0x7f1e5420)
18 0x (0x0f10e1f0)
0x230f4f61: call*0xc(%eax)
fixme:winedbg:be_i386_is_func_call Unsupported yet call insn (0x10) at
0x230f4f61
Modules:
...
This result suggests that builtin oleaut32 is unable to cope with the
typelib
embedded in DBGRID32.OCX. When *both* native oleaut32 and ole32 are
used, the
program starts up normally.
The following test was made: with MS Visual Basic 6 SP6, I made a sample
program
that includes a Data control, a DBGrid control from DBGRID32.OCX, and a
sample
MDB file to query into the DBGrid. This sample program crashes in the
exact same
way as the SIAP package when no overrides are used, and also runs
correctly when
native ole32 and oleaut32 are used. After some trial and error, I came
up with
the
Re: comctl32.dll: Running siap and modules under wine, first steps
On Saturday 17 September 2005 20:45, Robert Shearman wrote: Start the program with WINEDEBUG=+treeview wine program.exe treeview.log and send the treeview log to the list (compressed if it is over 50kB). It's about 31 Kb, it gets to the line 272 to open the main window and showing the treeview, as shown in the screenshot. The rest is just the program closing. I don't know if this could actually help but, I've noticed, after looking fiercely at the log, that the tree is being set to expand, but the Paint seems to only be calling DrawItem to the root (twice), but looking at the code I can't tell wheter the TREEVIEW_Expand is not setting the siblings to visible or if TREEVIEW_Paint is just failling. -- Saludos, /\/\ /\ `/ trace:treeview:TREEVIEW_Register err:statusbar:StatusWindowProc unknown msg 2210 wp=0001 lp=00010036 fixme:time:GetCalendarInfoA (0409,0001,2030,(nil),0,0x7fb9ee58): quarter-stub fixme:time:GetCalendarInfoW (0409,0001,2030,(nil),0,0x7fb9ee58): quarter-stub err:statusbar:StatusWindowProc unknown msg 2210 wp=0001 lp=0001006a trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0081 wp= lp=7fb9f4d4 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0083 wp= lp=7fb9f294 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0001 wp= lp=7fb9f4d4 trace:treeview:TREEVIEW_Create wnd 0x2007c, style 4622 trace:treeview:TREEVIEW_NotifyFormat (hwndFrom=0x10068, nCommand=4) trace:treeview:TREEVIEW_NotifyFormat format=1 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0030 wp=0b84 lp= trace:treeview:TREEVIEW_SetFont 0xb84 0 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1107 wp=000d lp= trace:treeview:TREEVIEW_SetIndent trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0005 wp= lp=009d0172 trace:treeview:TREEVIEW_SetFirstVisible (nil): null item trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0003 wp= lp=00890002 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 2210 wp=0001 lp=0002007c trace:treeview:TREEVIEW_WindowProc Unknown msg 2210 wp=0001 lp=0002007c trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0018 wp=0001 lp= trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0046 wp= lp=7fb9f204 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0047 wp= lp=7fb9f204 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0085 wp=0001 lp= trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0014 wp=00a8 lp= trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1109 wp= lp= trace:treeview:TREEVIEW_SetImageList 0,(nil) trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1106 wp= lp= trace:treeview:TREEVIEW_GetIndent trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1107 wp=0013 lp= trace:treeview:TREEVIEW_SetIndent trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 000f wp=00a8 lp= trace:treeview:TREEVIEW_Paint trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0014 wp=0148 lp= trace:treeview:TREEVIEW_SendCustomDrawNotify drawstage:1 hdc:0xa8 trace:treeview:TREEVIEW_SendRealNotify wParam=0, lParam=2142893472 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 000f wp=00a8 lp= trace:treeview:TREEVIEW_Paint trace:treeview:TREEVIEW_SendCustomDrawNotify drawstage:1 hdc:0xa8 trace:treeview:TREEVIEW_SendRealNotify wParam=0, lParam=2142893472 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1109 wp= lp= trace:treeview:TREEVIEW_SetImageList 0,(nil) trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1109 wp= lp=7ff54800 trace:treeview:TREEVIEW_SetImageList 0,0x7ff54800 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1101 wp= lp= trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): null item trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 000b wp= lp= trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1100 wp= lp=7fb9f68c trace:treeview:TREEVIEW_InsertItemT parent 0x7ff3a018 position 0x0002: callback trace:treeview:TREEVIEW_DoSetItemT item 0x7ff57518 trace:treeview:TREEVIEW_DoSetItemT setting callback, item 0x7ff57518 trace:treeview:TREEVIEW_InsertItemT new item 0x7ff57518; parent 0x7ff3a018, mask 27 trace:treeview:TREEVIEW_UpdateDispInfo mask 1 callbackMask 23 trace:treeview:TREEVIEW_SendRealNotify wParam=0, lParam=2142892700 trace:treeview:TREEVIEW_UpdateDispInfo same buffer str , len=1, buflen=260 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 110d wp= lp=7fb9f6c8 trace:treeview:TREEVIEW_SetItemT item 1,mask 4 trace:treeview:TREEVIEW_DoSetItemT item 0x7ff57518 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1100 wp= lp=7fb9f68c
Re: comctl32.dll: Running siap and modules under wine, first steps
Hi, On Sat, Sep 17, 2005 at 08:20:29PM -0300, Maximiliano Curia wrote: So, what should I do next? I'm afraid I cannot give much technical advice how to proceed here, but what you should do soon is to protest loudly against *FORCING* a Windows-only program on the public in this day and age of multi-platform use, despite those cross-platform toolkits such as Qt, wxWidgets, GTK and Java having been available for long times already (not to mention that several of those should actually be superiour to the single-platform toolkit that may have been used here!). This is §$%§(% incredible ignorance and malvolence. But I'm confident that many of you have already been doing this. Good luck with this major annoyance, Andreas Mohr
Re: comctl32.dll: Running siap and modules under wine, first steps
On Sat, 2005-09-17 at 17:46 -0300, Maximiliano Curia wrote: Is anybody working in this dll, or has worked on this widget? Nobody currently works on the treeview unfortunately, and it needs love. Lots of it. If you want to take a stab at it, you can find it in dlls/comctl32/treeview.c -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: comctl32.dll: Running siap and modules under wine, first steps
Maximiliano Curia wrote: ... There are a couple of important widgets that seem to be incompatible with wine. But as I'm not an expert neither in Windows nor in wine, the one I could really track down is a TreeView widget (from comctl32.dll) (from the main window of the program), that is not fully implemented in wine, and by using a native comctl32.dll (I tried using the win98, winme, win2k libraries) the widget would work but some of the other stuff, like switching to one of the modules wouldn't. I made a screenshot to make this clearer, the wine version[3] and the w2k version[4]. So, what should I do next? Start the program with WINEDEBUG=+treeview wine program.exe treeview.log and send the treeview log to the list (compressed if it is over 50kB). Is there some documentation of how to implement a certain Windows widget in wine? Not really. My guess is that either some message is failing because it is hitting some border case. Is anybody working in this dll, or has worked on this widget? I have worked on the control, but I don't really have time to look at the specific problem, other than giving a 5 minute look over any log files you send. -- Rob Shearman
