Qt for Excel/VBA

**Nightfox** · 12th December 2012, 20:15

I made a Qt test application that loads the two different .dll using QLibrary. They behave that same. Also, they have the same binary interface as you can see from the Dependency Walker screenshot.

I could be great to hear from somebody that have succeeded in running Qt dll from Excel/VBA.

**amleto** · 12th December 2012, 20:27

the dll and the .a do not have the same filename. This might be an issue? Don't know if a lookup for libxxx.a is always automatic on windows

You're also comparing debug vc6 build with release mingw build.

**Nightfox** · 12th December 2012, 20:44

There's no .a file?! .a is the extension of a static library, I'm compiling both as shared .dll
Debug/Release mode is irrelevant for this comparison.
Look, my problem is to figure out why Excel/VBA will accept the VC6 .dll and not the Qt .dll. They should be exactly the same but they're not.

**d_stranz** · 12th December 2012, 22:39

Look, my problem is to figure out why Excel/VBA will accept the VC6 .dll and not the Qt .dll. They should be exactly the same but they're not.

Why do you think they should be exactly the same? You're using two different compilers, which more than likely have different conventions for the name mangling that occurs during compilation. So, since your VC6 DLL was built using the same compiler that MS uses to create VBA, the name mangling is the same. You many have defined the methods inside them the same way, but I doubt if they look the same from VBA's viewpoint. If your .def file contains the names as generated from VC6, then it is likely incorrect to try to use it with the mingw-generated DLL. I do not know how to use mingw, but there should be a way to determine the names of symbols exported from a DLL.

A second issue is that a Qt DLL needs a running QApplication event loop in order to receive and process Qt events. This certainly isn't being supplied by VBA, so where is it coming from?

**amleto** · 12th December 2012, 22:47

he's compiling .c files as c code. There is no (c++) mangling.

Originally Posted by Nightfox

There's no .a file?! .a is the extension of a static library, I'm compiling both as shared .dll
Debug/Release mode is irrelevant for this comparison.
Look, my problem is to figure out why Excel/VBA will accept the VC6 .dll and not the Qt .dll. They should be exactly the same but they're not.

There IS a .a file in your qt release folder that contains the .dll. This is probably analogous to the .lib file that msvc c++ compiler makes when building a .dll that has exported symbols.

As for debug/release... I find that when you try to tackle a problem it helps to reduce all controllable differences. The fact that these should have been built with different CRT could be a crucial factor. You can't know for sure until you *eliminate* it as a variable. Please, if you are going to pedal the line 'they should be exactly the same', let's not overlook something as significant as debug vs release.

**Nightfox** · 13th December 2012, 11:39

Originally Posted by d_stranz

Why do you think they should be exactly the same? You're using two different compilers, which more than likely have different conventions for the name mangling that occurs during compilation.

Although it's posible to export C++ functions from a DLL, I want to avoid doing so because it doesn't have the well defined application binary interface that C does. Which is why I'm using .C files as pointed by amleto.

Originally Posted by d_stranz

A second issue is that a Qt DLL needs a running QApplication event loop in order to receive and process Qt events. This certainly isn't being supplied by VBA, so where is it coming from?

Please note that the source code doesn't contain any QObjects so no event loop needed.

Originally Posted by amleto

Please, if you are going to pedal the line 'they should be exactly the same', let's not overlook something as significant as debug vs release.

You're absolutely right, all stones should be turned. I compiled the Qt source in debug mode but still no success.

I had a closer look to the dependency walker. The VC6 (VC6DLL4VBA.dll) has a size of 201KB where the Qt (QTDLL4VBA.dll) only has a size of 19KB. Both in debug mode. The significant size difference made me look closer to dependency walker and at first sight, both of the libraries depend on KERNEL32 and USER32, but Qt depends on a third library that VC6 doesn't - the Microsoft C run time library (MSVCRT.DLL). I don't know why it's included in the Qt dll and not in the VC6?
But more interesting, it seem like the KERNEL32 include from the VC6 dll contain way more functions than the Qt dll that only contains two? WTF!?? Why am I only including a fraction of the KERNEL32? Seems like I'm opening a wormbox!

Any ideas to progress from here?