Re: [Mingw-w64-public] [PATCH 1/2] crt: Add wsmsvc to all architectures
On Thu, 14 Dec 2023, Mark Harmstone wrote:
On 13/12/23 09:06, Martin Storsjö wrote:
On Wed, 13 Dec 2023, Mark Harmstone wrote:
Signed-off-by: Mark Harmstone
---
mingw-w64-crt/lib-common/wsmsvc.def | 3675 +++
mingw-w64-crt/lib32/Makefile.am | 1 +
mingw-w64-crt/lib32/wsmsvc.def | 3673 ++
mingw-w64-crt/lib64/Makefile.am | 1 +
mingw-w64-crt/libarm64/Makefile.am | 1 +
5 files changed, 7351 insertions(+)
create mode 100644 mingw-w64-crt/lib-common/wsmsvc.def
create mode 100644 mingw-w64-crt/lib32/wsmsvc.def
Note that we do have a version of this def file already, for arm32 only.
As we're adding one version in lib-common and reusing it for arm64, I
wonder if we should reuse/share it for arm32 as well? Are there many
differences between these symbols between x86_64 and i386, or between
x86_64 and arm32? Depending on that, we should either keep all 4 separate
(I can generate ones for all 4 architectures by dumping DLLs, but if we
generate it from import libraries you should be able to do it yourself as
well), or share them more than this.
Thanks Martin. Yes, I should have pointed out that this was deliberate. It
looks like the MSVC name mangling is slightly different between arm32 and
i386 (but the same for x86_64 and arm64).
Oh, I see. That's slightly surprising, but apparently that's what it is
then. Yeah, mentioning it in the commit message might be good.
On the other hand, I wonder how much utility there is to this at all - as
no mingw tools really can use the MSVC C++ ABI anyway, so is it worth
adding this at all? (Or should we add it as a stub, empty def file?)
Well, there is that. It's worth adding wsmsvc though, as there's some C
symbols right at the end.
Oh, I didn't notice that. Then I guess it's at least somewhat usable.
I would rather like to add support for MSVC name mangling to GCC one day, but
I suspect it'd be quite a big job...
FWIW, just supporting the name mangling isn't very helpful in the end;
you'd need to support the whole MSVC C++ ABI more or less, in order to
make it useful. Clang does support that, but one can't pick and choose
ABI/mangling per class, but you'd switch entirely between MSVC and mingw
mode per compilation unit. (There is actually a
-fc++-abi={itanium,microsoft} option that one can use to switch the C++
ABI separately from the overall target/mode, but I don't think it's
practically tested to mix MSVC C++ with mingw in that way.)
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Add missing functions to mmdevapi
Signed-off-by: Mark Harmstone --- mingw-w64-crt/lib-common/mmdevapi.def | 30 +++ mingw-w64-crt/lib32/mmdevapi.def | 30 +++ 2 files changed, 60 insertions(+) diff --git a/mingw-w64-crt/lib-common/mmdevapi.def b/mingw-w64-crt/lib-common/mmdevapi.def index 4a516..81fea2c13 100644 --- a/mingw-w64-crt/lib-common/mmdevapi.def +++ b/mingw-w64-crt/lib-common/mmdevapi.def @@ -1,3 +1,33 @@ LIBRARY "mmdevapi.dll" EXPORTS +AETraceOutputDebugString ActivateAudioInterfaceAsync +CleanupDeviceAPI +FlushDeviceTopologyCache +GenerateMediaEvent +GetCategoryPath +GetClassFromEndpointId +GetEndpointGuidFromEndpointId +GetEndpointIdFromDeviceInterfaceId +GetNeverSetAsDefaultProperty +GetSessionIdFromEndpointId +InitializeDeviceAPI +MMDeviceCreateRegistryPropertyStore +MMDeviceGetDeviceEnumerator +MMDeviceGetEndpointManager +MMDeviceGetPolicyConfig +RegisterForMediaCallback +UnregisterMediaCallback +mmdDevFindMmDevProperty +mmdDevGetDeviceIdFromPnpInterface +mmdDevGetEndpointFormFactorFromMMDeviceId +mmdDevGetInstanceIdFromInterfaceId +mmdDevGetInstanceIdFromMMDeviceId +mmdDevGetInterfaceClassGuid +mmdDevGetInterfaceDataFlow +mmdDevGetInterfaceIdFromMMDevice +mmdDevGetInterfaceIdFromMMDeviceId +mmdDevGetInterfacePropertyStore +mmdDevGetMMDeviceFromInterfaceId +mmdDevGetMMDeviceIdFromInterfaceId +mmdDevGetRelatedInterfaceId diff --git a/mingw-w64-crt/lib32/mmdevapi.def b/mingw-w64-crt/lib32/mmdevapi.def index a13425cb6..fb764aa8b 100644 --- a/mingw-w64-crt/lib32/mmdevapi.def +++ b/mingw-w64-crt/lib32/mmdevapi.def @@ -1,3 +1,33 @@ LIBRARY "mmdevapi.dll" EXPORTS +AETraceOutputDebugString ActivateAudioInterfaceAsync@20 +CleanupDeviceAPI@0 +FlushDeviceTopologyCache@0 +GenerateMediaEvent@8 +GetCategoryPath@16 +GetClassFromEndpointId@4 +GetEndpointGuidFromEndpointId@8 +GetEndpointIdFromDeviceInterfaceId@8 +GetNeverSetAsDefaultProperty@16 +GetSessionIdFromEndpointId@4 +InitializeDeviceAPI@0 +MMDeviceCreateRegistryPropertyStore@12 +MMDeviceGetDeviceEnumerator@4 +MMDeviceGetEndpointManager@4 +MMDeviceGetPolicyConfig@4 +RegisterForMediaCallback@8 +UnregisterMediaCallback@4 +mmdDevFindMmDevProperty@12 +mmdDevGetDeviceIdFromPnpInterface@8 +mmdDevGetEndpointFormFactorFromMMDeviceId@8 +mmdDevGetInstanceIdFromInterfaceId@8 +mmdDevGetInstanceIdFromMMDeviceId@8 +mmdDevGetInterfaceClassGuid@8 +mmdDevGetInterfaceDataFlow@8 +mmdDevGetInterfaceIdFromMMDevice@8 +mmdDevGetInterfaceIdFromMMDeviceId@8 +mmdDevGetInterfacePropertyStore@12 +mmdDevGetMMDeviceFromInterfaceId@8 +mmdDevGetMMDeviceIdFromInterfaceId@8 +mmdDevGetRelatedInterfaceId@24 -- 2.41.0 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Add wsmsvc to all architectures
On 13/12/23 09:06, Martin Storsjö wrote: On Wed, 13 Dec 2023, Mark Harmstone wrote: Signed-off-by: Mark Harmstone --- mingw-w64-crt/lib-common/wsmsvc.def | 3675 +++ mingw-w64-crt/lib32/Makefile.am | 1 + mingw-w64-crt/lib32/wsmsvc.def | 3673 ++ mingw-w64-crt/lib64/Makefile.am | 1 + mingw-w64-crt/libarm64/Makefile.am | 1 + 5 files changed, 7351 insertions(+) create mode 100644 mingw-w64-crt/lib-common/wsmsvc.def create mode 100644 mingw-w64-crt/lib32/wsmsvc.def Note that we do have a version of this def file already, for arm32 only. As we're adding one version in lib-common and reusing it for arm64, I wonder if we should reuse/share it for arm32 as well? Are there many differences between these symbols between x86_64 and i386, or between x86_64 and arm32? Depending on that, we should either keep all 4 separate (I can generate ones for all 4 architectures by dumping DLLs, but if we generate it from import libraries you should be able to do it yourself as well), or share them more than this. Thanks Martin. Yes, I should have pointed out that this was deliberate. It looks like the MSVC name mangling is slightly different between arm32 and i386 (but the same for x86_64 and arm64). On the other hand, I wonder how much utility there is to this at all - as no mingw tools really can use the MSVC C++ ABI anyway, so is it worth adding this at all? (Or should we add it as a stub, empty def file?) Well, there is that. It's worth adding wsmsvc though, as there's some C symbols right at the end. I would rather like to add support for MSVC name mangling to GCC one day, but I suspect it'd be quite a big job... Mark ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] headers: move PPROC_THREAD_ATTRIBUTE_LIST in PARTITION_APP
It's needed by CreateProcess (via STARTUPINFOEX) which is available in UWP apps. --- mingw-w64-headers/include/processthreadsapi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/include/processthreadsapi.h b/mingw-w64-headers/include/processthreadsapi.h index ec07a5fe3..334463436 100644 --- a/mingw-w64-headers/include/processthreadsapi.h +++ b/mingw-w64-headers/include/processthreadsapi.h @@ -199,12 +199,12 @@ DEFINE_ENUM_FLAG_OPERATORS(MACHINE_ATTRIBUTES); WINBASEAPI WINBOOL WINAPI SetThreadSelectedCpuSetMasks (HANDLE Thread, PGROUP_AFFINITY CpuSetMasks, USHORT CpuSetMaskCount); #endif + typedef struct _PROC_THREAD_ATTRIBUTE_LIST *PPROC_THREAD_ATTRIBUTE_LIST, *LPPROC_THREAD_ATTRIBUTE_LIST; + #endif /* WINAPI_PARTITION_APP */ #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP) - typedef struct _PROC_THREAD_ATTRIBUTE_LIST *PPROC_THREAD_ATTRIBUTE_LIST, *LPPROC_THREAD_ATTRIBUTE_LIST; - WINBASEAPI HANDLE WINAPI CreateRemoteThread (HANDLE hProcess, LPSECURITY_ATTRIBUTES lpThreadAttributes, SIZE_T dwStackSize, LPTHREAD_START_ROUTINE lpStartAddress, LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId); WINBASEAPI WINBOOL WINAPI TerminateThread (HANDLE hThread, DWORD dwExitCode); WINBASEAPI WINBOOL WINAPI SetProcessShutdownParameters (DWORD dwLevel, DWORD dwFlags); -- 2.39.2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] crt: Add wsmsvc to all architectures
On Wed, 13 Dec 2023, Mark Harmstone wrote: Signed-off-by: Mark Harmstone --- mingw-w64-crt/lib-common/wsmsvc.def | 3675 +++ mingw-w64-crt/lib32/Makefile.am |1 + mingw-w64-crt/lib32/wsmsvc.def | 3673 ++ mingw-w64-crt/lib64/Makefile.am |1 + mingw-w64-crt/libarm64/Makefile.am |1 + 5 files changed, 7351 insertions(+) create mode 100644 mingw-w64-crt/lib-common/wsmsvc.def create mode 100644 mingw-w64-crt/lib32/wsmsvc.def Note that we do have a version of this def file already, for arm32 only. As we're adding one version in lib-common and reusing it for arm64, I wonder if we should reuse/share it for arm32 as well? Are there many differences between these symbols between x86_64 and i386, or between x86_64 and arm32? Depending on that, we should either keep all 4 separate (I can generate ones for all 4 architectures by dumping DLLs, but if we generate it from import libraries you should be able to do it yourself as well), or share them more than this. On the other hand, I wonder how much utility there is to this at all - as no mingw tools really can use the MSVC C++ ABI anyway, so is it worth adding this at all? (Or should we add it as a stub, empty def file?) // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Add DnsCleanupTcpConnections to dnsapi
Mark Harmstone wrote: diff --git a/mingw-w64-crt/lib-common/dnsapi.def b/mingw-w64-crt/lib-common/dnsapi.def index 929deecd6..fae00a0a5 100644 --- a/mingw-w64-crt/lib-common/dnsapi.def +++ b/mingw-w64-crt/lib-common/dnsapi.def @@ -28,6 +28,7 @@ DnsAsyncRegisterTerm DnsCancelQuery DnsCheckNrptRuleIntegrity DnsCheckNrptRules +DnsCleanupTcpConnections DnsConnectionDeletePolicyEntries DnsConnectionDeletePolicyEntriesPrivate DnsConnectionDeleteProxyInfo Which API-version are these part of? E.g. 'DnsCleanupTcpConnections()' is not in my WinSDK ver 10.0.22621.0 'WinDNS.h'. And a search for: https://learn.microsoft.com/en-us/search/?terms=DnsCheckNrptRules gave nothing. So some of these are for internal use only? -- --gv ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
