The New Sudoku Players' Forum

[Mathimagics]

(Terminology: A "PE" is a "Portable Executable" file, on Windoze that means a DLL or EXE, and a "PE tool" is a tool that lets you peek inside these. Particularly if you want to find out what DLL functions this PE calls, aka its "Import Table", and what functions can be called in this PE, aka its "Export Table").

I just wasted 12 hours trying to find out what was "wrong" with a program … that actually had nothing wrong with it at all!

I was building a simple DLL that would make a generic DLX solver function available.

As usual, when I first created the DLL, I used a "PE tool" to check that the DLL that I had made actually exported the desired functions, and to my horror found that it wasn't exporting anything!

I checked all my existing DLL builds, and nothing was wrong there, so I found myself thinking that it must be some obscure bug in the GCC compiler/linker that was causing this. This seemed to be even more likely as the PE tool in question reported "No exports" for the 64-bit DLL build, but actually crashed when I gave it the same DLL, but built for Win32. Something dodgy in the export table, right?

12 hours later (after considerable "wailing and gnashing of teeth") I finally discovered that it was a fault in the PE tool itself - a case where a poor workman blaming his tools is justified!

The PE tool was downloaded from HERE. It generally works fine, does what it says on label, for the most part, except of course in this case. I think the bug relates to very short export tables, since this DLL only exports a single function, unlike most of the others that I have used the tool with.

Anyway, all sorted now, but can anyone suggest an alternative (freeware) PE tool?

I do have my own tool which works for Win32 PE's (DLL's, EXE's), so maybe I just need to know how to make it work for Win64 PE's, and any pointers to information that would help me to do this would also be useful.

Cheers
MM

[Mathimagics]

.
Hmmm .. maybe something IS a little dodgy about this DLL?

Having verified (with my PE32 tool) that it really does export the desired function, I then find that VB6 still finds something wrong with this DLL.

It reports "File not found: GenericDLX32.dll", and when this happens but you know the DLL does exist and is in the current directory, that is a sure sign that VB6 has gotten an error when it makes a call to the Win Kernel32 function "LoadLibrary". And that really does suggest that perhaps the fault is with (my version) of GCC.

If the function was simply misnamed, we would expect a different error ("Entrypoint XXX not found in YYY.dll").
If we messed up the calling convention (cdecl vs stdcall), VB tells us about this case too (it checks the stack).

My tool just extracts the Export tables from the PE, it does not attempt to load the PE image into memory, whereas the freeware "PE tool" does …

Curiouser and curiouser …


[EDIT] Ok, I added 20 dummy exported functions to the DLL. The PE tool no longer crashes when loading the 32-bit version, and shows the correct export table. But alas, VB6 still does NOT like it … ???

[EDIT] "PE tool crash" problem is probably a red herring. It no longer seems to do this so probably an error on my part. But it DOES report wrongly that the export table (when I remove the dummy functions) is empty.

Also, the 32-bit DLL itself is definitely viable - it works perfectly well when called (using stdcall) from a C program linked with it.

This is not truly dynamic linking however, as the DLL function name/address resolution is done at link-time, not the same as VB6 which does "LoadLibrary" + "GetProcAddress" at runtime. That "LoadLibrary" call still fails, it seems, where it has never failed before for other DLL's built the same way. We can emulate this "resolve at link-time" mechanism and bypass the VB6 run-time linking by declaring the DLL functions in a TLB (Type Library), and I have done this on Win32, but not yet attempted it on Win64.

And all of this suggests that the "PE tool" problem itself is a complete red herring … there remains one more theory to test ...

[Mathimagics]

.

• "PE Tool" does have a bug, but that was a red herring, and I got sucked right in chasing it!

• GCC linker has no fault either

• it was all down to a memory-allocation problem

The DLX function in the DLL is "generic" (intended to solve Samurai's with independent variant modes), so it needs a large table. We have 369 cells, and so we need up to 369 x 9 (2321) rows. The column requirements vary for each Sudoku variant, but at a minimum, if all 5 are vanilla (3D) we need 5 x 3 x 81 (1215), and if we get really exotic and use 5D in all grids, this rises to 5 x 5 x 81 (2025). Plus in all cases we need to add 369 columns for the cells.

I have 32Gb of RAM, so I declared this table as 4096 x 4096 (to be sure, to be sure ...), and at 32-bytes per element, this is precisely 1/2 GB. Very modest, IMHO, you would hardly notice it!

In fact, if the VB6 app is compiled to an EXE, it doesn't mind at all! But in the IDE, that somehow interferes with the IDE's heap, and so the LoadLibrary fails … 1/4 Gb seems to be the limit.

But we have learned something from this night of pain - always check your tools thoroughly, lest they lead you off on a hare-brained herring hunt!

And finally, the bottom line is that this entire thread has now lost any relevance, and says nothing useful!

I mean who in their right mind would still be running VB6 ?

[Hajime]

.
I mean who in their right mind would still be running VB6 ?

I use VB in .NET 2017 Visual Studio, free for individuals, as long if you have a hotmail address.
It is much faster than VB6.

[Mathimagics]

VB.NET 2017 ... is much faster than VB6.

That is rather a curious claim … faster at what, exactly? Everything?

For every instance where a programmer ports a VB6 app to VB.Net (which can be a very painful process), and gets an app that runs faster, I think you'll find someone else who gets the opposite effect (Google "vb6 faster than vb.net" turns up lots of examples).

So it really depends on just what your app is actually doing, plus what compiler switches are used, what environment its running in, etc etc ... many factors.

VB6 is simply convenient for me - if I want speed of execution, and I want a GUI front-end, then I will use C/C++ for the grunt/crunch work, and then wrap that in a DLL so I can call it from VB6 (much as I am doing with my Samurai app).

It's also really, really stable, since it is frozen in time …

"Horses for courses" ...

Cheers
MM


PS: Now I'm curious. Why did you build your Gattai app in Excel/VBA ?? Not with VB.Net ...

[Mathimagics]

Looks like VB.net is also going to have a limited future. See this article (from 2 years back)