ds,
/Pete
On 2025.03.04 03:37, LIU Hao wrote:
在 2025-03-04 01:14, Pete Batard via Mingw-w64-public 写道:
Considering that the current approach to fighting DLL side-loading
vulnerabilities for MinGW generated executables is to manually run
them through something like procmon, to see if they attempt to
Hi,
By default, the gcc generated PE binaries do not appear to have
directory entry #11, a.k.a 'Load Configuration', whereas MSVC generated
ones do:
$ objdump -x mingw/rufus.exe | grep "Load Configuration"
Entry a Load Configuration Directory
$ objdump -x vs2022/ruf
Further update to mention that this does appear to be a known ld bug
that was reported 12 years ago:
https://sourceware.org/bugzilla/show_bug.cgi?id=14339
I have therefore asked for the priority of this bug to be raised.
Regards,
/Pete
On 2024.07.16 17:45, Pete Batard wrote:
Thanks again
wrote:
On Thu, 11 Jul 2024, Pete Batard wrote:
Thanks for investigating this, Jeremy.
I guess if people on this list think it boils down to a binutils bug, I can
take it to the binutils mailing list. I will however wait about a day before
doing so, in case anybody else wants to chime in.
I&#x
wrote:
I was looking into delayload stuff a while back, and was pretty
disappointed with how it works in binutils. I suspect some sort of bug in
binutils here. Here are some random thoughts, none of which actually
help.
On Wed, 10 Jul 2024, Pete Batard via Mingw-w64-public wrote:
Hi
Hi,
# Description
This whole issue is better illustrated (and replicated) with the sample
code provided at https://github.com/pbatard/delayload and is the result
of a longstanding issue that I've been battling with when trying to use
DLL delay loading with MinGW in Rufus, per
https://github.
On 2011.09.21 07:51, Ozkan Sezer wrote:
> Hmm, do the following fix your case?
>
> Kai?
>
> --- _timeval.h~ 2010-05-26 20:21:09.0 +0300
> +++ _timeval.h2011-09-21 09:48:42.0 +0300
> @@ -16,7 +16,7 @@ struct timeval
> #define timerisset(tvp) ((tvp)->tv_sec
On 2010.09.11 13:46, Kai Tietz wrote:
> 2010/9/11 Ozkan Sezer:
>> On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
>>> On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
You need the @8 _and_ the leading underscore for x86
So you need adjusting your Makefile and libusb0_drv.def
>>>
For those interested, I recently blogged about how one can get a working
multilib MinGW-w64 on Linux, which includes how to work around the
"skipping incompatible" errors [1].
I'm pretty sure there's a much better way than what I did (for one
thing, I didn't use --with-sysroot), and it's likely
On 2010.08.19 00:37, NightStrike wrote:
> Do you have a good testsuite for your project?
I wouldn't say so.
The aim of the project is to provide generic user level access with any
USB device, so that's very far reaching, and while we attempt to test
with as many devices as we can, this testing
Thanks for the replies.
On 2010.08.18 22:17, Dmitrijs Ledkovs wrote:
> I'm not entirely sure that it works for ada, fortran, boehm/java.
>
> I presume it is far more safe for C, since multilib support within gcc
> starts with that.
Yeah. Forgot to mention that our project was C only.
> Please al
Hi,
We are currently using a multilib MinGW-w64 to generate 32 and 64 bit
binary snapshots for the libusb 1.0 Windows backend. This includes
static libraries as well as DLLs, with the latter being built with the
aim of being fully interchangeable with MSVC/WDK ones (which we can also
build in
On 2010.08.17 12:55, Kai Tietz wrote:
> Pete,
>
> could you provide us a list of the Interlock* API, which has stdcall
> calling convention by our findings? Please just list names of those
> functions and don't copy from VC's header-set. So we can adjust things
> for win32 more easily without viola
On 2010.08.17 12:29, Ozkan Sezer wrote:
>> Thank you Pete for noticing that. We are aware of this and we solved
>> things here a bit different, but
>
> AFAIR, they aren't specifically marked as WINAPI in ms headers
> (well, maybe their mistake?..)
Well, the thing is that the MSDN documentation has
For 32 bit, the current MinGW-w64 winbase has:
LONG InterlockedIncrement(LONG volatile *lpAddend);
LONG InterlockedDecrement(LONG volatile *lpAddend);
LONG InterlockedExchange(LONG volatile *Target,LONG Value);
However, MinGW32 uses:
LONG WINAPI InterlockedDecrement(LONG volatile *);
15 matches
Mail list logo
