Hello Luis,
ERROR_SYMLINK_NOT_SUPPORTED is missing. We will add it soon.
Thanks for reporting,
Kai
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape
Hello,
When using -D_WIN32_WINNT=0x0600 to use Vista+ definitions, it seems
ERROR_SYMLINK_NOT_SUPPORTED (1464L) appears to be missing.
I checked winerror.h in trunk and compared with MSDN list of errors:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681385(v=vs.85).aspx
Or I'm missi
2012/7/16 Kai Tietz:
> Well,
>
> I am fine by this patch, but I would love to get additional a testcase
> added for it.
>
> So patch is ok with a testcase.
Log in attachment.
--
Regards,
niXman
___
Dual-target(32 & 64 bit) MinGW compilers for 32
2012/7/17 Corinna Vinschen :
> Hi,
>
> as proposed on IRC, the below patch replaces all usage of unsigned long
> in the ddk subdir with ULONG. Ok to apply?
>
>
> Thanks,
> Corinna
Patch is ok.
Thanks,
Kai
--
Live Securi
Hi,
as proposed on IRC, the below patch replaces all usage of unsigned long
in the ddk subdir with ULONG. Ok to apply?
Thanks,
Corinna
* include/ddrawint.h (MAKE_HRESULT): Define in terms of ULONG
instead of unsigned long.
* include/ddk/scsiwmi.h (struct _GUID): Define
2012/7/17 Corinna Vinschen :
> Hi,
>
> per the subject, patch below. Ok to apply?
>
>
> Thanks,
> Corinna
Yes, patch is ok.
Thanks,
Kai
--
Live Security Virtual Conference
Exclusive live event will cover all the ways to
Hi,
per the subject, patch below. Ok to apply?
Thanks,
Corinna
* _mingw_mac.h (__MSABI_LONG): Define for LP64 systems as well.
Index: _mingw_mac.h
===
--- _mingw_mac.h(revision 5225)
+++ _mingw_mac.h(wor
On Jul 16 17:25, Corinna Vinschen wrote:
> On Jul 16 15:56, Kai Tietz wrote:
> > Well,
> >
> > I would like to have here one define for long, which is then later on
> > used consistently to replace use of 'long' type. I don't see much
> > advantage in adding here a signed and a unsigned variant t
I'm resending this. I have a work-around, which involves putting PRId64 in a
global variable, but that doesn't seem right. Is there a bug in the #include
files?
Simson
When I #include with mingw64-g++ the PRId64 value is no longer
interpreted correctly.
Here is the test program:
#define _
On 07/16/12 15:33, Jacek Caban wrote:
> On 07/16/12 14:26, Ozkan Sezer wrote:
>> On Mon, Jul 16, 2012 at 3:03 PM, JonY wrote:
>>> On 7/16/2012 19:10, JonY wrote:
On 7/16/2012 18:46, Ozkan Sezer wrote:
> On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote:
>> On 7/16/2012 17:19, Jacek Caban wr
10 matches
Mail list logo