Re: [Mingw-w64-public] undefined reference to IID_*

[Vincent Torri]

hello

pass -luuid to gcc (at least for d3d11. I pass dxguid.lib to the
visual studio linker

Vincent

On Fri, Jun 17, 2022 at 8:09 PM Maarten ten Velden
 wrote:
>
> I tried to use _ID3D12Device and link with -ldxguid, sort of as suggested 
> here..
> https://github.com/microsoft/DirectX-Graphics-Samples/issues/567
> .. yet with/without -ldxguid the error undefined reference to 
> `IID_ID3D12Device' occurs either way.
>
> mingw version is 11.2.0.07112021 from chocolatey.
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] No d3d12 debug message(s)

[Vincent Torri]

hello

same for d3d11. To get them, I run my prog ni gdb, maybe something
related to flushing stdout

Vincent

On Fri, Jun 17, 2022 at 8:21 PM Maarten ten Velden
 wrote:
>
> I tried w. ID3D12Debug* from D3D12GetDebugInterface, which succeeds but there 
> is never any output printed to stdout.
>
> There is also this post 
> https://devblogs.microsoft.com/directx/d3d12-debug-layer-message-callback/ 
> explaining how to set a custom callback, however the latest mingw version I 
> downloaded from (11.2.0.07112021 from chocolatey) doesn't have the 
> ID3D12InfoQueue1 yet nor does 
> https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/include/d3d12sdklayers.h.
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] winpthreads: Do not use `dllimport` when building 3rd-party DLLs

[Vincent Torri]

On Sun, May 1, 2022 at 9:36 AM Martin Storsjö  wrote:
>
> On Sun, 1 May 2022, JonY via Mingw-w64-public wrote:
>
> > On 5/1/22 05:19, LIU Hao wrote:
> >> 在 2022-05-01 13:15, LIU Hao 写道:
> >>> This is the alternative patch as discussed with jon_y on IRC.
> >>>
> >>>
> >>
> >> I forgot to update the commit message. Here is the revised patch.
> >>
> >
> > +Programs are usually linked against the winpthreads DLL, and winpthreads
> > +headers expose `dllexport` APIs by default. When linking against the
> > +static library, especially when building a user DLL with libtool, it is
> > +necessary to define the `WINPTHREAD_STATIC` macro to avoid undefined
> > +references.
> >
> > I think dllexport should be replaced by dllimport in the above statement.
> >
> > Building a DLL with dllexport marked symbols is correct and expected.
> > The problem comes in when dllimport is used when the user intentionally
> > wants to link to a static library, hence they need to add
> > -DWINPTHREAD_STATIC to signal that they do actually want it so.
>
> FWIW, I think this will break a number of users, who currently
> successfully are linking statically, who now need to set a winpthread
> specific define to make it work. Yes, they can change their setups to
> manually define WINPTHREAD_STATIC, but it will cause lots of extra
> inconvenience for users with setups that so far have worked just fine.
>
> But if you really really prefer this setup, then fine, go ahead. But I did
> warn that it will inconvenirnce users.

should winpthread be used by users ? i thought it was written for c++11 threads

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API

[Vincent Torri]

On Sun, Jan 16, 2022 at 10:44 AM Martin Mitáš  wrote:
>
>
> Hello.
>
> I was dealing with this exact problem some time ago.
>
> Note the problem is wider. At certain point in time, Microsoft stopped to
> care about C compatibility of (some of) their SDK headers. This includes
> GDI+ and Direct2D APIs for example.
>
> I.e. even if you somehow make it work with mingw-w64 headers, it would still
> not be buildable with MSVC. If you need that, your options are even more
> limited and Wine headers won't help you much as I think their headers are
> not compatible with Microsoft SDK.

It is for a toolkit that is not portable to msvc anyway. So I care
only about mingw-w64

> For my projects, I've eventually ended with creating C-compatible headers
> for D2D and GDI+. You can find them here:
>
> https://github.com/mity/c-win32

hoo, you're the author of md4c :-) I use it for this toolkit :-)

I'll look at it.

> However note they are not a drop-in replacement for two reasons:
>
> (1) They are designed to live alongside standard SDK headers: The cost of
> this decision is that all their top-level identifiers differ ("c_" prefix).

not a problem. Only a few functions have problems. Technically
speaking, I can even replace them by something else (GetPixelSize -->
size of the client region of the Windows, and GetPixelFormat, well, I
use only one pixel format,  so not a problem). Your license is also
good.

> (2) They provide only stuff I needed so they're incomplete in many ways.
> That said however adding more stuff should be quite a straight-forward
> exercise.

i did something similar to have a dcomp C API for some functions.

> So whether this is the right path forward for you, I don't know. Depends
> on your trade-off considerations and requirements.

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API

[Vincent Torri]

On Sun, Jan 16, 2022 at 10:18 AM Nikolay Sivov  wrote:
>
>
>
> On 1/16/22 10:06, Vincent Torri wrote:
> > hello
> >
> > On Sat, Jan 15, 2022 at 9:28 AM Vincent Torri  
> > wrote:
> >> On Sat, Jan 15, 2022 at 7:43 AM Nikolay Sivov  
> >> wrote:
> >>>
> >>>
> >>> On 1/14/22 23:05, Vincent Torri wrote:
> >>>> On Fri, Jan 14, 2022 at 6:31 PM Nikolay Sivov  
> >>>> wrote:
> >>>>>> on the contrary, CreateBitmap(), DrawBitmap(), BeginDraw(), EndDraw()
> >>>>>> or SetTransform() are working with the C API.
> >>>>>>
> >>>>>> Does someone have an idea of the problem. I have a test program if you 
> >>>>>> want
> >>>>> It's a known thing, C-compatible prototypes would be different for such
> >>>>> methods:
> >>>>>
> >>>>> D2D1_SIZE_U * ID3D1HwndRenderTarget_GetPixelSize(void *this, D2D1_SIZE_U
> >>>>> *size).
> >>>> but then I have a compilation error because in d2d1.h provided by
> >>>> mingw-w64, GetPixelSize() has only 1 argument, not 2.
> >>> Naturally, because headers are not prepared for that.
> >>>
> >>> If you wanted to use C++ with msvc compatible prototypes, there is
> >>> WIDL_EXPLICIT_AGGREGATE_RETURNS for that,
> >>> for C definitions it won't work, you'll have to use wine headers, or
> >>> more specifically a header widl produces from wine's d2d1.idl. Widl
> >>> detects such cases automatically, see is_aggregate_return() in widl 
> >>> sources.
> >>>
> >>> I think what should be done is WIDL_EXPLICIT_AGGREGATE_RETURNS case for
> >>> C definitions patched in for mingw headers.
> > i've installed wine in archlinux, and
> > ID3D1HwndRenderTarget_GetPixelSize is defined with another macro, i
> > guess, which i don't know the value (no lucj with an fgrep -r in
> > /usr/include/wine
> >
> > so i don't know the declaration of the function with d2d1.h provided with 
> > wine
>
> Please take a closer look, there is a function wrapper called
> ID2D1HwndRenderTarget_GetPixelSize().

yes, and it has 1 argument, the render target (in the archlinux installed wine)

> Also see attached patch, maybe that's enough to make it work for now.

I'll try it, thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API

[Vincent Torri]

hello

On Sat, Jan 15, 2022 at 9:28 AM Vincent Torri  wrote:
>
> On Sat, Jan 15, 2022 at 7:43 AM Nikolay Sivov  wrote:
> >
> >
> >
> > On 1/14/22 23:05, Vincent Torri wrote:
> > > On Fri, Jan 14, 2022 at 6:31 PM Nikolay Sivov  
> > > wrote:
> > >>> on the contrary, CreateBitmap(), DrawBitmap(), BeginDraw(), EndDraw()
> > >>> or SetTransform() are working with the C API.
> > >>>
> > >>> Does someone have an idea of the problem. I have a test program if you 
> > >>> want
> > >> It's a known thing, C-compatible prototypes would be different for such
> > >> methods:
> > >>
> > >> D2D1_SIZE_U * ID3D1HwndRenderTarget_GetPixelSize(void *this, D2D1_SIZE_U
> > >> *size).
> > > but then I have a compilation error because in d2d1.h provided by
> > > mingw-w64, GetPixelSize() has only 1 argument, not 2.
> >
> > Naturally, because headers are not prepared for that.
> >
> > If you wanted to use C++ with msvc compatible prototypes, there is
> > WIDL_EXPLICIT_AGGREGATE_RETURNS for that,
> > for C definitions it won't work, you'll have to use wine headers, or
> > more specifically a header widl produces from wine's d2d1.idl. Widl
> > detects such cases automatically, see is_aggregate_return() in widl sources.
> >
> > I think what should be done is WIDL_EXPLICIT_AGGREGATE_RETURNS case for
> > C definitions patched in for mingw headers.

i've installed wine in archlinux, and
ID3D1HwndRenderTarget_GetPixelSize is defined with another macro, i
guess, which i don't know the value (no lucj with an fgrep -r in
/usr/include/wine

so i don't know the declaration of the function with d2d1.h provided with wine

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API

[Vincent Torri]

On Sat, Jan 15, 2022 at 7:43 AM Nikolay Sivov  wrote:
>
>
>
> On 1/14/22 23:05, Vincent Torri wrote:
> > On Fri, Jan 14, 2022 at 6:31 PM Nikolay Sivov  
> > wrote:
> >>> on the contrary, CreateBitmap(), DrawBitmap(), BeginDraw(), EndDraw()
> >>> or SetTransform() are working with the C API.
> >>>
> >>> Does someone have an idea of the problem. I have a test program if you 
> >>> want
> >> It's a known thing, C-compatible prototypes would be different for such
> >> methods:
> >>
> >> D2D1_SIZE_U * ID3D1HwndRenderTarget_GetPixelSize(void *this, D2D1_SIZE_U
> >> *size).
> > but then I have a compilation error because in d2d1.h provided by
> > mingw-w64, GetPixelSize() has only 1 argument, not 2.
>
> Naturally, because headers are not prepared for that.
>
> If you wanted to use C++ with msvc compatible prototypes, there is
> WIDL_EXPLICIT_AGGREGATE_RETURNS for that,
> for C definitions it won't work, you'll have to use wine headers, or
> more specifically a header widl produces from wine's d2d1.idl. Widl
> detects such cases automatically, see is_aggregate_return() in widl sources.
>
> I think what should be done is WIDL_EXPLICIT_AGGREGATE_RETURNS case for
> C definitions patched in for mingw headers.

who is the maintainer of these headers ? Jacek ? Martin ?

for now, what i can do is just having my own declarations in my source
code, based on wine generated headers

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API

[Vincent Torri]

On Fri, Jan 14, 2022 at 6:31 PM Nikolay Sivov  wrote:
> >
> > on the contrary, CreateBitmap(), DrawBitmap(), BeginDraw(), EndDraw()
> > or SetTransform() are working with the C API.
> >
> > Does someone have an idea of the problem. I have a test program if you want
>
> It's a known thing, C-compatible prototypes would be different for such
> methods:
>
> D2D1_SIZE_U * ID3D1HwndRenderTarget_GetPixelSize(void *this, D2D1_SIZE_U
> *size).

but then I have a compilation error because in d2d1.h provided by
mingw-w64, GetPixelSize() has only 1 argument, not 2.

> You could check hows it's done in Wine, where we don't use C++.

do you have a link, please ?

thank you

Vincent


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] direct2d functions work with C++ API, but not with C API

[Vincent Torri]

Hello

first, I'm on Win10

After initializing Direct2D, when I call

ID2D1HwndRenderTarget_GetPixelSize

 with a HwndRenderTarget, i get a seg fault.

But when I use the C++ API, no problem.

there is the same behavior with GetPixelFormat()

on the contrary, CreateBitmap(), DrawBitmap(), BeginDraw(), EndDraw()
or SetTransform() are working with the C API.

Does someone have an idea of the problem. I have a test program if you want

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] contributions

[Vincent Torri]

On Wed, Sep 8, 2021 at 4:24 PM LIU Hao  wrote:
>
> 在 2021-09-06 19:26, Glenn Burkhardt 写道:
> >
> > Why won't anyone answer my question about how to submit patches or pull 
> > requests, instead of making
> > spurious, erroneous comments on the merits of a submission?  Wasn't the 
> > rigidity of Earnie //Boyd to
> > accept contributions and suggestions for improvements the reason for the 
> > fork of MinGW-w64 from
> > MinGW years ago?
> >
>
> My presumption is that we haven't formally dropped Windows XP support, which 
> had no symlink support.
> Only since Vista have symlinks be supported, their creation requires admin 
> priviledges, which is not
> Linux users normally expect. Unless these distinctions are resolved, it would 
> be unlikely that we
> accept symlink support.

for me, needing administrator privileges is a no go. Also, suppose
that symlinks are implemented, should we also add lstat() and other
Unix functions that have a symlink as argument ?

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _access and predefined modes

[Vincent Torri]

On Tue, Aug 10, 2021 at 5:56 PM Guy Helmer  wrote:
>
> > On Aug 10, 2021, at 9:28 AM, Vincent Torri  wrote:
> >
> > Hello
> >
> > according to MSDN (see
> > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/access-waccess?view=msvc-160)
> > the valid modes of _access are 0, é, 4 and 6.
> >
> > But in io.h, we have :
> >
> > #defineF_OK0/* Check for file existence */
> > #defineX_OK1/* Check for execute permission. */
> > #defineW_OK2/* Check for write permission */
> > #defineR_OK4/* Check for read permission */
>
> Both the webpage and this list are correct. Look closely, e.g. at this line:
> 06 -Read and write
>
> W_OK | R_OK == 06

and X_OK ?


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] _access and predefined modes

[Vincent Torri]

Hello

according to MSDN (see
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/access-waccess?view=msvc-160)
the valid modes of _access are 0, é, 4 and 6.

But in io.h, we have :

#defineF_OK0/* Check for file existence */
#defineX_OK1/* Check for execute permission. */
#defineW_OK2/* Check for write permission */
#defineR_OK4/* Check for read permission */

is it normal ?

Vincent  Torri


___
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.

[Vincent Torri]

On Wed, Apr 28, 2021 at 9:35 PM Christian Franke
 wrote:
>
> Liu Hao wrote:
> > 在 4/27/21 2:00 AM, Christian Franke 写道:
> >>
> >> Which complexity do you mean - the extra cost of the system call or
> >> the extra 15 lines of code?
> >>
> >
> > It's actually both.
> >
> > Wall clocks are not meant to be steady, because they are free to jump
> > back and forth due to NTP synchronization, and arithmetic operations
> > aren't predicable either due to leap seconds.
>
> That's all correct. But there are several use cases where a higher than
> this ~15.6ms (1/64s) resolution is needed and where occasional clock
> jumps are acceptable - for example debug logs.
>
> If there were no use cases, the evolution
>time() -> ftime(...) -> gettimeofday(...) ->
> clock_gettime(CLOCK_REALTIME,...)
> would possibly never have happened :-)
>
> BTW.1: Hack:
> Do this once in the program
>#ifdef _WIN32
>  timeBeginPeriod(1);

https://docs.microsoft.com/fr-fr/windows/win32/api/timeapi/nf-timeapi-timebeginperiod?redirectedfrom=MSDN

"Setting a higher resolution can improve the accuracy of time-out
intervals in wait functions. However, it can also reduce overall
system performance, because the thread scheduler switches tasks more
often. High resolutions can also prevent the CPU power management
system from entering power-saving modes. "

also, just for more information about this discussion:
https://devblogs.microsoft.com/oldnewthing/20170921-00/?p=97057

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw And dlopen

[Vincent Torri]

Hello

On Sat, Mar 6, 2021 at 8:48 AM Thomas Dineen  wrote:
>
> Gentle People:
>
>   Do any of you have experience with Mingw gcc and dlopen for
> dynamic (under application
> program control) loading of libs. Specifically I am looking at passing
> externs into C functions
> included in a dll library. I have been able to make this work just fine
> using gcc on Solaris and
> CentOS Linux by simply including extern statements in the lib (.so)
> source outside the function.
> Now using Mingw gcc the externs seem to be ignored and I get undeclared
> variables errors.
>  Can any of you point me to a simple (and current) example of how to
> do this?
> Why is it so different from Solaris and Linux.
> PS I am totally burned out from surfing the web and not finding a simple
> and current
> way of doing this.

It's more a Windows question than mingw one

basically :

to load the DLL : LoadLibrary()
to get the function pointer of the function in your DLL : GetProcAddress()
to free resources : FreeLibrary()

example attached

I suggest that you download dependency walker [1] to see if your
functions in your  correctly exported

hth

Vincent Torri

[1] https://dependencywalker.com/

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mingw Gcc Windows 7 Reboot

[Vincent Torri]

Have you tried with DrMemory ? Or on linux with Wine + valgrind ?

Vincent Torri

On Tue, Mar 2, 2021 at 10:42 PM Thomas Dineen  wrote:
>
> Gentle People:
>
>  I have an unusual situation! For some time now I have been
> developing and application
>
> using C with Mingw gcc. The application performs long overnight
> optimization runs,
>
> sometimes running several days.
>
>   The application crashes on Win7 (Read that causes Reboot on Win7)
> but runs fine on Win10!
>
> Windows 7 - Mingw Gcc Build - Crashes Windows7
>
> Windows 10 - Mingw Gcc Build - Works Great
>
> Solaris - Gcc Build - Works Great
>
> Redhat/CentOS- Gcc Build - Works Great
>
> I am aware of memory consumption or leak issues, and with
> significant amounts of effort have
>
> fixed them in the architecture. The architecture relies heavily on
> linked lists and I am well aware of
>
> freeing or recycling unneeded lists to control memory leaks. I have
> verified this with observation of the
>
> Resource Monitor!
>
>  Question 1: Has anyone else seen this type of bug?
>
>  Question 2: How do I debug this given the fact that Win 7 crashes
> and takes gdb with it.
>
>
>
> ___
> 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] missing C api for direct composition

[Vincent Torri]

hello

so trying to port in C the code in
https://docs.microsoft.com/en-us/archive/msdn-magazine/2014/june/windows-with-c-high-performance-window-layering-using-the-windows-composition-engine,
i've seen that there is no C API in dcomp.h (dcomp.h/idl does not
exist in wine)

I hope someone will be able to add it.

thank you

Vincent Torri


___
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

[Vincent Torri]

On Thu, Nov 5, 2020 at 5:30 PM Biswapriyo Nath  wrote:
>
> Vincent Torri, if you are not familiar with the header files here, I
> may send the required patches this week.

that would be very nice if you can send those patches

thank you

Vincent Torri


___
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

[Vincent Torri]

On Thu, Nov 5, 2020 at 5:30 PM Biswapriyo Nath  wrote:
>
> Vincent Torri, if you are not familiar with the header files here, I
> may send the required patches this week.

i'm not familiar at all with the mingw-w64 headers, indeed. I'm just
guessing stuff by comparing what is in d2d1.h,  d2d1_1.h and the
d2d1_1.h generated with widl.

Vincent Torri


___
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

[Vincent Torri]

On Thu, Nov 5, 2020 at 3:18 PM Liu Hao  wrote:
>
> 在 2020/11/5 21:37, Vincent Torri 写道:
> >
> > i can add what is missing part by part in d2d1.h. What is the standard
> > procedure ? if there is a github mirror and if PR are a possible way
> > to provide patches, i can do that
> >
> > regards
> >
> >
>
> You may clone the mingw-w64 repo, commit your changes locally, then use `git 
> format-patch  [-o
> ]` to create patches, then send them to this mailing 
> list. Patches can be
> opened with an email client directly, or sent as attachments. Your 
> contribution will be appreciated.
>
>
> For example, to export the last 3 commits in the current branch to the 
> current directory, use
>
> git format-patch HEAD~3
>
> To export all commits since `origin/master`, use
>
> git format-patch origin/master
>
> To export a specific commit, use
>
> git format-patch -1 
>
> To export only the last commit in the current branch, use
>
> git format-patch HEAD~  # alternative 1
> git format-patch -1 HEAD# alternative 2

Question:

I have added ID2D1Properties C API (see attached diff). In d2d1.h,
STDMETHOD_ was used for the functions in the Vtbl struct. Should I do
the same ?

thank you

Vincent Torri

___
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

[Vincent Torri]

On Wed, Nov 4, 2020 at 8:08 PM Jacek Caban  wrote:
>
> 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.

i can add what is missing part by part in d2d1.h. What is the standard
procedure ? if there is a github mirror and if PR are a possible way
to provide patches, i can do that

regards

Vincent Torri


___
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

[Vincent Torri]

On Wed, Nov 4, 2020 at 10:34 AM 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.

i also have an error that i do not understand

when i use

ID2D1Factory1_CreateDevice(***);

the compiler says that

d2d.c:12:60: error: 'ID2D1FactoryVtbl' has no member named 'CreateDevice'
   12 | #define ID2D1Factory1_CreateDevice(this,A,B)
(this)->lpVtbl->CreateDevice(this,A,B)
  |^~
d2d.c:301:16: note: in expansion of macro 'ID2D1Factory1_CreateDevice'
  301 | if (FAILED(ID2D1Factory1_CreateDevice(factory,
dxgi_device, _device)))
  |^~

i don't understand why. I've properly defined

#define D2D_USE_C_DEFINITIONS
#define _WIN32_WINNT 0x0A00

before inclusion of d2d header

any idea why ?

Vincent


___
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

[Vincent Torri]

On Wed, Nov 4, 2020 at 8:18 AM Ruslan Garipov  wrote:
>
> Oh, I'm sorry, I accidentally replied directly to you, not to the list.
>
> On 11/4/2020 10:01 AM, Vincent Torri wrote:
> > for now :
> >
> > CreateDeviceContext method of a ID2D1Device1
> It's already in the master:
>
> $ fgrep -n CreateDeviceContext mingw-w64-headers/include/d2d1_1.h
> 1014:STDMETHOD(CreateDeviceContext)(D2D1_DEVICE_CONTEXT_OPTIONS
> options, ID2D1DeviceContext **deviceContext) PURE;
> 1034:STDMETHOD(CreateDeviceContext)(ID2D1Device *This,
>
> $ git blame -L1034,1036 HEAD mingw-w64-headers/include/d2d1_1.h
> 3cc762bfb (Ruslan Garipov 2020-05-19 14:29:13 +0500 1034)
> STDMETHOD(CreateDeviceContext)(ID2D1Device *This,
> 3cc762bfb (Ruslan Garipov 2020-05-19 14:29:13 +0500 1035)
> D2D1_DEVICE_CONTEXT_OPTIONS options,
> 3cc762bfb (Ruslan Garipov 2020-05-19 14:29:13 +0500 1036)
> ID2D1DeviceContext **deviceContext) PURE;

i know how to use fgrep...

what is missing is the classic C API, like (in d2d1_1.h) :

ID2D1Factory1_QueryInterface

that is, a define that call the method from the "virtual table" :

#define ID2D1Factory1_QueryInterface(this,A,B)
(this)->lpVtbl->Base.Base.QueryInterface((IUnknown *)(this),A,B)

it calls QueryInterface from the IUnknownVtbl structure, through
Base.Base in the define above

These are those defines that are missing.

Same for BeginDraw and EndDraw

Vincent Torri

> $ git show --pretty=fuller 3cc762bfb
> commit 3cc762bfbbbefcefa97d937fed89764ed4f58034
> Author: Ruslan Garipov 
> AuthorDate: Tue May 19 14:29:13 2020 +0500
> Commit: Liu Hao 
> CommitDate: Tue May 19 22:31:26 2020 +0800
>
> d2d1_1.h: Add C declaration for ID2D1Device
>
> Signed-off-by: ‡Ruslan Garipov 
> Signed-off-by: Liu Hao 
>
> diff --git a/mingw-w64-headers/include/d2d1_1.h
> b/mingw-w64-headers/include/d2d1_1.h
> index f090be7a..f48ac349 100644
> --- a/mingw-w64-headers/include/d2d1_1.h
> +++ b/mingw-w64-headers/include/d2d1_1.h
> @@ -1014,7 +1014,29 @@ interface ID2D1Device : public ID2D1Resource
>  #else
>
>  typedef interface ID2D1Device ID2D1Device;
> -/* FIXME: Add full C declaration */
> +
> +typedef struct ID2D1DeviceVtbl {
> +struct ID2D1ResourceVtbl Base;
> +
> +STDMETHOD(CreateDeviceContext)(ID2D1Device *This,
> +D2D1_DEVICE_CONTEXT_OPTIONS options,
> +ID2D1DeviceContext **deviceContext) PURE;
> +STDMETHOD(CreatePrintControl)(ID2D1Device *This,
> +IWICImagingFactory *wicFactory,
> +IPrintDocumentPackageTarget *documentTarget,
> +CONST D2D1_PRINT_CONTROL_PROPERTIES *printControlProperties,
> +ID2D1PrintControl **printControl) PURE;
> +STDMETHOD_(void, SetMaximumTextureMemory)(ID2D1Device *This,
> +UINT64 maximumInBytes) PURE;
> +STDMETHOD_(UINT64, GetMaximumTextureMemory)(ID2D1Device *This) PURE;
> +STDMETHOD_(void, ClearResources)(ID2D1Device *This,
> +UINT32 millisecondsSinceUse) PURE;
> +}
> +ID2D1DeviceVtbl;
> +
> +interface ID2D1Device {
> +const ID2D1DeviceVtbl *lpVtbl;
> +};
>
>  #endif
>
> > BeginDraw and EndDraw methods of a ID2D1DeviceContext (which inherits
> > from a ID2D1RenderTarget)
> The ID2D1DeviceContext is also in the tree (after 0c0da49fd):
>
> $ fgrep -n "struct ID2D1DeviceContextVtbl"
> mingw-w64-headers/include/d2d1_1.h
> 881:typedef struct ID2D1DeviceContextVtbl {
>
> $ tail -n +879 mingw-w64-headers/include/d2d1_1.h | head -130
> ...
>
> And the functions you are looking for (BeginDraw() and EndDraw()), were
> also added for C target long before 0c0da49fd:
>
> $ tail -n +934 mingw-w64-headers/include/d2d1.h | head -n 120 | egrep
> "BeginDraw|EndDraw"
> STDMETHOD_(void, BeginDraw)(ID2D1RenderTarget *This) PURE;
> STDMETHOD(EndDraw)(ID2D1RenderTarget *This, D2D1_TAG *tag1, D2D1_TAG
> *tag2) PURE;
> #define ID2D1RenderTarget_BeginDraw(this) (this)->lpVtbl->BeginDraw(this)
> #define ID2D1RenderTarget_EndDraw(this,A,B)
> (this)->lpVtbl->EndDraw(this,A,B)
>
> If you need some other interfaces -- let's try to add them.  Because I
> have developed a C program rendering with Direct2D, and also I'm to
> continue with that project in future.
>
> >
> > Vincent Torri
> >
> > On Tue, Nov 3, 2020 at 9:31 PM Ruslan Garipov  
> > wrote:
> >>
> >> On 11/3/2020 9:36 PM, Vincent Torri wrote:
> >>> Hello
> >> Hello!
> >>
> >>>
> >>> does someone plan to add all the missing C API in d2d1_1.h ?
> >> Which interfaces (or some other API parts?) exactly do you need?
> >>
> >>> Currently, it's not possible to use d2d 1.1  API in C
> >>>
> >>> thank you
> >>>
> >>> Vincent Torri
> >>>
> >>>
> >>> ___
> >>> Mingw-w64-public mailing list
> >>> Mingw-w64-public@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >>>


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] d2d1_1.h : plenty of C API missing

[Vincent Torri]

here it is  (based on
https://docs.microsoft.com/en-us/archive/msdn-magazine/2014/june/windows-with-c-high-performance-window-layering-using-the-windows-composition-engine)


On Wed, Nov 4, 2020 at 5:11 AM Biswapriyo Nath  wrote:
>
> If you have a project to test new header changes it will be helpful.
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
/* gcc -g -Wall -o d2d d2d.c -ld2d1 -luuid */

#define COBJMACROS
#define D2D_USE_C_DEFINITIONS
#define _WIN32_WINNT 0x0A00

#include 

#include 
#include 
#include 
#include 


static HINSTANCE instance = NULL;
static HWND win = NULL;
static ID3D11Device *d3d_device = NULL;
static IDXGIDevice *dxgi_device = NULL;
static IDXGIFactory2 *dxgi_factory = NULL;
static ID2D1Factory *factory = NULL;
static IDXGISwapChain1 *swapchain= NULL;
static ID2D1Device *d2d_device = NULL;
static ID2D1DeviceContext *d2d_device_ctx = NULL;
static ID2D1HwndRenderTarget* render_target = NULL;

LRESULT CALLBACK _window_procedure(HWND   window,
   UINT   message,
   WPARAM window_param,
   LPARAM data_param);

int
render_target_properties_new(void)
{
D2D1_SIZE_U size;
D2D1_RENDER_TARGET_PROPERTIES rtp;
D2D1_HWND_RENDER_TARGET_PROPERTIES wrtp;
RECT r;
FLOAT dpix;
FLOAT dpiy;
HRESULT res;

ID2D1Factory_GetDesktopDpi(factory, , );

rtp.type = D2D1_RENDER_TARGET_TYPE_HARDWARE;
rtp.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM;
rtp.pixelFormat.alphaMode = D2D1_ALPHA_MODE_PREMULTIPLIED;
rtp.dpiX = dpix;
rtp.dpiY = dpiy;
rtp.usage = D2D1_RENDER_TARGET_USAGE_NONE;
rtp.minLevel = D2D1_FEATURE_LEVEL_10;

GetClientRect(win, );
size.width = r.right - r.left;
size.height = r.bottom - r.top;

wrtp.hwnd = win;
wrtp.pixelSize = size;
wrtp.presentOptions = D2D1_PRESENT_OPTIONS_IMMEDIATELY;

res = ID2D1Factory_CreateHwndRenderTarget(factory, , , 
_target);
if (FAILED(res))
return 0;
return 1;
}

void
render_tartget_properties_free()
{
ID2D1HwndRenderTarget_Release(render_target);
}

void
render_bitmap(HWND win)
{
D2D1_BITMAP_PROPERTIES props;
D2D1_SIZE_U size;
ID2D1RenderTarget* rt;
RECT r;
D2D1_RECT_F rect;
ID2D1Bitmap *bitmap;
unsigned int i, j;
unsigned int *data, *iter;
HRESULT res;

GetClientRect(win, );
size.width = r.right - r.left;
size.height = r.bottom - r.top;

data = malloc(size.width * size.height * sizeof(unsigned int));
iter = data;
for (i = 0; i < size.width; i++)
{
for (j = 0; j < size.height; j++, iter ++)
{
if (i >= 50 && j>= 50)
*iter = 0xffff;
else
*iter = 0x;
}
}

props.pixelFormat.format = DXGI_FORMAT_B8G8R8A8_UNORM;
props.pixelFormat.alphaMode = D2D1_ALPHA_MODE_PREMULTIPLIED;
props.dpiX = 96.0f;
props.dpiY = 96.0f;

rt = (ID2D1RenderTarget *)render_target;

res = ID2D1RenderTarget_CreateBitmap(rt,
 size, data, 4 * size.width,
 , );

if (FAILED(res))
return;

ID2D1RenderTarget_BeginDraw(rt);

rect.left = (float)r.left;
rect.top = (float)r.top;
rect.right = (float)r.right;
rect.bottom = (float)r.bottom;

ID2D1RenderTarget_DrawBitmap(rt,
 bitmap, , 1.0f,
 
D2D1_BITMAP_INTERPOLATION_MODE_NEAREST_NEIGHBOR, NULL);

ID2D1RenderTarget_EndDraw(rt, NULL, NULL);
}


LRESULT CALLBACK
_window_procedure(HWND   window,
  UINT   message,
  WPARAM window_param,
  LPARAM data_param)
{
  switch (message)
{
case WM_CLOSE:
  PostQuitMessage(0);
  return 0;
case WM_KEYUP:
  if (window_param == 'Q')
{
  PostQuitMessage(0);
}
  return 0;
  /* GDI notifications */
case WM_CREATE:
case WM_PAINT:
  {
RECT rect;

printf("paint\n");
fflush(stdout);
if (GetUpdateRect(window, , FALSE))
  {
PAINTSTRUCT ps;
BeginPaint(window, );
//render();
EndPaint(window, );
  }
return 0;
  }
default:
  return DefWindowProc(window, message, window_param, data_param);
}
}


int main()
{
/* class */
WNDCLASS wc;

instance = GetModuleHandle(NULL);
if (!instance)
return 1;

memset (, 0, sizeof (WNDCLASS));
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = _window_procedure;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = instance;
wc.hIcon = LoadIcon (NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor (NULL, IDC_ARROW);

Re: [Mingw-w64-public] missing dxgidebug import library

[Vincent Torri]

On Mon, Oct 26, 2020 at 2:41 PM Nikolay Sivov  wrote:
>
>
>
> On 10/26/20 4:25 PM, Vincent Torri wrote:
> > On Mon, Oct 26, 2020 at 2:06 PM Nikolay Sivov  
> > wrote:
> >>
> >>
> >> On 10/26/20 4:00 PM, Vincent Torri wrote:
> >>> On Mon, Oct 26, 2020 at 12:44 PM Nikolay Sivov  
> >>> wrote:
> >>>>
> >>>> On 10/26/20 2:35 PM, Vincent Torri wrote:
> >>>>> On Mon, Oct 26, 2020 at 12:15 PM Nikolay Sivov  
> >>>>> wrote:
> >>>>>> On 10/26/20 11:55 AM, Vincent Torri wrote:
> >>>>>>> On Sun, Oct 25, 2020 at 10:03 PM Biswapriyo Nath 
> >>>>>>>  wrote:
> >>>>>>>> Which specific APIs are you interested in? As far as I know, most of
> >>>>>>>> them are COM interfaces.
> >>>>>>> IDXGIDebug_ReportLiveObjects
> >>>>>>>
> >>>>>>> i'm coding in C, not C++.
> >>>>>> It's a regular interface method available through dxgidebug.h, why do
> >>>>>> you need an import library for this?
> >>>>> if i link against the dll directly, IDXGIDebug_ReportLiveObjects is 
> >>>>> undefined
> >>>>>
> >>>>> so i guess that ass all the other symbols work, there is something in
> >>>>> the import lib that takes care of the C API
> >>>> To get C macros you'll need:
> >>>>
> >>>> #define COBJMACROS
> >>> i know, i already do that and i already call direct3d, direct2d and dxgi 
> >>> C API
> >>>
> >>>> My guess is that you should use DXGIGetDebugInterface(_IDXGIDebug),
> >>>> and then call IDXGIDebug_ReportLiveObjects() on returned interface.
> >>> btw, without linking to the dxgidebug dll :
> >>>
> >>> $ gcc -g -Wall -Wextra -o d2d.exe d2d.c -ld3d11 -ld2d1 -ldxgi -luuid
> >>> C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>> C:\Documents\msys2\tmp\ccjEHgWG.o:d2d.c:(.rdata$.refptr.DXGI_DEBUG_ALL[.refptr.DXGI_DEBUG_ALL]+0x0):
> >>> undefined reference to `DXGI_DEBUG_ALL'
> >>> C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>> C:\Documents\msys2\tmp\ccjEHgWG.o:d2d.c:(.rdata$.refptr.IID_IDXGIDebug[.refptr.IID_IDXGIDebug]+0x0):
> >>> undefined reference to `IID_IDXGIDebug'
> >>> collect2.exe: error: ld returned 1 exit status
> >>>
> >>> DXGI_DEBUG_ALL and IID_IDXGIDebug are defined only with C++ in dxgidebug.h
> >> How does it work with MS C compiler? You probably need to link with
> >> -ldxguid as well.
> > same error
> Again, what would you be using on Windows with MS compiler to link with
> these guids?

VS is  no go : i plan to use direct2d and VS' d2d.h does not include C
interface...

>My guess is dxguid, and if true mingw will simply have to
> amend it with dxgidebug guids.

so mingw problem...

> >
> >
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] missing dxgidebug import library

[Vincent Torri]

On Mon, Oct 26, 2020 at 2:06 PM Nikolay Sivov  wrote:
>
>
>
> On 10/26/20 4:00 PM, Vincent Torri wrote:
> > On Mon, Oct 26, 2020 at 12:44 PM Nikolay Sivov  
> > wrote:
> >>
> >>
> >> On 10/26/20 2:35 PM, Vincent Torri wrote:
> >>> On Mon, Oct 26, 2020 at 12:15 PM Nikolay Sivov  
> >>> wrote:
> >>>>
> >>>> On 10/26/20 11:55 AM, Vincent Torri wrote:
> >>>>> On Sun, Oct 25, 2020 at 10:03 PM Biswapriyo Nath  
> >>>>> wrote:
> >>>>>> Which specific APIs are you interested in? As far as I know, most of
> >>>>>> them are COM interfaces.
> >>>>> IDXGIDebug_ReportLiveObjects
> >>>>>
> >>>>> i'm coding in C, not C++.
> >>>> It's a regular interface method available through dxgidebug.h, why do
> >>>> you need an import library for this?
> >>> if i link against the dll directly, IDXGIDebug_ReportLiveObjects is 
> >>> undefined
> >>>
> >>> so i guess that ass all the other symbols work, there is something in
> >>> the import lib that takes care of the C API
> >> To get C macros you'll need:
> >>
> >> #define COBJMACROS
> > i know, i already do that and i already call direct3d, direct2d and dxgi C 
> > API
> >
> >> My guess is that you should use DXGIGetDebugInterface(_IDXGIDebug),
> >> and then call IDXGIDebug_ReportLiveObjects() on returned interface.
> > btw, without linking to the dxgidebug dll :
> >
> > $ gcc -g -Wall -Wextra -o d2d.exe d2d.c -ld3d11 -ld2d1 -ldxgi -luuid
> > C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > C:\Documents\msys2\tmp\ccjEHgWG.o:d2d.c:(.rdata$.refptr.DXGI_DEBUG_ALL[.refptr.DXGI_DEBUG_ALL]+0x0):
> > undefined reference to `DXGI_DEBUG_ALL'
> > C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > C:\Documents\msys2\tmp\ccjEHgWG.o:d2d.c:(.rdata$.refptr.IID_IDXGIDebug[.refptr.IID_IDXGIDebug]+0x0):
> > undefined reference to `IID_IDXGIDebug'
> > collect2.exe: error: ld returned 1 exit status
> >
> > DXGI_DEBUG_ALL and IID_IDXGIDebug are defined only with C++ in dxgidebug.h
>
> How does it work with MS C compiler? You probably need to link with
> -ldxguid as well.

same error


___
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 dxgidebug import library

[Vincent Torri]

On Mon, Oct 26, 2020 at 12:44 PM Nikolay Sivov  wrote:
>
>
>
> On 10/26/20 2:35 PM, Vincent Torri wrote:
> > On Mon, Oct 26, 2020 at 12:15 PM Nikolay Sivov  
> > wrote:
> >>
> >>
> >> On 10/26/20 11:55 AM, Vincent Torri wrote:
> >>> On Sun, Oct 25, 2020 at 10:03 PM Biswapriyo Nath  
> >>> wrote:
> >>>> Which specific APIs are you interested in? As far as I know, most of
> >>>> them are COM interfaces.
> >>> IDXGIDebug_ReportLiveObjects
> >>>
> >>> i'm coding in C, not C++.
> >> It's a regular interface method available through dxgidebug.h, why do
> >> you need an import library for this?
> > if i link against the dll directly, IDXGIDebug_ReportLiveObjects is 
> > undefined
> >
> > so i guess that ass all the other symbols work, there is something in
> > the import lib that takes care of the C API
> To get C macros you'll need:
>
> #define COBJMACROS

i know, i already do that and i already call direct3d, direct2d and dxgi C API

> My guess is that you should use DXGIGetDebugInterface(_IDXGIDebug),
> and then call IDXGIDebug_ReportLiveObjects() on returned interface.

btw, without linking to the dxgidebug dll :

$ gcc -g -Wall -Wextra -o d2d.exe d2d.c -ld3d11 -ld2d1 -ldxgi -luuid
C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Documents\msys2\tmp\ccjEHgWG.o:d2d.c:(.rdata$.refptr.DXGI_DEBUG_ALL[.refptr.DXGI_DEBUG_ALL]+0x0):
undefined reference to `DXGI_DEBUG_ALL'
C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Documents\msys2\tmp\ccjEHgWG.o:d2d.c:(.rdata$.refptr.IID_IDXGIDebug[.refptr.IID_IDXGIDebug]+0x0):
undefined reference to `IID_IDXGIDebug'
collect2.exe: error: ld returned 1 exit status

DXGI_DEBUG_ALL and IID_IDXGIDebug are defined only with C++ in dxgidebug.h

Vincent Torri


___
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 dxgidebug import library

[Vincent Torri]

On Sun, Oct 25, 2020 at 10:03 PM Biswapriyo Nath  wrote:
>
> Which specific APIs are you interested in? As far as I know, most of
> them are COM interfaces.

IDXGIDebug_ReportLiveObjects

i'm coding in C, not C++.

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] missing dxgidebug import library

[Vincent Torri]

Hello

is it normal that there is no import lib for dxgidebug API ?

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] (no subject)

[Vincent Torri]

hello

i've updated mingw-w64 with pacman in MSYS2 and i have this warning
each time gcc is called :

C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
warning: --export-dynamic is not supported for PE+ targets, did you
mean --export-all-symbols?

gcc has been updated to 10.2.0

is it a bug in the msys2 package ?

Vincent Torri


___
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

[Vincent Torri]

On Wed, Sep 23, 2020 at 5:24 PM Jacek Caban  wrote:
>
> 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.

thank you very much

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] missing d3d11on12.h file

[Vincent Torri]

Hello

I'm trying to compile Angle with D3D11 support (using meson) and the
file d3d11on12.h is missing.

i've juste updated msys2 5 minutes ago.

is the addition ofthis file planned ?

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc

[Vincent Torri]

On Thu, Aug 27, 2020 at 8:51 AM Vincent Torri  wrote:
>
> On Thu, Aug 27, 2020 at 8:45 AM Ruben Van Boxem
>  wrote:
> >
> > Op do 27 aug. 2020 om 07:18 schreef Vincent Torri :
> >
> > > On Thu, Aug 27, 2020 at 3:24 AM Liu Hao  wrote:
> > > >
> > > > 在 2020/8/27 上午2:06, Vincent Torri 写道:
> > > > >
> > > > > i've checked in cmd too, same result
> > > > >
> > > > > But there is anyway something strange to me :
> > > > >
> > > > > myprog_gcc.exe and myprog_vs are *both* run in MSYS2, and the result
> > > > > is different. So I don't think it's related to path translation. It
> > > > > would suggest something related to how gcc builds the binary
> > > > >
> > > >
> > > >
> > > > In 'mingw-w64-crt/crt/crtexe.c' , `argv` is initialized by the function
> > > `__getmainargs()` which is imported from MSVCRT. VC
> > > > uses new versions of runtime libraries so it'd be MSVCR100, MSVCR120,
> > > etc. There might be some differences in the
> > > > aforementioned function.
> > >
> > > that makes sense. Is it possible to tell gcc to use msvcr*.dll instead
> > > of msvcrt.dll ?
> > >
> >
> > Asking where the difference comes from is a useful question.
> > Relying on these kinds of details to make Unicode work is not IMHO.
> >
> > If you want correct handling of unicode path names, call the appropriate
> > functions.
> > Either compile the GCC code with -municode and use _wmain, or call
> > CommandLineToArgvW with GetCommandLineW and then a _wfopen.
> > Windows is an obtuse platform, and its shells do not support the Unix-wide
> > UTF-8 assumption.
>
> I will try this, thank you

test file :

--
#include 

#include 

int wmain( int argc, wchar_t *argv[ ], wchar_t *envp[ ] )
{
  if (argc < 2)
{
  wprintf(L"%s\n", argv[0]);
  return 1;
}

  return 0;
}
---

but :
$ gcc -g -Wall -o fopenw fopenw.c -municode
C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:/Documents/msys2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_w.o):
in function `wmain':
D:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_w.c:23:
undefined reference to `wWinMain'
collect2.exe: error: ld returned 1 exit status

no idea what is missing, here...

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc

[Vincent Torri]

On Thu, Aug 27, 2020 at 8:45 AM Ruben Van Boxem
 wrote:
>
> Op do 27 aug. 2020 om 07:18 schreef Vincent Torri :
>
> > On Thu, Aug 27, 2020 at 3:24 AM Liu Hao  wrote:
> > >
> > > 在 2020/8/27 上午2:06, Vincent Torri 写道:
> > > >
> > > > i've checked in cmd too, same result
> > > >
> > > > But there is anyway something strange to me :
> > > >
> > > > myprog_gcc.exe and myprog_vs are *both* run in MSYS2, and the result
> > > > is different. So I don't think it's related to path translation. It
> > > > would suggest something related to how gcc builds the binary
> > > >
> > >
> > >
> > > In 'mingw-w64-crt/crt/crtexe.c' , `argv` is initialized by the function
> > `__getmainargs()` which is imported from MSVCRT. VC
> > > uses new versions of runtime libraries so it'd be MSVCR100, MSVCR120,
> > etc. There might be some differences in the
> > > aforementioned function.
> >
> > that makes sense. Is it possible to tell gcc to use msvcr*.dll instead
> > of msvcrt.dll ?
> >
>
> Asking where the difference comes from is a useful question.
> Relying on these kinds of details to make Unicode work is not IMHO.
>
> If you want correct handling of unicode path names, call the appropriate
> functions.
> Either compile the GCC code with -municode and use _wmain, or call
> CommandLineToArgvW with GetCommandLineW and then a _wfopen.
> Windows is an obtuse platform, and its shells do not support the Unix-wide
> UTF-8 assumption.

I will try this, thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc

[Vincent Torri]

On Thu, Aug 27, 2020 at 3:24 AM Liu Hao  wrote:
>
> 在 2020/8/27 上午2:06, Vincent Torri 写道:
> >
> > i've checked in cmd too, same result
> >
> > But there is anyway something strange to me :
> >
> > myprog_gcc.exe and myprog_vs are *both* run in MSYS2, and the result
> > is different. So I don't think it's related to path translation. It
> > would suggest something related to how gcc builds the binary
> >
>
>
> In 'mingw-w64-crt/crt/crtexe.c' , `argv` is initialized by the function 
> `__getmainargs()` which is imported from MSVCRT. VC
> uses new versions of runtime libraries so it'd be MSVCR100, MSVCR120, etc. 
> There might be some differences in the
> aforementioned function.

that makes sense. Is it possible to tell gcc to use msvcr*.dll instead
of msvcrt.dll ?

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc

[Vincent Torri]

On Thu, Aug 27, 2020 at 2:19 AM sisyphus  wrote:
>
> On Wed, Aug 26, 2020 at 7:01 PM Vincent Torri 
> wrote:
>
> > -
> > #include 
> >
> > #include 
> >
> > int main(int argc, char* argv[])
> > {
> > FILE* f;
> > if (argc < 2)
> > {
> > printf("%s\n", argv[0]);
> > return 1;
> > }
> >
> > f = fopen(argv[1], "rb");
> > if (!f)
> > printf("bad\n");
> > else
> > printf("good\n");
> > return 0;
> > }
> > -
> >
> >
> Looking at the code, I see no need for the inclusion of windows.h.
> I take it that the inclusion of windows.h is merely an oversight, and that
> the differing behaviour does not depend on it ?

it's just that i also tried with CreateFile, and remote it, i've
forgotten to remove windows.h inclusion

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc

[Vincent Torri]

On Wed, Aug 26, 2020 at 4:38 PM Liu Hao  wrote:
>
> 在 2020/8/26 18:05, Vincent Torri 写道:
> >
> > the file is : Moș_Crăciun_cântece.txt
> > I print it in the prog with printf :
> >
> > $ ./fopen.exe Moș_Crăciun_cântece.txt
> > bad
> > Mo?_Craciun_cÔntece.txt
> >
>
> Would you please check whether the program behaves as expected in CMD?
>
> MSYS2 performs some path translations, but I am not clear whether it has 
> anything to do with the encoding. I suspect it has,
> because Linux programs generally expects UTF-8, so there must be kind of 
> conversion from UTF-8 to ACP for arguments passed
> to native programs.

i've checked in cmd too, same result

But there is anyway something strange to me :

myprog_gcc.exe and myprog_vs are *both* run in MSYS2, and the result
is different. So I don't think it's related to path translation. It
would suggest something related to how gcc builds the binary

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc

[Vincent Torri]

On Wed, Aug 26, 2020 at 11:29 AM Liu Hao  wrote:
>
> 在 2020/8/26 下午5:00, Vincent Torri 写道:
> >
> > So, I have a file which has a romanian symbol : Moș.txt
> >
> > 1) if I run in MSYS2 ./myprog_gcc (compiled with gcc) Moș.txt, "bad"
> > is displayed
> >
> > 2) if I run in MSYS2 ./myprog_vs (compiled with VSc) Moș.txt, "good"
> > is displayed
> >
> > does someone have an idea why there is such difference ?
> >
>
> I suspect this has something to do with the encoding of paths, as `fopen()` 
> accepts paths in your system's DBCS encoding
> (a.k.a. ANSI code page).
>
> I cannot have your program work in any way on my Windows 7 in Simplified 
> Chinese (code page 936). The path passed to
> `fopen()` is `Mo?.txt`. That is, the `ș` character which does not exist in 
> CP936 gets replaced by a question mark, and is
> thus never a valid filename.
>
> It might help if you print the argument passed to `fopen()` and see whether 
> it is corrupted or not.

the file is : Moș_Crăciun_cântece.txt
I print it in the prog with printf :

$ ./fopen.exe Moș_Crăciun_cântece.txt
bad
Mo?_Craciun_cÔntece.txt

Vinent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] runtime difference between code compiled with VS and gcc

[Vincent Torri]

hello

(sorry, the previous mail has wrong topic)

I have this simple code :
-
#include 

#include 

int main(int argc, char* argv[])
{
FILE* f;
if (argc < 2)
{
printf("%s\n", argv[0]);
return 1;
}

f = fopen(argv[1], "rb");
if (!f)
printf("bad\n");
else
printf("good\n");
return 0;
}
-

of course, both compile with VS and on MSYS2+mingw-w64

The problem is runtime. I don't know if it is important or not, but I
am running Windows 10, french edition.

So, I have a file which has a romanian symbol : Moș.txt

1) if I run in MSYS2 ./myprog_gcc (compiled with gcc) Moș.txt, "bad"
is displayed

2) if I run in MSYS2 ./myprog_vs (compiled with VSc) Moș.txt, "good"
is displayed

does someone have an idea why there is such difference ?

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] runtime difference betwwith VS an een code compiled with gcc and VS

[Vincent Torri]

Hello

I have this simple code :
-
#include 

#include 

int main(int argc, char* argv[])
{
FILE* f;
if (argc < 2)
{
printf("%s\n", argv[0]);
return 1;
}

f = fopen(argv[1], "rb");
if (!f)
printf("bad\n");
else
printf("good\n");
return 0;
}
-

of course, both compile with VS and on MSYS2+mingw-w64

The problem is runtime. I don't know if it is important or not, but I
am running Windows 10, french edition.

So, I have a file which has a romanian symbol : Moș.txt

1) if I run in MSYS2 ./myprog_gcc (compiled with gcc) Moș.txt, "bad"
is displayed
2) if I run in MSYS2 ./myprog_vs (compiled with VSc) Moș.txt, "good"
is displayed

does someone have an idea why there is such difference ?

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] gcc is failing with "bad address" error

[Vincent Torri]

Hello

I am using MSYS2 with mingw-w64. I have updated everything

gcc version : 9.3.0

Several packages that I am building fail with the error:

/mingw64/bin/x86_64-w64-mingw32-gcc: Bad address

Does someone know what is happening, here ?

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Posix versus Win32 binaries

[Vincent Torri]

On Tue, Mar 3, 2020 at 4:10 PM Liu Hao  wrote:
>
> 在 2020/3/3 23:01, Vincent Torri 写道:
> >
> > but technically speaking, it can be implemented with the native
> > condition variables, right ?
> >
>
>
> No. See
> <https://github.com/gcc-mirror/gcc/blob/8e6d0dba166324f4b257329bd4b4ddc2b4522359/libgcc/config/i386/gthr-win32.c#L147>
> for mutex details.
>
> The native condition variables can only be used along with native
> critical sections or slim readers-writer locks. Re-implementing them
> would cause ABI breakage.

i understand, thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Posix versus Win32 binaries

[Vincent Torri]

On Tue, Mar 3, 2020 at 3:59 PM Liu Hao  wrote:
>
> 在 2020/3/3 22:44, Vincent Torri 写道:
> >
> > can you be a bit more precise about "libgcc doesn't implement
> > condition variables for win32 model" please ?
> >
> > Vincent Torri
> >
>
> See
> <https://github.com/gcc-mirror/gcc/blob/8e6d0dba166324f4b257329bd4b4ddc2b4522359/libgcc/config/i386/gthr-win32.h#L297>.

but technically speaking, it can be implemented with the native
condition variables, right ?

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Posix versus Win32 binaries

[Vincent Torri]

On Tue, Mar 3, 2020 at 2:46 PM Liu Hao  wrote:
>
> 在 2020/3/3 21:30, Vincent Torri 写道:
> > On Tue, Mar 3, 2020 at 2:17 PM Liu Hao  wrote:
> >>
> >>
> >> The posix/win32 diversity is about how to manipulate threads (there are
> >> a few more): via libwinpthread (slow but feature-complete) or via
> >> Windows APIs directly (fast but without condition variables etc.).
> >
> > but since Vista, it seems that condition variables exist:
> >
> > https://docs.microsoft.com/en-us/windows/win32/sync/condition-variables
> >
> > Vincent Torri
> >
> >
>
> Yes and no - libgcc doesn't implement condition variables for win32
> model, so they don't exist there.

can you be a bit more precise about "libgcc doesn't implement
condition variables for win32 model" please ?

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Posix versus Win32 binaries

[Vincent Torri]

On Tue, Mar 3, 2020 at 2:17 PM Liu Hao  wrote:
>
> 在 2020/3/3 21:02, Luiz Emediato 写道:
> > Hi there,
> >
> > Would you please help me answering the following questions?
> >
> > 1. What is the difference between x86_64-posix-seh and x86_64-win32-seh
> > binaries ?
> > Is the former for Linux and the latter for Windows ?
> >
> > 2. What is the best way to install MingGW64? Is MSYS2 also necessary ?
> >
>
>
> The posix/win32 diversity is about how to manipulate threads (there are
> a few more): via libwinpthread (slow but feature-complete) or via
> Windows APIs directly (fast but without condition variables etc.).

but since Vista, it seems that condition variables exist:

https://docs.microsoft.com/en-us/windows/win32/sync/condition-variables

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] confused about what to install from mingw-w64.org

[Vincent Torri]

hello

On Wed, Feb 26, 2020 at 5:56 AM A A  wrote:
>
> I am new to Mingw w64 so forgive my ignorance. In the main website it
> clearly states that v7.0.0: 2019-11-10 has been released. I was also able
> to find the download links for this version. However I was a bit confused
> when I headed to the alternate link
> http://mingw-w64.org/doku.php/download which
> provides version 3.3.0 installers for Windows. Have the version 7
> installers for windows simply not been created or am I looking at the wrong
> stuff? Please help as I am confused on which version I should install

If you are familiar with unix, you can install MSYS2 (which simulates
a posix terminal) and use the pacman command to install gcc and
mingw-w64

regards

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] cmake not creating directories on mingw64, works fine on linux.

[Vincent Torri]

On Fri, Jan 24, 2020 at 7:31 AM Ruben Van Boxem  In my eyes, your CMakeLists.txt shouldn't contain a hardcoded Unix path
> such as /tmp. Instead it should e.g. check if it exists and accept a
> parameter from the command line to overwrite this using an option. In this
> case, it is much more conventional (and it will probably work better
> already) if you pass CMAKE_INSTALL_PREFIX from the command line.
>
> Additionally, directly calling unix commands within a CMakeLists.txt is
> also suboptimal. Instead you should call cmake -E (replace "cmake" with the
> variable CMake defines for itself) followed by the appropriate command you
> want to execute.
>
> Lastly, if the path issue is really getting in your way, you could try
> calling/building/using an MSYS2 version of CMake. I'm not sure there is a
> ready-made package for it, and in light of the above options, I don't think
> this will really be necessary.
>
> Ruben
>
> While the file creation actions went into C:/tmp, after doing this:
> >
> > >>
> > >> mkdir /tmp/testinstall
> > >> mkdir /tmp/testinstall/bin
> > >> mkdir /tmp/testinstall/man
> > >> cmake -G "MSYS Makefiles" ..
> > >> make

in addition, i prefer cross compile cmake-based projects instead, even
in MSYS2. you must open the MinGW 64 bits shell to cross compile for
64 bits :

- cross.txt -

set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR AMD64)
set(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
set(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres)

- end of cross.txt -

cmake -DCMAKE_TOOLCHAIN_FILE=cross.txt -G "Unix Makefiles" 

Vincent Torri

> > the binaries and man files were all correctly deposited into
> > /tmp/testinstall, not C:\tmp\testinstall.  If this was a bash script I
> > would know how to handle this, but within cmake I don't.  Skipping all
> > the compile stuff look at this subsection:
> >
> > SET(CMAKE_INSTALL_PREFIX "/tmp/testinstall")
> > SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_INSTALL_PREFIX}/bin)
> > SET(MAN_INSTALL_DIR  ${CMAKE_INSTALL_PREFIX}/man/man1)
> >
> > FILE(MAKE_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY})
> > if (DO_MAN)
> > FILE(GLOB MAN_FILES  "${CMAKE_CURRENT_SOURCE_DIR}/*.1")
> > FILE(MAKE_DIRECTORY ${MAN_INSTALL_DIR})
> > #install man pages
> > ADD_CUSTOM_TARGET(man ALL
> > ${CMAKE_COMMAND} -E copy  ${MAN_FILES} ${MAN_INSTALL_DIR}
> > COMMENT "Copying all man pages")
> > endif (DO_MAN)
> >
> > The MAKE_DIRECTORY for ${MAN_INSTALL_DIR} went to C:\tmp\testinstall\man
> > and the CMAKE_COMMAND -E copy went to /tmp/testinstall/man.  I think
> > what is happening
> > here is that when the CMAKE_COMMAND (or a compiler action) is done cmake
> > actually spins out
> > a bash session and runs the command line within that, so the usual
> > cygwin to windows path conversions are performeds.  But
> > FILE(MAKE_DIRECTORY...) is internal to cmake and it probably does a
> > mkdir() call directly, so the conversions are not made.
> >
> > Suggestions for making this portable
> >
> > Thanks,
> >
> > David Mathog
> > mat...@caltech.edu
> > Manager, Sequence Analysis Facility, Biology Division, Caltech
> >
> >
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] errno not set by bad call to strtof()

[Vincent Torri]

try to load the symbol to bypass the mingw defines (LoadLibrary +
GetProcAddress and call the symbol)

also try without -std=c99 (and with -std=c89, as gcc sets itself by
default to gnu11 or something like that, iirc) to see if it works.
strtol always exists in Windows, whatever the standard is on Unix.

Vincent

On Wed, Jan 8, 2020 at 8:13 PM David Mathog  wrote:
>
> On 2020-01-08 09:58, Vincent Torri wrote:
> > the look at the official doc :
> > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strtof-strtof-l-wcstof-wcstof-l?view=vs-2019
> >
> > as strtof is a function in msvcrt.dll, maybe it's a bug in the
> > implementation.
>
> Stranger and stranger.  It fails when compiled this way:
>
> gcc -Wall -std=c99 -pedantic -o errno_prob errno_prob.c
>
> However, it works when compiled this way:
>
> g++ -Wall -o errno_prob errno_prob.c
>
> The binary is still linked to msvcrt.dll (according to ntdll) but
> perhaps in this mode
> it calls its own function?
>
> Searched around until the stdlib.h file was located and found within it
> that there was a define
> __USE_MINGW_STRTOX.   So built like this:
>
> gcc -Wall -std=c99 -pedantic -D__USE_MINGW_STRTOX -o errno_prob
> errno_prob.c
>
> and strtof's errno works in both mingw32 (W7) and mingw64 (W10).
>
> However, beyond the defines in stdlib.h I have not found any
> documentation about this.
> Could one of the developers please chip in and tell us what is going on
> here?
> gcc is 9.2.0.
>
> Thanks,
>
> David Mathog
> mat...@caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] errno not set by bad call to strtof()

[Vincent Torri]

the look at the official doc :
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strtof-strtof-l-wcstof-wcstof-l?view=vs-2019

as strtof is a function in msvcrt.dll, maybe it's a bug in the implementation.

Vincent Torri

On Wed, Jan 8, 2020 at 6:50 PM David Mathog  wrote:
>
> On 2020-01-07 20:40, Vincent Torri wrote:
> > hello
> >
> > have you looked at the exemple at the bottom of that page :
> >
> > https://linux.die.net/man/3/strtol
>
> Sure.  My code works on linux using gnu compilers but does not work in
> mingw64 using
> (more or less) the same compilers and the results differ. Below is a a
> tiny complete test program which demonstrates the issue showing the
> issue, just cut and paste the indicated region into a bash shell on
> linux and mingw64
>
> #start cut here
> cat >errno_prob.c <<'EOD'
> /*
>  Build with:
>
> gcc -Wall -std=c99 -pedantic -o errno_prob errno_prob.c
>
>  Run with
>
> errno_prob "1.0e+40"  #overflow test
>
> */
>
> #include 
> #include 
> #include 
>
>
> int main(int argc,char **argv){
> char *final;
> errno=0;
> float fv = strtof(argv[1],);
> fprintf(stderr,"DEBUG buffer %p final %p fv %f errno
> %d\n",argv[1],final,fv, errno);
> fflush(stderr);
> exit(EXIT_SUCCESS);
> }
> EOD
> gcc -Wall -std=c99 -pedantic -o errno_prob errno_prob.c
> ./errno_prob "1.0e+40"
> #end cut here
>
> Outputs from the two systems:
>
> linux:   DEBUG buffer 0x7ffdb3ad8ee0 final 0x7ffdb3ad8ee6 fv inf errno
> 34
> mingw64: DEBUG buffer 0068F970 final 0068F977 fv
> 1.#INF00 errno 0
>
> The only significant difference is that errno is not set in the mingw64
> one.  It should be though, because 1.0e+40 is an ERANGE state, as
> correctly indicated on linux.
> No input I tried would make errno something other than 0.  These were
> tried:
>
> 1.0e+40
> blech
> .001
> 1000
> 1.0e-100
>
> So why is errno not set in mingw64?
>
> Thanks,
>
> David Mathog
> mat...@caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] errno not set by bad call to strtof()

[Vincent Torri]

hello

have you looked at the exemple at the bottom of that page :

https://linux.die.net/man/3/strtol

?

Vincent Torri

On Tue, Jan 7, 2020 at 11:54 PM David Mathog  wrote:
>
> A program of mine "binload" which has key parts:
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include/* for uint8_t*/
> #include  /* for PRId64 */
> #include 
> #include/* for close */
> #include 
>
> int main(int argc,char **argv){
> errno = 0;  /* Works around an issue with OpenMPI preload which can
> leaver errno set */
>
> float fv;
> char  buffer[1024];
> char *final;
>
> /* code that reads a line of text and puts it into buffer */
>
> fv = strtof(buffer,);
> fprintf(stderr,"DEBUG buffer %p final %p fv %f errno
> %d\n",buffer,final,fv, errno);fflush(stderr);
>
> is compiled on mingw64 with:
>
> gcc -o binload binload.c
>
> When the strtof() function runs with buffer containing the string
> "1.0e+40" it fails, as it should,
> because the value is too large for a float.  On linux errno is set and
> later code handles the error.  However in mingw64 that debug line emits:
>
> DEBUG buffer 0068F970 final 0068F977 fv 1.#INF00 errno 0
>
> Because errno is not set the error isn't handled correctly.  If the
> formatted float in "buffer" is
> within range then strtof() returns the correct value.  For instace, for
> 1.0e+04 it emits:
>
> DEBUG buffer 0068F970 final 0068F977 fv 1.00
> errno 0
>
> Am I using errno improperly for mingw64 (maybe some Windows variant is
> needed instead?) or is there some other issue in play?
>
> Thanks,
>
> David Mathog
> mat...@caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now

[Vincent Torri]

Hello David

here is what i am doing with my package installer :

https://github.com/vtorri/ewpi/blob/master/packages/libxml2/install.sh
version i compile :
https://github.com/vtorri/ewpi/blob/master/packages/libxml2/libxml2.ewpi

hth

Vincent Torri

On Wed, Dec 11, 2019 at 10:50 PM David Mathog  wrote:
>
> Trying to build libxml2 in MSYS2 mingw32.  About a year ago using the
> same commands 2.9.7 built without problems.  Now neither 2.9.10 nor
> 2.9.7 will build, both failing in the "python" part of the build.
> After downloading and unpacking libxml2 2.9.10 (2.9.7 acts the same)
> did:
>
> #in an MSYS2 mingw32 window
> ./configure
> make
>
> which failed.
>
> The python section wanted to include "crypt.h".  Installed that with:
>pacman -S libcrypt
> but it still did not find it, because the file is in /usr/include rather
> than /mingw32/include.  It is looking for python includes in
> /usr/include/python3.7m but changing that to python2.7 did not help.
>
> With "make V=1" found the compile line which was looking for "crypt.h"
> and added to it "-I/usr/include".  That got it past the crypt.h problem
> but then it wanted "sys/select.h", which is I think an even bigger
> problem.
>
> I didn't see an option for 2.9.10 like "--disable-libcrypt" or anything
> like that.
>
> Anybody else run into this yet?
>
> This was after updating all of mingw32 with "pacman -Syu" (twice)
> yesterday.  So I think all of the Msys2/mingw32 pieces should be
> current.
> Everything was updated about a year ago too, before the last build.  So
> some combination of mingw32 and libxml2 changes in the last year seem to
> have broken things.
>
> Thanks,
>
> David Mathog
> mat...@caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ___
> 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] missing WTSEnumerateSessionsEx

[Vincent Torri]

Hello

afaics, WTSEnumerateSessionsEx and the related WTS_SESSION_INFO_1
structure are not declared.

Is it an omission or is it normal ?

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

[Vincent Torri]

On Fri, Jun 28, 2019 at 7:17 PM Ruben Van Boxem
 wrote:
>
>
> I'm interested in seeing real-world benchmarks when using this code!

that is something i would really like too

Vincent Torri


___
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] wrong declaration of InetNtopA and InetNtopW

[Vincent Torri]

hello

*pton has also the same wrong declaration, no ?

Vincent Torri

On Mon, Apr 22, 2019 at 9:07 PM Martin Storsjö  wrote:
>
> On Mon, 22 Apr 2019, Liu Hao wrote:
>
> > 在 2019/4/22 下午8:27, Martin Storsjö 写道:
> >> On Sat, 20 Apr 2019, Liu Hao wrote:
> >>
> >>> 在 2019/4/19 下午4:59, Vincent Torri 写道:
> >>>> when will this hit git or next mingw-w64 release ?
> >>>>
> >>>
> >>>
> >>> For this small change I will leave it on this mailing list for
> >>> discussion. If there is no objection I may push it a couple of days
> >>> later.
> >>
> >> Your patch broke compilation, as there's no type PCVOID commonly
> >> defined, only PVOID and LPCVOID.
> >>
> >> I pushed a fix for master, I can backport it just like your patch a bit
> >> later, unless you beat me to it.
> >>
> >>
> >
> > Well, there is a definition of `PCVOID` in 'cfgmgr32.h', but it is only
> > used in that file.
>
> Yup, that's what I meant about "commonly defined". (I was a bit terse
> before, typing on a phone.)
>
> > And, thanks for the fix. I have just noticed that these functions aren't
> > available unless `_WIN32_WINNT` is at least `0x0600` and it is why it
> > didn't fail on my side. Apologize for that.
>
> Ah, yes, that explains why it slipped through.
>
> // Martin
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] issues with application to run commands in parallel on Windows

[Vincent Torri]

On Tue, May 7, 2019 at 12:17 AM David Mathog  wrote:
>
> On 04-May-2019 20:31, Liu Hao wrote:
> > 在 2019/5/4 上午6:16, David Mathog 写道:
>
> Thanks for the feedback, but I'm still nowhere near getting this to
> work.
>
> >>
> >> Issues:
> >>
> >>
> >> 1.  Compiler warnings:
> >>
> >> c_spawn_n.c: In function 'main':
> >> c_spawn_n.c:47:13: warning: passing argument 3 of 'CreateThread' from
> >> incompatible pointer type [-Wincompatible-pointer-types]
> >>  RunCommand, // thread function name
> >>  ^~
> >
> > `LPTHREAD_START_ROUTINE` is the type of the parameter of
> > `CreateThread()`, which a pointer-to-function. The proper return type
> > for a thread procedure is `DWORD` rather than this thing.
>
> Changed the called routine to (see below):
>
> DWORD  RunCommand(  void *lpParam  ){

try :

DWORD WINAPI Runcommand(LPVOID lpParam) { ...}

see https://docs.microsoft.com/en-us/windows/desktop/procthread/creating-threads

Vincent Torri


___
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] wrong declaration of InetNtopA and InetNtopW

[Vincent Torri]

when will this hit git or next mingw-w64 release ?

On Fri, Apr 19, 2019 at 10:35 AM Liu Hao  wrote:
>
> 在 2019/4/19 下午3:29, Vincent Torri 写道:
> > hello
> >
> > in ws2tcpip.h, i have the following declarations of these 2 functions :
> >
> > WINSOCK_API_LINKAGE LPCWSTR WSAAPI InetNtopW(INT Family, PVOID pAddr,
> > LPWSTR pStringBuf, size_t StringBufSIze);
> > WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, PVOID pAddr,
> > LPSTR pStringBuf, size_t StringBufSize);
> >
> > that is the 2nd parameter is a void *
> >
> > But in the doc :
> >
> > https://docs.microsoft.com/fr-fr/windows/desktop/api/ws2tcpip/nf-ws2tcpip-inet_ntop
> > https://docs.microsoft.com/fr-fr/windows/desktop/api/ws2tcpip/nf-ws2tcpip-inetntopw
> >
> > the 2nd parameter is a  const void *
> >
> > is it normal or is it a bug in the declaration ?
> >
> > thank you
> >
> > Vincent Torri
> >
> >
>
> It looks like typos. The patch attached should fix this issue.
>
>
>
> --
> Best regards,
> LH_Mouse


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] wrong declaration of InetNtopA and InetNtopW

[Vincent Torri]

hello

in ws2tcpip.h, i have the following declarations of these 2 functions :

WINSOCK_API_LINKAGE LPCWSTR WSAAPI InetNtopW(INT Family, PVOID pAddr,
LPWSTR pStringBuf, size_t StringBufSIze);
WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, PVOID pAddr,
LPSTR pStringBuf, size_t StringBufSize);

that is the 2nd parameter is a void *

But in the doc :

https://docs.microsoft.com/fr-fr/windows/desktop/api/ws2tcpip/nf-ws2tcpip-inet_ntop
https://docs.microsoft.com/fr-fr/windows/desktop/api/ws2tcpip/nf-ws2tcpip-inetntopw

the 2nd parameter is a  const void *

is it normal or is it a bug in the declaration ?

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded

[Vincent Torri]

On Thu, Mar 7, 2019 at 10:30 AM Matthias Apitz  wrote:
>
> Re/ crosscompiling: I'm used to do so on FreeBSD amd64 for x86 target,
> but never compiled something on FreeBSD/Linux for Windows.

use the mingw-w64 toolchain (sould be available in your freebsd distribution)

i686-w64-mingw32-gcc, etc... for 32 bits

x86_64-w64-mingw32-gcc, etc... for 64 bits

Vincent Torri

>The CPP files
> here in question were written years ago with some Microsoft Visual
> Studio (at least some artefacts around the CPP files say so). I think,
> it's enough and easy to write some makefiles in addition and if I could
> integrate this in our Jenkins CI on Linux this would be the finest solution.
>
> matthias
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, 
> Druschba
> instead of Nazis, to live instead of to survive.
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] DLL produced by Mingw-w64 can't be loaded

[Vincent Torri]

On Thu, Mar 7, 2019 at 9:27 AM Matthias Apitz  wrote:
>
> El día Wednesday, March 06, 2019 a las 11:20:05AM -0800, David Grayson 
> escribió:
>
> > Your experience matches mine: the Cygwin ldd utility does not work properly
> > with MinGW DLLs and prints a bunch of question marks.  There is an ntldd
> > utility you can use instead.  If it's not on your path already, I'm not
> > sure the best way to obtain it.  I just use MSYS2, because it's basically a
> > fork of Cygwin that makes it easy to install MinGW compilers and all the
> > other open source utilities you would need to build software on Linux,
> > including ntldd.
> >
> > --David
>
> David, thanks for your reply. Does this mean I could move to a Linux system
> with Mingw-w64 to produce the DLL for Windows there? This would be the first
> option as I do know less as nothing about Windows, but 30++ years about
> UNIX :-)
>
> This also would allow to produce the DLL together with the Java software
> on our Jenkins server hosted on Linux...
>
> Re/ my problem "Can't find dependent libraries." from the Java DLL loader, I 
> found
> a thread in stackoverflow
> https://stackoverflow.com/questions/6092200/how-to-fix-an-unsatisfiedlinkerror-cant-find-dependent-libraries-in-a-jni-pro/6092576#6092576
> with a hint to a tool which analyses the DLL for missing dependencie (etc.)

dependency walker is a very nice tool too.

> Below is the (very short) list of missing pieces which I can't see on my
> Windows file system.
>
> Any ideas?
> -  -    
>   --
> [ ? ]  LIBGCC_S_SEH-1.DLL Error opening file. Das 
> System kann die angege
> [ ? ]  LIBSTDC++-6.DLLError opening file. Das 
> System kann die angege

those 2 files are in your gcc installation directory. They must be
copied in the directory of your DLL

> [D? ]  API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL Error opening file. Das 
> System kann die angege
> [D? ]  API-MS-WIN-CORE-WINRT-L1-1-0.DLL   Error opening file. Das 
> System kann die angege
> [D? ]  API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL  Error opening file. Das 
> System kann die angege
> [D? ]  API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLLError opening file. Das 
> System kann die angege
> [D? ]  DCOMP.DLL  Error opening file. Das 
> System kann die angege
> [D? ]  IESHIMS.DLL        Error opening file. Das 
> System kann die angege

these above should be part of Windows.

normally you only need to copy the 2 above gcc dll where your dll is located.

Vincent Torri

> [  6]  API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL  09.01.2019 04:06  
> 09.01.2019 04:07   4.608
> [D 6]  DWMAPI.DLL 09.07.2015 18:58  
> 09.07.2015 18:53  82.944
> [DE6]  ESENT.DLL  11.03.2011 07:33  
> 11.03.2011 07:22   2.565.632


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Linking fails for GetSaveFileName when cross compiling with MinGW

[Vincent Torri]

On Tue, Jan 8, 2019 at 9:40 PM Sailor Bob via Mingw-w64-public
 wrote:
>
>  OK, figured out what the problem was - order of arguements on the command 
> line:
> i686-w64-mingw32-g++ -lcomdlg32 -municode -o unilogger.exe
> gives the link error, however
> i686-w64-mingw32-g++ -municode -o unilogger.exe -lcomdlg32
>
> Compiles just fine.  Go figure...

it's normal, this is the classic order of dependencies (from the right
the libraries with the fewest deps to the left with the most deps)

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] inttypes Format Specifiers

[Vincent Torri]

On Fri, Oct 26, 2018 at 11:58 PM Mateusz  wrote:
>
> W dniu 26.10.2018 o 22:35, Tom Ritter pisze:
> > This is not really a MinGW problem, but MinGW does diverge from other
> > compilers and it caused Firefox to crash.
> >
> > MinGW defines a lot of I64[foo] format specifiers in inttypes.h.
> > clang and clang-cl don't use I64[foo] they use ll[foo]. (I64[foo] is
> > valid according to Microsoft. MinGW mentions "MS runtime does not yet
> > understand C9x standard "ll"" but at some point they started
> > supporting ll[foo].  And as I mentioned, that's what clang[-cl] uses.
> >
> > Mozilla has our own implementation of printf that does the format
> > specifier parsing. We don't support I64[foo]. So using it caused data
> > corruption and general bad behavior. Switching to ll[foo] fixed it.
> >
> > I have a patch here:
> > https://hg.mozilla.org/try/raw-file/eaae7782a1dd/build/build-clang/mingw-int.patch
>
> You can try to define
> __USE_MINGW_ANSI_STDIO
> instead of patching mingw-w64

i've mesure a significant performance loss when using printf
functions with __USE_MINGW_ANSI_STDIO cmopared to the ones in
msvcrt.dll

is it normal ?

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] dxgi debug is missing

[Vincent Torri]

Hello

dxgidebug.h (https://docs.microsoft.com/en-us/windows/desktop/api/dxgidebug/)
is missing.

Is it possible to add this header ?

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] D3DX11CreateShaderResourceViewFromFile is missing

[Vincent Torri]

Hello

this function seems deprecated (according to MSDN), but is it possible
that it is added ?

thank you

Vincent Torri


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] sizeof long

[Vincent Torri]

On Tue, Apr 17, 2018 at 4:58 PM,  <sisyph...@optusnet.com.au> wrote:
> Hi,
>
> Why is it that on our x86_64 compilers sizeof long is only 4 ?
> Does it absolutely have to be that way ?  Would it be possible to design
> a switch that would enable 8 byte longs ?
>
> The mismatch between linux and windows in this regard is a real pita, and
> I'm curious about the reason(s) that it exists.
> (A link to relevant explanation would be fine.)

https://msdn.microsoft.com/ro-ro/library/s3f49ktz.aspx
https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

Vincent Torri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] linux gcc vs mingw-w64 performance ?

[Vincent Torri]

On Thu, Jan 18, 2018 at 2:27 AM, lemonsqueeze  wrote:
> Ah, found the big one:
> Was testing single threaded but code uses __thread thread-local storage
> which slows things down a lot on mingw.
>
> Tried a few alternatives:
> - Microsoft TlsGetValue() / TlsSetValue()
> - pthread_getspecific() / pthread_setspecific()
> - __thread
> - own array-based tls using pthread_self()
> - own array-based tls using GetCurrentThreadId()
>
> Fastest so far is the last one, getting comparable perf with linux
> (8% slower instead of 30%).

what is the % with TlsGetValue / TlsSetValue ?

Vincent

>
>
> On 01/15/2018 10:22 PM, lemonsqueeze wrote:
>>
>> Hi,
>>
>> Typically what kind of performance should I expect when porting
>> cpu-intensive code from linux to mingw-w64 ?
>>
>> I'm doing some experiments with a particular C99 app:
>> linux i686 gcc 4.8vswindows x86 mingw-w64 7.2 (msys2)
>> same hardware (intel atom)
>>
>> Surprisingly it's getting almost 30% slower on windows in the
>> cpu-intensive part (single threaded, no syscalls, memory intensive
>> integer arithmetic mostly). gcc 4.8 doesn't favor linux, I would've
>> expected the opposite.
>>
>> Any ideas what's going on / where to look ?
>> I guess i'm going to need a good profiler to find out ...
>>
>> Cheers
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] basename with "/usr/"

[Vincent Torri]

On Sat, Dec 30, 2017 at 4:38 PM, Vincent Torri <vincent.to...@gmail.com> wrote:
> hello
>
> I tried dirname and basename with all the examples found here :
> https://linux.die.net/man/3/dirname
>
> and with "/usr/" I obtain
>  * for dirname : / (wich is correct)
>  * for basename : empty string (which is different from linux
> basename, should be "usr")
>
> is it a bug ?

if I strdup the path, then it is correct

forget about the noise

Vincent Torri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] basename with "/usr/"

[Vincent Torri]

On Sat, Dec 30, 2017 at 4:38 PM, Vincent Torri <vincent.to...@gmail.com> wrote:
> hello
>
> I tried dirname and basename with all the examples found here :
> https://linux.die.net/man/3/dirname
>
> and with "/usr/" I obtain
>  * for dirname : / (wich is correct)
>  * for basename : empty string (which is different from linux
> basename, should be "usr")
>
> is it a bug ?

or actually, it follows the GNU version as mentioned in the notes. But
I have that behavior without using _GNU_SOURCE

Vincent Torri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] basename with "/usr/"

[Vincent Torri]

also for dirname.c, line 74, maybe we should add a test like

(refpath[0]>= 'a' && refpath[0]>= 'z') || (refpath[0]>= 'A' && refpath[0]>= 'Z')

Vincent Torri

On Sat, Dec 30, 2017 at 4:38 PM, Vincent Torri <vincent.to...@gmail.com> wrote:
> hello
>
> I tried dirname and basename with all the examples found here :
> https://linux.die.net/man/3/dirname
>
> and with "/usr/" I obtain
>  * for dirname : / (wich is correct)
>  * for basename : empty string (which is different from linux
> basename, should be "usr")
>
> is it a bug ?
>
> thank you
>
> Vincent Torri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] basename with "/usr/"

[Vincent Torri]

hello

I tried dirname and basename with all the examples found here :
https://linux.die.net/man/3/dirname

and with "/usr/" I obtain
 * for dirname : / (wich is correct)
 * for basename : empty string (which is different from linux
basename, should be "usr")

is it a bug ?

thank you

Vincent Torri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc

[Vincent Torri]

it seems that it is part of gcc, so maybe the mingw-w64 maintainers should
be able to answer you

Vincent

On Sat, May 27, 2017 at 10:37 PM, Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:

> On 5/27/2017 12:08 PM, niXman wrote:
>
>> Edward Diener 2017-05-27 18:40:
>>
>>> On 5/26/2017 11:03 PM, Vincent Torri wrote:
>>>
>>>> ./configure --host=i686-w64-mingw32
>>>> or
>>>> ./configure --host=i686-w64-mingw32
>>>>
>>>> for respectively 32bits and 64bits support
>>>>
>>>
>>> Your configure commands are the same.
>>>
>>
>>
>>
>> ./configure --host=i686-w64-mingw32
>> or
>> ./configure --host=x86_64-w64-mingw32
>>
>
> OK.
>
> Do I use msys2 in order to build libbacktrace ? When building do I need to
> use the version of mingw-64/gcc for which I will be using libbacktrace when
> I eventually use mingw-64/gcc as my compiler ? If I need to do that do I
> just add the mingw-64/gcc compiler to the beginning of my msys2 path ?
>
> I have used various versions of mingw-64/gcc binaries in order to test
> Boost libraries but I have never built another library for use by any
> particular version of mingw-64/gcc, which is why I am asking these
> questions.
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc

[Vincent Torri]

On Sat, May 27, 2017 at 6:08 PM, niXman <i.nix...@autistici.org> wrote:

> Edward Diener 2017-05-27 18:40:
>
>> On 5/26/2017 11:03 PM, Vincent Torri wrote:
>>
>>> ./configure --host=i686-w64-mingw32
>>> or
>>> ./configure --host=i686-w64-mingw32
>>>
>>> for respectively 32bits and 64bits support
>>>
>>
>> Your configure commands are the same.
>>
>
>
>
> ./configure --host=i686-w64-mingw32
> or
> ./configure --host=x86_64-w64-mingw32
>

oups, copy paste :)

Vincent


>
>
> --
> Regards, niXman
> ___
> Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
> https://sf.net/p/mingw-w64/
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc

[Vincent Torri]

On Sat, May 27, 2017 at 12:14 AM, Edward Diener
<eldlistmaili...@tropicsoft.com> wrote:
> On 5/26/2017 4:13 PM, Vincent Torri wrote:
>>
>> Hello
>>
>> On Fri, May 26, 2017 at 9:50 PM, Edward Diener
>> <eldlistmaili...@tropicsoft.com> wrote:
>>>
>>> I would like to use a libbacktrace library for mingw-64/gcc. This is used
>>> by
>>> a new Boost library called stacktrace to provide stack traces anywhere in
>>> code in c++ when using GCC/MinGW/Clang on POSIX or Windows. Does such a
>>> library exist for mingw-64/gcc on Windows ? If not can such a library be
>>> built for a given version of mingw-64/gcc on Windows, presumably in MSYS2
>>> ?
>>
>>
>> I have written a small library and app around memory checking and PE
>> files. It is called examine and can report backtraces (using libbfd
>> for stack trace). It is here :
>>
>> https://vtorri.github.io/examine/
>> https://github.com/vtorri/examine
>>
>> I use MSYS2 + mingw-w64 for compilation, or Visual Studio.
>
>
> Thank you, but what does this have to do with libbacktrace for mingw-64/gcc
> ?

you wanted a library which provide stack traces.

for libbacktrace, I can see in
https://github.com/gcc-mirror/gcc/tree/master/libbacktrace so PE/COFF
commits and file. So I guess it is possible

try

autoreconf -vif

and

./configure --host=i686-w64-mingw32
or
./configure --host=i686-w64-mingw32

for respectively 32bits and 64bits support

regards

Vincent



>>
>> regards
>>
>> Vincent Torri
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc

[Vincent Torri]

Hello

On Fri, May 26, 2017 at 9:50 PM, Edward Diener
<eldlistmaili...@tropicsoft.com> wrote:
> I would like to use a libbacktrace library for mingw-64/gcc. This is used by
> a new Boost library called stacktrace to provide stack traces anywhere in
> code in c++ when using GCC/MinGW/Clang on POSIX or Windows. Does such a
> library exist for mingw-64/gcc on Windows ? If not can such a library be
> built for a given version of mingw-64/gcc on Windows, presumably in MSYS2 ?

I have written a small library and app around memory checking and PE
files. It is called examine and can report backtraces (using libbfd
for stack trace). It is here :

https://vtorri.github.io/examine/
https://github.com/vtorri/examine

I use MSYS2 + mingw-w64 for compilation, or Visual Studio.

regards

Vincent Torri

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GUID definition in guiddef.h

[Vincent Torri]

On Fri, Apr 28, 2017 at 3:27 PM, Liu Hao <lh_mo...@126.com> wrote:
> On 2017/4/28 19:38, Vincent Torri wrote:
>> Hello
>>
>> in guiddef.h, a GUID is a struct organized as : 4 bytes, 2 bytes 2
>> bytes and 8 times 1 byte
>>
>> but according to
>> https://msdn.microsoft.com/en-us/library/dd354925.aspx at the bottom :
>>
>> "The correct format of the GUID string is
>> {CDEF7890-ABCD-1234-ABCD-1234567890AB} where 0-9, A-F symbolizes
>> hexadecimal digits. "
>>
>> that is, the GUID structure should be organized as : 4 bytes, 2 bytes
>> 2 bytes 2 bytes and 6 times 1 byte
>>
>> is it normal that the GUID structure does not follow the MSDN doc ?
> It is because Microsoft's own version is defined like that and we
> shouldn't create the incompatibility.
>
> Reference:
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa373931(v=vs.85).aspx

ok, the MSDC doc i mentioned is incorrect...

thank you

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] GUID definition in guiddef.h

[Vincent Torri]

Hello

in guiddef.h, a GUID is a struct organized as : 4 bytes, 2 bytes 2
bytes and 8 times 1 byte

but according to
https://msdn.microsoft.com/en-us/library/dd354925.aspx at the bottom :

"The correct format of the GUID string is
{CDEF7890-ABCD-1234-ABCD-1234567890AB} where 0-9, A-F symbolizes
hexadecimal digits. "

that is, the GUID structure should be organized as : 4 bytes, 2 bytes
2 bytes 2 bytes and 6 times 1 byte

is it normal that the GUID structure does not follow the MSDN doc ?

Vincent

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] FLT_EPSILON missing

[Vincent Torri]

On Tue, Dec 20, 2016 at 12:38 PM, niXman <i.nix...@autistici.org> wrote:
> Vincent Torri 2016-12-20 09:04:
>> Hello
> Hi,
>
>> it seems that  FLT_EPSILON and DBL_EPSILON are missing in float.h. at
>> least, i can't find it here :
>>
>> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/crt/float.h
>>
>> for reference, see :
>>
>> https://msdn.microsoft.com/fr-fr/library/k15zsh48.aspx
>>
>> can this be added ?
>
> This is strange because just now I test it using i686-6.2.0-posix-dwarf
> and all works fine.
>
> My example:
>
> #include 
> #include 
>
> int main() {
> printf("%g\n", FLT_EPSILON);
> printf("%g\n", DBL_EPSILON);
> }
>

indeed, your test works here too

after a fgrep in the entire repo, FLT_EPSILON is defined as
__FLT_EPSILON__ in lib/***, not include/, the latter being defined
somewhere

sorry for the noise

Vincent

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] FLT_EPSILON missing

[Vincent Torri]

Hello

it seems that  FLT_EPSILON and DBL_EPSILON are missing in float.h. at
least, i can't find it here :

https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/crt/float.h

for reference, see :

https://msdn.microsoft.com/fr-fr/library/k15zsh48.aspx

can this be added ?

thank you

Vincent Torri

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
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 v7] Add include/iscygtty.c

[Vincent Torri]

i still don't understand why not using GetConsoleMode() and see if it
fails or not.

if it fails : redirection is done with named pipes
if not : it's standard win32 I/O

it's simple and works in my tests (DOS console, MSYS1, mintty, MSYS2
and cygwin terminal >= 1.8)

Vincent Torri


On Sun, Nov 13, 2016 at 1:00 AM, Mihail Konev <k@ya.ru> wrote:
> Applications now could call iscygtty(STDIN_FILENO)
> in order to detect whether they are running from
> Cygwin/MSys terminal.
>
> Without that, they have no choice but to think that
> stdin is redirected from a named pipe.
>
> Signed-off-by: Mihail Konev <k@ya.ru>
> Moved-from: https://github.com/Alexpux/mingw-w64/pull/3
> Adapted-from: https://cygwin.com/ml/cygwin-developers/2016-11/msg2.html
> ---
> v7:
> - set errno if returning false
> - do not depend on ntdll.dll being linked, use GetProcAddress
> - stricter name check
> - act as cygwin.dll isatty()
>   I.e. is-it-mintty-or-cmd?
>   To get the previous is-it-mintty? behaviour, just omit the "if (_isatty)".
>
> The is-it-mintty? is actually a leftover from initial example;
> the "real" version could as well aggressively alias the stanard api
> (especially given that applications could still call the is-it-cmd? _isatty() 
> if they want to).
>
> Don't know how to make it a substitute for isatty(), through.
> Putting this into io.h results in implicit declarations and errors.
>
> Should all used types be declared locally in the function,
> or headers be rearranged (but how?)?
>
> Also typedef proc_NtQueryObject could be broken in some compiler; should
> it not be used?
>
> This function is intended for:
> - "mingw64-" Cygwin packages
> - "mingw-w64-" MSYS packages
> Both should be built using mingw-w64 toolchain, and currenly have isatty() 
> being _isatty().
>
>  mingw-w64-headers/include/iscygtty.c | 96 
> 
>  1 file changed, 96 insertions(+)
>  create mode 100644 mingw-w64-headers/include/iscygtty.c
>
> diff --git a/mingw-w64-headers/include/iscygtty.c 
> b/mingw-w64-headers/include/iscygtty.c
> new file mode 100644
> index ..1c7a394d965b
> --- /dev/null
> +++ b/mingw-w64-headers/include/iscygtty.c
> @@ -0,0 +1,96 @@
> +#ifndef __ISCYGTTY_C__
> +#define __ISCYGTTY_C__
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static int iscygtty(int fd) {
> +typedef NTSTATUS (NTAPI proc_NtQueryObject) (HANDLE, 
> OBJECT_INFORMATION_CLASS, PVOID, ULONG, PULONG);
> +proc_NtQueryObject *pNtQueryObject;
> +
> +HANDLE h_fd;
> +
> +/* NtQueryObject needs space for OBJECT_NAME_INFORMATION.Name->Buffer 
> also. */
> +char ntfn_bytes[sizeof(OBJECT_NAME_INFORMATION) + MAX_PATH * 
> sizeof(WCHAR)];
> +
> +OBJECT_NAME_INFORMATION *ntfn = (OBJECT_NAME_INFORMATION*) ntfn_bytes;
> +NTSTATUS status;
> +ULONG ntfn_size = sizeof(ntfn_bytes);
> +
> +wchar_t c, *s;
> +USHORT i;
> +
> +h_fd = (HANDLE) _get_osfhandle(fd);
> +if (!h_fd || h_fd == INVALID_HANDLE_VALUE) {
> +errno = EBADF;
> +return 0;
> +}
> +
> +pNtQueryObject = (proc_NtQueryObject*) 
> GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQueryObject");
> +if (!pNtQueryObject)
> +goto no_tty;
> +
> +memset(ntfn, 0, ntfn_size);
> +status = pNtQueryObject((HANDLE)h_fd, ObjectNameInformation,
> +ntfn, ntfn_size, _size);
> +
> +if (!NT_SUCCESS(status)) {
> +/* If it is not NUL (i.e. \Device\Null, which would succeed),
> + * then normal isatty() could be consulted.
> + * */
> +if (_isatty(fd))
> +return 1;
> +goto no_tty;
> +}
> +
> +s = ntfn->Name.Buffer;
> +s[ntfn->Name.Length / sizeof(WCHAR)] = 0;
> +
> +/* Look for 
> \Device\NamedPipe\(cygwin|msys)-[a-fA-F0-9]{16}-pty[0-9]{1,4}-(from-master|to-master|to-master-cyg)
>  */
> +
> +if (wcsncmp(s, L"\\Device\\NamedPipe\\", 18))
> +goto no_tty;
> +s += 18;
> +
> +if (!wcsncmp(s, L"cygwin-", 7))
> +s += 7;
> +else if (!wcsncmp(s, L"msys-", 5))
> +s += 5;
> +else
> +goto no_tty;
> +
> +for (i = 0; i < 16; i++) {
> +c = *s++;
> +if (!( (c >= 'a' && c <= 'f') || (c >= 'A' && c <= 'F') || (c >= '0' 
> && c <= '9') ))
> +goto no_tty;
> +}
> +
> +if (wcsncmp(s, L"-pty", 4))
> +goto no_tty;
> +s += 4;
> +
> +for (i = 0; i <

Re: [Mingw-w64-public] [PATCH mingw-w64] Add include/iscygtty.c

[Vincent Torri]

two cases :

1) pipe redirection : mintty and therefore cygwin (>= 1.8) terminal
and MSYS2 terminal (as the 2 latters are based on mintty)
2) MSYS1 and CMD console

ConEmu is a specific case as, if i'm not mistaken, it can switch from
one redirection to the other one

Vincent

PS: i've also replied to the mingw-w64 ML, Mihail, maybe you should
send again the files to the ML

On Thu, Nov 10, 2016 at 7:13 PM, Mihail Konev <k@ya.ru> wrote:
> On Thu, Nov 10, 2016 at 06:16:38AM +0100, Vincent Torri wrote:
>> just call GetConsoleMode() and check its result to know if the
>> redirection is with a pipe or a console handle
> The result would then differ in two cases:
> - stdin is Cygwin/MSys terminal
> - stdin is Windows console
>
> Attached are test program source, Makefile, and 'make' output when run
> from MSys2-MINGW64 shell.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
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 mingw-w64] Add include/iscygtty.c

[Vincent Torri]

hello

just call GetConsoleMode() and check its result to know if the
redirection is with a pipe or a console handle

Vincent


On Thu, Nov 10, 2016 at 1:46 AM, Mihail Konev  wrote:
> Applications now could call iscygtty(STDIN_FILENO)
> in order to detect whether they are running from
> Cygwin/MSys terminal.
>
> Without that, they have no choice but to think that
> stdin is redirected from a named pipe.
>
> Signed-off-by: Mihail Konev 
> Moved-from: https://github.com/Alexpux/mingw-w64/pull/3
> ---
>  mingw-w64-headers/include/iscygtty.c | 69 
> 
>  1 file changed, 69 insertions(+)
>  create mode 100644 mingw-w64-headers/include/iscygtty.c
>
> diff --git a/mingw-w64-headers/include/iscygtty.c 
> b/mingw-w64-headers/include/iscygtty.c
> new file mode 100644
> index ..f7344b8b20c4
> --- /dev/null
> +++ b/mingw-w64-headers/include/iscygtty.c
> @@ -0,0 +1,69 @@
> +#ifndef __ISCYGTTY_C__
> +#define __ISCYGTTY_C__
> +
> +#include 
> +#include 
> +
> +static int iscygtty(int fd) {
> +intptr_t h_fd = _get_osfhandle(fd);
> +
> +char ntfn_bytes[sizeof(OBJECT_NAME_INFORMATION) + 256 * sizeof(WCHAR)];
> +OBJECT_NAME_INFORMATION *ntfn = (OBJECT_NAME_INFORMATION*) ntfn_bytes;
> +NTSTATUS status;
> +ULONG ntfn_size = sizeof(ntfn_bytes);
> +
> +USHORT i, l;
> +wchar_t c, *s0;
> +
> +memset(ntfn, 0, ntfn_size);
> +status = NtQueryObject((HANDLE)h_fd, ObjectNameInformation,
> +ntfn, ntfn_size, _size);
> +
> +if (!NT_SUCCESS(status))
> +return 0;
> +
> +l = ntfn->Name.Length;
> +s0 = ntfn->Name.Buffer;
> +
> +/* Check for "\Device\NamedPipe" */
> +{
> +USHORT l1 = l;
> +wchar_t *s1 = s0;
> +wchar_t expect[] = L"\\Device\\NamedPipe\\";
> +
> +if (s0[0] == '\\' && s0[1] == '\\' && s0[2] == '?' && s0[3] == '\\') 
> {
> +l1 -= 4;
> +s1 += 4;
> +}
> +for (i = 0; i < l1; i++) {
> +wchar_t e = expect[i];
> +c = s1[i];
> +if (!e)
> +break;
> +if (c != e)
> +return 0;
> +}
> +}
> +
> +/* Look for "-pty%d-" */
> +for (i = 0; i < l; i++) {
> +c = s0[i];
> +if (c == '-') {
> +wchar_t *s = s0 + i + 1;
> +c = *s;
> +if ((c == 'p' || c == 't') && s[1] == 't' && s[2] == 'y' &&
> +(c = s[3]) && (c >= '0') && (c <= '9'))
> +{
> +s += 4;
> +while ((c = *s) && (c >= '0') && (c <= '9'))
> +s++;
> +if (c == '-' || c == 0)
> +return 1;
> +}
> +}
> +}
> +
> +return 0;
> +}
> +
> +#endif /* __ISCYGTTY_C__ */
> --
> 2.9.2
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [MSYS2] How do I install makefinfo

[Vincent Torri]

isn't it in the texinfo package ?

Vincent Torri

On Fri, Jul 15, 2016 at 11:31 AM,  <sisyph...@optusnet.com.au> wrote:
> Hi,
>
> Using dongsheng's gmp-6.1.1 (win32 threads, seh) build.
>
> I'm trying to build mpfr (svn revision 10613) in the msys2 shell and getting
> hammered early on in the 'make' stage with:
>
> ###
> make[1]: Entering directory 'C:/_64/comp/mpfr-10613/doc'
> restore=: && backupdir=".am$$" && \
> am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \
> rm -rf $backupdir && mkdir $backupdir && \
> if (C:/_64/msys64/usr/bin/sh.exe /c/_64/comp/mpfr-10613/missing
> makeinfo --version) >/dev/null 2>&1; then \
>   for f in mpfr.info mpfr.info-[0-9] mpfr.info-[0-9][0-9] mpfr.i[0-9]
> mpfr.i[0-9][0-9]; do \
> if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
>   done; \
> else :; fi && \
> cd "$am__cwd"; \
> if C:/_64/msys64/usr/bin/sh.exe /c/_64/comp/mpfr-10613/missing
> akeinfo  --enable-encoding -I . \
> -o mpfr.info mpfr.texi; \
> then \
>   rc=0; \
>   CDPATH="${ZSH_VERSION+.}:" && cd .; \
> else \
>   rc=$?; \
>   CDPATH="${ZSH_VERSION+.}:" && cd . && \
>   $restore $backupdir/* `echo "./mpfr.info" | sed 's|[^/]*$||'`; \
> fi; \
> rm -rf $backupdir; exit $rc
> /c/_64/comp/mpfr-10613/missing: line 81: makeinfo: command not found
> WARNING: 'makeinfo' is missing on your system.
>  You should only need it if you modified a '.texi' file, or
>  any other file indirectly affecting the aspect of the manual.
>  You might want to install the Texinfo package:
>  <http://www.gnu.org/software/texinfo/>
>  The spurious makeinfo call might also be the consequence of
>  using a buggy 'make' (AIX, DU, IRIX), in which case you might
>  want to install GNU make:
>  <http://www.gnu.org/software/make/>
> make[1]: *** [Makefile:365: mpfr.info] Error 127
> make[1]: Leaving directory 'C:/_64/comp/mpfr-10613/doc'
> make: *** [Makefile:484: all-recursive] Error 1
> ###
>
> Now, I'm not so sure that I really do need makeinfo, but my old msys shell
> seems to have it and I'm therefore guessing it must surely be available for
> msys2.
> At least, if I can install makeinfo, I will surely get past this error.
> However:
>
> #
> sisyphus@Owner-PC311012 MSYS /c/_64/comp/mpfr-10613
> $ pacman -Ss makeinfo
>
> sisyphus@Owner-PC311012 MSYS /c/_64/comp/mpfr-10613
> #
>
> (I guess it's possible that I had built makeinfo from source for that old
> msys shell.)
>
> This same mpfr source builds trivially in the msys shell using gcc-5.3.0
> (posix threads, sjlj) but when I switch to the above 6.1.1 compiler I have
> no end of trouble (both in msys and msys2 shells).
> And the only way I could build gmp-6.1.1 with this gcc-6.1.1 compiler was to
> build in the msys2 shell - though, again gmp-6.1.1 built fine in the msys
> shell with gcc-5.3.0.
>
> Any pointers as to why this gcc-6.1.1 compiler is creating its own unique
> problems would also be gratefully received.
>
> Cheers,
> Rob
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to make __declspec(dllexport) more picky?

[Vincent Torri]

https://msdn.microsoft.com/en-us/library/dabb5z75.aspx

On Fri, Apr 1, 2016 at 8:28 AM, lh_mouse  wrote:

> The attribute `dllexport`, as well as `dllimport`, is a GCC thing. You
> should look up it in GCC's main manual.
> You can find GCC manuals here https://gcc.gnu.org/onlinedocs/. The
> specification of either attribute is so long that I wouldn't paste it here.
> If you think it is a GCC bug you can file a bug report at
> https://gcc.gnu.org/bugzilla/.
>
> --
> Best regards,
> lh_mouse
> 2016-04-01
>
> -
> 发件人：Tony Kelman 
> 发送日期：2016-04-01 14:02
> 收件人：mingw-w64-public
> 抄送：
> 主题：[Mingw-w64-public] How to make __declspec(dllexport) more picky?
>
> Sorry in advance if this is an RTFM question. We test Julia's Windows
> build against mingw-w64 continuously, but only rarely build with MSVC
> or Windows Clang on a more experimental basis. One of the inconsistencies
> that comes up fairly often is that mingw-w64 is more tolerant of headers
> and implementation not having matching linkage export specification with
> __declspec(dllexport). MSVC and Windows Clang require them to match,
> mingw-w64 is more permissive. Since that's been the established behavior
> for a while with mingw-w64 I wouldn't expect the default to change in
> the short term, but does anyone know if there's an optional flag I could
> use to make mismatched linkage specification a warning or error? That
> way we'd catch these issues much faster. Or is this functionality that
> GCC isn't capable of doing?
>
> Thanks in advance,
> Tony
>
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Order of -ladvapi32 versus -lkernel32

[Vincent Torri]

hello

On Fri, Mar 18, 2016 at 2:48 AM, Vitaly Kruglikov
<vkrugli...@numenta.com> wrote:
>
> Carl of mingwpy suggested that I re-post this question here (originally 
> posted on https://groups.google.com/forum/#!topic/mingwpy/kHhGl3mBNfo)
>
>
> My project's CMAKE_CXX_STANDARD_LIBRARIES originally contained by default: 
> "-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid 
> -lcomdlg32 -ladvapi32" (without the quotes).
>
> I used mingwpy (based on mingw-w64) running on Windows Server 2008 32-bit to 
> build my python extension DLL. The apr (apache portable runtime) library 
> that's linked as a static library into my extension DLL makes a call to 
> "CreateProcessAsUserW". When testing, I would get this error: "The procedure 
> entry point CreateProcessAsUserW could not be located in the dynamic link 
> library KERNEL32.dll". I found this error surprising, because 
> CreateProcessAsUserW is in advapi32, and "-ladvapi32" was listed at the end 
> of CMAKE_CXX_STANDARD_LIBRARIES, so it should have been picked up by 
> mingwpy's linker/loader. I was able to fix this failure by moving
> "-ladvapi32" to the beginning so that it was in front of "-lkernel32" like 
> so: "-ladvapi32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 
> -loleaut32 -luuid -lcomdlg32".
>
> However, I don't understand why it was necessary to place -ladvapi32 in front 
> of -lkernel32 to make the CreateProcessAsUserW problem go away. Does someone 
> know why this would be necessary? Is there a better way to avoid this problem?

advapi32.dll depends on kernel32.dll (you can see that with dependency
walker for example), and the order of the -l flags is important : from
right to left : the "less dependent" to the "more dependant". So pass
to the linker "-ladvapi32 -lkernel32" because advapi32.dll depends on
kernel32.dll

Vincent Torri

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] does linker correctly set the creation date of a PE file ?

[Vincent Torri]

Hello

with my little Examine tool, or with the 'sigcheck' tool from
sysinternal, it seems that the TimeDateStamp field of the
IMAGE_FILE_HEADER structure, which is "the date and time the image was
created by the linker" (see
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680313%28v=vs.85%29.aspx
) is not correctly set. It returns 01/01/1970 as date (the local time
vary from file to file)

Can someone confirm that ? If yes, is it possible to fix this ?

thank you

Vincent Torri

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] does linker correctly set the creation date of a PE file ?

[Vincent Torri]

It's not a problem of striping files or not (the debug section is not
involved here). But anyway, i've just did this :

gcc -g -O2 -o pi pi.c

then, I run the sigcheck tool. Here is the output :

$ /sigcheck.exe ./pi.exe

Sigcheck v2.50 - File version and signature viewer
Copyright (C) 2004-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

E:\Documents\MSYS2\home\vtorri\code\pi.exe:
Verified:   Unsigned
Link date:  19:12 01/01/1970
Publisher:  n/a
Company:n/a
Description:n/a
Product:n/a
Prod version:   n/a
File version:   n/a
MachineType:64-bit

When I parse myself the TimeDateStamp field in the IMAGE_FILE_HEADER
structure, i obtain the same value.

My code (the relevant part) in Examine :



{
FILETIME ft;
FILETIME lft;
ULARGE_INTEGER uli;

#define EXM_WINDOWS_TICK 1000
#define EXM_SEC_TO_UNIX_EPOCH 11644473600ULL
uli.QuadPart = ((unsigned long
long)exm_pe_nt_header_get(pe)->FileHeader.TimeDateStamp +
EXM_SEC_TO_UNIX_EPOCH) * EXM_WINDOWS_TICK;
ft.dwLowDateTime = uli.LowPart;
ft.dwHighDateTime = uli.HighPart;
FileTimeToLocalFileTime(, );
if (!FileTimeToSystemTime(, ))
{
st.wHour = 0;
st.wMinute = 0;
st.wDay = 1;
st.wMonth = 1;
st.wYear = 1970;
}
}

printf("%02d:%02d %02d/%02d/%04d\n",
   st.wHour,
   st.wMinute,
   st.wDay,
   st.wMonth,
   st.wYear);

--------

Vincent Torri


On Sun, Feb 7, 2016 at 10:56 AM, Nakai Yuta <nak5...@live.jp> wrote:
> I cannot reproduce that.
> maybe, you strip output binaries?
>
> ________
> From: Vincent Torri <vincent.to...@gmail.com>
> Sent: Sunday, February 7, 2016 17:34
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] does linker correctly set the creation date of a  
>   PE file ?
>
> Hello
>
> with my little Examine tool, or with the 'sigcheck' tool from
> sysinternal, it seems that the TimeDateStamp field of the
> IMAGE_FILE_HEADER structure, which is "the date and time the image was
> created by the linker" (see
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms680313%28v=vs.85%29.aspx
> ) is not correctly set. It returns 01/01/1970 as date (the local time
> vary from file to file)
>
> Can someone confirm that ? If yes, is it possible to fix this ?
>
> thank you
>
> Vincent Torri
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] does linker correctly set the creation date of a PE file ?

[Vincent Torri]

On Sun, Feb 7, 2016 at 6:42 PM, Óscar Fuentes <o...@wanadoo.es> wrote:
> Vincent Torri <vincent.to...@gmail.com>
> writes:
>
>>>> Can someone confirm that ? If yes, is it possible to fix this ?
>>>
>>> For obtaining reproducible binaries I had to pass --no-insert-timestamp
>>> to the linker. That was last December, using the MSYS2's MinGW-w64
>>> toolchain (32 bits).
>>
>> i've just read that this option is not stable
>>
>> also, i don't want to remove timestamps, i want the linker to specify
>> the correct timestamp
>
> My point was that the linker is including the timestamps here, unless I
> explicitly command it to do otherwise.

my point is that the timestamp is incorrect (it is set to 0, which is wrong)

Vincent Torri

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthread and "leak"

[Vincent Torri]

Hey

it's indeed RtlInitializeCriticalSection() which is called. You should
indeed get InitializeCriticalSectionEx() wit GetProcAddress() to get
it

Vincent Torri

On Wed, Dec 30, 2015 at 5:09 PM, Martin Mitáš <m...@morous.org> wrote:
>
> Hello,
>
> after a glimpse into its sources I can see that there is 
> InitializeCriticalSection()
> called in pthread_cond_init().
>
> InitializeCriticalSection() is known to "leak" since Windows Vista: It 
> allocates some
> kind of debug block which is then never released. If it is not desired 
> behavior,
> InitializeCriticalSectionEx(CRITICAL_SECTION_NO_DEBUG_INFO) should be used 
> instead.
>
> However InitializeCriticalSectionEx() is only available on Vista and newer as 
> well,
> so for compatibility with Windows XP, it would have to use soma magic with
> GetProcAddress() to use one or the other.
>
> So if you are using pthread_cond_init() this could explain it.
>
> Martin
>
>
>
> Dne 30. 12. 2015 v 11:58 Vincent Torri napsal(a):
>> Hello
>>
>> With my little mem checker, i detect that winpthread does not free all
>> the resources it allocates. Is it normal ?
>>
>> thank you
>>
>> Vincent Torri
>>
>> --
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] winpthread and "leak"

[Vincent Torri]

Hello

With my little mem checker, i detect that winpthread does not free all
the resources it allocates. Is it normal ?

thank you

Vincent Torri

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] patching IAT and _strdup() and malloc() functions

[Vincent Torri]

On Tue, Dec 15, 2015 at 2:00 PM, Vincent Torri <vincent.to...@gmail.com> wrote:
> On Tue, Dec 15, 2015 at 12:05 PM, Jacek Caban <ja...@codeweavers.com> wrote:
>> Hi Vincent,
>>
>> On 12/15/15 7:20 AM, Vincent Torri wrote:
>>> Hello
>>>
>>> I am still working on Examine, my small valgrind-like memory leak
>>> detector (http://vtorri.github.io/examine/) and I have 2 questions.
>>>
>>> First, I recall that it works by doing DLL injection with
>>> CreateRemoteThread, and API hooking by patching the IAT.
>>>
>>> So Examine is working well, now, but I have 2 questions, about
>>> _strdup() and malloc() :
>>>
>>> 1) If I call malloc() in a program, it is detected by Examine. If I
>>> call _strdup(), malloc is not detected at all, while MSDN says that
>>> _strdup() "calls malloc to allocate storage space" (see
>>> https://msdn.microsoft.com/en-us/library/y471khhc.aspx). Does someone
>>> have an idea why malloc() is  not catched ?
>>
>> Both malloc and _strdup live in the same DLL (like msvcrt.dll or any
>> other msvcr*.dll version), so calls from _strdup to malloc don't use
>> import table, it's a direct call. You could have more luck by hot
>> patching malloc function itself, but I don't think it's the right solution.
>>
>> You may have more luck patching HeapAlloc (or even RtlAllocateHeap)
>> instead. At least in Wine, malloc ends up calling it.
>
> I've already patched HeapAlloc(), but malloc is already patched. I'll
> try to remove malloc() hook.

No luck. I have removed all the hooks except HeapAlloc. If I test
Examine with a program with only 1 malloc(), malloc is not detected.

Vincent Torri

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] patching IAT and _strdup() and malloc() functions

[Vincent Torri]

On Tue, Dec 15, 2015 at 8:54 AM, LRN <lrn1...@gmail.com> wrote:
> On 15.12.2015 9:20, Vincent Torri wrote:
>> Hello
>>
>> I am still working on Examine, my small valgrind-like memory leak
>> detector (http://vtorri.github.io/examine/) and I have 2 questions.
>>
>> First, I recall that it works by doing DLL injection with
>> CreateRemoteThread, and API hooking by patching the IAT.
>>
>> So Examine is working well, now, but I have 2 questions, about
>> _strdup() and malloc() :
>>
>> 1) If I call malloc() in a program, it is detected by Examine. If I
>> call _strdup(), malloc is not detected at all, while MSDN says that
>> _strdup() "calls malloc to allocate storage space" (see
>> https://msdn.microsoft.com/en-us/library/y471khhc.aspx). Does someone
>> have an idea why malloc() is  not catched ?
>>
>> 2) So to fix 1), i've just patched the IAT to detect _strdup() (but
>> i'm not satisfied with this). Now if I call strdup(), _strdup() is not
>> detected. I thought first that strdup() was a macro, but it is
>> actually declared in string.h. Does someone know why strdup() is not
>> catched too ?
>
> One possibility is the strdup builtin that gcc has. Though i'm not sure
> what exactly does it do, aside from checking for argument not being a NULL
> pointer.

I'll check that , thank you

Vincent

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] patching IAT and _strdup() and malloc() functions

[Vincent Torri]

On Tue, Dec 15, 2015 at 12:05 PM, Jacek Caban <ja...@codeweavers.com> wrote:
> Hi Vincent,
>
> On 12/15/15 7:20 AM, Vincent Torri wrote:
>> Hello
>>
>> I am still working on Examine, my small valgrind-like memory leak
>> detector (http://vtorri.github.io/examine/) and I have 2 questions.
>>
>> First, I recall that it works by doing DLL injection with
>> CreateRemoteThread, and API hooking by patching the IAT.
>>
>> So Examine is working well, now, but I have 2 questions, about
>> _strdup() and malloc() :
>>
>> 1) If I call malloc() in a program, it is detected by Examine. If I
>> call _strdup(), malloc is not detected at all, while MSDN says that
>> _strdup() "calls malloc to allocate storage space" (see
>> https://msdn.microsoft.com/en-us/library/y471khhc.aspx). Does someone
>> have an idea why malloc() is  not catched ?
>
> Both malloc and _strdup live in the same DLL (like msvcrt.dll or any
> other msvcr*.dll version), so calls from _strdup to malloc don't use
> import table, it's a direct call. You could have more luck by hot
> patching malloc function itself, but I don't think it's the right solution.
>
> You may have more luck patching HeapAlloc (or even RtlAllocateHeap)
> instead. At least in Wine, malloc ends up calling it.

I've already patched HeapAlloc(), but malloc is already patched. I'll
try to remove malloc() hook.

Vincent

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] patching IAT and _strdup() and malloc() functions

[Vincent Torri]

Hello

I am still working on Examine, my small valgrind-like memory leak
detector (http://vtorri.github.io/examine/) and I have 2 questions.

First, I recall that it works by doing DLL injection with
CreateRemoteThread, and API hooking by patching the IAT.

So Examine is working well, now, but I have 2 questions, about
_strdup() and malloc() :

1) If I call malloc() in a program, it is detected by Examine. If I
call _strdup(), malloc is not detected at all, while MSDN says that
_strdup() "calls malloc to allocate storage space" (see
https://msdn.microsoft.com/en-us/library/y471khhc.aspx). Does someone
have an idea why malloc() is  not catched ?

2) So to fix 1), i've just patched the IAT to detect _strdup() (but
i'm not satisfied with this). Now if I call strdup(), _strdup() is not
detected. I thought first that strdup() was a macro, but it is
actually declared in string.h. Does someone know why strdup() is not
catched too ?

thank you

Vincent Torri

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] WS_EX_NOREDIRECTIONBITMAP is not available

[Vincent Torri]

Hello

I wanted to use WS_EX_NOREDIRECTIONBITMAP on my Win 7. According to
MSDN, there is no Windows version information for that flag. Maybe it
has been introduced in Windows 8.0 or 8.1

cheers

Vincent Torri

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] About the recent sourceforge events

[Vincent Torri]

On Thu, Jun 11, 2015 at 9:54 PM, Adrien Nader adr...@notk.org wrote:

 On github there's already https://github.com/mingw-w64 but I have no
 idea who is behind that.

https://github.com/AndreRH

it seems that he's a Wine guy, according to his website

Vincent

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Fwd: Examine - a small Windows memory leak detector and PE file viewer

[Vincent Torri]

Hello

i have been working on a small application named 'Examine'. Its
features are basically 3 tools:

1) 'memcheck' (same name than valgrind's tool): a memory leak detector
with some memory checks for Windows,

2) 'depends': a PE file dependency viewer (CLI and GUI) ala dependency walker,

3) 'view': a PE file viewer to view the data values of the PE file.

Both 'depends' and 'view' tools can be run on Windows and Linux (and
any UNIX I think as Idon't use anything Linux-specific) but the
'memcheck' tool can only run on Windows.

The source code is hosted on github: https://github.com/vtorri/examine

It is a Work In Progress (tm) so it's not complete and certainly have
some bugs that I am not aware of.

If you want to give it a try, follow the instructions below.


INSTALLATION

1) Windows:

I've tested only with MSYS + win-builds

If gcc is installed in /opt/windows_64:

CFLAGS=-g -O0 ./configure --with-libbfd-prefix=/opt/windows_64

(./autogen.sh instead of ./configure, the first time)

then make  make install

2) Linux:

./configure
make  make install


USAGE

1) 'memcheck' tool

Of course it can not be run on Linux (use valgrind on linux...). The
usage is like valgrind:

examine the_app.exe the_app_arguments

the_app.exe should be compiled with -g -O0 to have a useful backtrace.
I use libbfd to get the backtrace (-On with n 0 adds
-fomit-frame-pointer)

The output mimics the valgrind output.

Currently supported functions: malloc, calloc, realloc, free,
HeapAlloc and HeapFree. More will be added soon

I have provided a test example, named examine_test :

examine /usr/local/examine_test

With that test, the output is the following (mimic also the valgrind
ouptput) : http://codepad.org/uRR1HnYm

2) 'depends' tool

It tries to mimic Dependency Walker

you have 3 possible outputs:

a) text output, with the dependecy tree:

examine -q --tool=depends pe_file

It should work on Windows and linux

b) text output, with the dependency list (like ldd):

examine -q --tool=depends --list pe_file

It should work on Windows and linux

c) GUI output, with a GUI which mimics Dependency Walker

examine -q --tool=depends --gui pe_file

The GUI is not perfect and should actually not be tried right now (it
can be very very slow)

2) 'view' tool

It views the content of  a PE file

examine -q --tool=view pe_file

It should work on Windows and Linux. There is also a GUI but not
really finished yet



Feel free to give remarks, ideas, etc...

thank you

Vincent Torri

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

[Vincent Torri]

hey

imho, you should add a paypal link with a nice icon on the front page,
and not only in the 'donate' page.

Vincent Torri



On Fri, Mar 20, 2015 at 10:51 PM, Adrien Nader adr...@notk.org wrote:
 Hi,

 I've just pushed a redirect from http://mingw-w64.sourceforge.net to
 http://mingw-w64.yaxm.org in order to serve a new website.

 I have been taking care of the website for at least a couple years now.
 Not that I particularly enjoy doing PHP, CSS and Javascript but there
 was a need. However I suck at design and I had very little time
 available, which meant all the changes I could do were minimal.

 Last week I finally bit the bullet and spent half a day assessing
 whether something based on dokuwiki could work and then spent a day
 moving the data from the website to that dokuwiki and tweak its them and
 plugins.
 This was discussed a bit over IRC and the switch has been hurried by the
 release of 4.0: I was feeling miserable each time I had to update
 anything on the website and I really didn't feel like taking one hour
 just to add a section to the existing layout, especially knowing the
 website replacement was going to occur soon.

 The now-old website is still available, only masked through a redirect.
 Please speak up if you are not pleased with the new one.

 One notable change is that the website is not served through
 sourceforge.net anymore. I had started with everything on SF but more
 often than not, the pages would fail to load. Unfortunately this means
 there is a user-visible redirection on a temporary subdomain; this is
 expected to remain for one month at most.

 NB: this does not change anything else; nothing but the website that has
 been visible on http://mingw-w64.sourceforge.net changes.

 The wiki from sourceforge is going to be abandoned. Well. Noone has
 touched wiki2 since it was set up a year ago so it's not a big loss.
 Dokuwiki should be a nicer place for wiki changes (faster, cuter, and
 fully integrated into the website obviously).
 The only minor downside currently is that users cannot register
 themselves to change the website. This is minor since I can do it on
 request and because the set of pages that is currently up will not be
 editable by most people anyway (i.e. main page, downloads). This will
 be fixed.

 On a final note I'd like to thank the author of the initial mingw-w64
 website. As far as I remember he had a company named CodeCamel but
 currently the website is MIA but the domain name has been parked with
 seemingly-innocuous link spam. That website has served mingw-w64 well
 for around 5 years.
 Its replacement did not happen out of discontent but because a lot has
 happened over these 5 years, both the web (mobile, many new viewport
 sizes, saner browsers, ...) and for mingw-w64 (so many more users,
 contributors, activity on all fronts and much more content).
 Working with sourceforge.net SSH access was the painful part as it was
 slow and not having a CSS theme used (and tested) by many other websites
 made the process brittle and time-consuming.

 I wished there had been time to bring the topic on the mailing-list
 before doing the switch but v4.0 timing made that hard and I've also
 taken great care to not lose anything in the process. Any constructive
 criticism is welcome; don't hesitate.

 --
 Adrien Nader

 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Help required about process and dll injection

[Vincent Torri]

Hello

My question is not related to mingw-w64 itself, I know, but i'm
desperatly trying to find help. Kai told me that maybe some people
here could help me.

I'm trying to write some kind of debugger to find leaks in a program
by injecting a DLL in the process I want to debug [1]. I have already
a code that injects a dll in a child process (but not in its
dependencies, and that is the problem). I use the CreateRemoteThread
method. So I do basically :

1) CreateProcess of the process I want to debug, in suspend mode
2) I inject the DLL.

but it is not good because :

a) the state of the process is not in a good shape when it is in suspend mode
b) and at this stage, the dll of the dependencies are not even loaded.
And I need them

so I've read here and there that a (and certainly the correct)
solution is to patch the entry point of the process with an infinite
loop. A rough description is here :
https://opcode0x90.wordpress.com/2011/01/15/injecting-dll-into-process-on-load/

but :

i) there is no detailed code (there are some non-detailed functions
and i'm not good enough to write them :-( )
ii) even if it works it's only for x86 (32 bits) and not x86_64 (the
CONTEXT structure has no Eip member on x86_64. Maybe using the Rip
member ?)

So does someone know where I can find detailed description for i) and
ii) (a piece of code would be the best :-p) ?

thank you

Vincent Torri

[1] https://github.com/vtorri/examine (in very early stage, but
comments and remarks are welcome of course)

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Help required about process and dll injection

[Vincent Torri]

Hey,

thanks for the answer. coments below

On Fri, Nov 14, 2014 at 3:35 PM, lh_mouse lh_mo...@126.com wrote:
 Possible solution:
 0) Load the debugee in suspended mode;
 1) Calculate the address of its entry point (typically mainCRTStartup or 
 WinMainCRTStartup) from its PE header, since its header should now have been 
 loaded into RAM;

I guess that I call CreateFilemapping() like that :

CreateFilemapping(pi.hProcess, NULL, PAGE_READWRITE, 0, 0, NULL);

with pi the PROCESS_INFORMATION structure passed to CreateProcess() ?

 2) Overwrite the byte at that address with 0xCC (a.k.a. int3 instruction on 
 both x86 and x64);
 3) Resume the process and it should hit the breakpoint, after all 
 statically-linked DLLs have been loaded successfully, before any static 
 constructors are invoked;

shouldn't I have to wait a bit so that all the DLL are loaded ? It
might take some time to load them, no ? That's what is done in the
link that i have posted

 4) Restore that byte;
 5) Inject your DLL;
 6) Resume the process as normal.

 I haven't tested it, but it should work. Some debuggers (specifically, 
 OllyDbg) have an option to decide where the first breakpoint should be set, 
 at system breakpoint(before any DLLs are loaded), PE entry(the point 
 mentioned above), or WinMain.

Vincent Torri

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Help required about process and dll injection

[Vincent Torri]

On Fri, Nov 14, 2014 at 4:49 PM, Vincent Torri vincent.to...@gmail.com wrote:
 Hey,

 thanks for the answer. coments below

 On Fri, Nov 14, 2014 at 3:35 PM, lh_mouse lh_mo...@126.com wrote:
 Possible solution:
 0) Load the debugee in suspended mode;
 1) Calculate the address of its entry point (typically mainCRTStartup or 
 WinMainCRTStartup) from its PE header, since its header should now have been 
 loaded into RAM;

 I guess that I call CreateFilemapping() like that :

 CreateFilemapping(pi.hProcess, NULL, PAGE_READWRITE, 0, 0, NULL);

 with pi the PROCESS_INFORMATION structure passed to CreateProcess() ?

what about that part ?

Vincent Torri

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Help required about process and dll injection

[Vincent Torri]

On Fri, Nov 14, 2014 at 5:01 PM, lh_mouse lh_mo...@126.com wrote:
 Hmm have a test yourself. :
 Since you are writing a debugger you can wait for the breakpoint. The system 
 generates an exception with code EXCEPTION_BREAKPOINT and your debugger 
 should handle it. Otherwise your program would be terminated.

i'm currently writing something more like valgrind, actually. Not a
program like gdb. So i'm not sure i can call what i write a debugger
:)

Vincent Torri

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] about localtime_r()

[Vincent Torri]

hey

in the mingw-w64 version i have (installed by win-builds 1.4),
localtime_r() is guarded by _POSIX (see time.h), so any program that
uses localtime_r has to pass -D_POSIX.

jony mentioned on IRC that, as guards were removed for strtok_r(),
maybe it should also be the case for localtime_r.

also note that http://linux.die.net/man/3/localtime_r gives another
set of guards.

what do you think ?

Vincent Torri

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public