Can an Equals sign appear in any of the PROJECT stream data values?

[Beakerboy]

I split each line at the equals sign. If things like description or file names are allowed to have an equals sign, the array will need to be joined back together.

[KallunWillock]

That's what I do too in vbaXray, but you raise a good point re: the Description field at least. Anywhere else and I suspect it wouldn't be compliant with the spec. For example:

HelpFile=""
Name="vbaSolitaire"
HelpContextID="0"
Description="Clone of classic Solitaire. A basic demonstration of VBA's graphical capabilities."
VersionCompatible32="313212980"
CMG="B5BA4E167BE2521A5216FF2165"
DPB="9F9649D2B962B299772B"
GC="88578E75BEA39FA39B9C"

[Beakerboy]

🤯

TIL there are people who actually are paying attention to this project besides me. By all means pester me with questions, requests, tests, or whatever else you want.

[Beakerboy]

According to the specification:
https://officeprotocoldoc.z19.web.core.windows.net/files/MS-OVBA/%5bMS-OVBA%5d.pdf

Any QuotedChar can contain equals, so that would be file paths, Description, or HostExtender Lib name.

[Beakerboy]

I’d love to leverage your expertise to help make the valid Excel add-ins that I aim to create. I am able to currently create files that Excel will open and enable, and whose source code can be displayed within the VBA IDE, but executing the functions produces errors. Do you think your tools would be able to help find the source of errors and help create files that are able to be fully manipulated by Excel.

Here’s one such file:
https://github.com/Beakerboy/VBA-CI-CD-Test/releases/download/0.0.19/Addin.xlam

[KallunWillock]

According to the specification: https://officeprotocoldoc.z19.web.core.windows.net/files/MS-OVBA/%5bMS-OVBA%5d.pdf

Any QuotedChar can contain equals, so that would be file paths, Description, or HostExtender Lib name.

You're right. I wouldn't have thought it would have been considered legal outside of the Description field, but I just checked and it seems it can be used in filepaths. I'll need to correct the logic in my code.

[KallunWillock]

I’d love to leverage your expertise to help make the valid Excel add-ins that I aim to create. I am able to currently create files that Excel will open and enable, and whose source code can be displayed within the VBA IDE, but executing the functions produces errors. Do you think your tools would be able to help find the source of errors and help create files that are able to be fully manipulated by Excel.

Here’s one such file: https://github.com/Beakerboy/VBA-CI-CD-Test/releases/download/0.0.19/Addin.xlam

Sorry - I only just saw this now. I just tried your XLAM file and you're right - it wouldn't work. There wasn't anything obvious about it or the ZIP internals to suggest why it wouldn't work, but let me do some checks and I'll update you.

Also, I would love to pick your brain about FRX files.

[Beakerboy]

Unfortunately, I don’t know anything about FRX files. More than happy to implement anything you figure out though. I have a separate project where I have information from the performance cash regions of the VBAProject.bin files.

Here are some white papers.
https://github.com/Beakerboy/MS-Pcode-Assembler/tree/main/docs

[Beakerboy]

It sounds like an FRX file is an OLE container with a 24 bytes prefix indicating the container’s size. If you have time to strip the first 24 bytes from an frx and extract the ole file contents, I can start a python file to rebuild the frx “from source”.

[Beakerboy]

Is this what you are looking for?
https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-oforms/9c79701a-8c3e-4429-a139-b60ac3a1d50a

[Beakerboy]

@KallunWillock
The FRX file contains a OLE container with three files, ‘o’, ‘f’, and ‘compobj’. It looks like the first two are described in MS-OFORMS, while the third is described in MS-OLED. I just started a repository to begin coding these data structures up.

[KallunWillock]

Sorry - It's been a painfully busy week at work, and am only just getting around to seeing this now.
I had been looking at the MS-OFORMS document already, but not the MS-OLED - thank you! This is very helpful.

As for your non-working addin file, the way I went about looking into it was:

1. Extract the source code from your XLAM (it looks like only one module contains meaningful code)
2. Create a fresh workbook in Excel and import that same module
3. Save that workbook back out as an XLAM
4. Unzip both files and compare the resulting vbaProject.bin structures with my class.

A soon-to-be-completed update will include a debug tree dump function, which I find useful for situations like this. When I ran your addin vbaproject.bin, it produced:

.
+-- [VBA]
|   +-- dir                             522 bytes
|   +-- Sheet1                          143 bytes
|   +-- HelloWorld                      84 bytes
|   +-- ThisWorkbook                    150 bytes
|   \-- _VBA_PROJECT                    7 bytes
\-- PROJECT                             430 bytes

and when I ran it over the new SampleAddin.xlam file, it produced:

.
+-- [VBA]
|   +-- dir                             572 bytes
|   +-- Sheet1                          1180 bytes
|   +-- __SRP_0                         2090 bytes
|   +-- __SRP_1                         250 bytes
|   +-- __SRP_2                         464 bytes
|   +-- __SRP_3                         106 bytes
|   +-- __SRP_4                         680 bytes
|   +-- __SRP_5                         106 bytes
|   +-- __SRP_6                         402 bytes
|   +-- __SRP_7                         156 bytes
|   +-- HelloWorld                      1485 bytes
|   +-- ThisWorkbook                    1188 bytes
|   \-- _VBA_PROJECT                    2616 bytes
+-- PROJECT                             476 bytes
\-- PROJECTwm                           95 bytes

The obvious point of difference is the SRP streams, but I frankly don't know much about them and didn't need to in order to extract the VBA code. As you say:

The SRP streams contains a performance cache information. How is each SRP stream tied to a specific module?

Another thing that jumped out of me was the _VBA_PROJECT stream - the bare-basic SampleAddin.xlam file seems to have 2616 bytes, and yours has 7 bytes.

I would also point out that Sheet1 and ThisWorkbook obviously do not have any code in it.

I don't know if this is helpful to you at all - I saw your White Papers - you obviously have put a lot of valuable work into this! I will keep investigating.

[Beakerboy]

The _VBA_PROJECT stream includes a lot of performance cache data. The OVBA spec requires that it not be included, so only the first 7 bytes of the header are written (per the spec) the SRP streams are also performance cache, and their structure is undocumented.

[KallunWillock]

Continuing with my checking of the differences between the working XLAM file and the malformed XLAM file, I see that the Sheet1 and ThisWorkbook files do not have GUIDs assigned to their VB_Base field:

Attribute VB_Name = "Sheet1"
Attribute VB_Base = "0
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = True
Attribute VB_TemplateDerived = False
Attribute VB_Customizable = True
...
Attribute VB_Name = "ThisWorkbook"
Attribute VB_Base = "0
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = True
Attribute VB_TemplateDerived = False
Attribute VB_Customizable = True

The problem appears to result from doc_module.py.

[Beakerboy]

I’ll look into that. Thanks for the investigation!

Related news, I should be able to create the FRX binary file for a form from a YAML file describing it’s design in a few days.