PB12.6 64-bit issue: GlobalMemoryStatus

[Former Member]

I am deploying my PB12.6 app as 64-bit.

Calls to GlobalMemoryStatus are returning low memory.

This is not correct as the memory exists and the 32-bit deployment works.

What can I do to rectify? I read somewhare that I should use GlobalMemoryStatusEx instead.

I tried that but my 32-bit deployment reported low memory!

My app is using the pfc libraries.

Is there a need to convert many function calls to run 64-bit?

Thanks in advance.

Larry

[Former Member · Accepted solution]

Hi Larry

you can modify your object by replacing the external function so:

GlobalMemoryStatusEx local exernal function definition is:

Subroutine GlobalMemoryStatus (ref os_memorystatus memorystatus ) Library "KERNEL32.DLL" alias for "GlobalMemoryStatusEx"

the new  os_memorystatus definition is:

type os_memorystatus from structure

    unsignedlong ul_length

    unsignedlong ul_memoryload

    longlong ll_totalphys

    longlong ll_availphys

    longlong ll_totalpagefile

    longlong ll_availpagefile

    longlong ll_totalvirtual

    longlong ll_availvirtual

    longlong ll_AvailExtendedVirtual

end type

before calling the api you have to set

lstr_memory.ul_length = 64 instead of 32

hope this helps

Alberto

[Former Member]

Thanks Alberto.

That fixed my problem.

I notice that lstr_memory.ul_length = 64 works in 32-bit.

Is this safe or should I only use 64 when running in 64-bit mode?

Thanks anyway

Larry

[Former Member]

Hi Larry,

64 is the size of the structure passed to the API, therefore is always 64 even in a 32bit environment.

regards Alberto

[Former Member]

Hi Larry;

    Its safe to leave the 64 bit option turned "ON" all the time - however, the 64 setting can lead to misleading memory mapping results when running in a 32 bit world.

---------------------------------------------------------------------------

This is how its coded in my STD Foundation Classes ...

IF  go_ac.of_is_64bit_os ( ) = TRUE  THEN

      isr_memory_status.si_length        =   64                                // Set length for 32bit

else

     isr_memory_status.si_length        =    32                                 // Set STR length

END IF

ib_rc    =    GlobalMemoryStatusEx ( isr_memory_status )       // Get device data

-------------------------------------------------------------------------------------------

  This is how the STD framework knows if your a 64 bit application or not ...

IsWOW64process ( GetCurrentProcess ( ) , ib_64bit_os_found)    / Load 64bit indicator

FUNCTION Boolean

IsWow64Process ( ulong hProcess,  Ref boolean Wow64Process) LIBRARY "KERNEL32.dll"

FUNCTION ulong

GetCurrentProcess ( )  LIBRARY "KERNEL32.dll"

Note: The "of_is_64bit_os" method just returns the "ib_64bit_os_found" setting.

HTH

Regards ... Chris

[former_member190719]

As Alberto indicated, you should pass 64 regardless of the OS bitness.  It's the size of the structure, and that particular structure doesn't change size based on the OS bitness.

You can prove that with a few lines of C++ code as a console application:

#include "stdafx.h"
#include <windows.h>
#include <iostream>

int _tmain(int argc, _TCHAR* argv[])
{
  MEMORYSTATUSEX memstatex;
  std::cout << "MEMORYSTATUSEX size is: " << sizeof (memstatex) << std::endl;

  MEMORYSTATUS memstat;
  std::cout << "MEMORYSTATUS   size is: " << sizeof (memstat) << std::endl;

  return 0;
}

When run as a 32 bit application, you'll get this:

MEMORYSTATUSEX size is: 64
MEMORYSTATUS   size is: 32
Press any key to continue . . .

And when run as a 64 bit application, you'll get this:

MEMORYSTATUSEX size is: 64
MEMORYSTATUS   size is: 56
Press any key to continue . . .

[Former Member]

Hi Chris.

Actually in PB 12.6 (Classic) there is theProcessBitnessproperty in the environment object which returns values 32 or 64 depending on process bitness of course.

Andreaw.

[Former Member]

Hi Andreas;

  That is a good point if you only use PB 12.6 Classic!

However ...

1) It will not work in PB versions < 12.6

2) It is not supported in Appeon Web

3) The new feature is not available in PB.Net 12.6

Whereas ... with my approach, it will work in all of the above scenarios. 

Food for thought.   😉

Regards ... Chris

[Former Member]

Thanks Bruce

[Former Member]

Hi Chris.

Actually the ProcessBitness property exists also in PB.NET 12.6, but doesn't works (it always returns 0). I really believe that they could make it working... PB 12.6 was released IMHO to fast for the work (improvements) they provided. Example: In pb classic x64 you can connect to a database using ado, odbc and native interfaces. But in pb.net 12.6 only ado.net is available.

PS: I thought you wasn't ineterested to PB.NET

Andreas Mykonios.

[Former Member]

Hi Andreas;

1) Thanks for the feedback on the ProcessBitness property not working. Sounds like SAP needs to open a support ticket on this feature then. Another good reason to use my approach then.  😉

2) That is interesting feedback on PB.Net's restriction to only use ADO.net. I am working at a client currently who is implementing an ADO.Net application built in VS accessing an ASE DBMS instance. From my testing, my PB applications are 35% faster using DBLIb than ADO.Net. So when you are building very large DB interactive applications - you can't beat the native drivers IMHO. I wonder if SAP will add more DB driver options to PB.net in the future (what ever that is).

Yes, PB.NOT for me. 

Regards ... Chris

[former_member190719]

In pb classic x64 you can connect to a database using ado, odbc and native interfaces. But in pb.net 12.6 only ado.net is available.

I'm trying to think of a reason that you would ever not want to use ADO.Net in a .Net application.  Using non-ADO.Net driver means you have to deploy unmanaged code and every database call would have to go through interop.  A couple of good reasons not to.

[former_member190719]

From my testing, my PB applications are 35% faster using DBLIb than ADO.Net. So when you are building very large DB interactive applications -

You're comparing apples and oranges.  Using ADO.Net from PB Classic means you have to go through interop.  When you use ADO.Net from a .Net application, you don't have to go through the interop.  Also, using native drivers from a .Net application also means you have to go through interop as well.

[Former Member]

Hi Bruce.

A simple reason... An application developed in pb classic, and converted to wpf...

Andreas.

[Former Member]

Another point...

In c# I use Sybase.Data.AseClient to connect to ASE. Don't know if it's the best way, but it works... Why not with pb.net transaction object?

Andreas.

[former_member190719]

In c# I use Sybase.Data.AseClient to connect to ASE. Don't know if it's the best way, but it works... Why not with pb.net transaction object?

You're losing me here.  Sybase.Data.AseClient is an ADO.Net driver.

[Former Member]

Chris,

I adopted function IsWOW64process() to determine bitness as you recommended but I have a problem. If running on a 64-bit PC with app linked in 64-bit mode, IsWOW64process() returns FALSE. This, I understand, is because "SysWOW64" was not invoked.

However, I find that checking environment.processbitness appears to give me what I think I need.

I wonder if you can explain why I should use IsWOW64process() instead of looking at environment.processbitness.

My test findings:

Running under Windows 8.1 with 64-bit PC.

With app linked in 64-bit mode:     environment.processbitness = 64     IsWOW64process() = false

With app linked in 32-bit mode:     environment.processbitness = 32     IsWOW64process() = true

Thanks,

Larry

[Former Member]

Hi Bruce..

Yes it is. But in Database Profile you have too many fields... Some times it's confusing in my opinion.

In Example, what is the ADO Release? What is the difference between two options? How do I know which driver is installed? Do I have to choose one of those values or can it be empty? Is it dependent to the sdk version I'm using?

In C# i simply declare (after referencing the apprpriate assembly):

Sybase.Data.AseClient.AseConnection cn = new Sybase.Data.AseClient.AseConnection("Data Source='*****';Port='5000';UID='*****';PWD='*****';Database='******';");

And It works... I don't mention ADORelease anywhere.

Finally I cannot understand why this limitation (in pb.net 12.6 x64 only ado.net is available, but in x32 you have all the options). I work a lot with sql anywhere and most of my applications connects to the database through odbc. To make them x64, I have to change the way I connect to the database and test everything again. And finally why to make odbc run through ADO? While I could use directly ODBC as in x32 (but it's not available in x64)? There is no impact in speed that way? If in x32 I make odbc connection through ADO.NET will it be slower, faster or there will be no change concerning to database communication speed?

Andreas.

[Former Member]

Hi Larry;

  Yes, I see the dilemma now in that I was always thinking 32bit applications in a 32bit world. Now that we have 64bit applications in a 64bit world the IsWOW64process ( ) method will always return a FALSE with that combination.

  Hmmm ... looks like a generic solution might be to use something like GetSystemInfo ( ) of GetVersionEx () MS-Windows API's instead.

Its interesting that the processbitness property worked OK for you yet Andreas claims that in his test this property was always a Zero (0) value.

Regards ... Chris

[former_member190719]

Yes it is. But in Database Profile you have too many fields... Some times it's confusing in my opinion.

It's confusing because those (any many other items on the other tabs) are all viable settings for the ADO.Net connection.  You can get the same effect once you start specifying those same options on the connection in C#.  The difference is that PowerBuilder provides you with a GUI that lets you know what the options are and then creates the connect string for you.  For many of those options though, you need to consult the documentation for the ADO.Net driver.

Finally I cannot understand why this limitation (in pb.net 12.6 x64 only ado.net is available, but in x32 you have all the options)

Covered that in my earlier response.

[Former Member]

Chris, as you indicated you are using this in your own code, do you plan to rectify and if so, how?

Thanks, anyway.

[Former Member]

Hi Larry;

I am working on a solution right now using PROCESSOR_ARCHITECTURE and

PROCESSOR_ARCHITEW6432 instead of WOW64.

Stay tuned.  😉

Regards ... Chris


[Former Member]

Hi Chris.

I was mentioning that the property exists in pb.net but doesn't work. I said nothing about pb classic where it works fine.

Andreas.

[Former Member]

<my bad> Sorry ... thought you were talking about Classic </my bad>

[Former Member]

Hi Larry;

  FYI .. here is my first initial test of my revised code in the STD Foundation Classes. Looks like this is working properly now in PB  versions 12=>12.6 and it correctly identifies a 32bit app in a 32 bit O/S, 32 in 64, and 64 in a 64. My testing has only been on AMD processors last night - but, I will check the Intel factor today. I do not foresee any issues with my new code though. If all goes well - I will release a new version of the FC's this week with this and other small upgrades.

Regards ... Chris

[Former Member]

Hi Larry;

  New code looks good on the INTEL side as well ...

Regards ... Chris

[Former Member]

Hi Chris,

I now understand that you are marketing these foundation classes.

I know nothing about them so maybe you can furnish a url which describes them.

In the meanwhile, I wonder if you could tell me why I should not trust the bitness property of the environment object? Or to put it another way, what else is that property for?

Thanks

Larry

[Former Member]

Hi Larry;

1) No marketing ... the frameworks (aka Foundation Classes) are free.You are welcome to use them, just learn from them, borrow code over to your applications and/or framework.  

2) You can have a look at the frameworks, supporting utilities, example code, etc on the SourceForge website:  STD Foundation Classes | SourceForge.net

3) You can also track new releases of the frameworks on my blog: Great White North Technical Evangelist

4) I will also be talking about the frameworks, giving a mini-course on them and demonstrating real-life production applications (native, web & mobile) built on these frameworks at the 2015 PowerBuilder Conference in Charlotte NC in May.

FYI:

I hope you can come!  

  As far as the new bitness property is concerned ... it only works in PB Classic 12.6 for native application EXE's only.

HTH

Regards ... Chris

[Former Member]

Thanks Chris.

i Will certainly download your framework and have a look at it.

I Am using PB12.6 Classic. What is 'native application EXEs'?

TIA, Larry

[Former Member]

Hi Larry;

1) You might want to wit a day ... I am uploading a new version tonight that supports bitness better (for PB 12.6) and a few other general goodies (including Active Directory login).   😉

2) Native Application EXE => what I call an EXE compiled into either P-Code or M-Code from the PB IDE (or Winforms - aka C# EXE). A Win32/64 based executable.

However:

  - Appeon Web cross compiles your PB code into HTML, XML & JavaScript and

   Java/C#  (depending on whether you are using the J2EE based Appeon

                    or the .NET base Appeon).

  - Appeon Mobile cross compiles your PB code into an .IPA executable for iOS

  - Appeon Mobile cross compiles your PB code into an .APK executable or Android

Note My framework code handles bitness across all of the above - even PB.Net (aka WPF).    😉

HTH

Regards ... Chris

[Former Member]

Hi Larry;

  A new version of the Integrated framework has now been released ....

FYI:  Great White North Technical Evangelist: New Release of the STD "Integrated" FrameWork!

Regards ... Chris

[Former Member]

I just downloaded it.

Thanks.

Will take me a while to assimilate...

[Former Member]

I've tested ProcessBitness in PB 12.6 Classic BUILD 4058

It's alway 0

//*****************************

environment env

integer rtnrtn = GetEnvironment(env)

messagebox("", string(env.processbitness ))

//*****************************

I use a stupid walkarround :

//**********************************

longPtr lptr_test

lptr_test = 2147483647 + 1

IF lptr_test > 0 THEN

    messagebox("", "64-bit")

ELSE

    messagebox("", "32-bit")

END IF

//****

[former_member190719]

It reports that when you compiled the app to 64 bit?  It works correctly for me.

[Former Member]

@Bruce

env.processbitness is zero when I execute a 64-bit compiled app with PB 12.6 Classic BUILD 4058

I'll try to install again PB12.6 and EBFs to verify It is not a problem in the install process.

[Former Member]

Hi Larry;

  Alberto's code is correct. I had to change this in my STD Foundation Classes many years ago as the Appeon Web product makes your Web Browser PB applications 64 bit automatically.

Note: For those using Appeon Mobile .. you need to use Appeon's "eon_mobile_deviceex" class to get the actual tablet or smartphones memory status.

Regards ... Chris