Originally Posted by randomizer
Correct. We have no access to the source code of the application because it is owned by another party.
That explains the non-rewritable part then
Originally Posted by Plan9
I wasn't aware VBA passwords were so easily broken. You learn something new every day
Not an ideal solution, but you can call Windows DLLs from VBA so you have the option of rewriting large parts in C++ if you needed to. Essentially just using VBA as the wrapper around your own APIs. (you might even get some performance gains depending on where bottleneck sits in application)
It seems like VBA is used to interface with the application - the impression I get is VBA is used for automation with the host application. You couldn't do this with interop to native code unfortunately (even though technically it should be possible... their COM API should be IDispatch interfaces which makes it available to scripting like VBA and available to any other COM supported language via IUnknown).
Thing is though, anything accessible via VBA should be accessible via any other language that supports COM - its kind of the whole point of COM in the first place.
Scripting works by calling IDispatch::GetIDsOfNames and then calling IDispatch::Invoke. This is late binding useful for VBScript. Though if I remember correctly, VB6 can use early binding via IUnknown directly.
So my question to the OP is, how does their VBA host work? Does using VBA really just script a bunch of COM objects? If so you can call these via CoCreateInstance in native code (give it the ProgID instead of a CLSID, or preferably use the CLSID if you know it.).
Although if they are doing their own processing or whatever on some data that is the bulk of the work then by all means offload that to native binaries (and enjoy the headaches, but hey, that's the price you need to pay