On 8/24/2013 09:30, Kai Tietz wrote:
> 2013/8/24 JonY:
>> Hi,
>>
>> Patch OK?
>>
>> Index: include/winuser.h
>> ===
>> --- include/winuser.h (revision 6067)
>> +++ include/winuser.h (working copy)
>> @@ -1750,6 +1750,9 @@
>> #defi
On 8/24/2013 09:28, Kai Tietz wrote:
>> Looks like a conflict, the definitions need to be merged. Kai OK to
>> merge them?
>
> Hmm, yes, merging seems to be ok. Nevertheless the real issue here is
> that THREAD_INFORMATION_CLASS is a typedef of THREADINFOCLASS in
> winternl.h. This conflicts wit
2013/8/24 JonY :
> Hi,
>
> Patch OK?
>
> Index: include/winuser.h
> ===
> --- include/winuser.h (revision 6067)
> +++ include/winuser.h (working copy)
> @@ -1750,6 +1750,9 @@
> #define MOD_CONTROL 0x0002
> #define MOD_SHIFT 0x000
2013/8/24 JonY :
> On 8/24/2013 05:40, niXman wrote:
>> Hi guys!
>>
>> Right now I am building gcc-trunk(with mingw-w64 rev. 6132). As host
>> compiler I used MinGW based on gcc-4.8.1 with mingw-w64 rev. 6132,
>> too.
>>
>> I get the following error:
>> libtool: compile: i686-w64-mingw32-gcc -DHAV
On 8/24/2013 05:40, niXman wrote:
> Hi guys!
>
> Right now I am building gcc-trunk(with mingw-w64 rev. 6132). As host
> compiler I used MinGW based on gcc-4.8.1 with mingw-w64 rev. 6132,
> too.
>
> I get the following error:
> libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
> -I../../
Hi,
Patch OK?
Index: include/winuser.h
===
--- include/winuser.h (revision 6067)
+++ include/winuser.h (working copy)
@@ -1750,6 +1750,9 @@
#define MOD_CONTROL 0x0002
#define MOD_SHIFT 0x0004
#define MOD_WIN 0x0008
+#if (_WIN3
Hi guys!
Right now I am building gcc-trunk(with mingw-w64 rev. 6132). As host
compiler I used MinGW based on gcc-4.8.1 with mingw-w64 rev. 6132,
too.
I get the following error:
libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I../../src/winpthreads -I../../src/winpthreads/include
-DIN
2013/8/23 Jim Michaels
> what is the size of a segment on IA32e using 64-bit flat model (that is
> what's used?)? I have been trying to read up on this, but getting nowhere
> by reading the docs.
> is it the same 64K limitation we've always had with 8086?
>
>
> I am asking because I have about 1