[Mingw-w64-public] [PATCH 2/3] ksuser: Add KSCATEGORY_VIDEO_CAMERA declaration.

2021-10-14 Thread Jacek Caban

Signed-off-by: Jacek Caban 
---
 mingw-w64-crt/libsrc/ksuser.c | 1 +
 1 file changed, 1 insertion(+)


diff --git a/mingw-w64-crt/libsrc/ksuser.c b/mingw-w64-crt/libsrc/ksuser.c
index 3cc7f1e33..b5e37fa7c 100644
--- a/mingw-w64-crt/libsrc/ksuser.c
+++ b/mingw-w64-crt/libsrc/ksuser.c
@@ -129,6 +129,7 @@ DEFINE_GUID(KSCATEGORY_TVAUDIO,0xa799a802,0xa46d,0x11d0,0xa1,0x8c,0,0xa0,0x24,0x
 DEFINE_GUID(KSCATEGORY_TVTUNER,0xa799a800,0xa46d,0x11d0,0xa1,0x8c,0,0xa0,0x24,0x1,0xdc,0xd4);
 DEFINE_GUID(KSCATEGORY_VBICODEC,0x7dad660,0x22f1,0x11d1,0xa9,0xf4,0,0xc0,0x4f,0xbb,0xde,0x8f);
 DEFINE_GUID(KSCATEGORY_VIDEO,0x6994ad05,0x93ef,0x11d0,0xa3,0xcc,0,0xa0,0xc9,0x22,0x31,0x96);
+DEFINE_GUID(KSCATEGORY_VIDEO_CAMERA,0xe5323777,0xf976,0x4f5b,0x9b,0x55,0xb9,0x46,0x99,0xc4,0x6e,0x44);
 DEFINE_GUID(KSCATEGORY_VIRTUAL,0x3503eac4,0x1f26,0x11d1,0x8a,0xb0,0,0xa0,0xc9,0x22,0x31,0x96);
 DEFINE_GUID(KSCATEGORY_VPMUX,0xa799a803,0xa46d,0x11d0,0xa1,0x8c,0,0xa0,0x24,0x1,0xdc,0xd4);
 DEFINE_GUID(KSCATEGORY_WDMAUD,0x3e227e76,0x690d,0x11d2,0x81,0x61,0,0,0xf8,0x77,0x5b,0xf1);

___
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] winuser.h: Add PW_RENDERFULLCONTENT define.

2021-10-14 Thread Jacek Caban

Signed-off-by: Jacek Caban 
---
 mingw-w64-headers/include/winuser.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)


diff --git a/mingw-w64-headers/include/winuser.h b/mingw-w64-headers/include/winuser.h
index 01f2a5be4..7252a53ea 100644
--- a/mingw-w64-headers/include/winuser.h
+++ b/mingw-w64-headers/include/winuser.h
@@ -2241,7 +2241,10 @@ extern "C" {
 #if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
   WINUSERAPI WINBOOL WINAPI GetLayeredWindowAttributes (HWND hwnd, COLORREF *pcrKey, BYTE *pbAlpha, DWORD *pdwFlags);
 
-#define PW_CLIENTONLY 0x0001
+#define PW_CLIENTONLY 0x0001
+#if _WIN32_WINNT >= 0x0603
+#define PW_RENDERFULLCONTENT  0x0002
+#endif
 
   WINUSERAPI WINBOOL WINAPI PrintWindow (HWND hwnd, HDC hdcBlt, UINT nFlags);
   WINUSERAPI WINBOOL WINAPI SetLayeredWindowAttributes (HWND hwnd, COLORREF crKey, BYTE bAlpha, DWORD dwFlags);

___
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/3] crt: Include windowscodecs.c in libuuid.a.

2021-10-14 Thread Jacek Caban

Signed-off-by: Jacek Caban 
---
That seems to match recent Windows SDK.

 mingw-w64-crt/Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 78d9a0a59..e889185a0 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -145,7 +145,8 @@ src_libuuid=\
   libsrc/ntddser-uuid.c   libsrc/ntddstor-uuid.clibsrc/ntddvdeo-uuid.clibsrc/oaidl-uuid.c libsrc/objidl-uuid.c   \
   libsrc/objsafe-uuid.c   libsrc/ocidl-uuid.c   libsrc/oleacc-uuid.c  libsrc/olectlid-uuid.c  libsrc/oleidl-uuid.c   \
   libsrc/power-uuid.c libsrc/powrprof-uuid.clibsrc/uianimation-uuid.c libsrc/usbcamdi-uuid.c  libsrc/usbiodef-uuid.c \
-  libsrc/uuid.c   libsrc/vds-uuid.c libsrc/virtdisk-uuid.clibsrc/wia-uuid.c
+  libsrc/uuid.c   libsrc/vds-uuid.c libsrc/virtdisk-uuid.clibsrc/wia-uuid.c \
+  libsrc/windowscodecs.c
 
 src_libws2_32=libsrc/ws2_32.c \
   \

___
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] wtypes.h: replace #include <...> with #include "..." for rpc

2021-09-05 Thread Jacek Caban

On 9/5/21 4:54 PM, LIU Hao wrote:

在 2021-09-04 23:53, JonY via Mingw-w64-public 写道:


I am OK with updating them to use double quotes but have no strong 
preference anyway since it has been using angular brackets for a long 
time.





So this change is okay, but... I have noticed that wtypes.h is 
generated from wtypes.idl, which contains no reference to  or 
. I don't know where those includes come from. Jacek, do you 
have any ideas?



They come from widl, so if we want this change, then widl needs to be 
changed instead. It looks like the reverse was done in the past:


https://source.winehq.org/git/wine.git/commitdiff/0bde2bbe010c68a54f8928469e89637a2322ae44

I don't know what was the reasoning there, it seems fine to change it back.


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] wtypes.h: replace #include <...> with #include "..." for rpc

2021-09-03 Thread Jacek Caban

Hi Jonathan,

On 9/3/21 11:48 PM, Jonathan Marler wrote:

Been another 4 days, anyone able to bring this patch in or review?



Your patch never arrived to the mailing list, it looks like the 
attachment is missing.



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 propvarutil.h from wine

2021-07-20 Thread Jacek Caban

On 7/20/21 4:58 PM, John Warburton wrote:

On Tue, 20 Jul 2021 at 15:09, Biswapriyo Nath 
wrote:


Apology for my mistake. It has been fixed today in wine by Jacek Caban
in this commit[1].

Thank you for checking this.

I am testing a build now.

Whoops. I forgot. That's Wine -- will wait for mingw-w64 to be altered.



I just pushed an update.


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] Discussion: Need new function declarations in propvarutil.h from wine

2021-07-16 Thread Jacek Caban

On 7/12/21 9:15 AM, LIU Hao wrote:

在 7/12/21 2:44 PM, Biswapriyo Nath 写道:

Would you like to upstream that change? I am not the author of that
commit and don't know why it was added. qt6-multimedia compiles fine
without that NTSTATUS re-definition.




FWIW, that typedef thing is a declaration, rather than a definition. 
This means that duplicates of such typedefs are allowed as long as 
they don't disagree with each other. I think the `#if...#endif` check 
may be removed.



Sure, so we don't need to worry about syncing guard names, I sent a 
patch to Wine:


https://source.winehq.org/patches/data/209719


There is another problem introduced by:

https://source.winehq.org/git/wine.git/commitdiff/4f52e32205fc3cc3f09adf6d7ff961c36e3b1f4d

I sent a fix:

https://source.winehq.org/patches/data/209718


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] Discussion: Need new function declarations in propvarutil.h from wine

2021-07-11 Thread Jacek Caban

On 7/11/21 3:26 PM, Biswapriyo Nath wrote:

Option 1: Import propvarutil.h from wine. But that reverts this commit
propvarutil.h: Added NTSTATUS declaration (d603db2). Before that
commit propvarutil.h was imported from wine. I have compiled
qt6-multimedia without that NTSTATUS declaration.
Option 2: Add new function declarations manually.
So, which one will be better?



Option 3: upsteram d603db2 to Wine and then import the header to 
mingw-w64. Wine uses a different guard macro, so this will need to be 
synced as well.



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: Don't initialize lconv to unsigned char mode

2021-06-11 Thread Jacek Caban

On 6/11/21 3:51 AM, Liu Hao wrote:

在 6/11/21 4:09 AM, Martin Storsjö 写道:

Since the initial commit of mingw-w64, there's a call (in a
constructor in crt/charmax.c, pulled in via the mingw_initcharmax
variable) to __lconv_init(), which reconfigures the CRT's lconv
info to unsigned char mode - but there's no explanation for why
this is the case.

The fact that mingw-w64 initializes lconv info this way breaks
a test in llvm's libc++ (where it expects lconv's frac_digits to
be intialized to CHAR_MAX, not UCHAR_MAX). This also differs to
how MSVC environments behave, where they are initialized to
CHAR_MAX.

So unless there's a clear known reason why we'd initialize it
to unsigned char mode, revert to the same behaviour as MSVC has.

Signed-off-by: Martin Storsjö 
---
  mingw-w64-crt/crt/crtexe.c | 2 --
  1 file changed, 2 deletions(-)




This patch looks good to me.



Looks good to me as well. I'm not sure if we want to keep charmax.c at 
all, or change default _charmax value, but it doesn't need to block 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] include/intrin-impl: Don't define `__cpuidex` for GCC 11

2021-05-23 Thread Jacek Caban

On 20/05/2021 17:46, Liu Hao wrote:


在 2021-05-20 22:40, Jacek Caban 写道:



We could #undef __cpuid just after including cpuid.h.




Updated patch is attached.



The whole thing is really a hack, but I don't see a better solution, so 
it looks fine 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] include/intrin-impl: Don't define `__cpuidex` for GCC 11

2021-05-20 Thread Jacek Caban

On 5/20/21 4:37 PM, Liu Hao wrote:

在 2021-05-20 22:29, Jacek Caban 写道:

On 5/20/21 4:21 PM, Liu Hao wrote:

+#if (!defined(__GNUC__) || __GNUC__ < 11)
  __MACHINEI(void __cpuid(int a[4],int b))
+#endif


__cpuid is a macro in both older GCCs and clang, so it will probably 
not work there. It's also present in intrin-impl.h.





So what should we do? Can we just comment it out?



We could #undef __cpuid just after including cpuid.h.


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-impl: Don't define `__cpuidex` for GCC 11

2021-05-20 Thread Jacek Caban

On 5/20/21 4:21 PM, Liu Hao wrote:

+#if (!defined(__GNUC__) || __GNUC__ < 11)
  __MACHINEI(void __cpuid(int a[4],int b))
+#endif


__cpuid is a macro in both older GCCs and clang, so it will probably not 
work there. It's also present in intrin-impl.h.



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-impl: Don't define `__cpuidex` for GCC 11

2021-05-20 Thread Jacek Caban

Hi Liu,

On 5/10/21 6:45 PM, Liu Hao wrote:

Subject: [PATCH] include/intrin-impl: Don't define `__cpuidex` for GCC 11

GCC 11 has this as a static inline function without any indicative
macros.

Reference:https://github.com/gcc-mirror/gcc/blob/23855a176609fe8dda6abaf2b21846b4517966eb/gcc/config/i386/cpuid.h#L333



As far as I can see, cpuid.h is not included by any other header shipped 
with GCC. It means that with your changes, users will would need to 
start including it themselves in addition to intrin.h.



For similar cases with other *intrin.h headers provided by GCC, we 
simply include them from intrin.h to avoid collisions. cpuid.h is risky 
in this regard, because it seems to provide way more than we want. But 
maybe that's fine...



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] __CRT_UUID_DECL in namespace causes error

2021-05-17 Thread Jacek Caban

On 5/14/21 11:20 AM, Biswapriyo Nath wrote:

If an interface declaration is moved inside a namespace
__CRT_UUID_DECL produces error. The error is: explicit specialization
of 'template const GUID& __mingw_uuidof()' outside its
namespace must use a nested-name-specifier [-fpermissive].

A simple reproducible code is attached (test.cpp). The same thing
happen with qtmultimedia/src/plugins/wmf/player/mfvideorenderercontrol.cpp
file of branch 5.15.2.



It looks to me like something that should be fixed in Qt by putting the 
macro in a global namespace. widl already does that for interfaces 
declared in IDL files. There is little we can do on mingw-w64 side 
(unless I'm missing something). Obviously ideal solution would be to 
implement proper support for __uuidof in GCC...



On semi-related note, the definition was changed on Wine and it may be 
interesting to get ported to mingw-w64:


https://source.winehq.org/git/wine.git/blob/HEAD:/include/guiddef.h#l53

https://source.winehq.org/git/wine.git/commitdiff/51b75e9a534d8c6021bbcc71889e3c154f0f84ea


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] wine FTBFS with mingw64 gcc 11: undefined reference to `sincos'

2021-05-15 Thread Jacek Caban

On 15/05/2021 04:24, lhmouse wrote:


在 5/15/21 1:27 AM, Jacek Caban 写道:

I think that the decision was unfortunate on GCC side, but there is little we 
can do. We will
probably need to provide it in msvcrt importlibs. Please try the attached 
patch, it should help.



Doesn't GCC transform such pair of calls to `sincos()` again and result in an 
infinite recursion?



The patched file is built with -fno-builtin, so it should be fine.


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] wine FTBFS with mingw64 gcc 11: undefined reference to `sincos'

2021-05-14 Thread Jacek Caban

Hi Alex,

On 5/14/21 3:01 AM, Alex Xu (Hello71) wrote:

Hi,

I tried building wine 6.8 with mingw. All fine, just one problem, it
reports error "undefined reference to `sincos'". Why, you may ask, since
wine never calls sincos function? Well, it seems to be because mingw gcc
11 enables sincos optimization: [0]. But, wine uses -nodefaultlibs,
intending to provide libc functions with msvcrt; however, wine msvcrt
doesn't implement any sincos. So, there is a mismatch: gcc accepts mingw
claim to implement sincos (ok since mingwex implements it), then
generates call to sincos, then fails at link time (because msvcrt does
not implement it).

After adding -fno-builtin-{sin,cos}{,f} to CFLAGS, wine compiled and ran
OK.

This issue seems to be worked around for winelib builds by adding
-fno-builtin, so that gcc will not generate sincos (or most other
problematic functions).

I think this issue could be worked around by adding those -fno-builtin-*
flags for mingw builds. However, I think the sin/cos->sincos
optimization is a good one, so maybe we could instead add sincos
forwarder in msvcrt (calling sin+cos separately in case sincos is not
implemented in libc?).

CCed mingw-w64-public@lists.sourceforge.net due to potential relevance
and felixonm...@archlinux.org due to maintaining wine and mingw-gcc on
Arch. You may need to subscribe in order to reply all. I look forward to
hearing your thoughts.



I think that the decision was unfortunate on GCC side, but there is 
little we can do. We will probably need to provide it in msvcrt 
importlibs. Please try the attached patch, it should help.



Thanks,

Jacek

diff --git a/dlls/msvcrt/mathf.c b/dlls/msvcrt/mathf.c
index 4038bdb4cf7..3cd5377f1e4 100644
--- a/dlls/msvcrt/mathf.c
+++ b/dlls/msvcrt/mathf.c
@@ -67,3 +67,15 @@ float exp2f(float x) { return powf(2.0f, x); }
 __ASM_GLOBAL_IMPORT(exp2)
 __ASM_GLOBAL_IMPORT(exp2f)
 #endif
+
+void sincos(double x, double *s, double *c)
+{
+*s = sin(x);
+*c = cos(x);
+}
+
+void sincosf(float x, float *s, float *c)
+{
+*s = sinf(x);
+*c = cosf(x);
+}
___
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: Increase precision of gettimeofday() if possible.

2021-05-03 Thread Jacek Caban

On 5/3/21 2:52 PM, Martin Storsjö wrote:

On Mon, 3 May 2021, Christian Franke wrote:

Would plain '... = 0' without cast also work ? IIRC it should since 
C89 :-)


That doesn't work either - clang seems to consider the cast (either 
implicit or explicit) between a integer or pointer-to-integer and a 
pointer-to-function as something which isn't a compile time constant, 
in this context...


Alternative: Leave '/* = 0 */' only as a comment. There is no need to 
set a static variable to 0.


That would work.

But the overall question remains - we don't really require a C11 
compiler for this yet, so use of that kind of atomics is a bit odd 
overall. If we use it, I think we should have to bump the requirement 
by explicitly building with -std=gnu11 or something like that. If we 
go that way, I think we should use C11 atomics for all of it, i.e. 
replace InterlockedCompareExchangePointer with a C11 equivalent.


Or go the other way, and use Interlocked* for both reads and updates 
of it (and then the variable itself doesn't need to be declared 
_Atomic, afaik).


Or just skip that aspect altogether and just blindly update the 
pointer variable; that's what's done in every existing case of 
GetProcAddress lazy loading in mingw-w64-crt. 



I'd say that we should skip it altogether. Atomic operations seem 
totally redundant in this case. What would it protect from? It won't 
prevent multiple GetProcAddress calls - for that we'd need a critical 
section. Since GetProcAddress will always return the same pointer, 
setting the static pointer multiple times is harmless.



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 symbols for POSIX time functions

2021-03-31 Thread Jacek Caban

On 31.03.2021 15:12, Martin Storsjö wrote:

On Wed, 31 Mar 2021, Liu Hao wrote:


在 2021/3/31 下午7:46, Martin Storsjö 写道:


Hmm, if MSVC defaults to a 64 bit time_t in 32 bit mode these days, 
I think we should too, for UCRT. (Technically I guess it's an ABI 
break, but I'd be quite comfortable doing it, while I'd be less 
comfortable changing any defaults for msvcrt.dll targets.)





It is not only 'these days'. Even with VS2013, when CL.EXE is invoked 
from command line, the default size of `time_t` will be 8 bytes, no 
matter whether to target x86 or x64, unless `_USE_32BIT_TIME_T` is 
defined, in which case it is 4 bytes.



```c
/* Run these commands in 'VS2013 x86 Native Tools Command Prompt':
*
*   cl test.c && test.exe
*   cl /D_USE_32BIT_TIME_T test.c && test.exe
**/

#include 
#include 

int main(void)
 {
   printf("sizeof(time_t) = %d\n", (int)sizeof(time_t));
 }
```


Fair point, it's probably been doing the sensible thing for quite a 
while now already. But anyway, we probably shouldn't be changing the 
defaults for msvcrt.dll targets, but for UCRT I think we are much more 
excused to be changing things. 



Agreed, I think that it would be better to use 64-bit time_t by default 
for UCRT.



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: Update the layout of struct _iobuf to match the layout used in UCRT

2021-03-26 Thread Jacek Caban

On 26/03/2021 12:22, Martin Storsjö wrote:

As there's no code that could be using the new UCRT spelling using any 
public headers, there's nothing we can try to remain compatible with 
in that case, so we'd only be setting new predecent (i.e. if building 
with mingw headers, and iff targeting UCRT, then access the field with 
a different name).


I.e., I'm a bit hesitant about whether we should be doing this at all, 
or if we should follow suit and make it a similar struct containing 
only the first member instead? 



In my opinion it was the right call by Microsoft to do that, so it would 
be nice to follow.



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 08/20] headers: move EventHandler delegate in windows.foundation.idl

2021-03-09 Thread Jacek Caban

Hi Steve,

On 09.03.2021 15:03, Steve Lhomme wrote:

  .../include/windows.foundation.collections.idl| 6 --
  mingw-w64-headers/include/windows.foundation.idl  | 8 
  2 files changed, 8 insertions(+), 6 deletions(-)



windows.foundation.collections.idl is imported from Wine, please send 
changes there. I was hoping to import windows.foundation.idl as well 
once Wine's version is in good enough shape.



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 deprecated `_{str, wcs}lwrt` aliases in DEF

2021-02-05 Thread Jacek Caban

On 05.02.2021 13:14, Liu Hao wrote:

在 2021-02-05 15:16, JonY via Mingw-w64-public 写道:


Your attached patch seems fine to me, please go ahead and push.




Thanks, pushed. What about the others?



They all 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] headers: Import wmp.idl from wine.

2021-01-31 Thread Jacek Caban

Hi,


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] IExtractIcon missing functions

2021-01-13 Thread Jacek Caban

On 11.01.2021 18:37, Biswapriyo Nath wrote:

Hmmm why aren't those IDLs imported from Wine?

1. Huge confusion. IExtractIcon is in -- shlobj_core.h in WinSDK,
shlobjidl.idl in wine, shlobj.h in mingw-w64.
2. Files differ largely between mingw-w64 and wine.



We still may import them, it's just more work. We could make it more 
compatible with Windows SDK in Wine if needed. We'd need also to make 
sure that by importing we will not lose any declarations and then we can 
import them.



BTW, it's shobjidl.idl (without 'l') and it exists in Windows SDK.


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.

2021-01-07 Thread Jacek Caban

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] [PATCH] headers: Use Windows 10 as default _WIN32_WINNT value.

2021-01-04 Thread Jacek Caban

On 31.12.2020 21:31, Martin Storsjö wrote:

On Thu, 31 Dec 2020, Jacek Caban wrote:

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.


Fair enough, yes, that's a correct distinction to make here I guess.

I guess that was the core part of my doubts regarding this, so with 
that cleared, I won't object to this change.


I still think there's a risk that it'll break (or more subtly, affect) 
a handful of projects (I need to revisit VLC's configure, for 
instance), so some general headsup to e.g. the msys2 project probably 
is warranted though.



FWIW, I think that the attached patch should do the right thing on VLC 
(but I don't really have setup to test it). If I'd choose the way to 
handle it myself, I'd set it always to win10 and have separated macro 
like VLC_MIN_WIN32 which I'd use internally, but current use should be 
perfectly fine with something like the patch.



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.



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?



Thanks,

Jacek

diff --git a/configure.ac b/configure.ac
index 96e47b1969..45b26bf8f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -264,11 +264,6 @@ case "${host_os}" in
 AC_PREPROC_IFELSE([AC_LANG_PROGRAM(
   [[#ifdef _WIN32_WINNT
# error _WIN32_WINNT already defined
-   #else
-   # include 
-   # if defined(_WIN32_WINNT) && _WIN32_WINNT >= 0x0601
-   #  error _WIN32_WINNT toolchain default high enough
-   # endif
#endif
   ]],[[;]])
 ],[
___
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.

2020-12-31 Thread Jacek Caban

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.

2020-12-28 Thread Jacek Caban

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.

2020-12-28 Thread Jacek Caban

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.

2020-12-26 Thread Jacek Caban

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

2020-12-20 Thread Jacek Caban

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.

2020-12-20 Thread Jacek Caban

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

2020-12-19 Thread Jacek Caban

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

2020-12-18 Thread Jacek Caban

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

2020-12-17 Thread Jacek Caban

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

2020-12-15 Thread Jacek Caban

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

2020-12-15 Thread Jacek Caban

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.

2020-12-15 Thread Jacek Caban

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.

2020-12-15 Thread Jacek Caban

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

2020-12-14 Thread Jacek Caban

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

2020-12-14 Thread Jacek Caban

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

2020-12-14 Thread Jacek Caban

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

2020-12-14 Thread Jacek Caban

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

2020-12-13 Thread Jacek Caban

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

2020-12-10 Thread Jacek Caban

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] [PATCH] headers: Include stdio.h in comutil.h for _COM_PRINTF_S_1 macro.

2020-12-07 Thread Jacek Caban

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] d2d1_1.h : plenty of C API missing

2020-11-04 Thread Jacek Caban

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.

2020-10-14 Thread Jacek Caban

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.

2020-10-13 Thread Jacek Caban


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

2020-09-24 Thread Jacek Caban

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

2020-09-23 Thread Jacek Caban

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

2020-09-20 Thread Jacek Caban

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

2020-09-07 Thread Jacek Caban

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()`

2020-07-22 Thread Jacek Caban

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`

2020-07-21 Thread Jacek Caban

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`

2020-07-21 Thread Jacek Caban

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`

2020-07-21 Thread Jacek Caban

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.

2020-07-15 Thread Jacek Caban

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

2020-06-12 Thread Jacek Caban

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

2020-06-12 Thread Jacek Caban

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

2020-06-12 Thread Jacek Caban

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

2020-06-08 Thread Jacek Caban

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.

2020-06-07 Thread Jacek Caban

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.

2020-06-07 Thread Jacek Caban

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

2020-06-04 Thread Jacek Caban

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

2020-06-04 Thread Jacek Caban

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

2020-06-04 Thread Jacek Caban

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

2020-06-04 Thread Jacek Caban

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

2020-05-22 Thread Jacek Caban

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.

2020-05-19 Thread Jacek Caban

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.

2020-05-17 Thread Jacek Caban

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.

2020-05-17 Thread Jacek Caban

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

2020-05-15 Thread Jacek Caban

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

2020-05-15 Thread Jacek Caban

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

2020-05-08 Thread Jacek Caban

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

2020-05-08 Thread Jacek Caban

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

2020-05-06 Thread Jacek Caban

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

2020-05-06 Thread Jacek Caban

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

2020-05-04 Thread Jacek Caban

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

2020-04-28 Thread Jacek Caban

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

2020-04-27 Thread Jacek Caban

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

2020-04-27 Thread Jacek Caban

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

2020-04-27 Thread Jacek Caban

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

2020-04-27 Thread Jacek Caban

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

2020-04-27 Thread Jacek Caban

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

2020-04-27 Thread Jacek Caban

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

2020-04-27 Thread Jacek Caban

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

2020-04-26 Thread Jacek Caban

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

2020-04-24 Thread Jacek Caban

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

2020-04-24 Thread Jacek Caban

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

2020-04-24 Thread Jacek Caban

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

2020-04-24 Thread Jacek Caban

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

2020-04-24 Thread Jacek Caban

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

2020-04-24 Thread Jacek Caban

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

2020-04-24 Thread Jacek Caban

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.

2020-04-23 Thread Jacek Caban

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

2020-04-23 Thread Jacek Caban

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

2020-04-23 Thread Jacek Caban

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

2020-04-22 Thread Jacek Caban

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

2020-04-22 Thread Jacek Caban

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

2020-04-22 Thread Jacek Caban

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


  1   2   3   4   5   6   7   8   >