Re: [Mingw-w64-public] IExtractIcon missing functions
So, I came up with this bizarre idea. I copy only the IExtractIcon{A,
W} interfaces from Wine's shlobjidl.idl file and create a dummy
shobj.idl file in mingw-w64. Then I generate the header file and
replace the generated interface to our shlobj.h file manually
**without deleting other things**. Now LRN's example code compiles
fine. I have tentatively attached the patch.
From 2195459621ed895f8bcfeb8d2a8456963a3b4ce8 Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Fri, 8 Jan 2021 10:50:09 +0530
Subject: [PATCH 1/2] headers: Add shlobj.idl for IExtractIcon only.
Signed-off-by: Biswapriyo Nath
---
mingw-w64-headers/include/shlobj.idl | 89
1 file changed, 89 insertions(+)
create mode 100644 mingw-w64-headers/include/shlobj.idl
diff --git a/mingw-w64-headers/include/shlobj.idl
b/mingw-w64-headers/include/shlobj.idl
new file mode 100644
index 000..b179691
--- /dev/null
+++ b/mingw-w64-headers/include/shlobj.idl
@@ -0,0 +1,89 @@
+cpp_quote("/**")
+cpp_quote(" * This file is part of the mingw-w64 runtime package.")
+cpp_quote(" * No warranty is given; refer to the file DISCLAIMER within this
package.")
+cpp_quote(" */")
+cpp_quote("")
+
+/*
+ * WARNING: THIS IS A DUMMY FILE, AT LEAST FOR NOW.
+ * DO NOT REGENERATE HEADER FILE FROM THIS IDL FILE.
+*/
+
+import "objidl.idl";
+import "oleidl.idl";
+import "oaidl.idl";
+import "wtypes.idl";
+
+cpp_quote("#define GIL_OPENICON 0x0001")
+cpp_quote("#define GIL_FORSHELL 0x0002")
+cpp_quote("#define GIL_ASYNC0x0020")
+cpp_quote("#define GIL_DEFAULTICON 0x0040")
+cpp_quote("#define GIL_FORSHORTCUT 0x0080")
+cpp_quote("#define GIL_CHECKSHIELD 0x0200")
+
+cpp_quote("#define GIL_SIMULATEDOC 0x0001")
+cpp_quote("#define GIL_PERINSTANCE 0x0002")
+cpp_quote("#define GIL_PERCLASS 0x0004")
+cpp_quote("#define GIL_NOTFILENAME 0x0008")
+cpp_quote("#define GIL_DONTCACHE0x0010")
+cpp_quote("#define GIL_SHIELD 0x0200")
+cpp_quote("#define GIL_FORCENOSHIELD 0x0400")
+
+/*
+ * IExtractIconA interface
+ */
+[
+object,
+uuid(000214eb---c000-0046),
+pointer_default(unique),
+local
+]
+interface IExtractIconA : IUnknown
+{
+HRESULT GetIconLocation(
+[in] UINT uFlags,
+[out, size_is(cchMax)] LPSTR szIconFile,
+[in] UINT cchMax,
+[out] INT *piIndex,
+[out] UINT *pwFlags);
+
+HRESULT Extract(
+[in] LPCSTR pszFile,
+[in] UINT nIconIndex,
+[out] HICON *phiconLarge,
+[out] HICON *phiconSmall,
+[in] UINT nIconSize );
+}
+
+/*
+ * IExtractIconW interface
+ */
+[
+object,
+uuid(000214fa---c000-0046),
+pointer_default(unique),
+local
+]
+interface IExtractIconW : IUnknown
+{
+HRESULT GetIconLocation(
+[in] UINT uFlags,
+[out, size_is(cchMax)] LPWSTR szIconFile,
+[in] UINT cchMax,
+[out] INT *piIndex,
+[out] UINT *pwFlags);
+
+HRESULT Extract(
+[in] LPCWSTR pszFile,
+[in] UINT nIconIndex,
+[out] HICON *phiconLarge,
+[out] HICON *phiconSmall,
+[in] UINT nIconSize );
+}
+
+cpp_quote("typedef IExtractIconA *LPEXTRACTICONA;")
+cpp_quote("typedef IExtractIconW *LPEXTRACTICONW;")
+
+cpp_quote("#define IExtractIcon __MINGW_NAME_AW(IExtractIcon)")
+cpp_quote("#define IExtractIconVtbl __MINGW_NAME_AW_EXT(IExtractIcon,Vtbl)")
+cpp_quote("#define LPEXTRACTICON __MINGW_NAME_AW(LPEXTRACTICON)")
--
2.30.0
From 3052196849b27d4afea735c1df2acf34670adbea Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Fri, 8 Jan 2021 10:50:40 +0530
Subject: [PATCH 2/2] headers: Replace IExtractIcon with widl generated
declarations.
Signed-off-by: Biswapriyo Nath
---
mingw-w64-headers/include/shlobj.h | 240 +++--
1 file changed, 226 insertions(+), 14 deletions(-)
diff --git a/mingw-w64-headers/include/shlobj.h
b/mingw-w64-headers/include/shlobj.h
index be087c4..411e954 100644
--- a/mingw-w64-headers/include/shlobj.h
+++ b/mingw-w64-headers/include/shlobj.h
@@ -129,6 +129,24 @@ extern "C" {
#include
+/* Forward declarations */
+
+#ifndef __IExtractIconA_FWD_DEFINED__
+#define __IExtractIconA_FWD_DEFINED__
+typedef interface IExtractIconA IExtractIconA;
+#ifdef __cplusplus
+interface IExtractIconA;
+#endif /* __cplusplus */
+#endif
+
+#ifndef __IExtractIconW_FWD_DEFINED__
+#define __IExtractIconW_FWD_DEFINED__
+typedef interface IExtractIconW IExtractIconW;
+#ifdef __cplusplus
+interface IExtractIconW;
+#endif /* __cplusplus */
+#endif
+
SHSTDAPI SHGetMalloc (IMalloc **ppMalloc);
SHSTDAPI_(void *) SHAlloc (SIZE_T cb);
SHSTDAPI_(void) SHFree (void *pv);
@@ -148,22 +166,216 @@ extern "C" {
#define GIL_SHIELD 0x200
#define GIL_FORCENOSHIELD 0x400
-#undef INTERFACE
-#define INTERFACE IExtractIconA
- DECLARE_INTERFACE_IID_
Re: [Mingw-w64-public] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.
Hi Martin, Sorry for the delay. On 04.01.2021 21:16, Martin Storsjö wrote: Hi, On Mon, 4 Jan 2021, Jacek Caban wrote: FWIW, I think that the attached patch should do the right thing on VLC (but I don't really have setup to test it). Thanks, looks like that could be enough - I'll try to get time to think through and test the potential combinations. A different case that came to mind now is ffmpeg; http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=900505756bf6fb734708da6278689037157fc53a;hb=0cd8769207f1a89fc2236aab9da1c77f5a0b490a#l5628 I guess the fix here would be to do the check without including a header first, to check whether it was defined in cflags. Then again, I just checked building with -D_WIN32_WINNT=0xA00, and the binary started on Vista, so there doesn't seem to be any configure tests for features above that anyway. ffmpeg use seems fine to me. They just make sure that it's high enough to have required declarations available. It doesn't seem to make any runtime decision based on _WIN32_WINNT value. It sounds lime msys2 will not be affected. I don't mind waiting with committing this patch if helps. I only think that it would be good to commit relatively early in release cycle so that we have time to address feedback. At this point, I don't think there's need to wait any more; it'd better to get it out there and see what it breaks, if anything, sooner rather than later. (And my setups already override it to win7 anyway, but I guess I could consider leaving it to the default if it's higher.) Sounds good to me, I pushed the commit. 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. Yeah, that's probably a separate discussion. And before doing it, I guess we should quantify what we actually gain from it, instead of just doing it for the sake of doing it. Being able to rely on more features in msvcrt.dll (for setups that use it) probably would be one thing. I'd be tempted to consider defaulting to UCRT, but I realize that it has serious compatibility implications. If we decided to do it, it would make msvcrt.dll setup much less important (and maybe even a way to keep optional compatibility with older Windows). It seems to me that llvm-mingw is successful defaulting to UCRT, do you think it makes sense for upstream default? Well, that comes with a bit bigger incompatibility, as it breaks most existing precompiled static libraries. In a sense, that's not new. We already caused them to be incompatible many times while changing crt. Of course we try to keep compatibility as much as possible, but it's often needed if we want to progress. An example of such changes is moving things to libmsvcrt.a to be able to better support both ucrt and classic msvcrt.dll. We already did it, so it's already true that if you mix static libraries with random toolchain versions, you may run into a problem. I'm not aware of any large scale practical problems caused by this (but I may be missing something). Of course a switch to ucrt is an order of magnitude more impactful to static libraries, but my feeling is that ecosystem can deal with such changes. I may be too optimistic about this, through. That's easier for llvm-mingw anyway, as it's mostly incompatible (due to libc++) - so it's mostly convenient where you build everything from scratch everytime. But even there, I've now started providing msvcrt.dll based builds (for people who want to target older versions where UCRT isn't guaranteed to be available, and for compatibility with precompiled non-C++ static libraries). I see, so there is still enough interest in that. It also means that it would be good to not break it on mingw-w64 crt side. I guess that keeping msvcrt.dll based crt in its current form is easy. If we want to use newer features in common (mingwex) code, we can move even more of it to lib*cr* libraries, keep old behavior in old libraries and use code depending on newer Windows versions only in ucrt. I can imagine going as far as moving entire entry point implementations, if it comes to this. This way old platforms could miss new features, but would not regress. AFAIK msys2 are considering switching to this as well, but it's in one sense a much bigger break. It will be interesting to see how it goes. 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] IExtractIcon missing functions
On 07.01.2021 23:36, Biswapriyo Nath wrote: Do you have any project which requires those APIs declarations? It would be better to have a test project. I wrote a test program[0] for a GLib issue 2096 that uses this functionality. [0]: https://gitlab.gnome.org/GNOME/glib/-/issues/2096#note_997704 -- O< ascii ribbon - stop html email! - www.asciiribbon.org OpenPGP_signature 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] IExtractIcon missing functions
Do you have any project which requires those APIs declarations? It would be better to have a test project. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
