forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Using third party "C" compilers (DLL creation)

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Thu Jan 21, 2021 9:34 pm    Post subject: Using third party "C" compilers (DLL creation) Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group