Hi Vijay;

  The error seems to be faulting on the MWARE32.dll. This is not part of PowerBuilder (IDE or runtime). So I am guessing that this must be a 3rd party DLL that is either: A) missing, B) needs updating or C) your PB App is compiled for 64bit operation and you are trying to use a 32but DLL (they must be the same bitness).  HTH

Regards ... Chris

Hi,

Do a search on mware.dll on all of your pb plbs. Probably it's being used in an external function declaration somewhere.

And of course, what Chris said is very possible about having compiled you app as 64 bit using a 32 bit mware.dll.

Another possibility is that that DLL is totally missing. Is it there?

Last thing I can think of is that you would have to declare some external function definition using the progma pack(1) spec:

• Add "progmapack(1)" external function’s declaration, like this: FUNCTION int STLAREGIO ( ref struckfzrechnerneu struckfz ) LIBRARY "KFZSS.DLL" alias for "STLAREGIO;Ansi" progma_pack(1)

  From https://docs.appeon.com/pb2021/migrating_32bit_applications_to_64bit/ch04s02.html 

regards.

Hi, Vijay -

When asking any question about interfacing PB with external DLL's, it is imperative that you tell us if you are running the app as 32-bit or 64-bit, as there are important differences. As others have stated, it is not possible to interface a 64-bit PB app with a DLL that is 32-bit.

Are you running the app from the PB IDE or from the compiled/deployed app?

Is the DLL accessible to the app (does it reside in a folder that is in the app's search/execution path)? The text of the error message you are getting leads me to wonder if the app cannot find the DLL. 

It would be helpful if you could please post the PB external function declaration(s) for the DLL in question from the PB 12.5 version of your application.

Is there any online documentation regarding this 3rd-party DLL from the author/vendor? If so, please include a link to it.

What is the source language the DLL is written in?

Best regards, John

Hi John,

Below are the details requested

When asking any question about interfacing PB with external DLL's, it is imperative that you tell us if you are running the app as 32-bit or 64-bit,
as there are important differences. As others have stated, it is not possible to interface a 64-bit PB app with a DLL that is 32-bit.--ANS--> 32-bit

Are you running the app from the PB IDE or from the compiled/deployed app?--ANS--> PB IDE

Is the DLL accessible to the app (does it reside in a folder that is in the app's search/execution path)?
The text of the error message you are getting leads me to wonder if the app cannot find the DLL.--ANS-->DLL is present in the folder and that is calling an middleware function mw_Initialize where we are getting the error, while we debug the code using PB IDE

It would be helpful if you could please post the PB external function declaration(s) for the DLL in
question from the PB 12.5 version of your application.--ANS-->f_initialize(string ps_appl_nme, string pb_dbparm)

Is there any online documentation regarding this 3rd-party DLL from the author/vendor? If so, please include a link to it.--ANS-->NO

What is the source language the DLL is written in?

Thanks,

Vijay Kumar

if you are trying to run Powerserver app, you must register all DLL and OCX first, save and then build and deploy (see image and see more in docs.appeon.com)
If you are just starting to test, it might be advisable to start with PB2022 there are many improvements since 2019
greetings

Here is what I think I know based on what you have told us, Vijay:

• Your PB app calls a function in an external DLL named mware32.dll. This DLL resides in the same folder as the compiled/deployed PB executable.
• The function in the DLL is named mw_Initialize. It assigns a value to two strings that are passed by reference to the DLL function so that PB can access these values, and returns a 16-bit signed integer value.

Does the PB application initialize both string values before the function is called? This is necessary in order for PB to correctly manage the memory used to hold the contents of the strings. What is typically done in situations like this is the PB application sets each string that will have a value assigned by the DLL with a series of spaces/blanks, to the maximum length that the DLL will assign. For example, if a DLL will be returning a single string value of 200 characters or less, then the PB app should do something like

ls_value1 = Space(200)

before the function in the DLL is called. Since I'm assuming the 12.5 version of the app works correctly, I presume the app is doing this already... However, since we cannot see your PB code, I'm calling attention to this point to ensure this is being done.

You neglected to answer my earlier question about the language used to create mware32.dll. Are there any runtime DLL's it requires, and are they also present in the same folder as the mware32.dll?

In order for Windows to properly locate and dynamically load and link any DLL, Windows needs to be able to locate both the DLL and any associated DLL's it requires. My guess is there is one or more pieces related to mware32.dll that cannot be located when the compiled application is executing, and that is what I think you should look for.

Here is a link to a detailed description of how Windows looks for a DLL:

    https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

The entire process is admittedly complex, but roughly 3/4 of the way into the article are listed the key places Windows searches:

7. The folder specified by lpFileName.
8. The system folder. Use the GetSystemDirectory function to retrieve the path of this folder.
9. The 16-bit system folder. There's no function that obtains the path of this folder, but it is searched.
10. The Windows folder. Use the GetWindowsDirectory function to get the path of this folder.
11. The current folder.
12. The directories that are listed in the PATH environment variable. This doesn't include the per-application path specified by the App Paths registry key. The App Paths key isn't used when computing the DLL search path.

I hope this information helps you find the cause of the issue.

Best regards, John