-
Apr 21st, 2021, 01:35 AM
#1
Thread Starter
Lively Member
Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
for use it , step1 : you should add this reg lic
<registry>
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Licenses\8804558B-B773-11D1-BC3E-0000F87552E7]
@="yjwqljkjjjljjjnjwklqqjqjxkrpljlqplvk"
</registry>
step2 : to replace your tlb 3 in the VBE7.DLL with this file
tlb_3.zip
step3 : copy the link.exe and mspdb60.dll to the VBE7.DLL's directory
step4 : open the MS-OFFICE'S VBE environment and start to build new project.
==============================
but it just can build only x86(32bit) p-code dll, anyone who can fix it to support x64 compile ?
-
Apr 21st, 2021, 01:36 AM
#2
Thread Starter
Lively Member
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
in the x64bit of VBE environment it can build dll but the link table isn't correct, we need an 64bit of MSVBVM60.DLL
-
Apr 21st, 2021, 01:56 AM
#3
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
Wow!
This is an outrageous hack already but it would have been a complete shock if VBA's IDE successfully compiled x86/x64 p-code binaries, can you imagine. . .
Btw, here is the contents of the typelib in the zip above
Code:
// Generated .IDL file (by the OLE/COM Object Viewer)
//
// typelib filename: <could not determine filename>
[
uuid(6715F050-F076-11CD-9B33-08002B336F14),
version(6.0),
helpfile("__VB_HELP__"),
helpcontext(00000000)
]
library VBInternal
{
// TLib : // TLib : OLE Automation : {00020430-0000-0000-C000-000000000046}
importlib("stdole2.tlb");
// Forward declare all types defined in this typelib
interface IClassModuleEvt;
dispinterface _DClass;
dispinterface _DPropNameOnly;
dispinterface _DPropPublicClassModule;
dispinterface _DPropPrivateClassModule;
interface IVBProjProps;
dispinterface INullExtender;
dispinterface ENullExtender;
typedef [uuid(1AB4F600-A738-11D1-96E8-00A0C91110EB), helpcontext(0x000df250)]
enum {
GlobalMultiUse = 6,
MultiUse = 5,
Private = 1,
PublicNotCreatable = 2
} EnumInstVbeClass;
typedef [uuid(54288490-C018-11CF-9F9D-00A0C90F26F9), helpcontext(0x000df250)]
enum {
Private = 1,
PublicNotCreatable = 2,
MultiUse = 5,
GlobalMultiUse = 6
} EnumInstActiveXDll;
[
odl,
uuid(FCFB3D21-A0FA-1068-A738-08002B3371B5),
hidden
]
interface IClassModuleEvt : IUnknown {
[helpcontext(0x000df257)]
HRESULT _stdcall Initialize();
[helpcontext(0x000df258)]
HRESULT _stdcall Terminate();
};
[
uuid(FCFB3D2B-A0FA-1068-A738-08002B3371B5),
hidden,
nonextensible
]
dispinterface _DClass {
properties:
methods:
};
[
uuid(FCFB3D2A-A0FA-1068-A738-08002B3371B5),
hidden
]
coclass Class {
[default] dispinterface _DClass;
[default, source] interface IClassModuleEvt;
};
[
uuid(FCFB3D28-A0FA-1068-A738-08002B3371B5),
hidden
]
dispinterface _DPropNameOnly {
properties:
[id(0x80010000), helpcontext(0x000df259)
]
BSTR Name;
methods:
};
[
uuid(FB1E1EC0-A735-11D1-96E8-00A0C91110EB),
hidden
]
dispinterface _DPropPublicClassModule {
properties:
[id(0x80010000), helpcontext(0x000df259)
]
BSTR Name;
[id(0x00000001), helpcontext(0x000df250)
]
EnumInstActiveXDll Instancing;
methods:
};
[
uuid(25411250-A738-11D1-96E8-00A0C91110EB),
hidden
]
dispinterface _DPropPrivateClassModule {
properties:
[id(0x80010000), helpcontext(0x000df259)
]
BSTR Name;
[id(0x00000001), helpcontext(0x000df250)
]
EnumInstVbeClass Instancing;
methods:
};
[
odl,
uuid(D957C650-C491-11CF-AA68-00A0C9055A90),
hidden
]
interface IVBProjProps : IDispatch {
[propget, helpcontext(0x000df25a)]
HRESULT _stdcall Name([out, retval] BSTR* Return);
[propput, helpcontext(0x000df25a)]
HRESULT _stdcall Name([in] BSTR Return);
};
[
uuid(3615E5E0-CF90-11CF-8E43-00A0C911005A),
hidden
]
dispinterface INullExtender {
properties:
methods:
};
[
uuid(3635E4E0-C690-11CF-8E43-00A0C911005A),
hidden
]
dispinterface ENullExtender {
properties:
methods:
};
[
uuid(3832D640-CF90-11CF-8E43-00A0C911005A),
hidden
]
coclass NullExtender {
[default] dispinterface INullExtender;
[default, source] dispinterface ENullExtender;
};
};
Here you can find the Class_Initialize "event" prototype for instance and every built-in base class too. Not every, only some.
cheers,
</wqw>
Last edited by wqweto; Apr 21st, 2021 at 02:01 AM.
-
Apr 21st, 2021, 02:18 AM
#4
Thread Starter
Lively Member
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
here is a dll which is compiled with the x64bit of VBE7
AddInProject1.zip
but it's RVA table isn't correct, so it couldn't be registed.
-
Apr 21st, 2021, 02:20 AM
#5
Thread Starter
Lively Member
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
but I think it only we need is an 64bit version of MSVBVM60.DLL
-
Apr 21st, 2021, 10:07 AM
#6
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
Dll Compile file format is 32 Bit DLL
in a pcode disassembler it does not show any vb objects like modules, classes, forms, addins etc
Object table is showing bad data with invalid virtual addresses. The top level VBHeader has a null for ProjectInfo structure so everything below is invalid.
Code:
top level VBHeader structure
VA Off Name Value
1100120C 000 signature VB5!
11001210 004 RuntimeBuild 454
11001212 006 LanguageDLL vb6chs.dll
11001220 014 BackupLanguageDLL *
1100122E 022 RuntimeDLLVersion A
11001230 024 LanguageID 804
11001234 028 BackupLanguageID 0
11001238 02C aSubMain 0
1100123C 030 aProjectInfo 0
11001240 034 fMDLIntObjs 0
11001244 038 fMDLIntObjs2 11001A90
11001248 03C ThreadFlags 0
1100124C 040 ThreadCount 302000
11001250 044 FormCount 0
11001252 046 ExternalComponentCount 0
11001254 048 ThunkCount 1
11001258 04C aGuiTable FFFFFFFF
1100125C 050 aExternalComponentTable 10001
11001260 054 aComRegisterData 100
11001264 058 oProjectExename 110011B4
11001268 05C oProjectTitle 0
1100126C 060 oHelpFile 110012C8
11001270 064 oProjectName 0
Maybe the embedded structures are 64 bit which would shift the values around. but it would need a 64bit dll husk then
Last edited by dz32; Apr 21st, 2021 at 01:31 PM.
-
Apr 21st, 2021, 03:46 PM
#7
Addicted Member
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
You can still use a 32-bit ActiveX/COM DLL from a 64-bit process, by using a DLLSurrogate.
Details on how I do it are available on my Github Page "Using a 32-bit In-Process COM Server DLL from 64-bit"
Joe
-
Apr 21st, 2021, 07:22 PM
#8
Thread Starter
Lively Member
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
Thanks for reply.
Is there anyway to build an 64bit of MSVBVM60.DLL
-
Apr 22nd, 2021, 12:44 AM
#9
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
Originally Posted by vb56390
Is there anyway to build an 64bit of MSVBVM60.DLL
Only if you find its source code on the internet.
cheers,
</wqw>
-
Apr 22nd, 2021, 07:52 AM
#10
Addicted Member
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
Take a look at openmsvbvm on GitHub.
From the project page:
This is an open source interpretation of what the MSVBVM60 library does.
Well, there's no need to do this, but since VB6 is getting outdated, an open source runtime library might add some years to VB6's lifespan.
This library IS NOT A FULL replacement of the original library. So, don't expect to be a drop-in replacement. Currently, a small subset of the original library are implemented.
Joe
-
Apr 23rd, 2021, 12:15 AM
#11
Thread Starter
Lively Member
Re: Now we can compile ActiveX Dll in use MS-OFFICE's VBE7 environment
thanks Joe
but the openmsvbvm isn't a fully replace of MSVBVM60, it's only less than 5% of the MSVBVM60
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|