From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) by sourceware.org (Postfix) with ESMTPS id 102CE386191C for ; Thu, 24 Sep 2020 16:22:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 102CE386191C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id LU0kkI2jws3D6LU0lkrDbp; Thu, 24 Sep 2020 10:22:24 -0600 X-Authority-Analysis: v=2.4 cv=bZHV7MDB c=1 sm=1 tr=0 ts=5f6cc7c0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=yMhMjlubAAAA:8 a=DGepJrkxeXANa8AWB7kA:9 a=5SmtuBGpqDnccwKR:21 a=cQK6aYBu3xT27gGa:21 a=QEXdDO2ut3YA:10 From: Brian Inglis Subject: Re: Updated: w32api-{headers,runtime}-8.0.0-1 (x86/x86_64) Reply-To: cygwin@cygwin.com To: cygwin@cygwin.com References: <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-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfD3EgFDrVIcwtGx/fxNmNAoRqa8alyAmT/xiTNxYhptE8OZ03NLW7tsK2g6g+xRhJyrJpdJKWdHOb7yiijAz5gO0Ea8NJ8uTlWvT2uGkMHQ3/FvWiLSz Boi2BlMldTVB9xgKaZoGsE5hvB24BAEtsussYlQ4FTZqty+HYzri8Jx65JHhxAt9s+2s50JRjQ2Sm4v/fugvvjBebWtZfDe4VAg= X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 16:22:26 -0000 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 >>>> #include >>>> #include >>>> #include >>>> #include >>>> >>>> #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.]