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-w
Dne 22. 2. 2020 v 19:22 Dan Raymond napsal(a):
> I don't think there is any doubt that something needs to be done to fix this.
>
+1
Although I hope that any solution would still allow apps to explicly choose
the MSVCRTL.DLL if the app knows what it does. It may be written with that
runtime in
Hello,
the subject says it all. The patch is in the attachment.
BR,
Martin Mitas
diff --git a/mingw-w64-headers/include/winhttp.h
b/mingw-w64-headers/include/winhttp.h
index 1577c76c..1713f5b5 100644
--- a/mingw-w64-headers/include/winhttp.h
+++ b/mingw-w64-headers/include/winhttp.h
@@ -45,7 +4
I recommend uploading those files to virustotal.com. It scans
with plethora of antivirus engines and it can give you quite
good idea whether it is really a false positive or not.
AFAIK there is also good data exchange between virustotal.com
and many AV vendors so this is often an indirect way how
Dne 17. 7. 2017 v 15:50 LRN napsal(a):
> On 7/17/2017 1:21 PM, Martin Mitáš wrote:
>> The aim is to have
>> the DLL without the typical symbol suffix decorations (@num).
>>
>> Is there better way, how to achieve the goal without manual
>> maintaining of two .def fi
Hello.
In the mCtrl project [1], we build a DLL. The aim is to have
the DLL without the typical symbol suffix decorations (@num).
This is to allow easy use of those symbols with LoadLibrary().
With mingw-w64, when linking against such DLL, the import lib
still needs to provide the decorations as
I guess that you might have a virus on your
> local system, or the heuristic of your defender has wrong positive.
> As the Windows defender guys in doubt.
>
> Regards,
> Kai
>
>
> 2017-01-27 2:09 GMT+01:00 Martin Mitáš :
>>
>> Hi,
>>
>> FYI, Windows De
Hi,
FYI, Windows Defender on Windows 10 with current definitions
just started to (mis)detect some .exe files inside mingw-builds
packages.
I tried both rev0 and rev1 downloaded from here:
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-bui
Dne 14. 4. 2016 v 5:02 Dongsheng Song napsal(a):
> Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
>
> --enable-threads=win32-vista
> --enable-threads=win32-win7 // Windows 7 and Windows Server 2008 R2
> --enable-threads=win32-win8 // Windows 8 and Windows Server 2012
Yes, if the _whole_ tool-chain is really multi-arch enabled.
I already saw some gcc-based toolchain builds targeting Windows
where actually only some of the tools were.
And, unfortunately, the command line parameters are inconsistent
among the tools.
I use:
* "-m32" or "-m64" for gcc (which is
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,
I
Ping.
Don't be confused by similarity with the recent patch fixing
ID2D1RenderTarget_CreateLayer(). This is another one. :-)
Unfortunately I spotted this issue after the previous one
has been posted.
Best regards,
Martin
Dne 2. 9. 2015 v 8:24 Martin Mitáš napsal(a):
>
Dne 2. 9. 2015 v 11:15 Adrien Nader napsal(a):
> Hi,
>
> On Wed, Sep 02, 2015, Martin Mitáš wrote:
>>
>> Hello,
>>
>> A few days ago, I tried to register on the http://mingw-w64.org in order
>> to edit link to mCtrl project as it has been migrated from [ol
Hello,
A few days ago, I tried to register on the http://mingw-w64.org in order
to edit link to mCtrl project as it has been migrated from [old] to [new].
(mCtrl is listed on the homepage as one of projects using mingw-w64.)
Unfortunately, it seems the registration process is broken. It doesn't
Macro ID2D1RenderTarget_CreateCompatibleRenderTarget() defined #if
D2D_USE_C_DEFINITIONS
in has wrong number of parameters. Ditto for all interfaces inherited
from
ID2D1RenderTarget.
Path is attached. BTW, are inline or attached patches preferred on this list?
Regards,
Martin
mingw-w64-hea
ead up with recent changes to
> dx-headers from Wine. So ignore my recent thread to you about this.
>
> 2015-08-30 16:51 GMT+02:00 Martin Mitáš :
>>
>> Macro ID2D1RenderTarget_CreateLayer() defined #if D2D_USE_C_DEFINITIONS
>> in has wrong number of parameters. Ditto for
Macro ID2D1RenderTarget_CreateLayer() defined #if D2D_USE_C_DEFINITIONS
in has wrong number of parameters. Ditto for all interfaces
inherited from ID2D1RenderTarget.
The attached patch fixes the issue. Please review and apply.
Regards,
Martin
mingw-w64-headers/include/d2d1.h | 8
1 f
sal(a):
> There are files in [1], if you browse into two more directories deeper.
>
>
> 2015-08-23 9:02 GMT+03:00 Martin Mitáš <mailto:m...@morous.org>>:
>
> Hello list,
>
> what's the status of the mingw-builds? I've noticed that [1] and [2]
Hello list,
what's the status of the mingw-builds? I've noticed that [1] and [2] are just
empty
directories tries, there are actually no files offered for downloading.
[1]
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.1.0/
[2]
Umm, it is much more complicated then that. There are many mingw-w64 repos
on github:
(1) mirror/mingw-w64, which is likely a mirror repo on sf.net [1],
(2) as of now, 7 forks of the above [2] (AndreRH's repo is one of these),
(3) mingw-w64/mingw-w64 [3], where 1st "mingw-w64" stands for an organ
AFAIK, ld.gold is designed to output only ELF [1] binaries (and the
specialization is what makes it superior to GNU ld when outputting ELF),
while Windows use PE [2] binaries.
So you cannot.
[1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
[2] https://en.wikipedia.org/wiki/Por
Dne 1. 4. 2015 v 10:13 Mattias Engdegård napsal(a):
> 1 apr 2015 kl. 05.35 skrev Dongsheng Song :
>
>> In my testing, getenv() is very fast.
>>
>> *) unset PRINTF_EXPONENT_DIGITS
>>
>> preheat 1 times, then perform 100 times (use 4.6 seconds)
>> getenv cost: 4.6 us
>>
>> *) set P
Hi,
Dne 2. 2. 2015 v 23:15 Martell Malone napsal(a):
> Previously dx11 and dxgi1.2 GUID's were missing from libuuid.
yes, mingw-w64's libuuid.a is very incomplete. Reminds me this:
https://sourceforge.net/p/mingw-w64/bugs/437/
And this:
https://sourceforge.net/p/mingw-w64/pat
ibute callee_pop_aggregate_return might be helpful here. And of
> course it is required on Linux-side of world.
>
> Regards,
> Kai
>
> 2014-12-23 14:39 GMT+01:00 Martin Mitáš :
>>
>> A comment in the pointed wine patch explains the situation quite well:
>> MS
mail/wine-patches/2014-September/134351.html
>
> Unless stdcall is handled differently for mingw target, we need to fix
> it in mingw as well. Kai may know more about this.
>
> Jacek
>
> On 12/23/14 11:55, Martin Mitáš wrote:
>> "Fixed" the DemoApp.cpp b
"Fixed" the DemoApp.cpp by rewriting the line 216 as follows:
// D2D1_SIZE_F rtSize = m_pRenderTarget->GetSize();
D2D1_SIZE_F rtSize = { 640, 480 };
Seems that calling ID2D1RenderTarget::GetSize() is broken when
called from gcc-compiled object.
This particular method is a bit unco
Dne 19. 12. 2014 v 10:20 Jack Andrews napsal(a):
> Thank you for mingw-w64.
>
> I am writing a DLL extension in C (not C++) and I came across a problem when
> I write test.c as:
>
> $cat test.c
> #include
>
> compiling the above causes an error.
>
(shortened)
>
> In the first error, the p
I know this is feature in at least one quite wide-spread antivirus.
It implements something called "file reputation service" (in a cloud) and
it simply sees any (executable) file which it does not know as potentially
dangerous.
The logic is that if it sees the file more often and for some tim
Hi list,
with mingw-w64, I'm used to build DLLs with gcc linker option -mdll.
I am currently playing with CMake as I consider to leave manually
maintained Makefiles behind me. It seems CMake prefers -shared over
-mdll. I cannot find any docs how the two options differ. So, which one
is the ri
Hi all,
I've been resolving some strange issues with resources ([1]). Although I
did not succeed so far, I've spent some time in hex editor and reading
objdump -s output (not much fun). My analyzes has exhibited some
differences in how windres and Microsoft's rc.exe layout the .rsrc section.
Hello,
On 11.11.2013 22:22, Kai Tietz wrote:
Hello Mity,
2013/11/11 :
Hi.
I'm using the Coverity scan [1] for static source analyzes for mCtrl
project [2] on a regular basis before each release. I've recently got some
false positives resulting from each usage of the macro InlineIsEqualGUID
>
> P.S.
> 32-bit:
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.1/threads-posix/sjlj/i686-4.8.1-release-posix-sjlj-rev1.7z
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/ming
>
> The difference between using abort() and using a debug break is that
> debug break, if it goes unhandled, won't print the usual "requrested to
> terminate blahblahblah" stuff, and the exception code that WER shows
> will change from 0x4015 to 0x8003.
That would mean that when not under
On 22.7.2013 23:24, niXman wrote:
>> Broken on Win2000 the same way as 4.8.1rev2.
> Please provide the full link to the build you have tested.
http://kent.dl.sourceforge.net/project/mingwbuilds/host-windows/testing/4.8.2/64-bit/threads-win32/sjlj/x64-4.8.2-prerelease-20130717-rev200927-win32-sj
On 22.7.2013 21:56, niXman wrote:
> 2013/7/22 Martin Mitáš
>
>> So here is result of the test:
>>
>> The binaries built with rev0 and rev1 do work on Windows 2000, but the
>> latest rev2 does not, i.e. the regression is something relatively recent.
>
> Please
On 22.7.2013 13:23, m...@morous.org wrote:
>
>
>> 2013/7/22 Jacek Caban:
>>
>>> BTW, it should be GCC version independent, it's a matter of
>>> mingw-w64-crt.
>> I know that. But, in order to determine the mingw-w64-crt revision, I
>> need to know the revision of the build, but TS haven't choose
On 10.7.2013 8:58, Koehne Kai wrote:
>
> While the question about what current users are using is already hard to
> answer, there's IMO a bigger one: What _potential_ users are there that
> aren't already using mingw-w64 :) I started looking into mingw-w64 maybe a
> year ago, only to find out
> > * Many commands (e.g. ls, basename, ...) start with writing the
> > following error message to stderr:
> >0 [main] basename 3784 stdio_init: couldn't make stderr
> > distinct from stdout
> >
> > It is funny because "ls 2>/dev/null" suppresses it so it seems the
> >
Hi Alexey,
I have just tried the 64-bit package on Win 7. I unpacked it it into
C:\msys as a replacement of my old MSYS package (not sure where it came
from). It could be an old MSYS package from the mingw project). I am
using console2 [1], which is set to use the following command as my shel
Dne 26.12.2012 22:01, Ruben Van Boxem napsal(a):
>
> > Is it just for some transitional phase, or the new way from now forever
> > (or until you decide to add yet another DLL depenencies)?
>
> Perhaps I might have forgotten to mention this is an *experimental*
> build. It allows you to use libstdc
>
> Every C++ and some C applications will implicitly depend on the
> libwinpthread dll. Don't worry, it won't eat your computer. One more
> DLL won't kill you.
Is it just for some transitional phase, or the new way from now forever
(or until you decide to add yet another DLL depenencies)?
My
Dne 11.8.2012 19:06, Kai Tietz napsal(a):
> No,
>
> please ignore this advice from Earnie. It is just partial true and
> also misleading. Indeed the decoration of symbols with an '@' is
> either caused by the stdcall-convention, or by the fastcall.
> Nevertheless there is a way to have in export
Dne 11.8.2012 12:26, Ruben Van Boxem napsal(a):
> Would you mind conjuring up a small test case (dll .c file, main.c
> file and compile options)? dllexport/dllimport of normal functions
> should work (dllexport of C++ classes is WIP). I *seem* to remember
> using a Clang-built GSL DLL once befo
> Clang for now uses "gcc"/"g++" for linking, and uses its runtime
> libraries libgcc and libstdc++. The way I set this up is to extract
> the gcc-dw2 and clang-3.1 packages into the same directory. Then
> everything (C and C++ headers, linker) will be found. binutils etc.
> are still used, an
> You might have also noticed I rearranged the "release" part of thee
> "rubenvb" section of the Personal Builds, going in against my previous
> promise. At the time of this writing, there are the following directories:
> gcc-4.5-release
> gcc-4.6-release
> gcc-4.7-release
> gcc-4.7-experimental
Dne 10.8.2012 15:50, Ruben Van Boxem napsal(a):
2012/8/10 mailto:m...@morous.org>>
Hi Ruben,
thanks for the work.
Just one point annoys me a bit: The Windows packages targeting
win32 and
win64 respectively differ in prefixes of binutils, e.g.:
mingw32/bin/windres.exe
It works correctly, because sizeof(int) == 4 and 1250
is too big for 32 bits. If you take the least significant four bytes
of that value, you get (what a surprise) exactly 445948416.
The three vars are expanded from short to int and multiplicated
(still into an int), then the result is e
I use the following:
#include
#ifdef __MINGW32__
#if defined __MINGW64_VERSION_MAJOR && defined __MINGW64_VERSION_MINOR
// mingw-w64 (either 32 or 64bit)
#else
// mingw
#endif
#else
// other toolchain
#endif
The #include is required as on mingw-w64 the headers
If you need to use Unix-like shell inside of the makefile (e.g. sed, rm
-rf etc.),
download and install MSYS:
https://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/
The MSYS package contains the appropriate make.
If using cmd.exe
Hi.
Perhaps this could help you:
http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx
Maybe your apps use the alternate search path, use SetDllDirectory, specify
the DLL in its manifest or some other similar stuff? Also check the app you
don't know anything about does not e.g. inst
Hi all,
please note there is a project using mingw-w64 as its primary
development platform: mCtrl.
It's a library of Windows user interface controls. It's still relatively
young but (as I hope)
promising :-)
Maybe some folks here could find it useful. See
http://mctrl.sourceforge.net for more
51 matches
Mail list logo
