So, I was having an email conversation with a regular reader of my Access Adventure and he was discussing the sad lack of documentation for VBA’s internals. The engine that runs it and it’s various components. Although I have a cursory knowledge of VBA, I have never traveled down a road of researching more about it. This morning I began.
As I’ve mentioned before, VBA is based on VB6. The code you write in VBA goes through a process called “compilation” by Microsoft which translates the code you wrote into a binary code called P-Code which Microsoft says stands for either “packed” code or “pseudo” code. I prefer packed code after reading this because I think of pseudo-code as being even more abstract than VBA code. P-code was introduced for both VB6 and C++ by Microsoft and if you know the concepts behind Java, it’s exactly the same idea. P-code runs on a virtual machine. In the case of Office, VBA ALWAYS is reduced to P-code which is then run on a virtual machine implementation inside of Office. This is a big difference between VBA and VB6 because VB6 could compile code into executable files OR P-code and so could run either way or in any combination.
I think being able to understand or write P-code could make us quite dangerous… 🙂 It would allow us to interact directly with the virtual machine. I know that at least one Access Add-in I use does some interesting things with memory and dropping in stange character sequences. This could be direct P-code, or something else. The code I looked at was written by Wayne Phillips and is in the vbWatchdog product which adds hooks to the error routines and a programmatic interface for accessing the VBA call stack, which is NOT something that VBA itself provides. You can SEE the call stack by pressing Ctrl-L while in debug mode, but you can’t programmatically refer to it.
Very interesting stuff. I haven’t reviewed this web site yet, but I am interested. It’s actually an early discussion of P-code when it was first implemented for C++: