[ANNOUNCEMENT] Updated: w32api-{headers, runtime}-8.0.0-1 (x86/x86_64)

[ANNOUNCEMENT] Updated: w32api-{headers, runtime}-8.0.0-1 (x86/x86_64)

[JonY via Cygwin-announce]

[-- Attachment #1.1: Type: text/plain, Size: 686 bytes --]

Now released for both 32bit and 64bit Cygwin:

w32api-headers-8.0.0-1
w32api-runtime-8.0.0-1

Based on mingw-w64-v8.0.0.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Updated: w32api-{headers,runtime}-8.0.0-1 (x86/x86_64)

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On 2020-09-18 23:19, JonY via Cygwin-announce wrote:
> Now released for both 32bit and 64bit Cygwin:
> 
> w32api-headers-8.0.0-1
> w32api-runtime-8.0.0-1
> 
> Based on mingw-w64-v8.0.0.

May be a definition conflict between updated headers rebuilding cygwin both 32
and 64 before and just after latest updates: see attached log.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

[-- Attachment #2: PVOID_definition_conflict.log --]
[-- Type: text/plain, Size: 1345 bytes --]

c++wrap -fno-exceptions -fno-rtti -Wimplicit-fallthrough=4 -Werror -O2 -g -fno-threadsafe-statics -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -c -o cygpath.o ../../.././winsup/utils/cygpath.cc
../../.././winsup/utils/cygpath.cc:27:33: error: conflicting declaration 'typedef struct MEM_EXTENDED_PARAMETER* PVOID'
   27 | #define PMEM_EXTENDED_PARAMETER PVOID
      |                                 ^~~~~
In file included from /usr/include/w32api/minwindef.h:163,
                 from /usr/include/w32api/windef.h:9,
                 from /usr/include/w32api/windows.h:69,
                 from ../../.././winsup/utils/cygpath.cc:28:
/usr/include/w32api/winnt.h:257:17: note: previous declaration as 'typedef void* PVOID'
  257 |   typedef void *PVOID;
      |                 ^~~~~
make[3]: *** [../../.././winsup/utils/../Makefile.common:41: cygpath.o] Error 1
make[3]: Leaving directory '.../newlib-cygwin/x86_64-pc-cygwin/winsup/utils'
/bin/sh: 1: [: utils: unexpected operator
make[2]: *** [Makefile:81: utils] Error 2
make[2]: Leaving directory '.../newlib-cygwin/x86_64-pc-cygwin/winsup'
make[1]: *** [Makefile:9464: all-target-winsup] Error 2
make[1]: Leaving directory '.../newlib-cygwin'
make: *** [Makefile:883: all] Error 2

Re: Updated: w32api-{headers,runtime}-8.0.0-1 (x86/x86_64)

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On 2020-09-22 16:10, Brian Inglis wrote:
> On 2020-09-18 23:19, JonY via Cygwin-announce wrote:
>> Now released for both 32bit and 64bit Cygwin:
>>
>> w32api-headers-8.0.0-1
>> w32api-runtime-8.0.0-1
>>
>> Based on mingw-w64-v8.0.0.

Sorry, ambigous - to clarify:may be a definition conflict between updated
headers rebuilding cygwin both 32
and 64 just after latest updates: see attached log.
Cygwin both 32 and 64 builds worked without any problems just before the latest
updates.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

[-- Attachment #2: PVOID_definition_conflict.log --]
[-- Type: text/plain, Size: 1345 bytes --]

c++wrap -fno-exceptions -fno-rtti -Wimplicit-fallthrough=4 -Werror -O2 -g -fno-threadsafe-statics -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -c -o cygpath.o ../../.././winsup/utils/cygpath.cc
../../.././winsup/utils/cygpath.cc:27:33: error: conflicting declaration 'typedef struct MEM_EXTENDED_PARAMETER* PVOID'
   27 | #define PMEM_EXTENDED_PARAMETER PVOID
      |                                 ^~~~~
In file included from /usr/include/w32api/minwindef.h:163,
                 from /usr/include/w32api/windef.h:9,
                 from /usr/include/w32api/windows.h:69,
                 from ../../.././winsup/utils/cygpath.cc:28:
/usr/include/w32api/winnt.h:257:17: note: previous declaration as 'typedef void* PVOID'
  257 |   typedef void *PVOID;
      |                 ^~~~~
make[3]: *** [../../.././winsup/utils/../Makefile.common:41: cygpath.o] Error 1
make[3]: Leaving directory '.../newlib-cygwin/x86_64-pc-cygwin/winsup/utils'
/bin/sh: 1: [: utils: unexpected operator
make[2]: *** [Makefile:81: utils] Error 2
make[2]: Leaving directory '.../newlib-cygwin/x86_64-pc-cygwin/winsup'
make[1]: *** [Makefile:9464: all-target-winsup] Error 2
make[1]: Leaving directory '.../newlib-cygwin'
make: *** [Makefile:883: all] Error 2

Re: Updated: w32api-{headers,runtime}-8.0.0-1 (x86/x86_64)

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

On 2020-09-22 22:17, Brian Inglis wrote:
> On 2020-09-22 16:10, Brian Inglis wrote:
>> On 2020-09-18 23:19, JonY via Cygwin-announce wrote:
>>> Now released for both 32bit and 64bit Cygwin:
>>>
>>> w32api-headers-8.0.0-1
>>> w32api-runtime-8.0.0-1
>>>
>>> Based on mingw-w64-v8.0.0.
> 
> Sorry, ambigous - to clarify: may be a definition conflict between updated
> headers rebuilding cygwin both 32 and 64 just after latest updates: see attached log.
> Cygwin both 32 and 64 builds worked without any problems just before the latest
> updates.

Tad confusing log messages, but it appears the actual issue may not be a
conflict to do with PVOID, but with PMEM_EXTENDED_PARAMETER between the below:

$ fgrep -wB12 PMEM_EXTENDED_PARAMETER /usr/include/w32api/winnt.h
  typedef struct DECLSPEC_ALIGN(8) MEM_EXTENDED_PARAMETER {
    __C89_NAMELESS struct {
        DWORD64 Type : MEM_EXTENDED_PARAMETER_TYPE_BITS;
        DWORD64 Reserved : 64 - MEM_EXTENDED_PARAMETER_TYPE_BITS;
    };
    __C89_NAMELESS union {
        DWORD64 ULong64;
        PVOID Pointer;
        SIZE_T Size;
        HANDLE Handle;
        DWORD ULong;
    };
  } MEM_EXTENDED_PARAMETER, *PMEM_EXTENDED_PARAMETER;
$ fgrep -wA8 PMEM_EXTENDED_PARAMETER winsup/utils/cygpath.cc
#define PMEM_EXTENDED_PARAMETER PVOID
#include <windows.h>
#include <userenv.h>
#include <shlobj.h>
#include <ntdef.h>
#include <ntdll.h>

#include "wide_path.h"
#include "loadlib.h"

It seems likely that we could perhaps just remove the conflicting #define, but
without some idea of the original intent and its impact, and a good cygpath
regression test suite, that could perhaps be a rash decision.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

[-- Attachment #2: PVOID_definition_conflict.log --]
[-- Type: text/plain, Size: 1345 bytes --]

c++wrap -fno-exceptions -fno-rtti -Wimplicit-fallthrough=4 -Werror -O2 -g -fno-threadsafe-statics -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -c -o cygpath.o ../../.././winsup/utils/cygpath.cc
../../.././winsup/utils/cygpath.cc:27:33: error: conflicting declaration 'typedef struct MEM_EXTENDED_PARAMETER* PVOID'
   27 | #define PMEM_EXTENDED_PARAMETER PVOID
      |                                 ^~~~~
In file included from /usr/include/w32api/minwindef.h:163,
                 from /usr/include/w32api/windef.h:9,
                 from /usr/include/w32api/windows.h:69,
                 from ../../.././winsup/utils/cygpath.cc:28:
/usr/include/w32api/winnt.h:257:17: note: previous declaration as 'typedef void* PVOID'
  257 |   typedef void *PVOID;
      |                 ^~~~~
make[3]: *** [../../.././winsup/utils/../Makefile.common:41: cygpath.o] Error 1
make[3]: Leaving directory '.../newlib-cygwin/x86_64-pc-cygwin/winsup/utils'
/bin/sh: 1: [: utils: unexpected operator
make[2]: *** [Makefile:81: utils] Error 2
make[2]: Leaving directory '.../newlib-cygwin/x86_64-pc-cygwin/winsup'
make[1]: *** [Makefile:9464: all-target-winsup] Error 2
make[1]: Leaving directory '.../newlib-cygwin'
make: *** [Makefile:883: all] Error 2

Re: Updated: w32api-{headers,runtime}-8.0.0-1 (x86/x86_64)

[Ken Brown]

On 9/23/2020 12:44 AM, Brian Inglis wrote:
> On 2020-09-22 22:17, Brian Inglis wrote:
>> On 2020-09-22 16:10, Brian Inglis wrote:
>>> On 2020-09-18 23:19, JonY via Cygwin-announce wrote:
>>>> Now released for both 32bit and 64bit Cygwin:
>>>>
>>>> w32api-headers-8.0.0-1
>>>> w32api-runtime-8.0.0-1
>>>>
>>>> Based on mingw-w64-v8.0.0.
>>
>> Sorry, ambigous - to clarify: may be a definition conflict between updated
>> headers rebuilding cygwin both 32 and 64 just after latest updates: see attached log.
>> Cygwin both 32 and 64 builds worked without any problems just before the latest
>> updates.
> 
> Tad confusing log messages, but it appears the actual issue may not be a
> conflict to do with PVOID, but with PMEM_EXTENDED_PARAMETER between the below:
> 
> $ fgrep -wB12 PMEM_EXTENDED_PARAMETER /usr/include/w32api/winnt.h
>    typedef struct DECLSPEC_ALIGN(8) MEM_EXTENDED_PARAMETER {
>      __C89_NAMELESS struct {
>          DWORD64 Type : MEM_EXTENDED_PARAMETER_TYPE_BITS;
>          DWORD64 Reserved : 64 - MEM_EXTENDED_PARAMETER_TYPE_BITS;
>      };
>      __C89_NAMELESS union {
>          DWORD64 ULong64;
>          PVOID Pointer;
>          SIZE_T Size;
>          HANDLE Handle;
>          DWORD ULong;
>      };
>    } MEM_EXTENDED_PARAMETER, *PMEM_EXTENDED_PARAMETER;
> $ fgrep -wA8 PMEM_EXTENDED_PARAMETER winsup/utils/cygpath.cc
> #define PMEM_EXTENDED_PARAMETER PVOID
> #include <windows.h>
> #include <userenv.h>
> #include <shlobj.h>
> #include <ntdef.h>
> #include <ntdll.h>
> 
> #include "wide_path.h"
> #include "loadlib.h"
> 
> It seems likely that we could perhaps just remove the conflicting #define, but
> without some idea of the original intent and its impact, and a good cygpath
> regression test suite, that could perhaps be a rash decision.

This is related to the extended memory API that Corinna started using last 
April.  At the time the relevant declarations and definitions weren't in the 
mingw-w64 headers yet, so Corinna had to do some ad hoc stuff.  Now that they've 
been added, a lot of that stuff should be removed.  I'll do it later today.

Ken

Re: Updated: w32api-{headers,runtime}-8.0.0-1 (x86/x86_64)

[Brian Inglis]

On 2020-09-23 08:49, Ken Brown via Cygwin wrote:
> On 9/23/2020 12:44 AM, Brian Inglis wrote:
>> On 2020-09-22 22:17, Brian Inglis wrote:
>>> On 2020-09-22 16:10, Brian Inglis wrote:
>>>> On 2020-09-18 23:19, JonY via Cygwin-announce wrote:
>>>>> Now released for both 32bit and 64bit Cygwin:
>>>>>
>>>>> w32api-headers-8.0.0-1
>>>>> w32api-runtime-8.0.0-1
>>>>>
>>>>> Based on mingw-w64-v8.0.0.
>>>
>>> Sorry, ambigous - to clarify: may be a definition conflict between updated
>>> headers rebuilding cygwin both 32 and 64 just after latest updates: see
>>> attached log.
>>> Cygwin both 32 and 64 builds worked without any problems just before the latest
>>> updates.
>>
>> Tad confusing log messages, but it appears the actual issue may not be a
>> conflict to do with PVOID, but with PMEM_EXTENDED_PARAMETER between the below:
>>
>> $ fgrep -wB12 PMEM_EXTENDED_PARAMETER /usr/include/w32api/winnt.h
>>    typedef struct DECLSPEC_ALIGN(8) MEM_EXTENDED_PARAMETER {
>>      __C89_NAMELESS struct {
>>          DWORD64 Type : MEM_EXTENDED_PARAMETER_TYPE_BITS;
>>          DWORD64 Reserved : 64 - MEM_EXTENDED_PARAMETER_TYPE_BITS;
>>      };
>>      __C89_NAMELESS union {
>>          DWORD64 ULong64;
>>          PVOID Pointer;
>>          SIZE_T Size;
>>          HANDLE Handle;
>>          DWORD ULong;
>>      };
>>    } MEM_EXTENDED_PARAMETER, *PMEM_EXTENDED_PARAMETER;
>> $ fgrep -wA8 PMEM_EXTENDED_PARAMETER winsup/utils/cygpath.cc
>> #define PMEM_EXTENDED_PARAMETER PVOID
>> #include <windows.h>
>> #include <userenv.h>
>> #include <shlobj.h>
>> #include <ntdef.h>
>> #include <ntdll.h>
>>
>> #include "wide_path.h"
>> #include "loadlib.h"
>>
>> It seems likely that we could perhaps just remove the conflicting #define, but
>> without some idea of the original intent and its impact, and a good cygpath
>> regression test suite, that could perhaps be a rash decision.
> 
> This is related to the extended memory API that Corinna started using last
> April.  At the time the relevant declarations and definitions weren't in the
> mingw-w64 headers yet, so Corinna had to do some ad hoc stuff.  Now that they've
> been added, a lot of that stuff should be removed.  I'll do it later today.

Thanks Ken,
Please let me know so I can pull and rebuild cygwin 32 and 64 to test both with
another cpuinfo update.

I'm going to try to wait until 5.9 release before committing and submitting
another cpuinfo patch, as feature updates are starting to be made visible in
cpuinfo. I thought there were going to be none, then they added some feature
updates, a couple of which were visible, and I thought that might be it, so sent
a patch with those, but more are coming with RCs now.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: Updated: w32api-{headers,runtime}-8.0.0-1 (x86/x86_64)

[Ken Brown]

On 9/23/2020 11:21 AM, Brian Inglis wrote:
> On 2020-09-23 08:49, Ken Brown via Cygwin wrote:
>> On 9/23/2020 12:44 AM, Brian Inglis wrote:
>>> On 2020-09-22 22:17, Brian Inglis wrote:
>>>> On 2020-09-22 16:10, Brian Inglis wrote:
>>>>> On 2020-09-18 23:19, JonY via Cygwin-announce wrote:
>>>>>> Now released for both 32bit and 64bit Cygwin:
>>>>>>
>>>>>> w32api-headers-8.0.0-1
>>>>>> w32api-runtime-8.0.0-1
>>>>>>
>>>>>> Based on mingw-w64-v8.0.0.
>>>>
>>>> Sorry, ambigous - to clarify: may be a definition conflict between updated
>>>> headers rebuilding cygwin both 32 and 64 just after latest updates: see
>>>> attached log.
>>>> Cygwin both 32 and 64 builds worked without any problems just before the latest
>>>> updates.
>>>
>>> Tad confusing log messages, but it appears the actual issue may not be a
>>> conflict to do with PVOID, but with PMEM_EXTENDED_PARAMETER between the below:
>>>
>>> $ fgrep -wB12 PMEM_EXTENDED_PARAMETER /usr/include/w32api/winnt.h
>>>     typedef struct DECLSPEC_ALIGN(8) MEM_EXTENDED_PARAMETER {
>>>       __C89_NAMELESS struct {
>>>           DWORD64 Type : MEM_EXTENDED_PARAMETER_TYPE_BITS;
>>>           DWORD64 Reserved : 64 - MEM_EXTENDED_PARAMETER_TYPE_BITS;
>>>       };
>>>       __C89_NAMELESS union {
>>>           DWORD64 ULong64;
>>>           PVOID Pointer;
>>>           SIZE_T Size;
>>>           HANDLE Handle;
>>>           DWORD ULong;
>>>       };
>>>     } MEM_EXTENDED_PARAMETER, *PMEM_EXTENDED_PARAMETER;
>>> $ fgrep -wA8 PMEM_EXTENDED_PARAMETER winsup/utils/cygpath.cc
>>> #define PMEM_EXTENDED_PARAMETER PVOID
>>> #include <windows.h>
>>> #include <userenv.h>
>>> #include <shlobj.h>
>>> #include <ntdef.h>
>>> #include <ntdll.h>
>>>
>>> #include "wide_path.h"
>>> #include "loadlib.h"
>>>
>>> It seems likely that we could perhaps just remove the conflicting #define, but
>>> without some idea of the original intent and its impact, and a good cygpath
>>> regression test suite, that could perhaps be a rash decision.
>>
>> This is related to the extended memory API that Corinna started using last
>> April.  At the time the relevant declarations and definitions weren't in the
>> mingw-w64 headers yet, so Corinna had to do some ad hoc stuff.  Now that they've
>> been added, a lot of that stuff should be removed.  I'll do it later today.
> 
> Thanks Ken,
> Please let me know so I can pull and rebuild cygwin 32 and 64 to test both with
> another cpuinfo update.

I've just sent a fix to cygwin-patches.  I won't push it until someone reviews 
it.  In particular, I'd like to know if my handling of the declaration of 
VirtualAlloc2 seems reasonable.  Among other things, I'm puzzled by the apparent 
need to add WINAPI.  If it's really needed, I don't know how the calls of that 
function could have worked before.  Can anyone enlighten me?

Ken

Re: Updated: w32api-{headers,runtime}-8.0.0-1 (x86/x86_64)

[Brian Inglis]

On 2020-09-23 17:57, Ken Brown via Cygwin wrote:
> On 9/23/2020 11:21 AM, Brian Inglis wrote:
>> On 2020-09-23 08:49, Ken Brown via Cygwin wrote:
>>> On 9/23/2020 12:44 AM, Brian Inglis wrote:
>>>> On 2020-09-22 22:17, Brian Inglis wrote:
>>>>> On 2020-09-22 16:10, Brian Inglis wrote:
>>>>>> On 2020-09-18 23:19, JonY via Cygwin-announce wrote:
>>>>>>> Now released for both 32bit and 64bit Cygwin:
>>>>>>>
>>>>>>> w32api-headers-8.0.0-1
>>>>>>> w32api-runtime-8.0.0-1
>>>>>>>
>>>>>>> Based on mingw-w64-v8.0.0.
>>>>>
>>>>> Sorry, ambigous - to clarify: may be a definition conflict between updated
>>>>> headers rebuilding cygwin both 32 and 64 just after latest updates: see
>>>>> attached log.
>>>>> Cygwin both 32 and 64 builds worked without any problems just before the
>>>>> latest
>>>>> updates.
>>>>
>>>> Tad confusing log messages, but it appears the actual issue may not be a
>>>> conflict to do with PVOID, but with PMEM_EXTENDED_PARAMETER between the below:
>>>>
>>>> $ fgrep -wB12 PMEM_EXTENDED_PARAMETER /usr/include/w32api/winnt.h
>>>>     typedef struct DECLSPEC_ALIGN(8) MEM_EXTENDED_PARAMETER {
>>>>       __C89_NAMELESS struct {
>>>>           DWORD64 Type : MEM_EXTENDED_PARAMETER_TYPE_BITS;
>>>>           DWORD64 Reserved : 64 - MEM_EXTENDED_PARAMETER_TYPE_BITS;
>>>>       };
>>>>       __C89_NAMELESS union {
>>>>           DWORD64 ULong64;
>>>>           PVOID Pointer;
>>>>           SIZE_T Size;
>>>>           HANDLE Handle;
>>>>           DWORD ULong;
>>>>       };
>>>>     } MEM_EXTENDED_PARAMETER, *PMEM_EXTENDED_PARAMETER;
>>>> $ fgrep -wA8 PMEM_EXTENDED_PARAMETER winsup/utils/cygpath.cc
>>>> #define PMEM_EXTENDED_PARAMETER PVOID
>>>> #include <windows.h>
>>>> #include <userenv.h>
>>>> #include <shlobj.h>
>>>> #include <ntdef.h>
>>>> #include <ntdll.h>
>>>>
>>>> #include "wide_path.h"
>>>> #include "loadlib.h"
>>>>
>>>> It seems likely that we could perhaps just remove the conflicting #define, but
>>>> without some idea of the original intent and its impact, and a good cygpath
>>>> regression test suite, that could perhaps be a rash decision.
>>>
>>> This is related to the extended memory API that Corinna started using last
>>> April.  At the time the relevant declarations and definitions weren't in the
>>> mingw-w64 headers yet, so Corinna had to do some ad hoc stuff.  Now that they've
>>> been added, a lot of that stuff should be removed.  I'll do it later today.
>>
>> Thanks Ken,
>> Please let me know so I can pull and rebuild cygwin 32 and 64 to test both with
>> another cpuinfo update.
> 
> I've just sent a fix to cygwin-patches.  I won't push it until someone reviews
> it.  In particular, I'd like to know if my handling of the declaration of
> VirtualAlloc2 seems reasonable.  Among other things, I'm puzzled by the apparent
> need to add WINAPI.  If it's really needed, I don't know how the calls of that
> function could have worked before.  Can anyone enlighten me?

Appears as with almost all MS Windows API functions, on Windows x86 they use the
stdcall variant of the more efficient original "Pascal" calling convention:
the former pushes the args right to left compatible with C, whereas the latter
pushes the args left to right in Pascal; in both the callee pops the fixed
number of arg stack entries as part of the return "ret n", unlike in C, where
the caller pops the same number of arg stack entries as they pushed, after the
return from each call:
https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types#WINAPI

"WINAPI	The calling convention for system functions.

	This type is declared in WinDef.h as follows:

	#define WINAPI __stdcall

	CALLBACK, WINAPI, and APIENTRY are all used to define functions with the
	__stdcall calling convention. Most functions in the Windows API are
	declared using WINAPI. You may wish to use CALLBACK for the callback
	functions that you implement to help identify the function as a callback
	function."

NTAPI is another name for stdcall.

This may be varied by the amd64/x64 ABI which passes the first 4 args in
registers if possible, and other requirements; on Linux x86 WINAPI routines use
the standard C convention; on ARM the native x64-like ABI convention is used.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]