forums.silverfrost.com

[wahorger]

Just an FYI of my experience. If your experience is different, I'd love to know!

I needed to add programmatic access to a large block of "C" code (not mine). I had tried to compile using SCC, but was getting access violations in odd places. I though I might be able to use a thrid-party compiler to see if it would solve this problem. However, you cannot load an object module from most third party compilers. So, I though I might use a DLL, which I had used in 32-bit models.

Because I wanted to have this code in a DLL, I chose a 64-bit MINGW compiler (V8.1.0) targeting to the x86-64 memory model. I ran into a few frustrations/blocks that I want to document here. If you have insights or observations, let me know!!

First was in the use of initialized variables (global). A global setting was either not being initialized as it appeared to be in the 32-bit version (loaded a object modules), or was being "zeroed" by being referenced from a DLL. I suspect the latter. But, I am unsure.

Second was the use of the "C" Windows getenv() function (not the FTN95 GETENV@, but the same functionality). This function did not work from the DLL. It did not crash, it just did not find the environment symbol name. I'm not sure how or if I could link with the FTN95 function call. Luckily the software had a "back-door" to allow setting what would nominally be an environment variable.

Third, pointer arithmetic can become problematic when calculating buffer lengths etc. in different memory models. Generally, if you can do the arithmetic without resorting to re-casting results into a different type before the math function, you will be better off, and the code becomes automatically portable between the two memory models.

All that being said, all the routines that I have been able to test so far are working great, just like their 32-bit counterparts. I will say that if/when there is a fault (divide by zero, for example), it is exceptionally difficult to use the MINGW generated set of addresses/offsets to figure out where the fault actually lies, unlike when compiling with SCC.

Bill