This idea was something I just wondered if I could do. So, when I figured it out, wasn't too difficult to create a mostly generic template that could be used & re-used as needed. And that's what we have here.
With VB we may have to jump through hoops trying to declare and use a Windows COM interface that doesn't inherit from IDispatch. Typically, we would add a type library (TLB) to our project that contains the interfaces we plan on using. That works pretty well.
With this code/idea, you can create these interfaces with pure VB code and without using any TLBs. If you're not the type that enjoys low-level coding, run away now, don't look back, just keep running ;).
This is pretty low-level stuff. The code creates a memory only VTable and thunks for the interface methods. But in order to do this, YOU have to research the interface. You need to know the IID (GUID) and the order of the methods in the interface (not the order posted on MSDN). Then you have to create each of the interface's methods as VB functions. Honestly, it's not that bad after you've done a few of them. I can generally whip up a working sample in about 5-10 minutes after I've found the IID and VTable order. MSDN is extremely useful in describing each method's parameters & return values.
FYI: IID is only needed should whatever you are passing this interface to asks it to identify itself. You want it to be able to say it is what it is pretending to be. In reality, and depending on what the interface is being used for, it's not often asked. But why risk it. The IID is the easiest thing to find. The VTable order is often more challenging.
Any how. As I said, low level. Because there are no TLBs to access these interfaces, we have to call them by their pointer and VTable function address offsets. Again, pretty easy really with the code provided and knowing the VTable order. But it does take some getting used to. For example, many times you may create or receive pointers to interfaces which you are required to add or remove a reference to. VB does this for us automatically. VB does not help here. You have to know when/if you must up the ref count or release the reference. Code is available to do that for you once you know those answers.
This is in no way an attempt to code without TLBs. However, it is kinda neat to know that you can create a class-only object that can be moved from project to project without requiring a TLB. I think that is about the only true advantage. The disadvantage, obviously, it's harder to do this manually.
That attached zip file has a sample project and the IFauxInterface template. That template has lots of comments, in fact, more comments than code. The sample project's IBindStatusCallback class was created from that template. The form in the project creates a pointer only interface and uses low-level access to manipulate it. Enjoy
Regarding the thunks. No malicious code in there. The thunks basically do this:
- store the stack
- set up the stack for the callback: add the class' object pointer and the parameters
- call the VB class private function
- restore/adjust/pop the stack as needed & set the VB function return address
- done. 48 bytes used per thunk, 4 bytes per VTable entry, 8 bytes per Interface pointer
Edited: If you don't see the progress bar dialog before the download finishes. The download was too quick or used cached data. The progress dialog is created in the form. The IBindStatusCallback class is what pushes that progress bar to be updated from the events it sends. What is giving us those progress events is the URLmon.dll via the interface we created from the template.
With VB we may have to jump through hoops trying to declare and use a Windows COM interface that doesn't inherit from IDispatch. Typically, we would add a type library (TLB) to our project that contains the interfaces we plan on using. That works pretty well.
With this code/idea, you can create these interfaces with pure VB code and without using any TLBs. If you're not the type that enjoys low-level coding, run away now, don't look back, just keep running ;).
This is pretty low-level stuff. The code creates a memory only VTable and thunks for the interface methods. But in order to do this, YOU have to research the interface. You need to know the IID (GUID) and the order of the methods in the interface (not the order posted on MSDN). Then you have to create each of the interface's methods as VB functions. Honestly, it's not that bad after you've done a few of them. I can generally whip up a working sample in about 5-10 minutes after I've found the IID and VTable order. MSDN is extremely useful in describing each method's parameters & return values.
FYI: IID is only needed should whatever you are passing this interface to asks it to identify itself. You want it to be able to say it is what it is pretending to be. In reality, and depending on what the interface is being used for, it's not often asked. But why risk it. The IID is the easiest thing to find. The VTable order is often more challenging.
Any how. As I said, low level. Because there are no TLBs to access these interfaces, we have to call them by their pointer and VTable function address offsets. Again, pretty easy really with the code provided and knowing the VTable order. But it does take some getting used to. For example, many times you may create or receive pointers to interfaces which you are required to add or remove a reference to. VB does this for us automatically. VB does not help here. You have to know when/if you must up the ref count or release the reference. Code is available to do that for you once you know those answers.
This is in no way an attempt to code without TLBs. However, it is kinda neat to know that you can create a class-only object that can be moved from project to project without requiring a TLB. I think that is about the only true advantage. The disadvantage, obviously, it's harder to do this manually.
That attached zip file has a sample project and the IFauxInterface template. That template has lots of comments, in fact, more comments than code. The sample project's IBindStatusCallback class was created from that template. The form in the project creates a pointer only interface and uses low-level access to manipulate it. Enjoy
Regarding the thunks. No malicious code in there. The thunks basically do this:
- store the stack
- set up the stack for the callback: add the class' object pointer and the parameters
- call the VB class private function
- restore/adjust/pop the stack as needed & set the VB function return address
- done. 48 bytes used per thunk, 4 bytes per VTable entry, 8 bytes per Interface pointer
Edited: If you don't see the progress bar dialog before the download finishes. The download was too quick or used cached data. The progress dialog is created in the form. The IBindStatusCallback class is what pushes that progress bar to be updated from the events it sends. What is giving us those progress events is the URLmon.dll via the interface we created from the template.