View Issue Details

IDProjectCategoryView StatusLast Update
0035439FPCRTLpublic2019-04-26 10:01
Reporter440bxAssigned ToMarco van de Voort 
Status resolvedResolutionreopened 
Product Version3.0.4Product Build 
Target VersionFixed in Version3.3.1 
Summary0035439: The kernel32 function GetPhysicallyInstalledSystemMemory is missing
DescriptionThe title says it all.

The definition is (tested):

  function GetPhysicallyInstalledSystemMemory(
                                    var TotalMemoryInKilobytes : TLargeInteger)
           : BOOL; stdcall; external kernel32;

NOTE: the TotalMemoryInKilobytes parameter can be defined as qword instead of TLargeInteger.
Steps To Reproducewrite a program that calls that function, it won't compile.
TagsNo tags attached.
Fixed in Revision41930
Attached Files


Marco van de Voort

2019-04-25 11:07

manager   ~0115798

Added using pulonglong as type


2019-04-25 22:00

reporter   ~0115813

@Marco, I understand that using PULONGLONG makes the definition match MSDN's but, the parameter is required, because of this, it would really be better if it were defined as a "var", it would prevent passing nil or some other pointer that points to nowhere. (best definition would actually be "out".)

J. Gareth Moreton

2019-04-25 22:28

developer   ~0115815

I think a lot of it is down to documentation - by having everything follow the MSDN documentation, it won't cause confusion and programmer frustration when apparently random functions use var or out parameters instead. I know I said before that var parameters should only be used if the parameter cannot be nil under any circumstances, but thinking about it, it's best to abide by the official documentation, even if it is designed for C and not Pascal.


2019-04-25 22:37

reporter   ~0115816

Gareth, I definitely see your point. The reason they used PULONGLONG is because C didn't/doesn't support passing parameters by reference, because of that, they have to pass a pointer to the variable.

I concur that changing existing definitions would be risky, prone to introducing bugs and incompatibilities.

For _new_ definitions, we don't need to carry C's deficiencies. Since the definition is new and fully consistent with the MSDN's it shouldn't cause any problems nor confusion and prevents making a mistake that C allows and Pascal can prevent. That's the beauty and power of Pascal, I believe we should take advantage of it whenever possible.

Serge Anvarov

2019-04-26 09:53

reporter   ~0115821

For me, it's easier to double the function declaration. One is entirely in accordance with the declaration in SDK (the C language), the other is in accordance with the ideology of the Pascal language. Out parameters are preferable instead of var, since WinAPI does not have managed types (except interfaces), the presence of var is justified only if the data is read and written.

Marco van de Voort

2019-04-26 10:00

manager   ~0115822

Gareth: Originally the VAR bit was attempted, but it lead to too much change over time. Nowadays the SDK is better, and annotates much more of such info, but that wasn't the case 18-20 years ago.

Serge: maybe for a new header translation. But making the current one a mishmash of styles is not an improvement

Issue History

Date Modified Username Field Change
2019-04-25 04:49 440bx New Issue
2019-04-25 11:07 Marco van de Voort Assigned To => Marco van de Voort
2019-04-25 11:07 Marco van de Voort Status new => resolved
2019-04-25 11:07 Marco van de Voort Resolution open => fixed
2019-04-25 11:07 Marco van de Voort Fixed in Version => 3.3.1
2019-04-25 11:07 Marco van de Voort Fixed in Revision => 41930
2019-04-25 11:07 Marco van de Voort Note Added: 0115798
2019-04-25 22:00 440bx Status resolved => feedback
2019-04-25 22:00 440bx Resolution fixed => reopened
2019-04-25 22:00 440bx Note Added: 0115813
2019-04-25 22:28 J. Gareth Moreton Note Added: 0115815
2019-04-25 22:37 440bx Note Added: 0115816
2019-04-25 22:37 440bx Status feedback => assigned
2019-04-26 09:53 Serge Anvarov Note Added: 0115821
2019-04-26 10:00 Marco van de Voort Note Added: 0115822
2019-04-26 10:01 Marco van de Voort Status assigned => resolved