Send MinGW-Notify mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osdn.me/mailman/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-Notify digest..."
Please do not reply to this notification; the sender address is unable to
accept incoming e-mail. If you wish to unsubscribe you can do so at
https://lists.osdn.me/mailman/listinfo/mingw-notify.
Today's Topics:
1. [mingw] #41567: Some new Win32 APIs are missing from w32api
(MinGW Notification List)
2. [mingw] #41567: Some new Win32 APIs are missing from w32api
(MinGW Notification List)
3. [mingw] #42344: Implement a generic infrastructure to
facilitate run-time linking of API functions (MinGW Notification List)
4. [mingw] #42344: Implement a generic infrastructure to
facilitate run-time linking of API functions (MinGW Notification List)
----------------------------------------------------------------------
Message: 1
Date: Sat, 22 May 2021 12:09:41 +0300
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #41567: Some new Win32 APIs are
missing from w32api
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#41567: Some new Win32 APIs are missing from w32api
Open Date: 2021-02-12 16:20
Last Update: 2021-05-22 12:09
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/41567
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41567
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2021-05-22 12:09 Updated by: eliz
Comment:
Reply To keith
I've attached my current W32API patch, to address this issue; please check if
it meets your requirements.
Thanks, this allows me to compile the pseudo-console test program.
Note that, to expose the pseudo-console API, you will need to #define
NTDDI_VERSION NTDDI_WIN10_RS5, (which, with our <sdkddkver.h> should also
implicitly #define _WIN32_WINNT _WIN32_WINNT_WIN10; if not, you will also need
to define this explicitly).
This is a bit of a condundrum: NTDDI_WIN10_RS5 is not known until w32api.h is
included, so the program which uses this must include that header first, or
manually deduce its numerical value and use that. Up until now, I only needed
to define _WIN32_WINNT to the relevant Windows version. But that is a minor
annoyance.
---------------------------------------------------------------------
Ticket Status:
Reporter: eliz
Owner: (None)
Type: Feature Request
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
To compile programs that use the Pseudo Console feature introduced recently
with Windows 10, there's a need in several additions to the MinGW w32api
headers and import libraries.
First, we need a value for _WIN32_WINNT that specifies Windows 10, in
sdkddkver.h:
#define _WIN32_WINNT_WIN10 0x0A00
Second, we need functions, data structures, and macros to create and update
lists of attributes for process and thread creation. These are:
InitializeProcThreadAttributeList function
UpdateProcThreadAttribute function
DeleteProcThreadAttributeList function
PROC_THREAD_ATTRIBUTE_LIST structure
STARTUPINFOEX structure
PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE macro
Other PROC_THREAD_ATTRIBUTE_* macros
These seem to be supported since Windows 7, with the exception of
PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, which is only supported since Windows 10,
and STARTUPINFOEX, which is supported since Vista. I think the proper place
for them is in the winbase.h header file.
We also need the EXTENDED_STARTUPINFO_PRESENT flag for the CreateProcess
function (this flag is supported since Vista and should be in winbase.h).
And finally, we need the functions, data types, and macros to manipulate
pseudo-consoles, available only since Windows 10:
CreatePseudoConsole function
ClosePseudoConsole function
ResizePseudoConsole function
HPCON data type
Thanks in advance for providing these.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/41567
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41567
------------------------------
Message: 2
Date: Sat, 22 May 2021 16:46:10 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #41567: Some new Win32 APIs are
missing from w32api
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#41567: Some new Win32 APIs are missing from w32api
Open Date: 2021-02-12 14:20
Last Update: 2021-05-22 16:46
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/41567
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41567
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2021-05-22 16:46 Updated by: keith
Comment:
Reply To eliz
Reply To keith
I've attached my current W32API patch, to address this issue; please check if
it meets your requirements.
Thanks, this allows me to compile the pseudo-console test program.
Good to know. Thanks.
Note that, to expose the pseudo-console API, you will need to #define
NTDDI_VERSION NTDDI_WIN10_RS5, (which, with our <sdkddkver.h> should also
implicitly #define _WIN32_WINNT _WIN32_WINNT_WIN10; if not, you will also need
to define this explicitly).
This is a bit of a condundrum:
Why?
NTDDI_WIN10_RS5 is not known until w32api.h is included, so the program which
uses this must include that header first, or manually deduce its numerical
value and use that.
No, that should not be necessary. It should be sufficient to:
#define NTDDI_VERSION NTDDI_WIN10_RS5up front; even if the value of
NTDDI_WIN10_RS5 is unknown at point of definition, all will be well provided it
is known at point of reference, (which it should be, because <sdkddkver.h>
should already have been included, implicitly, by the time the reference is
evaluated in <wincon.h>).
Up until now, I only needed to define _WIN32_WINNT to the relevant Windows
version. But that is a minor annoyance.
Blame Microsoft. Since Windows-10 came on the scene, _WIN32_WINNT isn't
sufficiently fine-grained to discriminate among the myriad sub-version feature
changes which have been introduced.
---------------------------------------------------------------------
Ticket Status:
Reporter: eliz
Owner: (None)
Type: Feature Request
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
To compile programs that use the Pseudo Console feature introduced recently
with Windows 10, there's a need in several additions to the MinGW w32api
headers and import libraries.
First, we need a value for _WIN32_WINNT that specifies Windows 10, in
sdkddkver.h:
#define _WIN32_WINNT_WIN10 0x0A00
Second, we need functions, data structures, and macros to create and update
lists of attributes for process and thread creation. These are:
InitializeProcThreadAttributeList function
UpdateProcThreadAttribute function
DeleteProcThreadAttributeList function
PROC_THREAD_ATTRIBUTE_LIST structure
STARTUPINFOEX structure
PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE macro
Other PROC_THREAD_ATTRIBUTE_* macros
These seem to be supported since Windows 7, with the exception of
PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, which is only supported since Windows 10,
and STARTUPINFOEX, which is supported since Vista. I think the proper place
for them is in the winbase.h header file.
We also need the EXTENDED_STARTUPINFO_PRESENT flag for the CreateProcess
function (this flag is supported since Vista and should be in winbase.h).
And finally, we need the functions, data types, and macros to manipulate
pseudo-consoles, available only since Windows 10:
CreatePseudoConsole function
ClosePseudoConsole function
ResizePseudoConsole function
HPCON data type
Thanks in advance for providing these.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/41567
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41567
------------------------------
Message: 3
Date: Sat, 22 May 2021 17:03:38 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #42344: Implement a generic
infrastructure to facilitate run-time linking of API functions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#42344: Implement a generic infrastructure to facilitate run-time linking of
API functions
Open Date: 2021-05-21 20:46
Last Update: 2021-05-22 17:03
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/42344
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=42344
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2021-05-22 17:03 Updated by: keith
Comment:
Consider the (trivial) program, (contrived in conjunction with development
related to feature request #41567):
#define _MINGW_LEGACY_SUPPORT #define NTDDI_VERSION NTDDI_WIN10_RS5 #include
<stdio.h> #include <winbase.h> #include <winerror.h> #include <wincon.h> int
conapi_test( void ) { HPCON hPC; COORD size = { 80, 25 }; if(
CreatePseudoConsole( size, 0, 0, 0, &hPC ) == ERROR_OLD_WIN_VERSION )
fprintf( stderr, "Pseudo-consoles not supported; Win10-RS5 (or later)
is required.\n" ); ResizePseudoConsole( hPC, size );
ClosePseudoConsole( hPC ); return 0; } int main() { printf( "Main program
started\n" ); return conapi_test(); }
Ignoring the effect of line 1, for the time being — because its influence is,
as yet, unimplemented — this will not compile, with the currently released
W32API version; compilation will fail, because HPCON is an undefined data type,
and furthermore, CreatePseudoConsole(), ResizePseudoConsole(), and
ClosePseudoConsole() are undeclared, so implicit declaration warnings are
raised for each:
$ mingw32-gcc -Wall -O3 conapi-test.c
pc.c: In function 'conapi_test':
pc.c:10:3: error: unknown type name 'HPCON'; did you mean 'HICON'?
10 | { HPCON hPC; COORD size = { 80, 25 };
| ^~~~~
| HICON
pc.c:11:7: warning: implicit declaration of function 'CreatePseudoConsole'
[-Wimplicit-function-declaration]
11 | if( CreatePseudoConsole( size, 0, 0, 0, &hPC ) ==
ERROR_OLD_WIN_VERSION )
| ^~~~~~~~~~~~~~~~~~~
pc.c:15:3: warning: implicit declaration of function 'ResizePseudoConsole'
[-Wimplicit-function-declaration]
15 | ResizePseudoConsole( hPC, size );
| ^~~~~~~~~~~~~~~~~~~
pc.c:16:3: warning: implicit declaration of function 'ClosePseudoConsole'
[-Wimplicit-function-declaration]
16 | ClosePseudoConsole( hPC );
| ^~~~~~~~~~~~~~~~~~
OTOH, if I implement the changes proposed in the first tentative implementation
patch, attached to #41567, and add "-I ..." and "-L ..." references, to locate
the uninstalled headers and import libraries within my local MinGW-WSL build
tree, this does compile, and link successfully:
$ mingw32-gcc -Wall -O3 -I ../w32api/include/ conapi-test.c -L ./w32api/
$ cp a.exe ~/VirtualBox/share/
So outwardly, all looks good. However, if I try to run this on any Windows
version pre-dating Win10-RS5, (I tried WinXP, in a virtual machine), it crashes
before it ever gets to that first printf statement in main(); I see a message
box telling me that entry point CreatePseudoConsole could not be found, in
kernel32.dll, and the process dies; (I guess it could equally well have failed
on either of the other two pseudo-console API entry points, depending on the
order in which the run-time loader attempts to resolve them).
Curiously, if I run it under Wine, (configured to emulate Win7 behaviour), it
runs successfully:
$ ./a.exe
Main program started
which should not have happened; I guess this is a bug in Wine-6.7, insofar as
it fails to reject API calls which should not be supported in its configured
Windows version emulation.
---------------------------------------------------------------------
Ticket Status:
Reporter: keith
Owner: keith
Type: Feature Request
Status: Open [Owner assigned]
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
As support for new (Windows version-dependent) APIs is added to MinGW, there is
increased potential for creating an application which will not load, much less
run, on legacy Windows versions; the typical manifestation of such a load
failure is that the process crashes with an "entry point not found" exception,
for the unsupported DLL function, before the main() function even gets control,
so there's no opportunity to handle the exception.
The only way to mitigate such exceptions, such that the application retains
control, is to always link potentially unsupported API functions dynamically,
at run-time, by retrieval of an entry-point reference, using GetProcAddress(),
and to always invoke the function via the reference pointer, (and never call it
directly, by name). The mechanism for dynamically linking such functions is
mostly the same, in each case, often resulting in significant repetitive
coding; it would be a great convenience, if MinGW were to implement a generic
API infrastructure, to encapsulate the common features of the required run-time
linking interface.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/42344
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=42344
------------------------------
Message: 4
Date: Sun, 23 May 2021 00:08:20 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #42344: Implement a generic
infrastructure to facilitate run-time linking of API functions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#42344: Implement a generic infrastructure to facilitate run-time linking of
API functions
Open Date: 2021-05-21 20:46
Last Update: 2021-05-23 00:08
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/42344
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=42344
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2021-05-23 00:08 Updated by: keith
Comment:
I've attached a proposed implementation.
With this in place, and with the <wincon.h> update, as proposed for feature
request #41567, augmented by the further addition of:
diff --git a/w32api/include/wincon.h b/w32api/include/wincon.h ---
a/w32api/include/wincon.h +++ b/w32api/include/wincon.h @@ -423,10 +423,49 @@
WINAPI HRESULT CreatePseudoConsole (COOR WINAPI HRESULT ResizePseudoConsole
(HPCON, COORD); WINAPI void ClosePseudoConsole (HPCON); #define
PSEUDOCONSOLE_INHERIT_CURSOR (DWORD)(1) +#ifdef _MINGW_LEGACY_SUPPORT +/*
For MinGW legacy platform support, provide inline redirector stubs, + * to
facilate graceful fallback action, in the event that any program, + * which has
been linked with the pseudo-console API, is run on an older + * version of
Windows. + */ +#include "legacy.h" + +__CRT_ALIAS WINAPI HRESULT
CreatePseudoConsole +( COORD size, HANDLE input, HANDLE output, DWORD flags,
HPCON *con ) +{ + typedef WINAPI HRESULT (*api)( COORD, HANDLE, HANDLE, DWORD,
HPCON * ); + + static void *call = API_UNCHECKED; + return ((call =
__kernel32_entry_point( call, __FUNCTION__ )) != NULL) + ? ((api)(call))(
size, input, output, flags, con ) + : __legacy_support(
ERROR_OLD_WIN_VERSION ); +} + +__CRT_ALIAS WINAPI HRESULT ResizePseudoConsole
(HPCON con, COORD size) +{ + typedef WINAPI HRESULT (*api)( HPCON, COORD ); +
+ static void *call = API_UNCHECKED; + return ((call =
__kernel32_entry_point( call, __FUNCTION__ )) != NULL) + ? ((api)(call))(
con, size ) : __legacy_support( ERROR_OLD_WIN_VERSION ); +} + +__CRT_ALIAS
WINAPI void ClosePseudoConsole (HPCON con) +{ + typedef WINAPI void (*api)(
HPCON ); + + static void *call = API_UNCHECKED; + if( (call =
__kernel32_entry_point( call, __FUNCTION__ )) == NULL ) +
(void)__legacy_support( ERROR_OLD_WIN_VERSION ); + else ((api)(call))( con );
+} +#endif /* _MINGW_LEGACY_SUPPORT */ + #endif /* Win10 Redstone 5 and later
*/ #endif /* Vista and later */ #endif /* WinXP and later */ #endif /* Win2K
and later */ my example program, from my previous comment, not only compiles
and links successfully, but when I run it on the WinXP virtual machine, I now
see the expected output:
$ /e/a.exe
Main program started
Pseudo-consoles not supported; Win10-RS5 (or later) is required.
I propose adding this for W32API version 5.5; notice that it does now attribute
meaning to the proposed new _MINGW_LEGACY_SUPPORT feature test macro.
---------------------------------------------------------------------
Ticket Status:
Reporter: keith
Owner: keith
Type: Feature Request
Status: Open [Owner assigned]
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
As support for new (Windows version-dependent) APIs is added to MinGW, there is
increased potential for creating an application which will not load, much less
run, on legacy Windows versions; the typical manifestation of such a load
failure is that the process crashes with an "entry point not found" exception,
for the unsupported DLL function, before the main() function even gets control,
so there's no opportunity to handle the exception.
The only way to mitigate such exceptions, such that the application retains
control, is to always link potentially unsupported API functions dynamically,
at run-time, by retrieval of an entry-point reference, using GetProcAddress(),
and to always invoke the function via the reference pointer, (and never call it
directly, by name). The mechanism for dynamically linking such functions is
mostly the same, in each case, often resulting in significant repetitive
coding; it would be a great convenience, if MinGW were to implement a generic
API infrastructure, to encapsulate the common features of the required run-time
linking interface.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/42344
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=42344
------------------------------
Subject: Digest Footer
_______________________________________________
MinGW-Notify mailing list
[email protected]
https://lists.osdn.me/mailman/listinfo/mingw-notify
------------------------------
End of MinGW-Notify Digest, Vol 44, Issue 10
********************************************
