Re: [PATCH] Cygwin: winlean.h: remove most of extended memory API

2020-09-24 Thread Ken Brown via Cygwin-patches

On 9/24/2020 10:04 AM, Jon Turney wrote:

On 24/09/2020 00:52, Ken Brown via Cygwin-patches wrote:

This was added as a temporary measure in commit e18f7f99 because it
wasn't yet in the mingw-w64 headers.  With one exception, it is now in
the current release of the headers (version 8.0.0), so we don't need
it in winlean.h.  The exception is that VirtualAlloc2 is only declared
conditionally in , so retain it in winlean.h.  Add


I assume it's conditional on the windows version targetted, but it might help to 
mention that in a comment.


Done.


"WINAPI" to its declaration for consistency with the delaration in
memoryapi.h.

Also revert commit 3d136011, which was a related temporary workaround.


Looks good to me.

I think this isn't going work any more with older win32api, but we probably 
don't care about that.  It would perhaps be nice to explicitly complain about 
that (checking __MINGW64_VERSION_MAJOR somehow), rather than exploding 
incomprehensibly if the w32api is too old?


We probably don't care much, since anyone building Cygwin should have the latest 
tools installed.  On the other hand, it's simple to add that check, so I've done 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?


I believe that WINAPI only does something (stdcall) on x86, so it might well be 
that it's never worked on Windows 10 =>1803 x86?


OK, I feel better now.

Thanks for the review.

Ken


Re: [PATCH] Cygwin: winlean.h: remove most of extended memory API

2020-09-24 Thread Jon Turney

On 24/09/2020 00:52, Ken Brown via Cygwin-patches wrote:

This was added as a temporary measure in commit e18f7f99 because it
wasn't yet in the mingw-w64 headers.  With one exception, it is now in
the current release of the headers (version 8.0.0), so we don't need
it in winlean.h.  The exception is that VirtualAlloc2 is only declared
conditionally in , so retain it in winlean.h.  Add


I assume it's conditional on the windows version targetted, but it might 
help to mention that in a comment.



"WINAPI" to its declaration for consistency with the delaration in
memoryapi.h.

Also revert commit 3d136011, which was a related temporary workaround.


Looks good to me.

I think this isn't going work any more with older win32api, but we 
probably don't care about that.  It would perhaps be nice to explicitly 
complain about that (checking __MINGW64_VERSION_MAJOR somehow), rather 
than exploding incomprehensibly if the w32api is too old?


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?


I believe that WINAPI only does something (stdcall) on x86, so it might 
well be that it's never worked on Windows 10 =>1803 x86?




Re: Re: [PATCH v4 1/3] Cygwin: rewrite and make public cmdline parser

2020-09-24 Thread Mingye Wang (Artoria2e5)

On 2020/9/7 17:39, Corinna Vinschen wrote:


Nope, we won't do that.  The command line parsing is an internal
thing, and we won't export arbitrary internal functions using
their own symbol.  *If* we should export this stuff at all, which
I highly doubt as necessary, it should use the cygwin_internal API.


The idea is that the sort of thing get reimplemented incorrectly a lot, 
and since we have the extra @file feature and the Unix glob it would be 
nice to allow other people to use it. Win32 has CommandLineToArgvW, so I 
figured it wouldn't be too strange to have.


The escaping function is there mostly for symmetry and convenience, 
since it's basically the standard escape.


--
Regards,
Mingye