Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
On 28.12.2020 23:23, Martin Storsjö wrote: On Mon, 28 Dec 2020, Jacek Caban wrote: As long as the application does not use new APIs, its compatibility with older Windows will not change. And this bit: This value is commonly mistaken with 'minimum version supported in runtime', which is simply not the case. It's only a version that headers will provide declarations for. https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt says The preprocessor macros WINVER and _WIN32_WINNT specify the minimum operating system version your code supports. Yes, but the critical part is the very first sentence, which says that 'you can specify which versions of Windows your code can run on.'. Note the difference between *can* and *need*. When using mingw-w64 with its defaults, you essentially *need* to do that if you're working on a modern application. That article is about changing the value, not about the meaning of its default value. The current difference between 'can' and 'need' comes from toolchain defaults and all we need to do to be precisely compatible with mentioned documentation is to change the default to win10, like authors of this documentation did in their SDK. If users still want headers to not provide Win10-only declarations, they may just set _WIN32_WINNT explicitly in build system to the exact version they want. If packagers prefer it the old way, they can use the configure stitch for that. Yeah, it's good that we're able to override the default - I think I'd still keep doing that. But I think there's at least some amount of projects (mingw centric projects primarily, as the default in MSVC is different) that expect and rely on the current norm of it being set to the minimum. Those are bugs in these projects. I'm not keen to break them, but I also don't think that we should keep current situation forever. I'd like users, who just installed a default mingw-w64, to be able to just #include and have the best of mingw-w64 available. Right now, when they try to use any recent API (as in younger than 19 years), they have to learn about _WIN32_WINNT and mess with it. In my opinion, they should not be required to do that. (Once they have some specific expectations about OS version, they may still want/need to do that, but mistakes of unrelated projects should not be among reasons to mess with _WIN32_WINNT). That sounds like a sensible goal to have - but I'm a little undecided about the practicalities. Then again, I can agree with the argument that projects that are built for distribution across older versions maybe should take care to specifically set the define themselves anyway. Regarding the current archaic default, an alternative path (that doesn't take us all the way, but at least a bit on the way) would be to bump it to Win7. I think that it's better than nothing, but it would only move the problem. It also rises more questions like why not win8? When will we rise it again? Will we wait until win7 becomes 19 years old? I think that those questions are better answered individually by projects themselves, we can't make a single choice good for all of them. I also faintly remember somebody suggesting that we'd formally drop support for XP altogether. FWIW, that sounds about right to me, but I didn't want to make this change about dropping XP support. I guess that what we're missing is some form of discussion and formalizing it, if that's the consensus. Thanks, Jacek ___ 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] headers: Use Windows 10 as default _WIN32_WINNT value.
On 28.12.2020 03:39, Liu Hao wrote: 在 2020/12/27 上午5:44, Martin Storsjö 写道: I'm not entierely sure I agree with this - I think different ecosystems have different expectations here. (It'd be interesting to e.g. rebuild all of msys2's mingw package repository with such headers, and see how many of them fail to run on the previous minimum version.) If users still want headers to not provide Win10-only declarations, they may just set _WIN32_WINNT explicitly in build system to the exact version they want. If packagers prefer it the old way, they can use the configure stitch for that. Yeah, it's good that we're able to override the default - I think I'd still keep doing that. But I think there's at least some amount of projects (mingw centric projects primarily, as the default in MSVC is different) that expect and rely on the current norm of it being set to the minimum. I have an impression that all projects should have defined `_WIN32_WINNT` in a similar way to how people work with feature test macros on Linux (the GNU C++ compiler on Linux defines `_GNU_SOURCE` but I think it's bad practice). The default value of `_WIN32_WINNT` doesn't matter in a sense. (And if we should catch with everything by default, why not just define it to `0x`?) I think that there are no plans for post-Windows 10 versions releases at the moment, so win10 should work just as well for foreseeable future without introducing a new value. There is also NTDDI_VERSION, which specifies win10 variant and we currently default it to 0. Jacek ___ 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] headers: Use Windows 10 as default _WIN32_WINNT value.
On 26.12.2020 22:44, Martin Storsjö wrote: On Sat, 26 Dec 2020, Jacek Caban wrote: Signed-off-by: Jacek Caban --- I think it's reasonable to assume that the current default value of Windows XP does not reflect reality. The new value deserves some considerations. I propose to go all the way to Windows 10 and match Windows SDK. The main concern about this is compatibility. This value is commonly mistaken with 'minimum version supported in runtime', which is simply not the case. It's only a version that headers will provide declarations for. As long as the application does not use new APIs, its compatibility with older Windows will not change. In addition to hiding declarations, it can also affect how APIs that used to exist are accessed. A concrete case is psapi.h: I can include psapi.h and call EnumProcessModules. If NTDDI_VERSION >= NTDDI_WIN7 when including the header, the call to EnumProcessModules gets redirected to K32EnumProcessModules which exists in kernel32.dll from win7. If I include the header with a lower version defined, it ends up calling EnumProcessModules in psapi.dll instead. Right, I missed this, I was concentrated on deciding if use win10 or something older. I think it was a mistake how MS dealt with it, esp. the version check, but if you want to link to psapi.dll, the solution is well documented and supported: –DPSAPI_VERSION=1. There is no need to touch NTDDI_VERSION or _WIN32_WINNT. Projects need to be aware of -lpsapi anyway. I realize that some projects don't do it right, but the alternative is to default to XP forever. BTW, if impact of the problem is too bad, we could just place K32* aliases to non K32-prefixed functions inside psapi importlib. This way projects that use headers in version 2, but link to psapi will keep consistent behaviour. I'm not sure it's needed nor better. Likewise, the optional IPv6 APIs end up called via GetProcAddress based wrappers. At least in official WinSDK (if I remember correctly and read the headers right), these end up skipped if _WIN32_WINNT targets a high enough version (but I think mingw-w64 headers always end up using the compat wrappers). I don't know about it. A quick grep in mingw-w64 didn't find that. A second concern is that the existing practice of build systems/configure scripts probing for function availability, expecting the declarations to be hidden if they aren't supposed to be used - VLC is one prime such example, and many others work the same way. And e.g. for that case, there's many different components that all can set the version, with varying levels of precedence: - The toolchain defaults. (E.g. in the case of llvm-mingw, the default is Win7, as libc++ on windows requires that, so there's no point in targeting anything below that.) Yes, to me llvm-mingw successfully using a version newer than XP was a prove that it works fine already. - The user's preference (if e.g. passing CFLAGS="-D_WIN32_WINNT=0x602" to configure) - The project's configure script. At least for the case of VLC, currently it doesn't IIRC set anything if it's already predefined e.g. in CFLAGS, but sets a higher version if the toolchain's default is lower than what the project itself strictly requires. If the toolchain's default is higher than the project required level, the version is not overridden to a lower version. I don't know the logic behind it, it looks buggy to me, but sounds like it would do what author meant... The alternative is to never rise it to anything higher than VLC allows us. So at least VLC would need some amount of tweaks to cope with the toolchain defaulting to a higher version, or require everyone building it to override the desired target version in CFLAGS. Yes, unfortunately it may need some adaptation. I think that wrong assumptions are spread around the ecosystem because the value was so conservative archaic for years. But yeah, in practice this only affects projects that have optional codepaths that can use newer features - except for the cases with e.g. psapi.h. I think that the change reflects expectations of majority of users. I'm not entierely sure I agree with this - I think different ecosystems have different expectations here.(It'd be interesting to e.g. rebuild all of msys2's mingw package repository with such headers, and see how many of them fail to run on the previous minimum version.) Yes, it would be interesting. If users still want headers to not provide Win10-only declarations, they may just set _WIN32_WINNT explicitly in build system to the exact version they want. If packagers prefer it the old way, they can use the configure stitch for that. Yeah, it's good that we're able to override the default - I think I'd still keep doing that. But I think there's at least some amount of projects (mingw centric projects primarily, as the default in MSVC is different) that ex
[Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
Signed-off-by: Jacek Caban --- I think it's reasonable to assume that the current default value of Windows XP does not reflect reality. The new value deserves some considerations. I propose to go all the way to Windows 10 and match Windows SDK. The main concern about this is compatibility. This value is commonly mistaken with 'minimum version supported in runtime', which is simply not the case. It's only a version that headers will provide declarations for. As long as the application does not use new APIs, its compatibility with older Windows will not change. I think that the change reflects expectations of majority of users. If users still want headers to not provide Win10-only declarations, they may just set _WIN32_WINNT explicitly in build system to the exact version they want. If packagers prefer it the old way, they can use the configure stitch for that. mingw-w64-headers/configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac index ca044a88..b0865e47 100644 --- a/mingw-w64-headers/configure.ac +++ b/mingw-w64-headers/configure.ac @@ -134,9 +134,9 @@ AC_SUBST([IDLHEAD_LIST]) AC_MSG_CHECKING([default _WIN32_WINNT version]) AC_ARG_WITH([default-win32-winnt], [AS_HELP_STRING([--with-default-win32-winnt=VER], -[Default value of _WIN32_WINNT (default: 0x502)])], +[Default value of _WIN32_WINNT (default: 0xa00)])], [], - [with_default_win32_winnt=0x502]) + [with_default_win32_winnt=0xa00]) AC_MSG_RESULT([$with_default_win32_winnt]) AS_VAR_SET([DEFAULT_WIN32_WINNT],[$with_default_win32_winnt]) AC_SUBST([DEFAULT_WIN32_WINNT]) ___ 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] widl: Patch imported wine headers to fix compilation with gcc for aarch64
Hi Martin,
On 20.12.2020 10:14, Martin Storsjö wrote:
diff --git a/mingw-w64-tools/widl/include/windef.h
b/mingw-w64-tools/widl/include/windef.h
index b8e5ed692..a7dd5ce6a 100644
--- a/mingw-w64-tools/widl/include/windef.h
+++ b/mingw-w64-tools/widl/include/windef.h
@@ -74,7 +74,7 @@ extern "C" {
# endif
# elif defined(__arm__) && defined (__GNUC__) && !defined(__SOFTFP__)
# define __stdcall __attribute__((pcs("aapcs-vfp")))
-# elif defined(__aarch64__) && defined (__GNUC__)
+# elif defined(__aarch64__) && defined (__GNUC__) && defined(__clang__)
How about making it more generic with __has_attribute? I think something
like that could go to Wine.
Thanks,
Jacek
___
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] headers: Import mfreadwrite.idl from Wine.
Hi Biswapriyo, Looks good, I pushed it. Thanks, Jacek ___ 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] include/intrin: Implement `_rot{l, r}{8, 16}` functions
On 13.12.2020 12:53, Liu Hao wrote: They are declared in 'intrin.h' but were not defined anywhere. The implementations might be imperfect: If the second argument is <= zero or is >= the width of the first parameter, one of the shift counts will be out of range and cause undefined behavior. Some bitwise arithmetic may be involved to prevent this (like in 'ia32intrin.h' from GCC 8), which is unfortunately not recognized by GCC 7 and earlier versions as bitwise rotation and results in rather complex code. Reference: https://docs.microsoft.com/en-us/cpp/intrinsics/rotl8-rotl16?view=msvc-160 Reference: https://github.com/msys2/MINGW-packages/issues/7437 Signed-off-by: Liu Hao --- The patch looks good to me. Thanks, Jacek ___ 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] headers: don't mark enums with [v1_enum] if they are not used in IDLs
Hi Steve, I pushed those patches and widl update. All IDLs can be successfully regenerated now, thanks! Jacek ___ 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 2/2] headers: put the [v1_enum] in bdatypes.h on one line
Hi Steve,
On 15.12.2020 16:33, Steve Lhomme wrote:
Otherwise it results in a compilation error with widl 6.0-rc1:
include/bdatypes.h:43: error: 'PBDA_EVENT_ID': [v1_enum] attribute applied
to non-enum type
The code generated without this [v1_enum] is the same but we can keep this
information.
---
mingw-w64-headers/include/bdatypes.h | 133 +++
1 file changed, 76 insertions(+), 57 deletions(-)
diff --git a/mingw-w64-headers/include/bdatypes.h
b/mingw-w64-headers/include/bdatypes.h
index 92f9a14eb..e3cabf2d9 100644
--- a/mingw-w64-headers/include/bdatypes.h
+++ b/mingw-w64-headers/include/bdatypes.h
@@ -55,11 +55,12 @@ typedef enum BDA_CHANGE_STATE {
BDA_CHANGES_PENDING
} BDA_CHANGE_STATE, *PBDA_CHANGE_STATE;
-typedef
#ifdef __WIDL__
- [v1_enum]
+typedef [v1_enum] enum MEDIA_SAMPLE_CONTENT
+#else
+typedef enum MEDIA_SAMPLE_CONTENT
#endif
- enum MEDIA_SAMPLE_CONTENT {
+{
MEDIA_TRANSPORT_PACKET,
MEDIA_ELEMENTARY_STREAM,
MEDIA_MPEG2_PSI,
Windows SDK uses ENUM macro that expands to [v1_enum] enum on midl. We
could do the same to avoid #ifdefs around each struct.
Jacek
___
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 05/13] headers: remove proxys generated by widl
On 15.12.2020 08:26, Steve Lhomme wrote: On 2020-12-14 22:10, Jacek Caban wrote: On 14.12.2020 09:30, Steve Lhomme wrote: widl 6.0-rc1 doesn't generate them. The IUnknown_QueryInterface_Proxy() is already hardcoded in unknwnbase.idl. Some methods still generate a proxy entry using "call_as" in the IDL file. --- mingw-w64-headers/include/bdaiface.h | 1865 --- mingw-w64-headers/include/objidl.h | 2567 +-- mingw-w64-headers/include/tuner.h | 2749 - mingw-w64-headers/include/unknwn.h | 67 - .../include/windows.foundation.h | 97 - .../include/windows.security.cryptography.h | 104 - mingw-w64-headers/include/windows.storage.h | 434 --- .../include/windows.storage.streams.h | 35 - .../include/windows.system.threading.h | 125 - 9 files changed, 8 insertions(+), 8035 deletions(-) Please avoid manual edits like this. This will be done by regenerating relevant headers when they are ready. What manual edits ? As the commit log suggests, all this is generated. Yes, but then you manually split it committed only parts of it. Ideally, generated files should only be modified by regenerating and commiting entire file at the time to avoid intermediate states that are not possible to regenerate (well, ideally we would always generate them during build and not store generated files in the tree, but I don't think it would meet compatibility requirements in this case). Anyway, it's not a big deal in this case and those files are already not possible to regenerate those files and I guess it will make further work on them easier, so I pushed this patch. Thanks, Jacek ___ 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 01/13] headers: do not typedef FARPROC function when running widl
Hi Steve,
On 14.12.2020 09:30, Steve Lhomme wrote:
widl 6.0-rc1 reports the following error:
include/wincrypt.idl:17: error: calling convention applied to non-function
type
FARPROC is not used in any IDL file anyway.
---
mingw-w64-headers/include/wincrypt.idl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mingw-w64-headers/include/wincrypt.idl
b/mingw-w64-headers/include/wincrypt.idl
index 8dcf920e..5b372268 100644
--- a/mingw-w64-headers/include/wincrypt.idl
+++ b/mingw-w64-headers/include/wincrypt.idl
@@ -13,9 +13,11 @@ cpp_quote("#include ")
cpp_quote("#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)")
+#ifndef __WIDL__
#ifndef FARPROC
typedef int (__stdcall FARPROC) ();
#endif
+#endif
Technically, this should also be fixed in widl, but I pushed it together
with regeneration of dependent headers.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 2/2] makefile: Don't try to generate headers from IDLs that are not meant to be generated.
Signed-off-by: Jacek Caban --- mingw-w64-headers/Makefile.am | 4 1 file changed, 4 insertions(+) diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am index 68021a99..c7646998 100644 --- a/mingw-w64-headers/Makefile.am +++ b/mingw-w64-headers/Makefile.am @@ -274,6 +274,10 @@ BUILT_SOURCES = $(IDL_SRCS:.idl=.h) $(TLB_SRCS:.idl=.tlb) %_i.c: %.idl crt/_mingw.h $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -Icrt -I$(srcdir)/crt -u -o $@ $< +# following headers are not meant to be generated from IDLs, so override default rule +include/prsht.h: ; +include/wincrypt.h: ; + endif _mingw_ddk.h: $(srcdir)/crt/sdks/_mingw_ddk.h.in ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 1/2] makefiles: Add a rule to generate _i.c files.
Signed-off-by: Jacek Caban --- So that msinkaut_i.c is regenerated. mingw-w64-headers/Makefile.am | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am index 0b3aed0f..68021a99 100644 --- a/mingw-w64-headers/Makefile.am +++ b/mingw-w64-headers/Makefile.am @@ -265,12 +265,15 @@ TLB_SRCS = \ BUILT_SOURCES = $(IDL_SRCS:.idl=.h) $(TLB_SRCS:.idl=.tlb) -.idl.h: crt/_mingw.h +%.h: %.idl crt/_mingw.h $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -Icrt -I$(srcdir)/crt -h -o $@ $< -.idl.tlb: +%.tlb: %.idl $(WIDL) -I$(srcdir)/include -t -o $@ $< +%_i.c: %.idl crt/_mingw.h + $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -Icrt -I$(srcdir)/crt -u -o $@ $< + endif _mingw_ddk.h: $(srcdir)/crt/sdks/_mingw_ddk.h.in ___ 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 13/13] headers: fix IAsyncAction definition in windows.foundation
Hi Steve, I extracted winrt part from the series and pushed it. Thanks! Jacek ___ 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 05/13] headers: remove proxys generated by widl
On 14.12.2020 09:30, Steve Lhomme wrote: widl 6.0-rc1 doesn't generate them. The IUnknown_QueryInterface_Proxy() is already hardcoded in unknwnbase.idl. Some methods still generate a proxy entry using "call_as" in the IDL file. --- mingw-w64-headers/include/bdaiface.h | 1865 --- mingw-w64-headers/include/objidl.h| 2567 +-- mingw-w64-headers/include/tuner.h | 2749 - mingw-w64-headers/include/unknwn.h| 67 - .../include/windows.foundation.h | 97 - .../include/windows.security.cryptography.h | 104 - mingw-w64-headers/include/windows.storage.h | 434 --- .../include/windows.storage.streams.h | 35 - .../include/windows.system.threading.h| 125 - 9 files changed, 8 insertions(+), 8035 deletions(-) Please avoid manual edits like this. This will be done by regenerating relevant headers when they are ready. Jacek ___ 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 04/13] headers: remove widl [v1_enum] in bdatypes.h
On 14.12.2020 09:30, Steve Lhomme wrote: It results in a compilation error with widl 6.0-rc1: include/bdatypes.h:43: error: 'PBDA_EVENT_ID': [v1_enum] attribute applied to non-enum type It looks like a widl bug, [v1_enum] should be there, as far as I can see. Jacek ___ 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 02/13] headers: add some guards for library defined in IDL files
Hi Steve, Please rebase the series. Patch 2 and 3 should be fixed in git since yesterday. Jacek ___ 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 01/14] update windows.security.cryptography.h
On 11.12.2020 12:42, Steve Lhomme wrote: On 2020-12-11 1:02, Jacek Caban wrote: Hi Steve, Hi Jacek, It's great to see work on getting those IDLs to be in a form that we can regenerate them again. Thanks! Yes. For now I call widl manually because it seems that many of the IDLs currently don't build. Should we fix those as well ? Apart from the winrt ones they don't use a namespace so should produce more of less the same thing as before. Ideally, yes. Some of those require fixes on widl side. There is recently an active (well, except for Wine code freeze) work on Wine side to improve support for winrt widl mode by Rémi Bernon. Great news. Hopefully widl will be able to properly support all those new constructs. I recently updated widl in mingw-w64 repo to a more recent upstream version and it already generates those headers differently. I think this patch will not work with enum handling changes. I'll have a look. I also noticed the wine code has even more changes. But IMO the IDLs and the headers in the mingw64 tree should match the widl in the same tree, IMO. That's why updating widl should also be paired with running the IDLs through it again. And why it's important the current tree already builds properly. I agree and that's how it was meant to be. The history did not go the way I liked and a number of commits conflicting with upstream was committed to mingw-w64, making the whole automation unreliable and preventing widl syncs for quite a while. Resynchronizing those things would be great. I'm currently doing that to IDLs imported from Wine when I update them. For non-imported IDLs, I occasionally go through them (I just pushed such an update), but it needs a lot of manual skipping for things that don't re-generate correctly. I would be happy to do that to all IDLs on each widl update once we solve those problems. Also, I'm not convinced that we want more new interfaces that require hacking around widl shortcomings. It would be great to have those fixed in widl instead. I'd say we should get changes that allow us to regenerate existing declarations with the new widl, but coordinate with widl on new additions. After having to hack my way through the IDLs files I agree. Alhough it seems there are some lexer in widl that I may not be capabale to update. But that would definitely be a good goal. On the other hand, widl seems to be mostly a wine thing and there is no IDL with namespaces, events, templates, etc. Would changes that have no use in wine be accepted anyway ? widl is meant to be midl replacement, so all those futures are welcome. It lives in Wine tree and has a few Wine-specific features, but it's meant to be a generic IDL compiler. It also already contains a number of commits that were really motivated by mingw-w64, not Wine needs. One thing that should be easy to support is eventadd/eventremove support. It's just adding a prefix like propget/propput. Templates are trickier because each variant has its own UUID which is not defined in the MS doc nor in their IDL files. Luckily just by implementing them it's possible to get the proper UUID when the code requests it in QueryInterface(). That means each variant needs to be explictely declared and given its UUID. The generated names in MS headers are quite different as well as they include the number of elements in the template and the full namespace for each element in the template. Proper templating in widl should produce similar code so code compiling with MSVC can also compile with mingw64. I will have a look at that but make no promise. See Rémi's patches, they implement all mentioned features: https://github.com/wine-staging/wine-staging/tree/master/patches/widl-winrt-support What about this particular patch that changes the generated code, making previous code that compiled with mingw64 unusable. It's my understanding that this file (and pretty much all the winrt) was added for VLC so maybe noone else is using it ? The code was not compatible with MSVC headers but after this patch it should be. I think that we want to get them right at the cost of compatibility with current headers. Thanks, Jacek ___ 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 01/14] update windows.security.cryptography.h
Hi Steve, It's great to see work on getting those IDLs to be in a form that we can regenerate them again. Thanks! There is recently an active (well, except for Wine code freeze) work on Wine side to improve support for winrt widl mode by Rémi Bernon. Hopefully widl will be able to properly support all those new constructs. I recently updated widl in mingw-w64 repo to a more recent upstream version and it already generates those headers differently. I think this patch will not work with enum handling changes. Also, I'm not convinced that we want more new interfaces that require hacking around widl shortcomings. It would be great to have those fixed in widl instead. I'd say we should get changes that allow us to regenerate existing declarations with the new widl, but coordinate with widl on new additions. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] d2d1_1.h : plenty of C API missing
On 04/11/2020 10:31, Biswapriyo Nath wrote: I would like to avoid the manual editing of d2d1 header files. I tried to import d2d1.idl and d2d1_1.idl from wine. widl produces the corresponding headers file without any errors. But while compiling crt, it conflicts with `namespace D2D1` in d2d1helper.h as it is in C++ realm. One thing can be done but I am not sure about it: 0. Sync mingw-w64's d2d1_1.h with wine's d2d1_1.idl. 1. Import d2d1.idl and d2d1_1.idl from wine. 2. Generate header for d2d1_1.idl but NOT for d2d1.h. 3. Fix necessary changes in mingw-w64's d2d1.h manually. There are multiple problems with C++ constructs used in d2d1.h that are not possible in IDL files and we'd need solutions to those first. I'm not convinced if it's the right thing to do for that particular header. For the time being, I'd suggest to extend the existing header. Jacek ___ 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] dcomp.h: Work around C++ ABI differences.
Hi, Looks good to me, I pushed your version. Thanks for reviews and upgrading. Jacek On 14/10/2020 10:00, Pierre Lamot wrote: Hi, Thanks for your patch, though it looks incomplete as many other class have the same issue. I took liberty to upgrade your patch accordingly (see enclosed) PS: I removed the sign-off as I altered the patch On 2020-10-13 20:57, Jacek Caban wrote: Signed-off-by: Jacek Caban --- This patch should fix the problem discussed in the other thread. It also came out recently in Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1667423 mingw-w64-headers/include/dcomp.h | 14 ++ 1 file changed, 14 insertions(+) ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] dcomp.h: Work around C++ ABI differences.
Signed-off-by: Jacek Caban
---
This patch should fix the problem discussed in the other thread. It also
came out recently in Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1667423
mingw-w64-headers/include/dcomp.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/mingw-w64-headers/include/dcomp.h b/mingw-w64-headers/include/dcomp.h
index ec237168..4b63bd23 100644
--- a/mingw-w64-headers/include/dcomp.h
+++ b/mingw-w64-headers/include/dcomp.h
@@ -223,18 +223,32 @@ DECLARE_INTERFACE_IID_(IDCompositionRectangleClip,IDCompositionClip,"9842ad7d-d9
#define INTERFACE IDCompositionVisual
DECLARE_INTERFACE_IID_(IDCompositionVisual,IUnknown,"4d93059d-097b-4651-9a60-f0f25116e2f3")
{
+#if defined(_MSC_VER) && defined(__cplusplus)
STDMETHOD(SetOffsetX)(THIS_ float) PURE;
STDMETHOD(SetOffsetX)(THIS_ IDCompositionAnimation*) PURE;
STDMETHOD(SetOffsetY)(THIS_ float) PURE;
STDMETHOD(SetOffsetY)(THIS_ IDCompositionAnimation*) PURE;
STDMETHOD(SetTransform)(THIS_ const D2D_MATRIX_3X2_F&) PURE;
STDMETHOD(SetTransform)(THIS_ IDCompositionTransform*) PURE;
+#else
+STDMETHOD(SetOffsetX)(THIS_ IDCompositionAnimation*) PURE;
+STDMETHOD(SetOffsetX)(THIS_ float) PURE;
+STDMETHOD(SetOffsetY)(THIS_ IDCompositionAnimation*) PURE;
+STDMETHOD(SetOffsetY)(THIS_ float) PURE;
+STDMETHOD(SetTransform)(THIS_ IDCompositionTransform*) PURE;
+STDMETHOD(SetTransform)(THIS_ const D2D_MATRIX_3X2_F&) PURE;
+#endif
STDMETHOD(SetTransformParent)(THIS_ IDCompositionVisual*) PURE;
STDMETHOD(SetEffect)(THIS_ IDCompositionEffect*) PURE;
STDMETHOD(SetBitmapInterpolationMode)(THIS_ DCOMPOSITION_BITMAP_INTERPOLATION_MODE) PURE;
STDMETHOD(SetBorderMode)(THIS_ DCOMPOSITION_BORDER_MODE) PURE;
+#if defined(_MSC_VER) && defined(__cplusplus)
STDMETHOD(SetClip)(THIS_ const D2D_RECT_F&) PURE;
STDMETHOD(SetClip)(THIS_ IDCompositionClip*) PURE;
+#else
+STDMETHOD(SetClip)(THIS_ IDCompositionClip*) PURE;
+STDMETHOD(SetClip)(THIS_ const D2D_RECT_F&) PURE;
+#endif
STDMETHOD(SetContent)(THIS_ IUnknown*) PURE;
STDMETHOD(AddVisual)(THIS_ IDCompositionVisual*,BOOL,IDCompositionVisual*) PURE;
STDMETHOD(RemoveVisual)(THIS_ IDCompositionVisual*) PURE;
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] dwrite_3.h regression fix
Hi, I sent this as a patch earlier, but it got stuck on moderation due to the size. Please review commit: https://github.com/cjacek/mingw-w64/commit/c073fb0c62a785cc5524e660568e85a89de2c0d5 This is suboptimal, but a better solution is unclear and I think that we should deal with the regression without waiting. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] missing d3d11on12.h file
On 23.09.2020 11:32, Biswapriyo Nath wrote: If you don't need ID3D11On12Device1 and ID3D11On12Device2 interfaces that d3d11on12.idl file could be imported from wine as is. /cc. Jacek C. Sure, I pushed import as 50bcd814eab58db7cb3e2238c6a2e6ba5e1fb400. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Trouble with new dwrite underscore notation
On 20/09/2020 14:02, Liu Hao wrote: 在 2020/9/20 19:45, Jean Pierre Cimalando 写道: Le Sun, 20 Sep 2020 19:18:51 +0800, Liu Hao a écrit : It is now imported from Wine. Perhaps it's a necessary trade-off, because not having a suffix would cause errors in C. The header has distinct interfaces for C and C++. It's understandable that C requires to use unique names, however will it be detrimental to modify code generation such that C++-only parts would conform to the original naming? I presume it is possible; even a naive `#if...#else...#endif` could resolve the issue. I would like to hear from Jacek first. #if is problematic, because it would need to be in cpp_quote() and we can't have those local to methods, so entire interfaces would need to be duplicated in cpp_quote()s. I think that we will need a widl extension. Maybe something like cpp_override attribute, which would look like: [cpp_override(GetPropertyValues)] HRESULT GetPropertyValues_( /*... */); and use the name provided by the attribute in C++ declaration. Jacek ___ 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: dwrite update
On 07.09.2020 04:10, Liu Hao wrote: [Please include the list when replying, for example, by clicking 'reply to all' or 'reply to list' instead of 'reply'.] 在 2020/9/6 上午7:25, Jean Pierre Cimalando 写道: Le Sat, 5 Sep 2020 22:47:19 +0800, Liu Hao a écrit : +DWRITE_FONT_PROPERTY_ID_TOTAL, +DWRITE_FONT_PROPERTY_ID_TOTAL_RS3, +DWRITE_FONT_PROPERTY_ID_PREFERRED_FAMILY_NAME, +DWRITE_FONT_PROPERTY_ID_FAMILY_NAME, +DWRITE_FONT_PROPERTY_ID_FACE_NAME These enumerators seem to have wrong values due to lack of initializers. Good remark. I remade the patch, after rechecking the enums. I take notice of Biswapriyo's remark on generating from IDL; unless I'm mistaken, there is not yet a tool which generates these definitions? (using the STDMETHOD format) This would simplify the work considerably. It looks like that neither of DWrite headers were imported for Wine. There must be a reason. Jacek might have some comments on it. They were not imported mostly because Biswapriyo's patch was incomplete. I fixed it, tested and pushed. Please give it a try. Thanks, Jacek ___ 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/stdio/fseeko64: Remove the now superfluous `mingw_dosmaperr()`
On 22.07.2020 16:28, Liu Hao wrote: It's neither called in this file nor declared or referenced elsewhere. Signed-off-by: Liu Hao Both patches look good to me. Thanks, Jacek ___ 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/stdio/fseeki64: Reimplement using `f{tell, seek}o`
On 21.07.2020 19:05, Liu Hao wrote: 在 2020/7/22 0:13, Jacek Caban 写道: Oh, right. The problem with fsetpos is that the way fseeko is implemented is not thread safe, but maybe it's not too bad. fseeko64 is not really long (the file looks more complicated than it is because of an unused mingw_dosmaperr function there...) maybe we could just duplicate that code for fseeko. So you suggest copying and pasting? That certainly would cause duplication. Yes, but I don't think it would be much. Note that if you strip fseeko64.c from unused declarations and function, there will be not much left. Is there any equivalent of `mingw_dosmaperr()` somewhere that is available publicly? I hope we need not duplicate everything. It's not used anywhere, we probably can just remote it. Jacek ___ 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/stdio/fseeki64: Reimplement using `f{tell, seek}o`
On 21.07.2020 17:19, Liu Hao wrote: 在 2020/7/21 23:07, Jacek Caban 写道: Sorry for joining the discussion late. How about implementing them directly on top of msvcrt functions? Would something like: return _telli64(_fileno(stream)); be enough for _ftelli64? Similarly: return _lseeki64(_fileno(stream), offset, origin); for fseeki64? `FILE` objects provide their own buffering, so calling `_telli64()` without flushing internal buffers might lead to incorrect results. `fseeko64()` calls `fsetpos()` in reality. Oh, right. The problem with fsetpos is that the way fseeko is implemented is not thread safe, but maybe it's not too bad. fseeko64 is not really long (the file looks more complicated than it is because of an unused mingw_dosmaperr function there...) maybe we could just duplicate that code for fseeko. Thanks, Jacek ___ 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/stdio/fseeki64: Reimplement using `f{tell, seek}o`
On 17.07.2020 21:41, Martin Storsjö wrote: On Fri, 17 Jul 2020, Liu Hao wrote: 在 2020/7/17 22:28, Martin Storsjö 写道: Sorry for the late reply, I started looking at this earlier but got sidetracked back then. In this case, _fseeki64 is a function in libmsvcrt-os.a while fseeko64 is in libmingwex.a - does that cause problematic dependencies, or did we already have such dependencies? Other than that, the change looks good, I believe - any other issues can probably only be found by taking the change into use and seeing if something breaks somewhere. Probably it is libmingwex that should depend on libmsvcrt-os, not the other way around. So here come two solutions: 0) Move `ftello.c` and `ftello64.c` into libmsvcrt-os. Not sure if that's really ideal - as we need them somewhere for the other CRTs (either in mingwex or in the other CRTs). 1) In addition to 0), rename the functions to `_fseeki()` and `_fseeki64()`, then make `fseeko()` and `fseeko64()` in libmingwex call the `_fseeki` variants instead. I think that might be the better option, but I'd like to hear Jacek's opinion before proceeding. Sorry for joining the discussion late. How about implementing them directly on top of msvcrt functions? Would something like: return _telli64(_fileno(stream)); be enough for _ftelli64? Similarly: return _lseeki64(_fileno(stream), offset, origin); for fseeki64? Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] winnt.h: Add missing STATUS_HEAP_CORRUPTION define.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/include/winnt.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-headers/include/winnt.h b/mingw-w64-headers/include/winnt.h
index c47dc7fd..13ba6c42 100644
--- a/mingw-w64-headers/include/winnt.h
+++ b/mingw-w64-headers/include/winnt.h
@@ -1369,6 +1369,7 @@ inline ENUMTYPE ^= (ENUMTYPE , ENUMTYPE b) { return (ENUMTYPE &)(((i
#define STATUS_FLOAT_MULTIPLE_FAULTS ((DWORD)0xC2B4)
#define STATUS_FLOAT_MULTIPLE_TRAPS ((DWORD)0xC2B5)
#define STATUS_REG_NAT_CONSUMPTION ((DWORD)0xC2C9)
+#define STATUS_HEAP_CORRUPTION ((DWORD)0xC374)
#define STATUS_STACK_BUFFER_OVERRUN ((DWORD)0xC409)
#define STATUS_INVALID_CRUNTIME_PARAMETER ((DWORD)0xC417)
#define STATUS_ASSERTION_FAILURE ((DWORD)0xC420)
___
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] widl: Update the relocatability patch to remove an unused variable
On 12.06.2020 15:07, Jacek Caban wrote: FWIW, my plan is to change the code in Wine to make mingw-w64 redundant, so whatever we do now will be temporary. I meant 'mingw-w64 *patch* redundant' ;-) We should be able to import the widl source code from Wine to mingw-w64 without modification. Jacek ___ 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] widl: Update the relocatability patch to remove an unused variable
On 12.06.2020 14:38, Biswapriyo Nath wrote: Question. The removal of `int i` declaration may be added with wine-import.sh shell script by mistake. In wine, the int i variable is used in for loop. IMHO, how about editing the wine/widl code? * Now: for (i = 0; i < ARRAY_SIZE(incl_dirs); i++) * Edited: for (int i = 0; i < ARRAY_SIZE(incl_dirs); i++) The "Now" version seems to be coding style for wine. Yours opinion? Variable declaration inside for statement is less portable. FWIW, my plan is to change the code in Wine to make mingw-w64 redundant, so whatever we do now will be temporary. My main problem is that I don't really know how exactly people use it on Windows, so I have limited trust for my testing. I did a change that was prerequisite for that and planned to wait a bit to see if there are complains before patching Wine with further changes. If you'd like to look at that yourself, see init_argv0_dir. We'd need to implement that for Windows case. Once we have that, we can #ifdef __WINESRC__ Wine-specific part of main (the part that's currently patched) and have another version that would be compatible with mingw-w64 directory layout. Once we have that in Wine tree, relocation patch will no longer be needed. Jacek ___ 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] widl: Update the relocatability patch to remove an unused variable
Hi Martin, Both patches look good to me. Thanks, Jacek ___ 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 v2] crt: Add a UCRT import library suitable for UWP use
Hi Martin, The idea of a separated crt library for UWP seems reasonable to be. It could also potentially help with some other UWP compatibility problems. Having to implement a number of string functions is not really optimal, but it looks like we need it. Long term, as we discussed lately, we may have a possibility to use Wine for that. Once Wine has proper msvcrt implementation in a PE file, it should be possible to extract that and provide a static msvcrt/ucrt library. Anyway, I'm fine with the patch. Thanks, Jacek On 05.06.2020 14:59, Martin Storsjö wrote: This adds libucrtapp.a, which is the same as libucrt.a, but excluding libapi-ms-win-crt-private-l1-1-0.a, and with a few statically linked functions added that otherwise normally are linked from libapi-ms-win-crt-private-l1-1-0.a. Linking against the private dll (and ucrtbase.dll) is prohibited when targeting UWP. An app built and packaged with MSVC would link against these functions from vcruntime140_app.dll, which ends up bundled with the app itself. However, the goal of this patch is to make it possible to build a UWP app with mingw tools and redistribute it without bundling vcruntime140_app.dll or similar ones from MSVC. By using a separate copy of libucrt*.a, without the forbidden bits, it gives a clear linker error if an app requires linking against other functions that aren't implemented yet, instead of silently ending up depending on the forbidden api-ms-win-crt-private-l1-1-0.dll. The functions from this DLL, that end up linked in a mingw build, are primarily one of the these four areas: - __C_specific_handler The implementation so far is a dummy; wine should have a suitable proper implementation for reference. This shouldn't matter much, except potentially for turning unhandled exceptions into signals (but that might also be handled via a different mechanism). - setjmp/longjmp The implementation should be ok, but doesn't do a SEH unwind (yet) but just a plain longjmp. A full implementation should be doable, but is not really needed for mingw code. - string functions: memcpy and memmove Added minimal wrappers that just call memcpy_s and memmove_s from api-ms-win-crt-string-l1-1-0.dll, as that one should have implementations with good performance. - string functions: memchr, memcmp, strchr, strrchr, strstr, wcschr, wcsrchr, wcsstr These are copied from musl (with minor modifications to make them compile in mingw-w64, and with an added copyright header). By naming the library libucrtapp.a, clang users can choose to link against this by passing -lucrtapp (which makes clang omit the default -lmsvcrt, which would be equal to libucrt.a in such a case). Signed-off-by: Martin Storsjö --- mingw-w64-crt/Makefile.am| 53 ++- mingw-w64-crt/crt/__C_specific_handler.c | 34 + mingw-w64-crt/lib-common/ucrtapp.mri | 19 +++ mingw-w64-crt/misc/longjmp.S | 97 + mingw-w64-crt/misc/setjmp.S | 115 +++ mingw-w64-crt/string/memchr.c| 50 +++ mingw-w64-crt/string/memcmp.c| 31 mingw-w64-crt/string/memcpy.c| 12 ++ mingw-w64-crt/string/memmove.c | 12 ++ mingw-w64-crt/string/memrchr.c | 34 + mingw-w64-crt/string/strchr.c| 32 mingw-w64-crt/string/strchrnul.c | 51 +++ mingw-w64-crt/string/strrchr.c | 31 mingw-w64-crt/string/strstr.c| 177 +++ mingw-w64-crt/string/wcschr.c| 31 mingw-w64-crt/string/wcsrchr.c | 31 mingw-w64-crt/string/wcsstr.c| 128 17 files changed, 930 insertions(+), 8 deletions(-) create mode 100644 mingw-w64-crt/crt/__C_specific_handler.c create mode 100644 mingw-w64-crt/lib-common/ucrtapp.mri create mode 100644 mingw-w64-crt/misc/longjmp.S create mode 100644 mingw-w64-crt/misc/setjmp.S create mode 100644 mingw-w64-crt/string/memchr.c create mode 100644 mingw-w64-crt/string/memcmp.c create mode 100644 mingw-w64-crt/string/memcpy.c create mode 100644 mingw-w64-crt/string/memmove.c create mode 100644 mingw-w64-crt/string/memrchr.c create mode 100644 mingw-w64-crt/string/strchr.c create mode 100644 mingw-w64-crt/string/strchrnul.c create mode 100644 mingw-w64-crt/string/strrchr.c create mode 100644 mingw-w64-crt/string/strstr.c create mode 100644 mingw-w64-crt/string/wcschr.c create mode 100644 mingw-w64-crt/string/wcsrchr.c create mode 100644 mingw-w64-crt/string/wcsstr.c diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index c30e22cce..b104da3a1 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -241,6 +241,23 @@ src_ucrtbase=\ stdio/ucrt_vsnprintf.c \ stdio/ucrt_vsprintf.c +src_ucrtapp=\ + crt/__C_specific_handler.c \ + misc/longjmp.S \ + misc/setjmp.S \ + string/memchr.c \ +
[Mingw-w64-public] [PATCH 2/2] headers: Use corecrt_stdio_config.h instead of local UCRTBASE_* defines.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/crt/conio.h | 37 +++--
mingw-w64-headers/crt/sec_api/stdio_s.h | 26 -
mingw-w64-headers/crt/sec_api/wchar_s.h | 12 ++--
mingw-w64-headers/crt/stdio.h | 59 ++--
mingw-w64-headers/crt/wchar.h | 74 +
5 files changed, 70 insertions(+), 138 deletions(-)
diff --git a/mingw-w64-headers/crt/conio.h b/mingw-w64-headers/crt/conio.h
index ff582c2b..b28a71c2 100644
--- a/mingw-w64-headers/crt/conio.h
+++ b/mingw-w64-headers/crt/conio.h
@@ -7,32 +7,9 @@
#define _INC_CONIO
#include
+#include
#include
-#if !defined(_UCRTBASE_STDIO_DEFINED) && defined(_UCRT)
-#define _UCRTBASE_STDIO_DEFINED
-
-#define UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION (0x0001)
-#define UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR (0x0002)
-#define UCRTBASE_PRINTF_LEGACY_WIDE_SPECIFIERS (0x0004)
-#define UCRTBASE_PRINTF_LEGACY_MSVCRT_COMPATIBILITY (0x0008)
-#define UCRTBASE_PRINTF_LEGACY_THREE_DIGIT_EXPONENTS (0x0010)
-
-#define UCRTBASE_SCANF_SECURECRT (0x0001)
-#define UCRTBASE_SCANF_LEGACY_WIDE_SPECIFIERS(0x0002)
-#define UCRTBASE_SCANF_LEGACY_MSVCRT_COMPATIBILITY (0x0004)
-
-/* Default wide printfs and scanfs to the legacy wide mode. Only code built
- * with -D__USE_MINGW_ANSI_STDIO=1 will expect the standard behaviour. */
-#ifndef UCRTBASE_PRINTF_DEFAULT_WIDE
-#define UCRTBASE_PRINTF_DEFAULT_WIDE UCRTBASE_PRINTF_LEGACY_WIDE_SPECIFIERS
-#endif
-#ifndef UCRTBASE_SCANF_DEFAULT_WIDE
-#define UCRTBASE_SCANF_DEFAULT_WIDE UCRTBASE_SCANF_LEGACY_WIDE_SPECIFIERS
-#endif
-#endif
-
-
#ifdef __cplusplus
extern "C" {
#endif
@@ -171,7 +148,7 @@ extern "C" {
__mingw_ovr int __cdecl _vcwprintf(const wchar_t * __restrict__ _Format,va_list _ArgList)
{
-return __conio_common_vcwprintf(UCRTBASE_PRINTF_DEFAULT_WIDE, _Format, NULL, _ArgList);
+return __conio_common_vcwprintf(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS, _Format, NULL, _ArgList);
}
__mingw_ovr int __cdecl _cwprintf(const wchar_t * __restrict__ _Format,...)
{
@@ -187,7 +164,7 @@ extern "C" {
__builtin_va_list _ArgList;
int _Ret;
__builtin_va_start(_ArgList, _Format);
-_Ret = __conio_common_vcwscanf(UCRTBASE_SCANF_DEFAULT_WIDE, _Format, NULL, _ArgList);
+_Ret = __conio_common_vcwscanf(_CRT_INTERNAL_LOCAL_SCANF_OPTIONS, _Format, NULL, _ArgList);
__builtin_va_end(_ArgList);
return _Ret;
}
@@ -196,13 +173,13 @@ extern "C" {
__builtin_va_list _ArgList;
int _Ret;
__builtin_va_start(_ArgList, _Locale);
-_Ret = __conio_common_vcwscanf(UCRTBASE_SCANF_DEFAULT_WIDE, _Format, _Locale, _ArgList);
+_Ret = __conio_common_vcwscanf(_CRT_INTERNAL_LOCAL_SCANF_OPTIONS, _Format, _Locale, _ArgList);
__builtin_va_end(_ArgList);
return _Ret;
}
__mingw_ovr int __cdecl _vcwprintf_p(const wchar_t * __restrict__ _Format,va_list _ArgList)
{
-return __conio_common_vcwprintf_p(UCRTBASE_PRINTF_DEFAULT_WIDE, _Format, NULL, _ArgList);
+return __conio_common_vcwprintf_p(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS, _Format, NULL, _ArgList);
}
__mingw_ovr int __cdecl _cwprintf_p(const wchar_t * __restrict__ _Format,...)
{
@@ -215,7 +192,7 @@ extern "C" {
}
__mingw_ovr int __cdecl _vcwprintf_l(const wchar_t * __restrict__ _Format,_locale_t _Locale,va_list _ArgList)
{
-return __conio_common_vcwprintf(UCRTBASE_PRINTF_DEFAULT_WIDE, _Format, _Locale, _ArgList);
+return __conio_common_vcwprintf(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS, _Format, _Locale, _ArgList);
}
__mingw_ovr int __cdecl _cwprintf_l(const wchar_t * __restrict__ _Format,_locale_t _Locale,...)
{
@@ -228,7 +205,7 @@ extern "C" {
}
__mingw_ovr int __cdecl _vcwprintf_p_l(const wchar_t * __restrict__ _Format,_locale_t _Locale,va_list _ArgList)
{
-return __conio_common_vcwprintf_p(UCRTBASE_PRINTF_DEFAULT_WIDE, _Format, _Locale, _ArgList);
+return __conio_common_vcwprintf_p(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS, _Format, _Locale, _ArgList);
}
__mingw_ovr int __cdecl _cwprintf_p_l(const wchar_t * __restrict__ _Format,_locale_t _Locale,...)
{
diff --git a/mingw-w64-headers/crt/sec_api/stdio_s.h b/mingw-w64-headers/crt/sec_api/stdio_s.h
index fd21d3ad..c6350e8d 100644
--- a/mingw-w64-headers/crt/sec_api/stdio_s.h
+++ b/mingw-w64-headers/crt/sec_api/stdio_s.h
@@ -39,7 +39,7 @@ extern "C" {
__mingw_ovr int __cdecl _vfscanf_s_l(FILE *_File, const char *_Format, _locale_t _Locale, va_list _ArgList)
{
-return __stdio_common_vfscanf(UCRTBASE_SCANF_SECURECRT, _File, _Format, _Locale, _ArgList);
+return __stdio_common_vfscanf(_CRT_INTERNAL_SCANF_SECURECRT, _File, _Format, _Locale, _ArgList);
}
__mingw_ovr int __cdecl _fscanf_s_l(FILE *_File, const char *_Format, _locale_t _Locale, ...)
{
@@ -85,7 +85,7 @@ extern "C
[Mingw-w64-public] [PATCH 1/2] crt: Use corecrt_stdio_config.h instead of local UCRTBASE_* defines.
Signed-off-by: Jacek Caban
---
mingw-w64-crt/crt/ucrtbase_compat.c| 2 +-
mingw-w64-crt/stdio/ucrt__vscprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt__vsnprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt__vsnwprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt_snprintf.c| 2 +-
mingw-w64-crt/stdio/ucrt_sprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt_vsnprintf.c | 2 +-
mingw-w64-crt/stdio/ucrt_vsprintf.c| 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/mingw-w64-crt/crt/ucrtbase_compat.c b/mingw-w64-crt/crt/ucrtbase_compat.c
index fa6d922c..d04f5f23 100644
--- a/mingw-w64-crt/crt/ucrtbase_compat.c
+++ b/mingw-w64-crt/crt/ucrtbase_compat.c
@@ -143,7 +143,7 @@ int __cdecl __ms_fwprintf(FILE *file, const wchar_t *fmt, ...)
va_list ap;
int ret;
va_start(ap, fmt);
- ret = __stdio_common_vfwprintf(UCRTBASE_PRINTF_LEGACY_WIDE_SPECIFIERS, file, fmt, NULL, ap);
+ ret = __stdio_common_vfwprintf(_CRT_INTERNAL_PRINTF_LEGACY_WIDE_SPECIFIERS, file, fmt, NULL, ap);
va_end(ap);
return ret;
}
diff --git a/mingw-w64-crt/stdio/ucrt__vscprintf.c b/mingw-w64-crt/stdio/ucrt__vscprintf.c
index 0c2b34b9..c0c02ad6 100644
--- a/mingw-w64-crt/stdio/ucrt__vscprintf.c
+++ b/mingw-w64-crt/stdio/ucrt__vscprintf.c
@@ -10,6 +10,6 @@
int _vscprintf(const char * __restrict__ _Format, va_list _ArgList)
{
- return __stdio_common_vsprintf(UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR, NULL, 0, _Format, NULL, _ArgList);
+ return __stdio_common_vsprintf(_CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR, NULL, 0, _Format, NULL, _ArgList);
}
int __cdecl (*__MINGW_IMP_SYMBOL(_vscprintf))(const char *__restrict__, va_list) = _vscprintf;
diff --git a/mingw-w64-crt/stdio/ucrt__vsnprintf.c b/mingw-w64-crt/stdio/ucrt__vsnprintf.c
index 2f5889a2..a82fd7dd 100644
--- a/mingw-w64-crt/stdio/ucrt__vsnprintf.c
+++ b/mingw-w64-crt/stdio/ucrt__vsnprintf.c
@@ -10,6 +10,6 @@
int __cdecl _vsnprintf(char * __restrict__ _Dest,size_t _Count,const char * __restrict__ _Format,va_list _Args) __MINGW_ATTRIB_DEPRECATED_SEC_WARN
{
- return __stdio_common_vsprintf(UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION, _Dest, _Count, _Format, NULL, _Args);
+ return __stdio_common_vsprintf(_CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION, _Dest, _Count, _Format, NULL, _Args);
}
int __cdecl (*__MINGW_IMP_SYMBOL(_vsnprintf))(char *__restrict__, size_t, const char *__restrict__, va_list) = _vsnprintf;
diff --git a/mingw-w64-crt/stdio/ucrt__vsnwprintf.c b/mingw-w64-crt/stdio/ucrt__vsnwprintf.c
index c505c31e..7f88fee8 100644
--- a/mingw-w64-crt/stdio/ucrt__vsnwprintf.c
+++ b/mingw-w64-crt/stdio/ucrt__vsnwprintf.c
@@ -10,6 +10,6 @@
int __cdecl _vsnwprintf(wchar_t * __restrict__ _Dest,size_t _Count,const wchar_t * __restrict__ _Format,va_list _Args) __MINGW_ATTRIB_DEPRECATED_SEC_WARN
{
- return __stdio_common_vswprintf(UCRTBASE_PRINTF_DEFAULT_WIDE | UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION, _Dest, _Count, _Format, NULL, _Args);
+ return __stdio_common_vswprintf(_CRT_INTERNAL_LOCAL_PRINTF_OPTIONS | _CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION, _Dest, _Count, _Format, NULL, _Args);
}
int __cdecl (*__MINGW_IMP_SYMBOL(_vsnwprintf))(wchar_t *__restrict__, size_t, const wchar_t *__restrict__, va_list) = _vsnwprintf;
diff --git a/mingw-w64-crt/stdio/ucrt_snprintf.c b/mingw-w64-crt/stdio/ucrt_snprintf.c
index 6d6d1bb1..c8931393 100644
--- a/mingw-w64-crt/stdio/ucrt_snprintf.c
+++ b/mingw-w64-crt/stdio/ucrt_snprintf.c
@@ -13,7 +13,7 @@ int snprintf (char * __restrict__ __stream, size_t __n, const char * __restrict_
__builtin_va_list ap;
int ret;
__builtin_va_start(ap, __format);
- ret = __stdio_common_vsprintf(UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR, __stream, __n, __format, NULL, ap);
+ ret = __stdio_common_vsprintf(_CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR, __stream, __n, __format, NULL, ap);
__builtin_va_end(ap);
return ret;
}
diff --git a/mingw-w64-crt/stdio/ucrt_sprintf.c b/mingw-w64-crt/stdio/ucrt_sprintf.c
index 48304f5d..1c1f3173 100644
--- a/mingw-w64-crt/stdio/ucrt_sprintf.c
+++ b/mingw-w64-crt/stdio/ucrt_sprintf.c
@@ -13,7 +13,7 @@ int __cdecl sprintf(char * __restrict__ _Dest,const char * __restrict__ _Format,
__builtin_va_list ap;
int ret;
__builtin_va_start(ap, _Format);
- ret = __stdio_common_vsprintf(UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR, _Dest, (size_t)-1, _Format, NULL, ap);
+ ret = __stdio_common_vsprintf(_CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR, _Dest, (size_t)-1, _Format, NULL, ap);
__builtin_va_end(ap);
return ret;
}
diff --git a/mingw-w64-crt/stdio/ucrt_vsnprintf.c b/mingw-w64-crt/stdio/ucrt_vsnprintf.c
index 81d5678e..ad454806 100644
--- a/mingw-w64-crt/stdio/ucrt_vsnprintf.c
+++ b/mingw-w64-crt/stdio/ucrt_vsnprintf.c
@@ -10,6 +10,6 @@
int vsnprintf (char * __restrict__ __stream, size_t __n, const char * __restrict__ __format, va_list __local_argv)
{
- return __stdio_common_vsprintf(UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR
Re: [Mingw-w64-public] [PATCH 2/3] crt: Rename longjmp.S to mingw_longjmp.S
On 04.06.2020 20:28, Martin Storsjö wrote:
On Thu, 4 Jun 2020, Jacek Caban wrote:
On 04.06.2020 15:33, Jacek Caban wrote:
On 04.06.2020 08:32, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 2 +-
mingw-w64-crt/misc/{longjmp.S => mingw_longjmp.S} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename mingw-w64-crt/misc/{longjmp.S => mingw_longjmp.S} (100%)
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 5fd779baf..9a9384bf1 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -430,7 +430,7 @@ src_libmingwex=\
math/cephes_emath.h math/cephes_mconf.h math/fp_consts.h
math/abs64.c \
\
misc/mb_wc_common.h \
- misc/longjmp.S \
+ misc/mingw_longjmp.S \
misc/mingw_getsp.S \
misc/alarm.c \
misc/basename.c misc/btowc.c misc/delay-f.c
misc/delay-n.c \
diff --git a/mingw-w64-crt/misc/longjmp.S
b/mingw-w64-crt/misc/mingw_longjmp.S
similarity index 100%
rename from mingw-w64-crt/misc/longjmp.S
rename to mingw-w64-crt/misc/mingw_longjmp.S
Can we use msvcrt for that and get rid of the implementation? On
ucrt it would need a redirect it to __intrinsic_*. Wine does that in
headers:
https://source.winehq.org/git/wine.git/commitdiff/0413e2a523e96b70ea4e8ba598b61460b1500d75
but we could also do that in importlib.
I was thinking about setjmpex. longjmp should just be available.
So, this file only has implementations for arm32 and arm64. For arm64,
we generally already call msvcrt/ucrt's setjmp/longjmp (or more
precisely, __intrinsic_setjmpex), if the compiler uses SEH (it was
enabled by default in clang for the mingw target around a year ago).
If we're fine with dropping support for Clang < 9 for the arm64
target, we could get rid of the local implementation.
For arm32, the msvcrt/ucrt setjmp/longjmp don't really work properly
in all cases - I don't have the notes around in which ways it didn't
work properly, but I guess it'd require the compiler to emit SEH
unwind info (which clang doesn't for arm32).
I was hoping for something like 436ad4b83035937125 but for ARM, but I
found your explanation from year ago:
What actually happens if SEH information is unavailable varies quite a
bit. When testing on ARM and ARM64, the longjmp will crash if SEH is
unavailable, when _setjmpex is called with a non-null frame pointer. On
ARM, if the second parameter to _setjmpex is NULL though, the longjmp
does succeed, but on ARM64 this doesn't help, SEH information simply is
mandatory. (And for ARM64, the exact form of the frame pointer needed is
a bit more tricky; llvm had to add a new intrinsic function for getting
it.)
Sorry for bothering then, the patch looks good.
Thanks,
Jacek
___
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 2/3] crt: Rename longjmp.S to mingw_longjmp.S
On 04.06.2020 15:33, Jacek Caban wrote:
On 04.06.2020 08:32, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 2 +-
mingw-w64-crt/misc/{longjmp.S => mingw_longjmp.S} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename mingw-w64-crt/misc/{longjmp.S => mingw_longjmp.S} (100%)
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 5fd779baf..9a9384bf1 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -430,7 +430,7 @@ src_libmingwex=\
math/cephes_emath.h math/cephes_mconf.h math/fp_consts.h
math/abs64.c \
\
misc/mb_wc_common.h \
- misc/longjmp.S \
+ misc/mingw_longjmp.S \
misc/mingw_getsp.S \
misc/alarm.c \
misc/basename.c misc/btowc.c misc/delay-f.c
misc/delay-n.c \
diff --git a/mingw-w64-crt/misc/longjmp.S
b/mingw-w64-crt/misc/mingw_longjmp.S
similarity index 100%
rename from mingw-w64-crt/misc/longjmp.S
rename to mingw-w64-crt/misc/mingw_longjmp.S
Can we use msvcrt for that and get rid of the implementation? On ucrt
it would need a redirect it to __intrinsic_*. Wine does that in headers:
https://source.winehq.org/git/wine.git/commitdiff/0413e2a523e96b70ea4e8ba598b61460b1500d75
but we could also do that in importlib.
I was thinking about setjmpex. longjmp should just be available.
Jacek
___
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 2/3] crt: Rename longjmp.S to mingw_longjmp.S
On 04.06.2020 08:32, Martin Storsjö wrote:
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/Makefile.am | 2 +-
mingw-w64-crt/misc/{longjmp.S => mingw_longjmp.S} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename mingw-w64-crt/misc/{longjmp.S => mingw_longjmp.S} (100%)
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 5fd779baf..9a9384bf1 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -430,7 +430,7 @@ src_libmingwex=\
math/cephes_emath.h math/cephes_mconf.h math/fp_consts.h math/abs64.c
\
\
misc/mb_wc_common.h \
- misc/longjmp.S \
+ misc/mingw_longjmp.S \
misc/mingw_getsp.S \
misc/alarm.c \
misc/basename.cmisc/btowc.c misc/delay-f.c
misc/delay-n.c \
diff --git a/mingw-w64-crt/misc/longjmp.S b/mingw-w64-crt/misc/mingw_longjmp.S
similarity index 100%
rename from mingw-w64-crt/misc/longjmp.S
rename to mingw-w64-crt/misc/mingw_longjmp.S
Can we use msvcrt for that and get rid of the implementation? On ucrt it
would need a redirect it to __intrinsic_*. Wine does that in headers:
https://source.winehq.org/git/wine.git/commitdiff/0413e2a523e96b70ea4e8ba598b61460b1500d75
but we could also do that in importlib.
Thanks,
Jacek
___
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/3] crt: ucrt.mri: Use one shared mri file for all architectures
On 04.06.2020 08:32, Martin Storsjö wrote: This requires adding libucrt.a to a DATA target in automake, instead of LIBRARIES. Signed-off-by: Martin Storsjö --- mingw-w64-crt/Makefile.am | 58 --- mingw-w64-crt/lib-common/ucrt.mri | 19 ++ mingw-w64-crt/lib32/ucrt.mri | 19 -- mingw-w64-crt/lib64/ucrt.mri | 19 -- mingw-w64-crt/libarm32/ucrt.mri | 19 -- mingw-w64-crt/libarm64/ucrt.mri | 19 -- 6 files changed, 33 insertions(+), 120 deletions(-) create mode 100644 mingw-w64-crt/lib-common/ucrt.mri delete mode 100644 mingw-w64-crt/lib32/ucrt.mri delete mode 100644 mingw-w64-crt/lib64/ucrt.mri delete mode 100644 mingw-w64-crt/libarm32/ucrt.mri delete mode 100644 mingw-w64-crt/libarm64/ucrt.mri Looks good to me. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Using midl/widl with MinGW
Hi Björn, On 02.05.2020 09:42, Björn Schäpers | MIMOT GmbH wrote: Then I learned there is widl and tried that. But the generated files are no good to me: Error: wine/exception.h: No such file or directory As far as I can tell, there is no package within msys2 where I could get wine/exception.h You may try to use interpreted stubs, those should not need exceptions. Please try -Oif widl option. midl uses this mode by default, we should probably change widl to do the same at some point as well. Jacek ___ 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] widl: Compute relative binary to include dir path in configure.
On 19.05.2020 10:34, Martin Storsjö wrote: On Mon, 18 May 2020, Jacek Caban wrote: Signed-off-by: Jacek Caban --- Wine has relocation support in widl now, which conflicts with mingw-w64 relocation patch. Wine uses BIN_TO_INCLUDEDIR macro, which gets computed relative path. Wine has its own makedep, which takes care of computing that, but it would be a bit overkill to port that to mingw-w64. I used autoconf AX_COMPUTE_RELATIVE_PATH macro for that. This allows nice simplification of mingw-w64 - specific code. AX_COMPUTE_RELATIVE_PATH doesn't seem to be available in the base autoconf distribution, so it'd be great to cache a copy of that in an m4 subdir, with the appropriate flags for including that dir. Other than that, it looks good - I haven't tested the feature in detail but seems to work in general - and it looks like it's taking --with-widl-includedir into account, so that's good. Same for other patch as well, looks good. Thanks for the review. I added m4 dir and pushed. Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 2/2] widl: Remove no longer needed helpers.
Signed-off-by: Jacek Caban
---
mingw-w64-tools/widl/include/pathtools.h | 31 --
mingw-w64-tools/widl/src/pathtools.c | 434 ---
2 files changed, 465 deletions(-)
diff --git a/mingw-w64-tools/widl/include/pathtools.h b/mingw-w64-tools/widl/include/pathtools.h
index 34777bf4..78104e90 100644
--- a/mingw-w64-tools/widl/include/pathtools.h
+++ b/mingw-w64-tools/widl/include/pathtools.h
@@ -11,39 +11,8 @@
#ifndef PATHTOOLS_H
#define PATHTOOLS_H
-#include
-#include
-#include
-
-char * malloc_copy_string(char const * original);
-
-/* In-place replaces any '\' with '/' and any '//' with '/' */
-void sanitise_path(char * path);
-
/* Uses a host OS specific function to determine the path of the executable,
if IMPLEMENT_SYS_GET_EXECUTABLE_PATH is defined, otherwise uses argv0. */
int get_executable_path(char const * argv0, char * result, ssize_t max_size);
-/* Where possible, in-place removes occourances of '.' and 'path/..' */
-void simplify_path(char * path);
-
-/* Allocates (via malloc) and returns the path to get from from to to. */
-char * get_relative_path(char const * from, char const * to);
-
-size_t split_path_list(char const * path_list, char split_char, char *** arr);
-
-/* Advances path along by the amount that removes n prefix folders. */
-char const *
-strip_n_prefix_folders(char const * path, size_t n);
-
-/* NULL terminates path to remove n suffix folders. */
-void
-strip_n_suffix_folders(char * path, size_t n);
-
-char const * get_relocated_path (char const * from, char const * to, char const * actual_from);
-char * get_relocated_path_list(char const * from, char const * to_path_list);
-
-char * single_path_relocation(const char *from, const char *to);
-char * pathlist_relocation(const char *from_path, const char *to_path_list);
-
#endif /* PATHTOOLS_H */
diff --git a/mingw-w64-tools/widl/src/pathtools.c b/mingw-w64-tools/widl/src/pathtools.c
index d3c5d071..29fa3352 100644
--- a/mingw-w64-tools/widl/src/pathtools.c
+++ b/mingw-w64-tools/widl/src/pathtools.c
@@ -40,235 +40,6 @@ __attribute__((dllimport)) long __attribute__((__stdcall__)) GetModuleFileNameA
#include "pathtools.h"
-char *
-malloc_copy_string(char const * original)
-{
- char * result = (char *) malloc (sizeof (char*) * strlen (original)+1);
- if (result != NULL)
- {
-strcpy (result, original);
- }
- return result;
-}
-
-void
-sanitise_path(char * path)
-{
- size_t path_size = strlen (path);
-
- /* Replace any '\' with '/' */
- char * path_p = path;
- while ((path_p = strchr (path_p, '\\')) != NULL)
- {
-*path_p = '/';
- }
- /* Replace any '//' with '/' */
- path_p = path;
- while ((path_p = strstr (path_p, "//")) != NULL)
- {
-memmove (path_p, path_p + 1, path_size--);
- }
- return;
-}
-
-char *
-get_relative_path(char const * from_in, char const * to_in)
-{
- size_t from_size = (from_in == NULL) ? 0 : strlen (from_in);
- size_t to_size = (to_in == NULL) ? 0 : strlen (to_in);
- size_t max_size = (from_size + to_size) * 2 + 4;
- char * scratch_space = (char *) alloca (from_size + 1 + to_size + 1 + max_size + max_size);
- char * from;
- char * to;
- char * common_part;
- char * result;
- size_t count;
-
- /* No to, return "./" */
- if (to_in == NULL)
- {
-return malloc_copy_string ("./");
- }
-
- /* If alloca failed or no from was given return a copy of to */
- if ( from_in == NULL
- || scratch_space == NULL )
- {
-return malloc_copy_string (to_in);
- }
-
- from = scratch_space;
- strcpy (from, from_in);
- to = from + from_size + 1;
- strcpy (to, to_in);
- common_part = to + to_size + 1;
- result = common_part + max_size;
- simplify_path (from);
- simplify_path (to);
-
- result[0] = '\0';
-
- size_t match_size_dirsep = 0; /* The match size up to the last /. Always wind back to this - 1 */
- size_t match_size = 0; /* The running (and final) match size. */
- size_t largest_size = (from_size > to_size) ? from_size : to_size;
- int to_final_is_slash = (to[to_size-1] == '/') ? 1 : 0;
- char from_c;
- char to_c;
- for (match_size = 0; match_size < largest_size; ++match_size)
- {
-/* To simplify the logic, always pretend the strings end with '/' */
-from_c = (match_size < from_size) ? from[match_size] : '/';
-to_c = (match_size < to_size) ? to[match_size] : '/';
-
-if (from_c != to_c)
-{
- if (from_c != '\0' || to_c != '\0')
- {
-match_size = match_size_dirsep;
- }
- break;
-}
-else if (from_c == '/')
-{
- match_size_dirsep = match_size;
-}
- }
- strncpy (common_part, from, match_size);
- common_part[match_size] = '\0';
- from += match_size;
- to += match_size;
- size_t ndotdots = 0;
- char const* from_last = from + strlen(from) - 1;
- while ((from = strchr (from, '/')) && from != from_last)
- {
-++ndotdots;
-++from;
- }
- for (count = 0; count < ndotdot
[Mingw-w64-public] [PATCH 1/2] widl: Compute relative binary to include dir path in configure.
Signed-off-by: Jacek Caban
---
Wine has relocation support in widl now, which conflicts with mingw-w64
relocation patch. Wine uses BIN_TO_INCLUDEDIR macro, which gets computed
relative path. Wine has its own makedep, which takes care of computing
that, but it would be a bit overkill to port that to mingw-w64. I used
autoconf AX_COMPUTE_RELATIVE_PATH macro for that. This allows nice
simplification of mingw-w64 - specific code.
mingw-w64-tools/widl/Makefile.am | 2 +-
mingw-w64-tools/widl/configure.ac | 8 +++-
mingw-w64-tools/widl/src/widl.c | 7 +--
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/mingw-w64-tools/widl/Makefile.am b/mingw-w64-tools/widl/Makefile.am
index bab752e4..dbd00067 100644
--- a/mingw-w64-tools/widl/Makefile.am
+++ b/mingw-w64-tools/widl/Makefile.am
@@ -58,7 +58,7 @@ widl_SOURCES = src/widl.h \
include/pathtools.h \
include/winnt.rh
-widl_CPPFLAGS = -I$(top_srcdir)/include -DINCLUDEDIR=\""@WIDL_INCLUDEDIR@"\" -DDEFAULT_BINDIR=\""$(bindir)"\"
+widl_CPPFLAGS = -I$(top_srcdir)/include -DINCLUDEDIR=\""@WIDL_INCLUDEDIR@"\" -DBIN_TO_INCLUDEDIR=\""@BIN_TO_INCLUDEDIR@"\"
widl_CFLAGS = -O3 -g -Wall -Wformat -Wpacked -Wmissing-declarations -Wimplicit-function-declaration -Wmissing-prototypes -Wstrict-aliasing=2
DISTCHECK_CONFIGURE_FLAGS = --host=$(host) --target=$(target)
diff --git a/mingw-w64-tools/widl/configure.ac b/mingw-w64-tools/widl/configure.ac
index ede6c7e0..60309c35 100644
--- a/mingw-w64-tools/widl/configure.ac
+++ b/mingw-w64-tools/widl/configure.ac
@@ -16,16 +16,22 @@ AM_MAINTAINER_MODE
AC_ARG_PROGRAM
+install_prefix=$(echo $prefix | sed "s,NONE,$ac_default_prefix,")
+install_bindir=$(echo $bindir | sed "s,\${exec_prefix},$(echo $install_prefix | sed s/,/,/),")
+
AC_MSG_CHECKING([for widl includedir])
AC_ARG_WITH([widl-includedir],
[AS_HELP_STRING([--with-widl-includedir=DIR],
[Make widl look for includes in this directory, relative to the bin directory (default: /..//include)])],
[],
- [with_widl_includedir="\$(includedir)/../\$(target)/include"])
+ [with_widl_includedir="$install_prefix/$target/include"])
AC_MSG_RESULT([$with_widl_includedir])
AS_VAR_SET([WIDL_INCLUDEDIR],[$with_widl_includedir])
AC_SUBST([WIDL_INCLUDEDIR])
+AX_COMPUTE_RELATIVE_PATH([install_bindir], [with_widl_includedir], [BIN_TO_INCLUDEDIR])
+AC_SUBST([BIN_TO_INCLUDEDIR])
+
# Checks for programs.
AC_PROG_CC
diff --git a/mingw-w64-tools/widl/src/widl.c b/mingw-w64-tools/widl/src/widl.c
index 6a5ca69f..35d37d9b 100644
--- a/mingw-w64-tools/widl/src/widl.c
+++ b/mingw-w64-tools/widl/src/widl.c
@@ -752,15 +752,10 @@ int main(int argc,char *argv[])
{
char exe_path[PATH_MAX];
get_executable_path (argv[0], _path[0], sizeof (exe_path) / sizeof (exe_path[0]));
- char * rel_to_includedir = get_relative_path (DEFAULT_BINDIR, INCLUDEDIR);
if (strrchr (exe_path, '/') != NULL) {
strrchr (exe_path, '/')[1] = '\0';
}
- char relocated_default_include_dir[PATH_MAX];
- strcpy (relocated_default_include_dir, exe_path);
- strcat (relocated_default_include_dir, rel_to_includedir);
- simplify_path (_default_include_dir[0]);
- wpp_add_include_path(relocated_default_include_dir);
+ wpp_add_include_path(strmake("%s%s/%s", sysroot, exe_path, BIN_TO_INCLUDEDIR));
}
switch (target_cpu)
___
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 2/2] dwrite_1.h: Fix build in C mode
On 08.05.2020 12:18, Ruslan Garipov wrote:
-enum DWRITE_BASELINE
+typedef enum DWRITE_BASELINE
{
DWRITE_BASELINE_DEFAULT,
DWRITE_BASELINE_ROMAN,
@@ -25,40 +70,40 @@ enum DWRITE_BASELINE
DWRITE_BASELINE_IDEOGRAPHIC_TOP,
DWRITE_BASELINE_MINIMUM,
DWRITE_BASELINE_MAXIMUM,
-};
+} DWRITE_BASELINE;
WinSDK doesn't have those typedefs and I think we should stay compatible
on that. I can see that dwrite.h has such typedefs, but it's probably a
mistake.
+STDMETHOD(GetDesignGlyphAdvances)(IDWriteFontFace1 *This, UINT32,UINT16
const*,INT32*,BOOL isSideways __MINGW_DEF_ARG_VAL(FALSE)) PURE;
You don't need default value in C version, it will not be used anyway.
Thanks,
Jacek
___
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] dwrite.h: Fix build in C mode
Hi Ruslan, The patch looks good to me, I pushed it. Thanks, Jacek ___ 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/libsrc: add netcfg-uuid.c for network config interfaces
Hi Biswapriyo, On 08.05.2020 22:32, Biswapriyo Nath wrote: mingw-w64-crt/Makefile.am | 18 +++ mingw-w64-crt/libsrc/netcfg-uuid.c | 37 ++ 2 files changed, 46 insertions(+), 9 deletions(-) create mode 100644 mingw-w64-crt/libsrc/netcfg-uuid.c Could we include netcfgx.h instead of duplicating it? Thanks, Jacek ___ 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/libsrc: include devguid.h in devguid.c and remove all defines
On 07.05.2020 18:45, Biswapriyo Nath wrote: Main goal is to update the devguid.c in libsrc folder for libuuid.a. There are two options I guess: 1. Copy the new GUIDs from devguid.h to devguid.c. 2. Include devguid.h in devguid.c. Option 2 is done in the attached patch file. Because if a new GUID is added to the library in Windows SDK then one has to add it in both .h and .c file. I have checked that all the GUIDs from devguid.h are exported from uuid.lib in Windows SDK using dumpbin tool. Open to any suggestion/discussion. It looks good to me, I pushed it. Thanks, Jacek ___ 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 8/9] winstorecompat: allow building with code that needs codeGeneration capability
On 06.05.2020 15:17, Martin Storsjö wrote: That lld patch is approved now FWIW, but I realized I want to refine it a bit further. I also came to think about another trick I implemented in lld - for the cases where the address is in a .refptr$ stub, lld can actually swap that out for the IAT entry, so for all such cases, there won't even be any pseudo relocations to fix up. There's only cases with e.g. global variables initialized to the address of an auto imported variable that can't be fixed. That limits usefulness of pseudo relocs even more. I'm tempted to suggest a bit more drastic solution and disable them by default. Instead of --disable-*, add --enable-runtime-pseudo-relocs, which could also unconditionally (my understanding is that it should be easy on linker side with command argument) reference _pei386_runtime_relocator and we could revisit the idea of making its linkage conditional. Thanks, Jacek ___ 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 v3 05/10] winstorecompat: provide GetUserName
On 06.05.2020 15:09, Martin Storsjö wrote: Or call directly GetEnvironment directly? If it works on all relevant Windows versions, that sounds good. MSDN says it's supported since XP so I suppose so, but I can't guarantee it. I can only test on windows 10 at the moment. Did I understand it correctly (from the patch, which has the code within "#if _WIN32_WINNT >= _WIN32_WINNT_WIN10") that GetEnvironmentVariable is supported in UWP (10) but not WinStore on 8? In that case, I'd prefer not to inline the call further up but just keep it winstorecompat - so that on Win 8 it'd be a stub function that just returns a failure. Sounds good to me. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import dvdif.idl and wincodecsdk.idl from wine
Pushed to git. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gdk-pixbuf-2.40.0 Build Errors
On 28.04.2020 23:27, Thomas Dineen wrote: 000b:fixme:winediag:__wine_start_process Wine Staging 5.0 is a testing version containing experimental patches. 000b:fixme:winediag:__wine_start_process Please mention your exact version when filing bug reports on winehq.org. 002b:err:module:__wine_process_init L"Z:\\home\\tdineen\\gdk-pixbuf-2\\gdk-pixbuf-2.40.0\\_build\\meson-private\\sanitycheckc_cross.exe" not supported on this system It looks like you don't have 32-bit Wine, so Wine can't run 32-bit executables. You may try installing 32-bit Wine. Also, there should be a way to tell meson that you're cross compiling that that is does not to try to run binaries. IIRC it was something like needs_exe_wrapper = true. Jacek ___ 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 v3 05/10] winstorecompat: provide GetUserName
On 27.04.2020 19:55, Jean-Baptiste Kempf wrote: On Mon, Apr 27, 2020, at 19:40, Jacek Caban wrote: On 27.04.2020 16:31, Steve Lhomme wrote: It's needed by: - getlogin() in mingwex Could we prohibit getlogin() on non-desktop in headers instead? Or call directly GetEnvironment directly? If it works on all relevant Windows versions, that sounds good. Thanks, Jacek ___ 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 v3 10/10] winstorecompat: add libwinstorecompatapp to use with libwindowsapp
On 27.04.2020 19:23, Martin Storsjö wrote: I'd still like this to be named e.g. winstorecompatuwp instead of -app. Other than that, I don't think I have any objections to the other patches in the set - but I'd like to hear Jacek's ack as well. Other than comments I just sent, I don't have any objections. Thanks, Jacek ___ 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 v3 05/10] winstorecompat: provide GetUserName
On 27.04.2020 16:31, Steve Lhomme wrote: It's needed by: - getlogin() in mingwex Could we prohibit getlogin() on non-desktop in headers instead? Thanks, Jacek ___ 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 v3 09/10] crt: compile the DLL Delay Loading code in delayimp
On 27.04.2020 19:22, Martin Storsjö wrote: Jacek, Wine uses delayloaded DLLs a lot - does it use -ldelayimp properly? Or does it entirely use its own implementation of the helper function nowadays? Wine will always use its own implementation (that just forwards the call to ResolveDelayLoadedAPI in its static lib), so it would be fine. I recall adding an empty -ldelayimp for Firefox, which required it to exist (because it's required on MSVC), so it should be fine as well. I don't know about other users. However, I'm not sure if moving the implementation solves any problem. It should be pulled by linker only when needed anyway. Jacek ___ 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 4/9] winstorecompat: handle LoadLibraryA alongside LoadLibraryW
On 27.04.2020 12:14, Martin Storsjö wrote: On Mon, 27 Apr 2020, Jacek Caban wrote: On 27.04.2020 11:46, Steve Lhomme wrote: On 2020-04-24 14:44, Jacek Caban wrote: On 24.04.2020 13:43, Steve Lhomme wrote: It's needed by: - __delayLoadHelper2() in mingwex I'm not sure what are the exact compatibility considerations here, but for win8+ builds we could just use LdrResolveDelayLoadedAPI and make __delayLoadHelper2 just a thin wrapper. See how Wine handles it: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winecrt0/delay_load.c#l38 If we consider UCRT builds to be win8+, we could do the same for UCRT builds. I tried to play with that. But in the end that means building mingwex that can only be used with win8+ or not pass the store. We would need to move __delayLoadHelper2 to be defined in msvcrt importlib first. Then we could use different implementation for different crts. UCRT could use LdrResolveDelayLoadedAPI, but other msvcrt version could keep using the existing implementation. Wasn't LdrResolveDelayLoadedAPI only available since Win 8? UCRT is runnable on Win 7, and I don't think we want to drop support for that combination. (Not that most users use delay loading, but anyway...) Yes. That's also where separate crt would be handy again: we could change it only for UWP builds. I'm not sure it's a big deal to limit support for win7 in UCRT in general, but if you prefer to support that, that's fine with me. We will need a compat stub then. Thanks, Jacek ___ 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 8/9] winstorecompat: allow building with code that needs codeGeneration capability
On 27.04.2020 12:10, Martin Storsjö wrote:
On Fri, 24 Apr 2020, Martin Storsjö wrote:
From when I implemented this in lld, I remember that it looked like
there was an intention that the linker would reference the symbol
_pei386_runtime_relocator (code in ld.bfd that tries to do that), to
force pulling in the whole mechanism - but doing that wasn't really
enough as is.
It would, at least, require changing crt/pseudo-reloc.c to add a
_CRTALLOC(".CRT$") constructor for doing the fixup without being
explicitly called.
So far in lld, I didn't implement that bit (trying to reference
_pei386_runtime_relocator when we see that we need pseudo relocs).
I think, faintly, that it wasn't trivial to do it, due to how the lld
code is structured. First it loads object files to satisfy all
undefined symbols. When that's done, it tries to fix up all
relocations, at which point it realizes it needs pseudo relocs for
this. At that point, it would then need to go back to add another
undefined reference to _pei386_runtime_relocator and iterate on
loading more object files until there's no more undefined references
again - and that'd be rather messy in that code base.
So for now, I didn't implement that aspect, as mingw-w64-crt
currently calls _pei386_runtime_relocator unconditionally.
I tried looking into this again, and the main blocker isn't lld code
itself (it should, after all, be fairly straightforward to implement
this).
The issue seems to be that ld.bfd has the intention to do this -
reference the symbol _pei386_runtime_relocator if it ends up using
pseudo relocs. But if _pei386_runtime_relocator isn't already linked
in due to a direct dependency pulling it in, this just ends up with an
undefined reference, like this:
ertr01.o:(.rdata+0x0): undefined reference to
`_pei386_runtime_relocator'
(This is the name of a linker synthesized object file - not one of the
real ones from the toolchain.)
So to go down this route, we'd need to fix this issue in ld.bfd (going
back to pull in more object files, when we realize we need pseudo
relocs), and in lld, before we could decouple this bit.
Oh, I see, thanks for looking at it and sorry for misleading. I don't
see any other way to avoid VirtualProtect dependency, so some form of
compat stub will indeed be needed.
Thanks,
Jacek
___
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 4/9] winstorecompat: handle LoadLibraryA alongside LoadLibraryW
On 27.04.2020 11:46, Steve Lhomme wrote: On 2020-04-24 14:44, Jacek Caban wrote: On 24.04.2020 13:43, Steve Lhomme wrote: It's needed by: - __delayLoadHelper2() in mingwex I'm not sure what are the exact compatibility considerations here, but for win8+ builds we could just use LdrResolveDelayLoadedAPI and make __delayLoadHelper2 just a thin wrapper. See how Wine handles it: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winecrt0/delay_load.c#l38 If we consider UCRT builds to be win8+, we could do the same for UCRT builds. I tried to play with that. But in the end that means building mingwex that can only be used with win8+ or not pass the store. We would need to move __delayLoadHelper2 to be defined in msvcrt importlib first. Then we could use different implementation for different crts. UCRT could use LdrResolveDelayLoadedAPI, but other msvcrt version could keep using the existing implementation. This would still affect compatibility of UCRT, but not others'. It will also affect only applications using delay load, which may make it more suitable, I'm not sure. Thanks, Jacek ___ 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] headers: import wincodec.idl from wine
Looks good, pushed. Thanks, Jacek ___ 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 8/9] winstorecompat: allow building with code that needs codeGeneration capability
On 24.04.2020 15:09, Martin Storsjö wrote: So for now, I didn't implement that aspect, as mingw-w64-crt currently calls _pei386_runtime_relocator unconditionally. So I'd just recommend a plain stub VirtualProtect that returns an error here... I should probably at least implement --disable-runtime-pseudo-reloc in lld, so you get a link time error if the code base needs pseudo relocs, instead of having it fail mysteriously at runtime. I see, we need it then. With --disable-runtime-pseudo-reloc, we could place .drectve in compat lib to disable it without user interaction. Thanks, Jacek ___ 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/9] crt: use GetEnvironmentVariableA in getopt
On 24.04.2020 15:14, Steve Lhomme wrote: On 2020-04-24 15:11, Jacek Caban wrote: On 24.04.2020 14:35, Steve Lhomme wrote: On 2020-04-24 14:30, Jacek Caban wrote: On 24.04.2020 14:26, Steve Lhomme wrote: On 2020-04-24 14:24, Jacek Caban wrote: On 24.04.2020 13:43, Steve Lhomme wrote: This avoids relying on getenv() from winstorecompat that returns NULL and can't be reimplemented in a clean way. What's the problem with getenv()? Would using _wgetenv instead help? According to this page it's not allowed https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps OK. You could use GetEnvironmentVariableW and pass NULL buffer if you're only interested in checking if the variable exists. Why GetEnvironmentVariableW and not GetEnvironmentVariableA ? The ANSI version is available in win8 UWP so we don't need the extra size. We don't need extra size and avoid useless conversion, see bellow. Well, L"POSIXLY_CORRECT" is double the size of "POSIXLY_CORRECT". I don't see how using GetEnvironmentVariableW is better. My look at this may be affected by the fact that I usually look at those things from the other side while working on Wine, but *A functions are just wrappers around *W ones in practice. I'm pretty sure it's true on Windows as well, because the environment is stored in unicode in PEB there as well. In this case *A function just converts passed name to unicode, passes it to *W function, get the result and convert the result back to CP_ACP (if only to return required buffer size). We may cut a lot of that by simply using the right one. There are reasons to prefer *W functions on Windows that don't apply to this case, but more to LoadLibraryA: you're not guaranteed that you may do conversion to CP_ACP. This makes, for example, using *A functions for file access (where path may contain any unicode character) technically wrong. Jacek ___ 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/9] crt: use GetEnvironmentVariableA in getopt
On 24.04.2020 14:35, Steve Lhomme wrote: On 2020-04-24 14:30, Jacek Caban wrote: On 24.04.2020 14:26, Steve Lhomme wrote: On 2020-04-24 14:24, Jacek Caban wrote: On 24.04.2020 13:43, Steve Lhomme wrote: This avoids relying on getenv() from winstorecompat that returns NULL and can't be reimplemented in a clean way. What's the problem with getenv()? Would using _wgetenv instead help? According to this page it's not allowed https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps OK. You could use GetEnvironmentVariableW and pass NULL buffer if you're only interested in checking if the variable exists. Why GetEnvironmentVariableW and not GetEnvironmentVariableA ? The ANSI version is available in win8 UWP so we don't need the extra size. We don't need extra size and avoid useless conversion, see bellow. The documentation doesn't mention if NULL is allowed and 0 may just give an error because the the null-terminating character is supposed to be there. https://docs.microsoft.com/en-us/windows/win32/api/processenv/nf-processenv-getenvironmentvariablew From this page: "If /lpBuffer/ is not large enough to hold the data, the return value is the buffer size, in characters, required to hold the string and its terminating null character and the contents of /lpBuffer/ are undefined." It means that if you pass 0-size buffer, it will return the size of required buffer. You could just do GetEnvironmentVariableW(L"POSIXLY_CORRECT", NULL, 0) != 0; Jacek ___ 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 8/9] winstorecompat: allow building with code that needs codeGeneration capability
On 24.04.2020 13:43, Steve Lhomme wrote: By default winstorecompat is built without the need for this capability. VirtualProtect may be mapped to VirtualProtectFromApp but only if the app has the codeGeneration capability. It is needed when compiling UNIX code with relocatable sections that are relocated at runtime. VirtualProtectFromApp is only available if compiled to target win10. We should be able to avoid depending on VirtualProtect for builds that don't use pseudo relocs. My understanding is that linker will emit a call to _pei386_runtime_relocator if it uses pseudo relocations. We, however, unconditionally call it anyway from entry points. My guess would be that we do that for some backward compatibility. Could someone familiar with internals confirm that? If my understanding is correct, we could remove unconditional calls and depend on linker to emit them. Jacek ___ 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 4/9] winstorecompat: handle LoadLibraryA alongside LoadLibraryW
On 24.04.2020 13:43, Steve Lhomme wrote: It's needed by: - __delayLoadHelper2() in mingwex I'm not sure what are the exact compatibility considerations here, but for win8+ builds we could just use LdrResolveDelayLoadedAPI and make __delayLoadHelper2 just a thin wrapper. See how Wine handles it: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winecrt0/delay_load.c#l38 If we consider UCRT builds to be win8+, we could do the same for UCRT builds. - WspiapiLoad() in ws2_32 This should be ported to unicode, IMHO. Thanks, Jacek ___ 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/9] crt: use GetEnvironmentVariableA in getopt
On 24.04.2020 14:26, Steve Lhomme wrote: On 2020-04-24 14:24, Jacek Caban wrote: On 24.04.2020 13:43, Steve Lhomme wrote: This avoids relying on getenv() from winstorecompat that returns NULL and can't be reimplemented in a clean way. What's the problem with getenv()? Would using _wgetenv instead help? According to this page it's not allowed https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps OK. You could use GetEnvironmentVariableW and pass NULL buffer if you're only interested in checking if the variable exists. Jacek ___ 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/9] crt: use GetEnvironmentVariableA in getopt
On 24.04.2020 13:43, Steve Lhomme wrote: This avoids relying on getenv() from winstorecompat that returns NULL and can't be reimplemented in a clean way. What's the problem with getenv()? Would using _wgetenv instead help? Jacek ___ 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: Don't use __mingw_init_ehandler on toolchains using SEH.
Signed-off-by: Jacek Caban
---
mingw-w64-crt/crt/crt_handler.c | 2 +-
mingw-w64-crt/crt/crtdll.c | 4 +++-
mingw-w64-crt/crt/crtexe.c | 4 ++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-crt/crt/crt_handler.c b/mingw-w64-crt/crt/crt_handler.c
index 6571e69e..fe52cf4e 100644
--- a/mingw-w64-crt/crt/crt_handler.c
+++ b/mingw-w64-crt/crt/crt_handler.c
@@ -40,7 +40,7 @@ PBYTE _GetPEImageBase (void);
int __mingw_init_ehandler (void);
extern void _fpreset (void);
-#if defined(__x86_64__) && !defined(_MSC_VER)
+#if defined(__x86_64__) && !defined(_MSC_VER) && !defined(__SEH__)
EXCEPTION_DISPOSITION __mingw_SEH_error_handler(struct _EXCEPTION_RECORD *, void *, struct _CONTEXT *, void *);
#define MAX_PDATA_ENTRIES 32
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 6187f10d..0d977022 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -148,7 +148,9 @@ WINBOOL WINAPI _CRT_INIT (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
static WINBOOL __DllMainCRTStartup (HANDLE, DWORD, LPVOID);
WINBOOL WINAPI DllMainCRTStartup (HANDLE, DWORD, LPVOID);
+#if defined(__x86_64__) && !defined(__SEH__)
int __mingw_init_ehandler (void);
+#endif
WINBOOL WINAPI
DllMainCRTStartup (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
@@ -157,7 +159,7 @@ DllMainCRTStartup (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
if (dwReason == DLL_PROCESS_ATTACH)
{
__security_init_cookie ();
-#ifdef __x86_64__
+#if defined(__x86_64__) && !defined(__SEH__)
__mingw_init_ehandler ();
#endif
}
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index b730dc47..c3deb6e0 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -200,7 +200,7 @@ int WinMainCRTStartup (void)
int mainCRTStartup (void);
-#ifdef _WIN64
+#if defined(__x86_64__) && !defined(__SEH__)
int __mingw_init_ehandler (void);
#endif
@@ -282,7 +282,7 @@ __tmainCRTStartup (void)
_pei386_runtime_relocator ();
__mingw_oldexcpt_handler = SetUnhandledExceptionFilter (_gnu_exception_handler);
-#ifdef __x86_64__
+#if defined(__x86_64__) && !defined(__SEH__)
__mingw_init_ehandler ();
#endif
_set_invalid_parameter_handler (__mingw_invalidParameterHandler);
___
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 a dummy RtlAddFunctionTable when linking with windowsapp
On 23.04.2020 10:19, Steve Lhomme wrote: This worked. The forbidden RtlAddFunctionTable calls are not done anymore. Thanks for testing, it passed my usual testing as well. Jacek ___ 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: Remove the vestigial gs_support.c
Hi Martin,
This patch looks right to me. If it never really worked, backward
compatibility is not an issue. If someone wants those features, using
UCRT seems to be the right answer.
Thanks,
Jacek
On 22.04.2020 23:00, Martin Storsjö wrote:
This was a partial (but incomplete!) support for the MSVC stack
cookie handling (under the MSVC option /GS, similar to GCC and
Clang/MinGW's -fstack-protector-strong). This contained the
stack cookie itself and the init function, and the error reporting
function, but not the checking function (__security_check_cookie).
And these functions would only end up being called by code generated
by MSVC anyway.
Signed-off-by: Martin Storsjö
---
This is one out of two alternative ways of handling the potentially
problematic function __report_gsfailure, which calls a number of
functions that aren't available for UWP apps - the other alternative
is to keep the functions but move __report_gsfailure to the msvcrt
import library, as more modern msvcrt versions, and ucrt, does provide
their own versions of the function - and in normal cases, nothing
references the symbol so it won't end up linked in (unless it's in
the same object file as __security_init_cookie).
---
mingw-w64-crt/Makefile.am | 2 +-
mingw-w64-crt/crt/crtdll.c | 1 -
mingw-w64-crt/crt/crtexe.c | 2 -
mingw-w64-crt/crt/gs_support.c | 154
mingw-w64-headers/crt/process.h | 10 ---
5 files changed, 1 insertion(+), 168 deletions(-)
delete mode 100644 mingw-w64-crt/crt/gs_support.c
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 0f882ae2a..86b0b0d73 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -115,7 +115,7 @@ src_libntoskrnl=libsrc/memcmp.c
src_libmingw32=include/oscalls.h include/internal.h include/sect_attribs.h \
crt/crt0_c.ccrt/dll_argv.c crt/gccmain.c crt/natstart.c
crt/pseudo-reloc-list.c crt/wildcard.c \
- crt/charmax.c crt/crt0_w.c crt/dllargv.c crt/gs_support.c
crt/_newmode.c crt/tlssup.c crt/xncommod.c \
+ crt/charmax.c crt/crt0_w.c crt/dllargv.c crt/_newmode.c
crt/tlssup.c crt/xncommod.c \
crt/cinitexe.c crt/crt0_w.c crt/merr.c crt/pesect.c
crt/udllargc.c crt/xthdloc.ccrt/CRT_fp10.c \
crt/mingw_custom.c crt/mingw_helpers.c \
crt/pseudo-reloc.c crt/udll_argv.c \
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 6187f10d2..797c1beeb 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -156,7 +156,6 @@ DllMainCRTStartup (HANDLE hDllHandle, DWORD dwReason,
LPVOID lpreserved)
mingw_app_type = 0;
if (dwReason == DLL_PROCESS_ATTACH)
{
- __security_init_cookie ();
#ifdef __x86_64__
__mingw_init_ehandler ();
#endif
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index b730dc479..f521b54cd 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -189,7 +189,6 @@ int WinMainCRTStartup (void)
);
#endif
mingw_app_type = 1;
- __security_init_cookie ();
ret = __tmainCRTStartup ();
#ifdef SEH_INLINE_ASM
asm ("\tnop\n"
@@ -217,7 +216,6 @@ int mainCRTStartup (void)
);
#endif
mingw_app_type = 0;
- __security_init_cookie ();
ret = __tmainCRTStartup ();
#ifdef SEH_INLINE_ASM
asm ("\tnop\n"
diff --git a/mingw-w64-crt/crt/gs_support.c b/mingw-w64-crt/crt/gs_support.c
deleted file mode 100644
index 0c6ac68cd..0
--- a/mingw-w64-crt/crt/gs_support.c
+++ /dev/null
@@ -1,154 +0,0 @@
-/**
- * This file has no copyright assigned and is placed in the Public Domain.
- * This file is part of the mingw-w64 runtime package.
- * No warranty is given; refer to the file DISCLAIMER.PD within this package.
- */
-
-#ifndef WIN32_LEAN_AND_MEAN
-#define WIN32_LEAN_AND_MEAN
-#endif
-#define WIN32_NO_STATUS
-#include /* abort () */
-#include
-#undef WIN32_NO_STATUS
-#include /* STATUS macros */
-#ifdef _WIN64
-#include
-#endif
-
-#ifdef _WIN64
-#define DEFAULT_SECURITY_COOKIE 0x2B992DDFA232ll
-#else
-#define DEFAULT_SECURITY_COOKIE 0xBB40E64E
-#endif
-
-/* Externals. */
-
-typedef LONG NTSTATUS; /* same as in ntdef.h / winternl.h */
-
-#define UNW_FLAG_NHANDLER 0x0
-
-typedef union
-{
- unsigned __int64 ft_scalar;
- FILETIME ft_struct;
-} FT;
-
-static EXCEPTION_RECORD GS_ExceptionRecord;
-static CONTEXT GS_ContextRecord;
-
-static const EXCEPTION_POINTERS GS_ExceptionPointers = {
- _ExceptionRecord,_ContextRecord
-};
-
-DECLSPEC_SELECTANY UINT_PTR __security_cookie = DEFAULT_SECURITY_COOKIE;
-DECLSPEC_SELECTANY UINT_PTR __security_cookie_complement =
~(DEFAULT_SECURITY_COOKIE);
-
-void __cdecl __security_init_cookie (void);
-
-void __cdecl
-__security_init_cookie (void)
-{
- UINT_PTR cookie;
- FT systime = { 0, };
- LARGE_INTEGER perfctr;
-
- if (__security_cookie !=
Re: [Mingw-w64-public] [PATCH] crt: add a dummy RtlAddFunctionTable when linking with windowsapp
On 22.04.2020 14:03, Martin Storsjö wrote:
On Wed, 22 Apr 2020, Jacek Caban wrote:
On 22.04.2020 12:47, Martin Storsjö wrote:
The compiler doesn't generate .pdata sections if e.g. building with
a toolchain that defaults to SJLJ exception handling - that's a
common (not the most common, but still occurring) configuration.
Like I already wrote once, this is a catch-all handler for catching
SEH exceptions (like crashes and similar) within the mingw code, if
SEH isn't used for the C++ exception handling mechanism. As far as I
see it, it's a nice-to-have feature for those cases.
How reliably can we detect the condition when if compiler will
generate .pdata sections? If it's something like #ifdef __SEH__, then
we could probably use that to limit use of this code inside mingw32
to relevant builds. It would solve this problem as well and reduce
statically linked code for users that don't need it. It would behave
differently than now if other compiler is used to build crt and use
the app using it, but such configs are shaky anyway.
I think with both Clang and GCC, that you should be able to check for
__SEH__, yes.
That has a fairly high chance of retaining the intended behaviour - so
that's good.
There's of course a chance that my guess for what the code was
supposed to do is wrong, but in any case, if __SEH__ is defined, then
both GCC and Clang do generate .pdata, and the checks would make the
code no-op in any case.
(There's also potential corner cases of using a compiler that uses SEH
for C++ exceptions, but building with -fno-unwind-tables (so that
plain C code doesn't generate unwind info), so it would be possible to
construct a SEH-configured executable without .pdata, but that's
really splitting hairs and not a configuration I think we need to
consider.)
That sounds good, it should be as simple as the attached patch. Steve,
can you please give it a try.
Jacek
commit b2c86d72e721062d063d8d3ed02d9b34a40911db
Author: Jacek Caban
Date: Wed Apr 22 16:23:54 2020 +0200
crt: Don't use __mingw_init_ehandler on toolchains using SEH.
diff --git a/mingw-w64-crt/crt/crt_handler.c b/mingw-w64-crt/crt/crt_handler.c
index 6571e69e..fe52cf4e 100644
--- a/mingw-w64-crt/crt/crt_handler.c
+++ b/mingw-w64-crt/crt/crt_handler.c
@@ -40,7 +40,7 @@ PBYTE _GetPEImageBase (void);
int __mingw_init_ehandler (void);
extern void _fpreset (void);
-#if defined(__x86_64__) && !defined(_MSC_VER)
+#if defined(__x86_64__) && !defined(_MSC_VER) && !defined(__SEH__)
EXCEPTION_DISPOSITION __mingw_SEH_error_handler(struct _EXCEPTION_RECORD *, void *, struct _CONTEXT *, void *);
#define MAX_PDATA_ENTRIES 32
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 6187f10d..0d977022 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -148,7 +148,9 @@ WINBOOL WINAPI _CRT_INIT (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
static WINBOOL __DllMainCRTStartup (HANDLE, DWORD, LPVOID);
WINBOOL WINAPI DllMainCRTStartup (HANDLE, DWORD, LPVOID);
+#if defined(__x86_64__) && !defined(__SEH__)
int __mingw_init_ehandler (void);
+#endif
WINBOOL WINAPI
DllMainCRTStartup (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
@@ -157,7 +159,7 @@ DllMainCRTStartup (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
if (dwReason == DLL_PROCESS_ATTACH)
{
__security_init_cookie ();
-#ifdef __x86_64__
+#if defined(__x86_64__) && !defined(__SEH__)
__mingw_init_ehandler ();
#endif
}
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index b730dc47..c3deb6e0 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -200,7 +200,7 @@ int WinMainCRTStartup (void)
int mainCRTStartup (void);
-#ifdef _WIN64
+#if defined(__x86_64__) && !defined(__SEH__)
int __mingw_init_ehandler (void);
#endif
@@ -282,7 +282,7 @@ __tmainCRTStartup (void)
_pei386_runtime_relocator ();
__mingw_oldexcpt_handler = SetUnhandledExceptionFilter (_gnu_exception_handler);
-#ifdef __x86_64__
+#if defined(__x86_64__) && !defined(__SEH__)
__mingw_init_ehandler ();
#endif
_set_invalid_parameter_handler (__mingw_invalidParameterHandler);
___
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 a dummy RtlAddFunctionTable when linking with windowsapp
On 22.04.2020 13:28, Jacek Caban wrote: How reliably can we detect the condition when if compiler will generate .pdata sections? I meant s/when/when building crt/. Jacek ___ 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 a dummy RtlAddFunctionTable when linking with windowsapp
On 22.04.2020 12:47, Martin Storsjö wrote: The compiler doesn't generate .pdata sections if e.g. building with a toolchain that defaults to SJLJ exception handling - that's a common (not the most common, but still occurring) configuration. Like I already wrote once, this is a catch-all handler for catching SEH exceptions (like crashes and similar) within the mingw code, if SEH isn't used for the C++ exception handling mechanism. As far as I see it, it's a nice-to-have feature for those cases. How reliably can we detect the condition when if compiler will generate .pdata sections? If it's something like #ifdef __SEH__, then we could probably use that to limit use of this code inside mingw32 to relevant builds. It would solve this problem as well and reduce statically linked code for users that don't need it. It would behave differently than now if other compiler is used to build crt and use the app using it, but such configs are shaky anyway. Thanks, Jacek ___ 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 a dummy RtlAddFunctionTable when linking with windowsapp
On 21.04.2020 19:40, Martin Storsjö wrote: I don't think particularly that is a good idea here. windowsapp is a replacement for kernel32 and a few other dlls, but the CRT in this case is libucrt.a (which links against the api-ms-win-crt-*) which also can be used for normal desktop things. What I'm suggesting would result in a separated crt, say libucrtapp.a, which you would use instead of libucrt.a. On build system side, we'd just use exactly the same sources as libucrt.a, except that we'd have a macro that we'd use to disable unavailable nice-to-have features like this. The same thing can be done with other stubs from the compat code. Jacek ___ 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 a dummy RtlAddFunctionTable when linking with windowsapp
Hi Steve, On 21.04.2020 16:40, Steve Lhomme wrote: windowsapp is meant to replace kernel32, user32, shell32, etc. These older libraries should be used with it to avoid linking to entries that should not be used in that context (apps working on all win10 devices) https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis When linking with just windowsapp (and a C runtime) there's a call in mingw32 to RtlAddFunctionTable(). In practice this call has no effect as the .pdata of the section takes predecence. https://pmeerw.net/blog/programming/RtlAddFunctionTable.html This function call is not allowed an not needed in this context, so we just forward the call to an internal dummy version. winstorecompat also has a similar function but it should not be used with windowsapp as some functions replaced by winstorecompat are now allowed in windowsapp. We already have similar hacks in the tree already, so if others like it I won't stay in a way of the patch, but I think that this could be done better. We should be able to avoid the call in the first place. One way to achieve that would be to move crt_handler.c to msvcrt importlib. Then we can customize that for windowsapp crt and avoid problematic functions. Thanks, Jacek ___ 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 v3 1/6] headers: crt: include winapifamily in corecrt.h
On 18.04.2020 14:51, Liu Hao wrote: 在 2020/4/17 20:25, Steve Lhomme 写道: So we can restrict some C runtime APIs based on the target family. Based on this documentation some APIs are not allowed in UWP builds https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=vs-2019 The documentation is old and may not apply to Win10 but it's still the one listed for UCRT compatibility : https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=vs-2019 --- mingw-w64-headers/crt/corecrt.h | 2 ++ 1 file changed, 2 insertions(+) It seems that MS headers don't check for such configuration. I also consider it wrong to check for Windows API macros in CRT headers. As far as I can see, they do, but differently. corecrt.h defines or not _CRT_USE_WINAPI_FAMILY_DESKTOP_APP. If WINAPI_FAMILY is not defined, it just assumes desktop. Otherwise it includes winapifamily.h and uses that to do the check. That, at least, limits the dependency to builds using those features. Other crt headers can just use _CRT_USE_WINAPI_FAMILY_DESKTOP_APP. Jacek ___ 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] Add the IApplicationData2 storage interface
Hi Steve, Yeah, winrt IDLs in mingw-w64 are a mess right now. They are invalid and they required hacked widl version to generate. Long term solution is finishing winrt support in upstream widl (I did some work on that, but more is needed) and rewrite those IDLs. If you need a quicker solution, it should be possible to use widl version prior to: https://sourceforge.net/p/mingw-w64/mailman/message/36161806/ Thanks, Jacek On 10.04.2020 15:50, Steve Lhomme wrote: I had a lot of trouble generating the .h The widl I'm using would not recognize the declarations in namespaces. So I put the declerations outside and it kinda worked. Using the proper namespace and removing a few things works. But then the COBJMACRO API calls are quite different (and ugly) from what they are now. On the other hand they match what MS generates. On 2020-04-10 15:38, Liu Hao wrote: 在 2020/4/10 0:48, Biswapriyo Nath 写道: enum AsyncStatus is present in AsyncInfo.idl file in Windows SDK which is not present in mingw-w64-headers. It's on line 32 in 'windows.foundation.idl'. But for some unknown reason WIDL doesn't recognize this typedef. -- Best regards, LH_Mouse ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ 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: Remove unused/unnecessary declarations of _commode in internal.h
On 01.04.2020 14:14, Martin Storsjö wrote: Signed-off-by: Martin Storsjö --- mingw-w64-crt/include/internal.h | 6 -- 1 file changed, 6 deletions(-) Looks good to me. Thanks, Jacek ___ 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/5] headers: add dxvahd.idl
On 10/03/2020 12:48, Steve Lhomme wrote: On 2020-03-10 11:31, Jacek Caban wrote: On 10/03/2020 07:34, Steve Lhomme wrote: You mean squash all 5 patches into one or just the first two ? In general I prefer to split commits so if something breaks it's easier to know what is wrong in a particular commit and possibly revert it, without losing all changes. Splitting patches is generally a good habit, but only when it makes sense. In this case, you know that the interface that you're adding in patch 1 is broken (and you already have a fix for that), so how can we review patch 1? Patch one is generating the "same" file from an IDL file. With the same incorrect order and with the same tricks like the CALLBACK one or the interface warning during compilation. Modifying an IDL file is easier and has less duplicate parts so it's easier to get there sooner in the patchset. That avoids modifying more lines later and making more mistake. Reviewing this patch means verifying it produces more or less the same file without breaking anything. I looked only at .idl part and for some reason operated under assumption that we don't have that header yet. Sorry about that, split version of the patch is actually better in that case. I will review it later today. Thanks, Jacek ___ 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] headers: Add corecrt_stdio_config.h header.
On 09/03/2020 21:59, Martin Storsjö wrote: On Mon, 9 Mar 2020, Jacek Caban wrote: Signed-off-by: Jacek Caban --- mingw-w64-headers/crt/corecrt_stdio_config.h | 30 mingw-w64-headers/crt/stdio.h | 2 +- 2 files changed, 31 insertions(+), 1 deletion(-) create mode 100644 mingw-w64-headers/crt/corecrt_stdio_config.h This looks ok in itself - are you going to take these new defines into use in the rest of the headers as well, which I presume is the ultimate goal? I recently ported Wine headers to ucrt and I thought I could share with mingw-w64 at least some bits that are possible to share. I will plan to replace existing defines in headers and crt if you agree it's a good idea. Thanks, Jacek ___ 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/5] headers: add dxvahd.idl
On 10/03/2020 07:34, Steve Lhomme wrote: You mean squash all 5 patches into one or just the first two ? In general I prefer to split commits so if something breaks it's easier to know what is wrong in a particular commit and possibly revert it, without losing all changes. Splitting patches is generally a good habit, but only when it makes sense. In this case, you know that the interface that you're adding in patch 1 is broken (and you already have a fix for that), so how can we review patch 1? Please merge them all. Thanks, Jacek ___ 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] headers: Do legacy null termination in vsnwprintf for UCRT
On 09/03/2020 22:48, Martin Storsjö wrote: On Mon, 9 Mar 2020, Jacek Caban wrote: Hi Martin, On 09.03.2020 10:43, Martin Storsjö wrote: According to standard C99, the swprintf and vswprintf functions return a negative value if the buffer is insufficient (contrary to snprintf), and the contents of the buffer is undefined in this case. Both swprintf and vswprintf functions for UCRT end up calling this inline function. As far as I can see, UCRT calls it with UCRTBASE_PRINTF_DEFAULT_WIDE. No, that's a different thing. With UCRTBASE_PRINTF_DEFAULT_WIDE, or _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS, you'd primarily change between the legacy and standard handling of %s/%S in wide printfs. This patch is not about that aspect, but about the return value and null termination of these functions. Normally that's tied to the function variant (different variants have different legacy behaviours defined), as _CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION and _CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR are or'ed in with the user-overrideable value. Yes, I know, sorry for being imprecise. I meant plain UCRTBASE_PRINTF_DEFAULT_WIDE without any other legacy or standard flag. Also, there is a duplicated declaration in wchar.h that would need a change (or move to corecrt_wstdio.h to avoid duplication). Oh right, thanks for pointing it out. I noticed that this patch didn't match the null termination behaviour of MSVC exactly (for swprintf, MSVC does null terminate but returns -1, contrary to _snwprintf which doesn't null terminate), I've fixed that in an updated version of the patch. The updated patch makes the output of the attached test file (or https://martin.st/temp/swprintf.c if the mailing list drops the attachment) match MSVC when using UCRT. Looks good to me now, thanks. Jacek ___ 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/5] headers: add dxvahd.idl
Hi Steve, On 04.03.2020 15:27, Steve Lhomme wrote: Use the generated dxvahd.h --- mingw-w64-headers/Makefile.am| 1 + mingw-w64-headers/include/dxvahd.h | 841 ++- mingw-w64-headers/include/dxvahd.idl | 427 ++ 3 files changed, 990 insertions(+), 279 deletions(-) create mode 100644 mingw-w64-headers/include/dxvahd.idl Please merge those patches. There is no need to add methods in wrong order only to reorder them later in the series. Thanks, Jacek ___ 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: Add corecrt_stdio_config.h header.
Signed-off-by: Jacek Caban --- mingw-w64-headers/crt/corecrt_stdio_config.h | 30 mingw-w64-headers/crt/stdio.h| 2 +- 2 files changed, 31 insertions(+), 1 deletion(-) create mode 100644 mingw-w64-headers/crt/corecrt_stdio_config.h diff --git a/mingw-w64-headers/crt/corecrt_stdio_config.h b/mingw-w64-headers/crt/corecrt_stdio_config.h new file mode 100644 index ..02a83684 --- /dev/null +++ b/mingw-w64-headers/crt/corecrt_stdio_config.h @@ -0,0 +1,30 @@ +/** + * This file has no copyright assigned and is placed in the Public Domain. + * This file is part of the Wine project. + * No warranty is given; refer to the file DISCLAIMER.PD within this package. + */ + +#ifndef _STDIO_CONFIG_DEFINED +#define _STDIO_CONFIG_DEFINED + +#include + +#define _CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION 0x0001ULL +#define _CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR0x0002ULL +#define _CRT_INTERNAL_PRINTF_LEGACY_WIDE_SPECIFIERS0x0004ULL +#define _CRT_INTERNAL_PRINTF_LEGACY_MSVCRT_COMPATIBILITY 0x0008ULL +#define _CRT_INTERNAL_PRINTF_LEGACY_THREE_DIGIT_EXPONENTS 0x0010ULL + +#define _CRT_INTERNAL_SCANF_SECURECRT0x0001ULL +#define _CRT_INTERNAL_SCANF_LEGACY_WIDE_SPECIFIERS 0x0002ULL +#define _CRT_INTERNAL_SCANF_LEGACY_MSVCRT_COMPATIBILITY 0x0004ULL + +#ifndef _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS +#define _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS _CRT_INTERNAL_PRINTF_LEGACY_WIDE_SPECIFIERS +#endif + +#ifndef _CRT_INTERNAL_LOCAL_SCANF_OPTIONS +#define _CRT_INTERNAL_LOCAL_SCANF_OPTIONS _CRT_INTERNAL_SCANF_LEGACY_WIDE_SPECIFIERS +#endif + +#endif /* _STDIO_CONFIG_DEFINED */ diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h index 1284e0ba..34392849 100644 --- a/mingw-w64-headers/crt/stdio.h +++ b/mingw-w64-headers/crt/stdio.h @@ -6,7 +6,7 @@ #ifndef _INC_STDIO #define _INC_STDIO -#include +#include #pragma pack(push,_CRT_PACKING) ___ 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: Provide _vscprintf as a non-inline function for UCRT
On 09.03.2020 10:41, Martin Storsjö wrote: The libmingwex implementation of asprintf requires a _vscprintf now, and that implementation is supposed to be agnostic of the underlying CRT type. The patch looks good to me. Thanks, Jacek ___ 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] headers: Do legacy null termination in vsnwprintf for UCRT
Hi Martin, On 09.03.2020 10:43, Martin Storsjö wrote: According to standard C99, the swprintf and vswprintf functions return a negative value if the buffer is insufficient (contrary to snprintf), and the contents of the buffer is undefined in this case. Both swprintf and vswprintf functions for UCRT end up calling this inline function. As far as I can see, UCRT calls it with UCRTBASE_PRINTF_DEFAULT_WIDE. Also, there is a duplicated declaration in wchar.h that would need a change (or move to corecrt_wstdio.h to avoid duplication). Thanks, Jacek ___ 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] include: Fix definition of VMR9AlphaBitmap
On 04.03.2020 18:39, Biswapriyo Nath wrote: The vmr9.idl file seems to be imported from wine headers but it's not present in wine-import.sh script. Can the vmr9.idl be added in wine-import script as well? Yes, after Nikolay's patch is committed to Wine. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] snprintf() vs. _snprintf()
On 24.02.2020 12:46, Jacek Caban wrote: On 24.02.2020 12:28, Martin Storsjö wrote: On Mon, 24 Feb 2020, Jacek Caban wrote: Still, the problematic commit tries to solve some problems that are already solved when using mingw-w64 *printf implementation. Since non-underscored does not exist in msvcrt.dll, it's our extension anyway. So how about making it always use __mingw_vsnprintf regardless of __USE_MINGW_ANSI_STDIO instead? Applications aware of msvcrt.dll will use underscored version which would end up straight in msvcrt.dll anyway, so it should be fine with them. I don't think that's desireable. As the msvcrt.dll _snprintf handles format strings differently (ms_printf vs gnu_printf etc), having e.g. fprintf and snprintf (when accessed from within the same translation unit) implemented with a different backend would be rather messy. I think the best way forward is the one with the least amount of surprises/changes - the already committed patch looks fine and fixes the null termination and return value, but it needs the patch I sent earlier today (or something similar) to make __ms_snprintf an alias for snprintf (for all the configure checks and similar that only tests linking without including stdio.h). Sure, that's fine with me. Actually, do we really need __ms_snprintf? Could we just use snprintf() in headers instead? Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] snprintf() vs. _snprintf()
On 24.02.2020 12:28, Martin Storsjö wrote: On Mon, 24 Feb 2020, Jacek Caban wrote: Still, the problematic commit tries to solve some problems that are already solved when using mingw-w64 *printf implementation. Since non-underscored does not exist in msvcrt.dll, it's our extension anyway. So how about making it always use __mingw_vsnprintf regardless of __USE_MINGW_ANSI_STDIO instead? Applications aware of msvcrt.dll will use underscored version which would end up straight in msvcrt.dll anyway, so it should be fine with them. I don't think that's desireable. As the msvcrt.dll _snprintf handles format strings differently (ms_printf vs gnu_printf etc), having e.g. fprintf and snprintf (when accessed from within the same translation unit) implemented with a different backend would be rather messy. I think the best way forward is the one with the least amount of surprises/changes - the already committed patch looks fine and fixes the null termination and return value, but it needs the patch I sent earlier today (or something similar) to make __ms_snprintf an alias for snprintf (for all the configure checks and similar that only tests linking without including stdio.h). Sure, that's fine with me. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] snprintf() vs. _snprintf()
Hi, I think that the best way forward is UCRT. When using UCRT, there is already no issue. We should probably revisit making that a default configuration. I don't agree with us trying to limit use to VC6 subset. Microsoft does not intentionally break applications and I'm pretty sure that removing functions from msvcrt.dll would break some applications and they are aware of that. Still, the problematic commit tries to solve some problems that are already solved when using mingw-w64 *printf implementation. Since non-underscored does not exist in msvcrt.dll, it's our extension anyway. So how about making it always use __mingw_vsnprintf regardless of __USE_MINGW_ANSI_STDIO instead? Applications aware of msvcrt.dll will use underscored version which would end up straight in msvcrt.dll anyway, so it should be fine with them. Thanks, Jacek ___ 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] dxva2api.idl: import from wine
Hi Biswapriyo, Sorry for the delay. On 07.02.2020 15:36, Biswapriyo Nath wrote: There is no regression, I have check it. I found a regression in wine-gecko build: /home/jacek/mozilla/wine-gecko-git/dom/media/platforms/wmf/WMFUtils.cpp: In function ‘HRESULT mozilla::wmf::DXVA2CreateDirect3DDeviceManager9(UINT*, IDirect3DDeviceManager9**)’: /home/jacek/mozilla/wine-gecko-git/dom/media/platforms/wmf/WMFUtils.cpp:257:23: error: ‘::DXVA2CreateDirect3DDeviceManager9’ has not been declared; did you mean ‘mozilla::wmf::DXVA2CreateDirect3DDeviceManager9’? 257 | ENSURE_FUNCTION_PTR(DXVA2CreateDirect3DDeviceManager9, dxva2.dll) Cheers, Jacek ___ 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/3] crt: Sync comments about libraries handled specially in Makefile.am
Hi Martin, Patches look good to me. Thanks, Jacek ___ 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 missing t to rstrtmgr.def
Hi Alex,
On 27/01/2020 06:32, Alex Henrie wrote:
Signed-off-by: Alex Henrie
---
The name of the library was already correct inside the def files
themselves and also in the rstrtmgr.def file for libarm32.
---
mingw-w64-crt/Makefile.in | 4 ++--
mingw-w64-crt/lib32/Makefile.am | 2 +-
mingw-w64-crt/lib32/{rstrmgr.def => rstrtmgr.def} | 0
mingw-w64-crt/lib64/Makefile.am | 2 +-
mingw-w64-crt/lib64/{rstrmgr.def => rstrtmgr.def} | 0
5 files changed, 4 insertions(+), 4 deletions(-)
rename mingw-w64-crt/lib32/{rstrmgr.def => rstrtmgr.def} (100%)
rename mingw-w64-crt/lib64/{rstrmgr.def => rstrtmgr.def} (100%)
I changed the patch to share .def files between all non-x86 archs and
pushed.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is it possible to import dxva2api.idl from wine?
On 26/01/2020 16:25, Biswapriyo Nath wrote: * Cause: - The dxva2api.idl in mingw-w64 is not complete. - Many definitions are required for msys2/vlc. Though the actual VLC repository imports it from wine. * Asking this because: - The copyright is different. - The diff seems to be too big but it is actually little -- some of them are indentation changes, some of them are due to change from ccp_quote to enumerations and structures. Yes, it would be nice to replace it with Wine version, but it requires a careful review. We don't want to cause regressions, so you'd need to make sure that all declarations present in current mingw-w64 are present in Wine version first. Also, as usual, some testing would be needed. Thanks, Jacek ___ 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] include: update thumbcache.idl
Hi, I just pushed an update from Wine containing those changes to git. There is no need for separated patches here. Updates from Wine are pre-approved and will be done as soon as someone (usually me) runs the script and pushes it. I do that one in a while, unless we have a particular reason to do it sooner. If you need a quicker update in the future, feel free to ping me. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] configure: Deprecate directx SDK option.
This is the final part of direct-x header move series. Please review. Signed-off-by: Jacek Caban --- mingw-w64-headers/Makefile.am | 2 -- mingw-w64-headers/configure.ac | 20 +--- 2 files changed, 5 insertions(+), 17 deletions(-) diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am index 9789725b..7d374ef9 100644 --- a/mingw-w64-headers/Makefile.am +++ b/mingw-w64-headers/Makefile.am @@ -25,11 +25,9 @@ nodist_sdkshead_HEADERS = _mingw_ddk.h noinst_HEADERS = crt/sdks/_mingw_ddk.h.in ddkheaddir = $(baseheaddir)/ddk -dxheaddir = $(baseheaddir) idlheaddir = $(baseheaddir) ddkhead_HEADERS = @DDKHEAD_LIST@ -dxhead_HEADERS = @DXHEAD_LIST@ idlhead_HEADERS = @IDLHEAD_LIST@ CLEANFILES = $(nodist_sdkshead_HEADERS) diff --git a/mingw-w64-headers/configure.ac b/mingw-w64-headers/configure.ac index 010ca099..ca044a88 100644 --- a/mingw-w64-headers/configure.ac +++ b/mingw-w64-headers/configure.ac @@ -44,7 +44,6 @@ SECHEAD_LIST="$srcdir/crt/sec_api/stralign_s.h" for i in c inl dlg h16 hxx rh ver; do BASEHEAD_LIST="$BASEHEAD_LIST "$srcdir/include/*.$i done -#FIXME: Add in base directx AC_MSG_CHECKING([whether to build a w32api package for Cygwin]) AC_ARG_ENABLE([w32api], @@ -95,31 +94,22 @@ AC_SUBST([SECSYSHEAD_LIST]) AC_MSG_CHECKING([for optional sdk headers]) AC_ARG_ENABLE([sdk], [AS_HELP_STRING([--enable-sdk=ARG], -[Add the desired SDK, where ARG can be one of ddk, directx, no or all. Default is all.])], +[Add the desired SDK, where ARG can be one of ddk, no or all. Default is all.])], [], [AS_VAR_SET([enable_sdk],[all])]) AS_CASE([$enable_sdk], [all|yes],[ -AS_VAR_SET([enable_sdk],[ddk,directx]) -AS_VAR_SET([enable_ddk],[yes]) -AS_VAR_SET([enable_directx],[yes])], +AS_VAR_SET([enable_sdk],[ddk]) +AS_VAR_SET([enable_ddk],[yes])], [ddk],[ AS_VAR_SET([enable_ddk],[yes])], [directx],[ -AS_VAR_SET([enable_directx],[yes])], +AC_MSG_WARN([Deprecated option: directx. directx headers are always enabled.])], [no],[], - [AC_MSG_ERROR([Invalid option: $enable_sdk. Please choose one of ddk, directx, no or all.])]) + [AC_MSG_ERROR([Invalid option: $enable_sdk. Please choose one of ddk, no or all.])]) AC_MSG_RESULT([$enable_sdk]) -AS_VAR_IF([enable_directx],[yes],[ -MINGW_HAS_DX=1 - ],[ -MINGW_HAS_DX=0 - ]) -AC_SUBST([DXHEAD_LIST]) -AC_SUBST([MINGW_HAS_DX]) - AS_VAR_IF([enable_ddk],[yes],[ DDKHEAD_LIST=$srcdir/ddk/include/ddk/*.h MINGW_HAS_DDK=1 ___ 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/3] headers: Get rid of check for DX headers presence.
On 20.01.2020 15:25, Liu Hao wrote: 在 2020/1/8 23:39, Jacek Caban 写道: It's no longer needed, it's always available. Signed-off-by: Jacek Caban --- mingw-w64-headers/include/d2d1.h | 121 --- mingw-w64-headers/include/ddrawgdi.h | 3 - mingw-w64-headers/include/strmif.idl | 17 3 files changed, 141 deletions(-) These patches look good to me. Please go ahead. Apologies for the very late response, and thanks for taking care of it. I pushed patches. Thanks for review. Jacek ___ 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] thumbcache.idl: import from wine
On 09.01.2020 10:05, Biswapriyo Nath wrote: * Required for msys2/Blender. * Makefile.in and configure script are not updated. Sorry for the delay. The patch looks good, I pushed it. Thanks, Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 3/3] headers: Remove remaining direct-x directory usage.
Signed-off-by: Jacek Caban --- I plan to amend git rm -f direct-x to this patch before pushing it. mingw-w64-headers/Makefile.am | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/mingw-w64-headers/Makefile.am b/mingw-w64-headers/Makefile.am index 9a8e3cc0..6bbf5bb7 100644 --- a/mingw-w64-headers/Makefile.am +++ b/mingw-w64-headers/Makefile.am @@ -36,7 +36,7 @@ CLEANFILES = $(nodist_sdkshead_HEADERS) DISTCHECK_CONFIGURE_FLAGS = --enable-crt --enable-sdk=all --enable-idl -EXTRA_DIST = $(srcdir)/ChangeLog.* include crt direct-x ddk tlb +EXTRA_DIST = $(srcdir)/ChangeLog.* include crt ddk tlb dist-hook: find $(distdir) -name ".svn" -type d -delete @@ -61,8 +61,6 @@ EXTRA_HEADERS = \ crt/sys/*.h \ crt/sec_api/*.h \ crt/sec_api/sys/*.h \ - direct-x/include/*.h \ - direct-x/include/*.idl \ ddk/include/ddk/*.h \ tlb/*.tlb @@ -245,7 +243,7 @@ TLB_SRCS = \ BUILT_SOURCES = $(IDL_SRCS:.idl=.h) $(TLB_SRCS:.idl=.tlb) .idl.h: crt/_mingw.h - $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -I$(srcdir)/direct-x/include -Icrt -I$(srcdir)/crt -h -o $@ $< + $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -Icrt -I$(srcdir)/crt -h -o $@ $< .idl.tlb: $(WIDL) -I$(srcdir)/include -t -o $@ $< ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
