• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Call to in house C++ DLL returns "Error opening DLL" for the version wrapped for Veryant 64 bit but not for 64 bit MF COBOL version

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (3)

Resolved Call to in house C++ DLL returns "Error opening DLL" for the version wrapped for Veryant 64 bit but not for 64 bit MF COBOL version

  1. Advice
0
Votes
Undo
  1. Aimee Stephens
    Aimee Stephens
  2. PowerBuilder
  3. Tuesday, 20 December 2022 18:07 PM UTC

We've converting our backend system from MF COBOL 32 bit to Veryant 64 bit.  When we try to run with the 64 bit PB, 64 bit Veryant and 64 bit DLLs we get the "Error opening DLL" message.  The DLL is wrapped for Veryant and the person responsible for the DLL says that it's a PB issue.  I'm sure that's possible but to me seems odd because:

We can run our current 32 bit PB agains our current 32 bit MF COBOL AND the 32 bit C++ DLL,

**We can run our current 32 bit PB against the NEW 32 bit Veryant AND the NEW 32 bit wrapped C++ DLL,

We can run our current 64 bit PB against our current 64 bit MF COBOL AND the recompiled 64 bit C++ DLL, BUT

We CANNOT run our 64 bit PB against the new 64 bit Veryant with the new 64 bit wrapped C++ DLL

I tried adding progma_pack(1) to the end of the external function call along with checking the Tool-->System Options-->Use 1-byte structure member alignment in external function option but that didn't make a difference.  The function returns an int (0 or 1).

What could possibly make the 64 bit wrapped DLL different than the non-wrapped 64 bit DLL that I am able to call?  And if there's some sort of issue with Veryant, why cam I able to call the 32 bit wrapped DLL?

Using PB 2022 Build 1878

  1. 64-bit
  2. DLL
How do I change a MDI Frame's Window Title Backgro...
Error on export MS excel12
Responses (3)
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Tuesday, 20 December 2022 20:13 PM UTC
  2. PowerBuilder
  3. # 1

You can't call a 64bit DLL from a 32bit PowerBuilder app or 32bit DLL from 64bit PowerBuilder. They have to have matching bitness.

Comment
Aimee Stephens
  1. Aimee Stephens
  2. Tuesday, 20 December 2022 21:23 PM UTC
Correct. We have separate environments setup for each - 4 total. I know that the PB and the DLL are both 64 bit from a tip where you can edit the exe or DLL using Multi-Edit and the HEX value of a specifc field will display as PE d and both do. Also, I know for sure PB is 64 bit by running task manager after starting the application and going to Details tab and looking at the platform. Can't get to that level of certainty with the DLL though.

I know I can call the version of the 64 bit DLL that isn't wrapped. It just seems to me there's an issue with the way it was wrapped, recompiled or something and has nothing to do with PB but I have to make certain my code is right.
  1. Helpful
Roland Smith
  1. Roland Smith
  2. Tuesday, 20 December 2022 21:26 PM UTC
Perhaps the C++ runtime needed for one of the in-house DLLs is missing on your computer.
  1. Helpful 1
Aimee Stephens
  1. Aimee Stephens
  2. Tuesday, 20 December 2022 21:53 PM UTC
Possibly a 64bit runtime of the Veryant wrapper is missing. I'll pass that by the developer and see if there's any chance something didn't get loaded. So far that's the only logical solution!
  1. Helpful
There are no comments made yet.
Aimee Stephens
Aimee Stephens Accepted Answer Pending Moderation
  1. Tuesday, 20 December 2022 19:29 PM UTC
  2. PowerBuilder
  3. # 2

This is the first time I've had a chance to look at the code for the DLL.

DllExport int _stdcall INIT01 (char inComingData[])struct DataStream
{

{
char opSys[03];
char programName[10];
char entryPt[40];
char msg[200];
char dataField[25000];
};

However, all of the years this DLL has been in use PB has been passing one long stream with all of these variables strung together.  I was never informed that the function I was calling was expecting a structure.  I knew I was passing multiple parameters and just thought the person that had coded the DLL was parsing through the string.  Here is how she told me to call her function and how it's been called for 24 years.

function int INIT01 (ref string s_cobol_parameters) LIBRARY "gqeclps.dll" alias for "INIT01;Ansi" progma_pack(1)

The ;Ansi was added when we converted to 2019 and I just added the progma_pack(1) today when it failed to call the 64 bit version that's wrapped.  That's the only version that isn't working and why I'm skeptical of it being a PB issue.  The PB isn't changing, the compiling and wrapping of the DLL is changing.  I successfully call the 64 bit version that isn't wrapped.  I successfully call the 32 bit version that is wrapped.  It's only the 64 bit wrapped version that is returning the error.

Comment
John Fauss
  1. John Fauss
  2. Tuesday, 20 December 2022 20:05 PM UTC
You can remove the progma_pack(1) change as well as specifying 1-byte structure alignment in Tools->System Options, because you are passing a single string variable from PB, not a structure. These settings apply only to structures.

I'm afraid I don't understand the distinction between what you are calling a 64-bit "wrapped" DLL and a 64-bit DLL. If you are able to successfully call a 64-bit DLL, why the need for the "wrapped" DLL???? It seems clear that PB is unable to interface with the 64-bit DLL's wrapper, but without a better understanding of the details, I can only guess as to the cause.
  1. Helpful 2
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 20 December 2022 18:49 PM UTC
  2. PowerBuilder
  3. # 3

Are there structures being passed in/out of the DLL? Are those structures laid out (packed) on single-byte boundary? Is specifying 1-byte alignment necessary for the 32-bit interfacing with PB?

What calling convention are the DLL entry points using in the 64-bit version? PB requires use of __stdcall calling convention in either bitness. 

Comment
John Fauss
  1. John Fauss
  2. Tuesday, 20 December 2022 19:26 PM UTC
Also, what exactly do you mean with the phrase "64-bit wrapped DLL"? That is a somewhat odd expression... I'd expect you to say the DLL is either 32-bit or 64-bit, not 64-bit wrapped.
  1. Helpful
Aimee Stephens
  1. Aimee Stephens
  2. Tuesday, 20 December 2022 20:36 PM UTC
Apparently, by converting our current MF COBOL backend programs to Veryant COBOL the DLL has to be wrapped in order to interface with the new Veryant programs (which are Java classes). This is what is absolutely confusing to me because I can call the 32 bit DLL that has been wrapped but not the 64 bit version. And I completely agree with you. From my viewpoint the only thing I am thinking of is 32 bit vs. 64 bit and under those circumstances I am able to call both of those with no issues. But then they throw this "wrapper" on the DLL and I am only able to call the 32 bit version. Seems to me that if the PB side isn't changing there's something wrong with the way this particular version is wrapped or compiled or something but I have to prove beyone any doubt that PB isn't causing this issue.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.