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

Resolved Using Windows ReportEvent API from Appeon PowerBuilder 2022 R2

  1. How-to
0
Votes
Undo
  1. Larry Peters
    Larry Peters
  2. PowerBuilder
  3. Wednesday, 11 October 2023 21:52 PM UTC

I have an application which has been working fine under various PowerBuilder releases, 2017, 2019 & 2021. The application is compiled 64bit.

However, it will not run properly when compiled in PB 2022 R2 Build 2819.

The crash is when a function calls Windows API ReportEvent().

 

The crash is:

PowerBuilder application execution error (R0015)

Application terminated.

Error: Error calling external function %s at line 74 in function of_log2windows of object of_log2windows.

 

 

Function of_log2windows line 74 is:

if not ReportEvent(lul_eventsource, li_messagelevel, lul_category, aul_identifier, 0, UpperBound(ls_errmsg), 0, ls_errmsg, 0) then...

 

The ReportEvent prototype is:

FUNCTION boolean ReportEvent (ulong hEventLog, uint wType, uint wCategory, ulong dwEventID, ulong lpUserSid, uint wNumStrings, ulong dwDataSize, string lpStrings[], ulong lpRawData) Library "advapi32.dll" Alias For "ReportEventW"

 

Is there something wrong with my prototype? I notice it has an alias "ReportEventW". Should this be "ReportEventA:ansi"? What is the difference? Why is this only a problem with PB 2022 R2 but fine in earlier versions?

 

TIA

 

Larry

How to get the MDI frame position (x,y) in relatio...
Opening url in webbrowser object with authenticati...
Responses (4)
Larry Peters
Larry Peters Accepted Answer Pending Moderation
  1. Thursday, 12 October 2023 01:15 AM UTC
  2. PowerBuilder
  3. # 1

Hi John,

If what you say is correct then I will need to review ALL calls to Windows API which use a Handle variable. From a quick estimate there are at least 2-3 dozen calls in my system. Bummer! Somehow I'm optimistic because I'm not crashing all over the place - only in ReportEvent.

So far as advapi32.dll being 32-bit then what about kernel32.dll? I'm not crashing there. Could it be that Microsoft somehow under-the-hood arbitrates these calls?

Interesting to know if anyone else is having similar problems?

Thanks

Larry

Comment
John Fauss
  1. John Fauss
  2. Thursday, 12 October 2023 02:39 AM UTC
In order to minimize the impact of potential coding changes, Microsoft made some interesting design decisions when it created a 64-bit implementation of Windows. Case in point: Windows O/S DLL names. The kernel32.dll in Windows 32-bit is named kernel32.dll in Windows 64-bit (?!?!?)... there is NO difference in the DLL names!

The location where the system DLL's reside, however, IS different. In Windows 32-bit, the 32-bit kernel32.dll resides in C:\Windows\System32. In Windows 64-bit, the 64-bit kernel32.dll resides in C:\Windows\System32 (!!!), so the path and name of the DLL is unchanged when changing bitness. The wrinkle is the 32-bit kernel32.dll in the 64-bit Windows O/S. It resides in C:\Windows\SysWOW64. "WOW64" is not a proclamation or exclamation, it stands for "Windows On WIndows-64". When a 32-bit application is executed in 64-bit Windows, The O/S redirects all system DLL references to the SysWOW64 subdirectory.

It sounds as though you are experienced in PB, but new to 64-bit. If so, I'd like to suggest you examine the Appeon publication "Migrating 32-bit Applications to 64-bit", if you have not already done so: https://docs.appeon.com/pb2022r2/migrating_32bit_applications_to_64bit/index.html

You may also benefit from examining a four-part tutorial regarding the interfacing of PB applications to the Windows API, available in the "Articles & Blogs" section of the Community:

https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/302-interfacing-pb-applications-with-the-windows-api-part-1

https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/303-interfacing-pb-applications-with-the-windows-api-part-2

https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/304-interfacing-pb-applications-with-the-windows-api-part-3

https://community.appeon.com/index.php/articles-blogs/tutorials-articles/2-powerbuilder/305-interfacing-pb-applications-with-the-windows-api-part-4

Depending on which API functions and structures you are utilizing, there can be some additional complications when migrating to 64-bit, mostly involving structure member layout in memory and possible changes in structure size/length. The tutorials cover this topic and more.

The Community is here to help, so ask whenever you feel you need a little assistance. Good luck!
  1. Helpful 3
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Thursday, 12 October 2023 15:54 PM UTC
Great info John!!!
  1. Helpful
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Thursday, 12 October 2023 00:58 AM UTC
  2. PowerBuilder
  3. # 2

Hi, Larry - 

From what I understand or have been told, PB 2022 is created with a newer version of Visual Studio than previous versions and as a result, PB is now more sensitive to incorrect datatype usage. The Microsoft runtime DLL's use to allow or automatically handle some instances of data type promotion/demotion.

I believe the problem you're experiencing involves the first argument in the External Function Declaration (EFD) and in the function call in PowerScript. The API documentation for the ReportEventW API function shows this argument is a Windows Handle. Handles are 32-bit in a 32-bit application and they are 64-bit in a 64-bit app. You stated your application is compiled as 64-bit... therefore, the hEventLog argument in the EFD should be declared as Longptr instead of as UnsignedLong. In case you're not familiar, LongPtr is a 32-bit integer when the app is compiled for 32-bit, and a 64-bit integer when the app is compiled for 64-bit. This makes LongPtr an ideal data type to be used with Windows Handles.

In the PowerScript code, the datatype "lul_eventsource" variable should also be changed from UnsignedLong to Longptr.

Use whatever Hungarian notation you prefer (I'm glad to see you use it!)... I've seen some people use "llp_xxxxx" (Local LongPtr). Personally, I prefer "llptr_xxxxx", as it stands out in the code a little better, IMHO.

You may need to also revise the code that determines the value of the Windows Handle. Note for future reference: The PowerScript Handle() function returns a LongPtr value.

Best regards, John

Comment
Larry Peters
  1. Larry Peters
  2. Thursday, 12 October 2023 01:06 AM UTC
Thanks John,

I'll change the code to use Longptr and see if this helps.

Great!
  1. Helpful
There are no comments made yet.
Larry Peters
Larry Peters Accepted Answer Pending Moderation
  1. Thursday, 12 October 2023 00:50 AM UTC
  2. PowerBuilder
  3. # 3

Thanks Chris,

So obviously, by virtue of it's name, advapi32.dll is 32-bit! I'll look for a 64-bit version.

However, I still do not understand why I don't have the same problem with PB 2017, 2019 & 2021. They were also all compiled 64-bit and work fine with the same code!

Regards

Larry

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Thursday, 12 October 2023 14:14 PM UTC
PB 2022 & 2022 R2 are built with a much newer version of the MS VC++ compiler which is much more strict data type wise.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 11 October 2023 23:05 PM UTC
  2. PowerBuilder
  3. # 4

Hi Larry;

  When you compile PB App EXE's into 64 bit mode, you must also only use 64 bit external DLLs.

Regards ... Chris

Comment
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.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.