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

Resolved Error Opening DLL Library

  1. How-to
0
Votes
Undo
  1. Jonathan Lawson
    Jonathan Lawson
  2. PowerBuilder
  3. Tuesday, 11 January 2022 16:57 PM UTC

I'm migrating a legacy application from PB8 to PB 2019R3.  

The app makes use of a DLL called mnutil.dll that was written in-house in C many years ago. The PB8 version of the app works happily enough on Win 10 currently, but I'm having issues with the DLL in PB 2019. 

At runtime (both from within PB 2019 and when running the 32-bit exe), I'm getting an error 'Error opening DLL library mnutil.dll for external function...'

I have the mnutil.dll file sitting in the same folder as the application PBLs and the app all builds nicely in PB.  I've tried adding the folder to the PATH too, but that makes no difference, so I'm assuming the error is not because it can't find the file.

 

The external function definition looks like this:

FUNCTION int GenMNPassword(ref string sip, ref string sop, long nopbuf) LIBRARY "Mnutil.dll" alias for "GenMNPassword;Ansi"

 

The DLL source code for that function looks like this:

int FAR PASCAL GenMNPassword(char far* szInput, char far* szOutput, long nOPBufSize)
{ ...

 

Finally, the Powerscript code calling the function looks like this:

string ls_input, ls_output
integer li_ret

ls_output = Space(32)

ls_input = (stext)
li_ret = GenMNPassword(ls_input, ls_output, 31)

Return ls_output

 

Can anyone offer any advice on where to look next?  Thanks!!!

 

  1. External Functions
store chinese character on nvarchar
PB2019 R3: When using FileMove() permissions are n...
Responses (5)
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 12 January 2022 10:36 AM UTC
  2. PowerBuilder
  3. # 1

Could it be it needs some old c++ runtime or an older ATLxx.DLL or MSVCRxx.DLL ? Maybe a missing dependency?

Comment
There are no comments made yet.
Jonathan Lawson
Jonathan Lawson Accepted Answer Pending Moderation
  1. Wednesday, 12 January 2022 09:32 AM UTC
  2. PowerBuilder
  3. # 2

Thanks all for the help/advice so far!

I've tried adding the PROGMA_PACK(1) entry, and also changing the return datatype to Long, but neither have made any difference.

Unfortunately that might mean we have to look at the DLL source, which hasn't been touched for 15+ years and I guess will require a whole different set of tools/resources.  Wish me luck! 

Comment
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 11 January 2022 22:49 PM UTC
  2. PowerBuilder
  3. # 3

The "pascal" calling convention is quite different from the "stdcall"/"WINAPI" calling convention. In the pascal calling convention, arguments are placed onto the call stack in left-to-right order. In stdcall, arguments are placed onto the call stack in right-to-left order.

http://www.c-jump.com/CIS77/ASM/Procedures/P77_0070_pascal_stdcall.htm

Comment
There are no comments made yet.
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Tuesday, 11 January 2022 21:12 PM UTC
  2. PowerBuilder
  3. # 4

This probably isn't the problem but a long in C is a ulong in PowerBuilder. A PowerBuilder long is integer in C. A PowerBuilder integer is a short in C.

For an Ansi C dll I would code the function as:

 

int WINAPI GenMNPassword(LPSTR szInput, LPSTR szOutput, long nOPBufSize)

 

Comment
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 11 January 2022 17:26 PM UTC
  2. PowerBuilder
  3. # 5

Hi, Jonathan -

It's probably the byte-alignment value used by the DLL. You say it's old, so I suspect it is expecting single-byte alignment. Try including "PROGMA_PACK(1)" [without the double-quotes] after the ALIAS FOR clause in the PB External Function Declaration and see if that resolves the issue. PB switched to using 8-byte alignment many versions ago.

Best regards, John

 

Comment
John Fauss
  1. John Fauss
  2. Tuesday, 11 January 2022 17:33 PM UTC
It might be the calling convention used by the DLL. External DLL's need to use the WINAPI (_stdcall) format. "far pascal" may or may not be equivalent. It's been a couple of decades since I've seen or used that.
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 12 January 2022 15:11 PM UTC
Hi John;

Yes, newer PB's no longer support the Pascal calling convention. You have us the _STDCALL mechanism. PB used to support Pascal when the PB IDE & Runtime were built using the WatcomC/C++ compiler (PowerSoft days) but Sybase swapped that out for the Microsoft C/C++ compiler in newer PB versions.

FYI: https://docs.appeon.com/pb2019/application_techniques/ch23s01.html

Regards ... Chris
  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.