Request for a Qt export demangler utility

[gdmeunier]

Hello,
Your Qt6 project for Windows 7 is pure gold.

The only issue is that by default Qt6 apps use highly specific export function names, which also end up in the import table of compiled Qt EXE files too.

However, there's for example IDA Pro which cans demangle function names automatically (generating clean function names, without prototype info).

If you could perhaps even create a tool that demangles the names of exported functions in any Qt6 DLL, then we could automatically sanitize the function names of your DLL files.

Then we would also be able to run that tool on a target Qt6 program (e.g. XCA.exe, X-Certificate Authority, an x509 cert management utility), and it would look for imported DLLs names that start with "Qt6" or "qwindows".

If any such imported DLL names are found, then the names of the imported functions would also be sanitized and we would end up with matching DLL exports, without all the compiler-specific prototypes which seem to break direct DLL swapping.

For the rest of the DLL calls, we could use either VxKex or we can redirect all missing DLL files to their appropriate real DLL.

(e.g. almost all the Win10 exclusive "api-ms-win-core-synch-2-1-0.dll" calls are actually already in Win7's kernel32.dll)

Thanks for the Qt6 DLLs nonetheless, it's already a great start.
They just need a way to simplify the exported function names.

References:

XCA: https://github.com/chris2511/xca
VxKex: https://github.com/vxiiduu/VxKex

[kleuter]

Hi and thanks for kind words. Not sure about such an utility: an obvious solution to exports/imports issue is simply recompiling a Qt app against qt6windows7 (provided an app is open source, of cause).

[gdmeunier]

Hello,
Thanks for your reply.

I have experience recompiling some Github projects, but those that I successfully recompiled were Visual Studio solutions & those that don't use a makefile or qmake build system.

There's also a tool that I already use graphically named CFF Explorer, which offers a scripting API (for advanced users). I don't use its scripting API, but it cans be interesting as well.

For Windows 7 compatibility of new programs in general, almost all of incompatibilities are because of missing ApiSet stubs (api-ms-win-[...].dll files).

Those ApiSet stubs are unnecessary anyway, since all the functions are redirects to kernel32.dll, user32.dll, and so on. If you look at it deeper, these functions already exist in Windows 7 natively at their real system DLL.

Even in VxKex's registry config for DllRewrites, many api-ms-win[...] files are rewritten to its NTD33.dll file.

And again, thanks to developers like you who keep Windows 7 in good shape.