[Mingw-w64-public] [PATCH] headers: Add void parameter in EarlyStartDisplaySystem() in mshtmhst.idl.
From 7a0742229b7d4bbe92ca5c93cc7825754b35f80e Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Mon, 14 Dec 2020 13:02:43 +0530
Subject: [PATCH] headers: Add void parameter in EarlyStartDisplaySystem() in
mshtmhst.idl.
Signed-off-by: Biswapriyo Nath
---
mingw-w64-headers/include/mshtmhst.idl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-headers/include/mshtmhst.idl
b/mingw-w64-headers/include/mshtmhst.idl
index 48ab58d..a23c39e 100644
--- a/mingw-w64-headers/include/mshtmhst.idl
+++ b/mingw-w64-headers/include/mshtmhst.idl
@@ -79,7 +79,7 @@ cpp_quote("#if !defined (_ARM_) && !defined (__arm__)")
cpp_quote("STDAPI RunHTMLApplication (HINSTANCE hinst, HINSTANCE hPrevInst,
LPSTR szCmdLine, int nCmdShow);")
cpp_quote("#endif")
cpp_quote("STDAPI CreateHTMLPropertyPage (IMoniker *pmk, IPropertyPage
**ppPP);")
-cpp_quote("STDAPI EarlyStartDisplaySystem ();")
+cpp_quote("STDAPI EarlyStartDisplaySystem (void);")
cpp_quote("STDAPI IERegisterXMLNS (LPCWSTR lpszURI, GUID clsid, BOOL
fMachine);")
cpp_quote("STDAPI IEIsXMLNSRegistered (LPCWSTR lpszURI, GUID *pCLSID);")
cpp_quote("STDAPI GetColorValueFromString (LPCWSTR lpszColor, BOOL
fStrictCSS1, BOOL fIsStandardsCSS, COLORREF *pColor);")
--
2.29.2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] include/intrin: Implement `_rot{l, r}{8, 16}` functions
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
---
.../include/psdk_inc/intrin-impl.h| 48 +++
1 file changed, 48 insertions(+)
diff --git a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
index 072a98f6..27cc26ac 100644
--- a/mingw-w64-headers/include/psdk_inc/intrin-impl.h
+++ b/mingw-w64-headers/include/psdk_inc/intrin-impl.h
@@ -607,6 +607,54 @@ unsigned long _lrotr(unsigned long __X, int __C)
#define __INTRINSIC_DEFINED__lrotr
#endif /* __INTRINSIC_PROLOG */
+#if __INTRINSIC_PROLOG(_rotl8)
+unsigned char _rotl8(unsigned char __X, unsigned char __C);
+#if !__has_builtin(_rotl8)
+__INTRINSICS_USEINLINE
+unsigned char _rotl8(unsigned char __X, unsigned char __C)
+{
+ return (__X << __C) | (__X >> (8 - __C));
+}
+#endif
+#define __INTRINSIC_DEFINED__rotl8
+#endif /* __INTRINSIC_PROLOG */
+
+#if __INTRINSIC_PROLOG(_rotr8)
+unsigned char _rotr8(unsigned char __X, unsigned char __C);
+#if !__has_builtin(_rotr8)
+__INTRINSICS_USEINLINE
+unsigned char _rotr8(unsigned char __X, unsigned char __C)
+{
+ return (__X >> __C) | (__X << (8 - __C));
+}
+#endif
+#define __INTRINSIC_DEFINED__rotr8
+#endif /* __INTRINSIC_PROLOG */
+
+#if __INTRINSIC_PROLOG(_rotl16)
+unsigned short _rotl16(unsigned short __X, unsigned char __C);
+#if !__has_builtin(_rotl16)
+__INTRINSICS_USEINLINE
+unsigned short _rotl16(unsigned short __X, unsigned char __C)
+{
+ return (__X << __C) | (__X >> (16 - __C));
+}
+#endif
+#define __INTRINSIC_DEFINED__rotl16
+#endif /* __INTRINSIC_PROLOG */
+
+#if __INTRINSIC_PROLOG(_rotr16)
+unsigned short _rotr16(unsigned short __X, unsigned char __C);
+#if !__has_builtin(_rotr16)
+__INTRINSICS_USEINLINE
+unsigned short _rotr16(unsigned short __X, unsigned char __C)
+{
+ return (__X >> __C) | (__X << (16 - __C));
+}
+#endif
+#define __INTRINSIC_DEFINED__rotr16
+#endif /* __INTRINSIC_PROLOG */
+
#if defined(__x86_64__) || defined(_AMD64_)
#if __INTRINSIC_PROLOG(__faststorefence)
--
2.29.2
signature.asc
Description: OpenPGP digital signature
___
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
