Let's build a transpiler! Part 54

This is the fifty-fourth post in a series of building a transpiler.
You can find the previous ones here.

Zany Zooms

Even though I don't have a job anymore, once in a while I am called to work on some old projects as a free-lancer. Due to that, sometimes I need to join video conferences. There's nothing much to do there, but I am required to join just in case I need to answer something. This is another way to put it: These meetings are boring. Boring to death.
The other day I realized that if I'm listening to music on my computer, the other attendees cannot hear it. It makes sense, but I used to think my audio would be automatically shared with everyone.
After that, when joining such meetings, I put my music just loud enough so I can hear it and also what people are talking about. Of course, I'm using headphones, so when I unmute and talk, nobody hears my buzzing Electric Swing.
It is such an amazing finding, that - while in a meeting - I told my wife "After I've found out I can hear music during these meetings, everything changed to me!"
Except that, you know, I was not on mute. Uh, oh!
That was strike one.

There was a meeting that was scheduled very early in the morning. I put my cellphone to ring half an hour before the scheduled time and would join the meeting from my bed. I would have no time to take a shower, change clothes, and have a breakfast as I usually do. Mind you, we don't activate our cams during meetings, so I thought nothing about it. The meeting started and at some point, I was required to talk. Have you ever noticed how close the unmute button is to the activate cam one?
Well, yeah. I clicked the wrong button and while I was haphazardly trying to "unclick" it people saw me looking like this:

Me as a caveman
Credits: Toonify

That was strike two.

Sometimes we have to share our desktop to show everyone what we are doing or seeing.
I keep the source code for that old projects in another drive, so, when I needed to show it, I would open that drive and browse to the relevant folder. Until one day it dawned on me. I keep some... well, entertaining files in that same drive, in a folder with a very suggesting name (Sexxx, of all things!) Every time I opened that drive, everyone at the meeting would see it right there and would have no doubts about its contents.
Oh, my... It was almost as embarrassing as this.
That was strike three. Enough is enough.

Now, I join meetings wearing a cap and installed an app that uses shortcut keys to mute my mic. It has a very prominent indication in the middle of the screen whether it is on or off
And I renamed that folder to Chess.

Back to business

Last time, I said we would revisit our TLib dumper module. When I first made it, there were some things I did not know how to do. (How to enumerate the interfaces a coclass implemented, for instance.) As I said before, I read TheirCorp's manual several times, but there's too much missing there. Previously, I tried to find the source code mentioned in the manual but was unable to. This time, however, I succeeded! It is here. Due to that, I updated my version of TheirCorp's manual with the tidbits I could find in the source code. After carefully reading it, these are the main new "knowns:"

For each available GUID, calculate its hash, then store that GUID's offset at the Lib Table's entry pointed to by the hash. The algorithm is:

Function HashGuid(ByRef Bytes() As Byte) As Byte
Dim Idx As Integer

For Idx = 0 To 6 Step 2
HashGuid = HashGuid Xor Bytes(Idx)
Next

HashGuid = HashGuid And &H1F
End Function
The same goes for the Unknown1 and the Name Table. For each name, its offset is stored into Unknown1's entry pointed by hashing the name. The hashing algorithm for names is a little more involved, though:

Function HashName(ByVal SysKind As Integer, ByVal LCID As Integer, ByVal Name As String) As Byte
Dim IsMac As Boolean
Dim HashTb() As Byte
Dim Ch As Integer
Dim Result As Long
Dim Idx As Long

IsMac = SysKind = SYS_MAC
Name = StrConv(Name, vbFromUnicode)

Rem Select a hash table according to the provided LCID
Select Case LCID And &H3FF
Case (...)
Tb = (...)
(...)
End Select

For Idx = 1 To LenB(Name)
'MidB$(Name, Idx, 1) |> AscB |> CInt -> Ch
Ch = CInt(AscB(MidB$(Name, Idx, 1)))
If Ch > &H7F And IsMac Then Ch = Ch + &H80

Rem Avoiding overflow
If Result >= &H6EB_3E45 Then
Result = CLng(Result * 37^ Mod &H100000000^)

ElseIf Result <= &H914_C1BB Then
Result = -CLng(Result * 37^ Mod &H100000000^)

Else
Result = Result * 37
End If

Result = UAdd(Result, HashTb(Ch))
Next

Result = Result \ &H1003F And &H7F
HashName = CByte(Result)
End Function
A class' TypeInfo.DataType1 is an offset into the References Tables. There, its RefType is an offset into the TypeInfo to the first implemented interface. We can find the next implemented interface in NextOffset, that is another offset into the References Table. Then rinse and repeat until we find a NextOffset equal to -1 marking the end of the chain.

But some unknowns still remain:

I don't know why the Offsets to TypeInfos are laid out the way they are. Those entries do not seem to have a discernible order.
I'm not sure what goes into the Custom Data section nor how it is used.
WTF means "If TypeKind is an interface, then DataType1 is a reference to inherited interface?" How do references differ from offsets? Are they some table's zero-based indexes? If it is so, which table??

Due to that, I was unable to complete my TLib compiler, but I updated the dumper. The code below has a bug fix and an improvement: It now lists the implemented interfaces (yay!)

Next week we'll see how to replicate VB's error management without resorting to non-portable code.

Andrej Biasic
2022-01-19