AddressOf for Class Methods (and other VTable exploration)?

[LaVolpe]

Any suggestions ?

Honestly, start a new thread. Specifically address COM in 64 bit, VTable layout and more.

For example, and I'm not even sure this is correct... In a 64 bit Access module to scan an Access class

Option Explicit

Private Declare PtrSafe Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef src As Any, ByRef dst As Any, ByVal cbLen As LongLong)

Public Sub doIt()

    Dim c As New Class1
    Dim nAddr As LongPtr, nMethod As LongPtr, b As Byte
    
    CopyMemory nAddr, ByVal ObjPtr(c), 8
    
    CopyMemory nMethod, ByVal nAddr + 7 * 8, 8
    
    CopyMemory b, ByVal nMethod, 1
    
    Debug.Print "byte "; b ' opcode

End Sub

Is that opcode the method signature that 32bit routine is looking for? I don't know. As you can see, just getting to the VTable is a bit challenging. Instead of using offset 28 (7*4 or &H1C) as we would for 32bit VB/VBA class, I used 7*8 hoping it is right. I actually crashed the first time when I guessed wrong.

Now, the code we know and has been tested on VB6 classes (not 64bit office), likely is not coded the same in 64bit which means someone needs to spend time spelunking. For example, in 32bit, we'd expect the 1st byte of the class to be &H33 when uncompiled, but the above sample returned &H258. Is that because a) I guessed wrong on how to access the VTable and its function, or b) 64bit Office rewrote its classes using 64bit registers vs 16/32bit, or c) 64bit office rewrote their class stubs and known opcodes no longer apply anyway.

But as I suggested, may want to start a new thread. I would suspect it might get lengthy. In addition, you may want to explain what you plan on doing with the function pointers once you get them (which will also be in 8-byte lengths).

[JAAFAR]

But as I suggested, may want to start a new thread. I would suspect it might get lengthy. In addition, you may want to explain what you plan on doing with the function pointers once you get them (which will also be in 8-byte lengths).

I want this simply for learning purposes.

As an example I would want to see if I can keep a SetTimer API callback routine within a class module without the need for an additional standard module.

I'll start a new thread later.

Thanks for responding.

EDIT
How did you get the &H258 ?

[LaVolpe]

How did you get the &H258 ?

... but the above sample returned &H258

Any way, let me dump my latest version here. It is not 64bit compatible, but heavily commented. I think you can use those comments to help decipher what you will want to be looking for in the 64bit versions. Bottom line, VB's functions (likely templates) are standard, so Paul Caton did the spelunking to find the patterns/signatures/opcodes. You or others will need to do likewise for 64bit.

   code moved to the code bank
http://www.vbforums.com/showthread.p...Object-Modules

Edited: You do realize you won't be able to use thunks created for 32bit for 64bit, don't you? Reasons are several, but one of the limiting factors is that the 32bit thunks are only familiar with 32bit pointers. The 64bit ObjPtrs will be 64bit

[JAAFAR]

Thanks very much LaVolpe.

I'll study the function and see how it goes.

[JAAFAR]

This is new territory for me ... Can you suggest a tool (if there is one) for inspecting the memory layout\addreses of a vba class ? (in the case of vba, the code is not compiled)

[The trick]

This is new territory for me ... Can you suggest a tool (if there is one) for inspecting the memory layout\addreses of a vba class ? (in the case of vba, the code is not compiled)

You could use a 64 bit debugger. I can suggest you x64dbg which is the quite user-friendly one.
Also you can check this class which works in both 32 and 64 bit environment.

[wqweto]

Has anyone figured out why the compiler adds private/friend methods to the class/form VTable but still emits direct calls to friend/private methods/properties when invoked?

This seems like a bug (or vestige from olden VB3 days) they never cared to fix/remove. It seems like this way most VTables gets filled up with redunandant offsets that are never used during the lifetime of the class and these can be safely removed with no effect on the normal operation of the compiled application.

cheers,
</wqw>

[xiaoyao]

can use Multithreading(createthread api),call class1.function1(***)
but when run function1 end,exe The program crashed

[Elroy]

Hmmm, I'm just seeing all this recent activity. Usually I'm fairly tolerant of hijacking, but all this 64-bit stuff does seem a bit far afield from VB6. This actually might be more appropriate over in the "Office Development" forum, but I'll let the moderators make that call.

But, if a new thread could be started, it would be much appreciated. Personally, I've tried to move away from the VBA, currently only having one bit of code still in a VBA form (in an Excel report that can be reconfigured by the user after it's exported). The biggest problem for me with using the VBA is that the code gets replicated all over the place (at least in my case, where I use Word and Excel files as report exports), and it's near impossible to make retroactive updates to that code.

I've actually toyed with the idea of just bringing my entire major project into the VBA. However, the primary reasons I haven't are that the forms are somewhat different and I don't get User Controls. So, it would still require a rather major rewrite. I still have an inkling of hope that there may someday be a 64-bit version of VB6 (although I know that's complete wishful thinking).

[LaVolpe]

Has anyone figured out why the compiler adds private/friend methods to the class/form VTable but still emits direct calls to friend/private methods/properties when invoked?

This seems like a bug (or vestige from olden VB3 days) they never cared to fix/remove. It seems like this way most VTables gets filled up with redunandant offsets that are never used during the lifetime of the class and these can be safely removed with no effect on the normal operation of the compiled application.

cheers,
</wqw>

Likely simply forgot to remove them for compiling or couldn't because other offsets elsewhere would be corrupted if they were removed?

In IDE, those pointers in those VTable slots are to stubs it appears. If while in IDE and running the project, you decide to make changes to the code when IDE is paused (debugging), then VB will change an address in the stub. This is a "MOV dx" instruction that likely updates the register with a new offset to call/jump to a JIT-compiled-routine later. So, having them in the VTable during IDE kinda makes sense to me - easy reference. Leaving them there after compiling, well? Personally, I'm kinda glad VB left them there -- makes writing thunks for them so much easier

[xiaoyao]

Here are some routines that addresses the question "Is there an AddressOf for object modules?" These functions are heavily based on Paul Caton's code here and LaVolpe's code here. These have not been tested in VBA, so use at your own risk.

[CODE]
Dim UC1 As UserControl1
VTOffset=1956 ,it's run successfull
in other usercontrol,VTOffset=1968,why not same?

 Dim UC1 As UserControl1
 Set UC1 = Screen.ActiveForm.UserControl11
    CallMembers UC1


Private Sub CallMembers(ByVal Obj As Object)
    Const NULL_ = 0&, S_OK = 0&
    Dim HR As Long, pFunc As Long, This As Long, VTOffset As Long, RV As Variant

    This = ObjPtr(Obj)

    VTOffset = OffsetOfFirstProc(This):                                                                     Debug.Assert VTOffset >= 7& * 4&
    If VTOffset >= 7& * 4& Then HR = DispCallFunc(This, VTOffset, CC_STDCALL, vbEmpty, 0&):                  Debug.Assert HR = S_OK

but this why not run ok?

 VTOffset = OffsetOfFirstProc(ObjPtr(UserControl11)):
 Debug.Print "Form UserControl VTOffset=" & VTOffset
  Call DispCallFunc(ObjPtr(UserControl11), VTOffset, CC_STDCALL, vbEmpty, 0&)
  
Form UserControl VTOffset=132