DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 102CE386191C
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
Subject: Re: Updated: w32api-{headers,runtime}-8.0.0-1 (x86/x86_64)
To: cygwin@cygwin.com
References: <announce.d744b23b-75c7-1ee1-9b94-15736fc47b98@gmail.com>
 <9a0a7e24-45fb-55d8-67f6-377b153810ab@SystematicSw.ab.ca>
 <6d714acb-1df5-0c53-0409-65b4c43e8b36@SystematicSw.ab.ca>
 <0c884817-574a-e171-9bb5-b8d313a5f6ee@SystematicSw.ab.ca>
 <6ac829c6-5281-ce39-d22b-d57b7d476c1c@cornell.edu>
 <06124a28-ecf3-fed1-7df3-947b91641f26@SystematicSw.ab.ca>
 <1c24c7a0-187d-8d1d-2ef4-232bc8c19003@cornell.edu>
Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual;
 keydata=
 mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0
 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA
 PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW
 AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO
 WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB
 BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5
 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF
 IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5
 RSyTY8X+AQ==
Organization: Systematic Software
Message-ID: <3b0dd931-3d2f-61f0-5e7a-c8177343db4b@SystematicSw.ab.ca>
Date: Thu, 24 Sep 2020 10:22:22 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <1c24c7a0-187d-8d1d-2ef4-232bc8c19003@cornell.edu>
Content-Language: en-CA
Precedence: list
Reply-To: cygwin@cygwin.com
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces@cygwin.com
Sender: "Cygwin" <cygwin-bounces@cygwin.com>
Content-Transfer-Encoding: 8bit

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.]
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple