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

Resolved 64bit deployment newbie questions

  1. How-to
0
Votes
Undo
  1. Tomáš Podzimek
    Tomáš Podzimek
  2. PowerBuilder
  3. Tuesday, 20 February 2024 09:31 AM UTC

Hi all,

We are planning to move our application to 64bit. I have read several guides, but still, a few things are unclear to me. I am asking for help with the following:

We use some custom DLLs (20+ years old). Somehow, I managed to compile it as a 64-bit version.

How to ensure that the application uses the correct version (32/64 bit) according to the IDE settings? For system DLLs (e.g., user32.dll), it works, but for this custom one, I do not know how to arrange it.

So far, I have 2 versions: our.dll and our64.dll, and in the definition of the external function, I currently rewrite it, for instance:

FUNCTION int GetDecimalSeparator(REF string as_separator, unsignedlong aul_length) library "our.dll" alias for "GetDecimalSeparator;Ansi"

to

FUNCTION int GetDecimalSeparator(REF string as_separator, unsignedlong aul_length) library "our64.dll" alias for "GetDecimalSeparator;Ansi"

or I need to copy a DLL with the correct bitness into a folder with the app (if the DLL names are the same for 32/64bit).

Surely, there is a smarter way.

 

Furthermore, I have read that PBD files are the same for both 32 and 64 bits. The only difference is in the exe.

Is there any way to create only an exe for 32 or 64 bits without having to run the build for the entire application?

Thanks in advance for the advice.

 

Regards,

Tomáš

  1. 64-bit
PowerBuilder IDE 2019 R3 is unable to access neith...
SAP BAPI Call with 64 Bit SAP GUI
Accepted Answer
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 20 February 2024 14:28 PM UTC
  2. PowerBuilder
  3. # Permalink

I guess I'm missing a piece of the puzzle... because I think you're making this too complex.

If you compile/deploy/execute a 64-bit version of your application, just package the 64-bit version of our.dll named "our.dll" with the app. For a 32-bit version of the application, include the 32-bit version of our.dll named "our.dll". Then you only need a single external function declaration in the PB application and there is no need to code IF-statements that check the ProcessBitness property of the PB Environment object.

This is, essentially, what Windows does, except that for a 32-bit app running on a 64-bit version of Windows, the O/S automatically intercepts the DLL references and redirects the call to the C:\Windows\SysWOW64 folder (where the 32-bit version of the system DLL's reside). Both versions of the system DLL's (32-bit and 64-bit) are named identically.

One minor, semi-related question: If the our.dll is working with an ANSI string, why subtract 2 from the length value that is passed in the second argument instead of subtracting 1?

Best regards, John

Comment
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 20 February 2024 15:48 PM UTC
You're very right John!
  1. Helpful
Tomáš Podzimek
  1. Tomáš Podzimek
  2. Wednesday, 21 February 2024 07:16 AM UTC
Thanks for the explanation, John. It makes sense for deployment.

When switching between 32 and 64 bit in the IDE, I need to copy the dll with the correct bitness each time, right? We will have to support both versions, at least in the beginning.

Answer to your semi-related question: I don't know :-). This dll is 20+ years old, I'm not the author and the author is no longer here. So far it has been a black box for me that has done done its job.

Regards,

Tomáš
  1. Helpful
John Fauss
  1. John Fauss
  2. Thursday, 22 February 2024 01:41 AM UTC
I made an assumption that since you produced a 64-bit version of the DLL, you have the source code and therefore would know how this function works. I was guessing that the second argument is the number of characters (bytes, since the characters are ANSI), so subtracting one for the terminating null would be reasonable. Subtracting two from the length of the string seems unusual... but, hey, if it works, it works! Good luck on your migration!
  1. Helpful
There are no comments made yet.
Responses (3)
Tomáš Podzimek
Tomáš Podzimek Accepted Answer Pending Moderation
  1. Tuesday, 20 February 2024 12:59 PM UTC
  2. PowerBuilder
  3. # 1

Bitness of an app is not a problem, it can be found in an Environment variable. So far I got something like this:

Environment lo_env

GetEnvironment (lo_env)									

ls_help = Space(1000)

if lo_env.processbitness = 64 then
	li_return=This.GetDecimalSeparator64(REF ls_help, Len(ls_help)-2)	
else
	li_return=This.GetDecimalSeparator(REF ls_help, Len(ls_help)-2)
end if

 

But I don't like the idea of putting something like this to every dll call...

Comment
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 20 February 2024 10:49 AM UTC
  2. PowerBuilder
  3. # 2

You might be able to use this external function to determine if you app is running as 64 or 32 bit. You'll have to put some IF statements in you code to use one or the other 'our.dll'.

 

[Local external definitions]
FUNCTION long IsWow64Process(long hwnd, ref  boolean Wow64Process) &
    LIBRARY "Kernel32.DLL"

FUNCTION long GetCurrentProcess ()  LIBRARY "KERNEL32.DLL"

[Powerscript]
boolean wow64 =false
IsWow64Process(GetCurrentProcess(), wow64)
MessageBox("Running in 64b env", wow64)
Comment
Benjamin Gaesslein
  1. Benjamin Gaesslein
  2. Tuesday, 20 February 2024 11:38 AM UTC
IsWow64Process will report TRUE if you have a 32bit process running on 64bit Windows. It will return FALSE in these cases:

- The process is 32bit running on a 32bit OS

- The process is 64bit running on a 64bit OS

Unless you can guarantee that the process is running in 64Bit Windows, it's not enough to find out its bitness.
  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.