64 bit Cygwin target and _WIN64

[Corinna Vinschen]

Hi guys,


Here's a problem I need feedback for.

I'm currently working on making Mingw64 headers 64 bit Cygwin aware.
One, IMHO pretty tough problem is the definition of _WIN64.

A Cygwin-targeting gcc does not define WIN32, _WIN32, __WIN32 and
__WIN32__ by default. The original reason is that we had (and probably
still have) a lot of projects, which test for _WIN32 one way or the
other to decide if a POSIX or a Windows function should be called,
the latter typically to be avoided.

Now comes the time for _WIN64. _WIN64 is used a *LOT* inside of the
Mingw64 headers to distinguish type definitions which differ from the
32 bit version, or to declare functions which only exist on 64 bit
machines, stuff like that.

There are a couple of ways to help us along with this problem:

1. Replace all

#ifdef _WIN64

with

#if defined (_WIN64) || defined (__CYGWIN64__)

2. In a core Mingw64 header:

#if defined (_WIN64) || defined (__CYGWIN64__)
#define _WINX64
#endif

Then replace all `#ifdef _WIN64' with `#ifdef _WINX64'.

3. In a core Mingw64 header:

#ifdef __CYGWIN64__
#define _WIN64
#endif

4. Let the Cygwin 64 bit gcc define _WIN64 by default.

I think all of these variations have up- and downsides. I just can't
decide which is the best way to handle the problem. So, let me tell
you what I think and then chime in, please:

1. Most straightforward, but uglifies the headers extremly. All
later added ifdefs have to be checked so that they don't exclude
__CYGWIN64__.

2. Better than 1 as far as readability and ugliness are concerned.
But also requires constant vigilance so that _WIN64 doesn't creep in
again.

3. If _WIN64 is defined in a Mingw64 header, then all projects which
don't include windows headers are off the hook. configure is off
the hook as well. Only projects which use `#ifdef _WIN64' within
the code may be in trouble.

4. What can I say? This is exaclty the situation we'd like to avoid.

Concerning point 3 and 4, the question on the Mingw64 IRC channel was
this: Is that really a serious problem? Projects testing for windows
targets usually test for _WIN32, not for _WIN64, since _WIN32 is always
defined, on 32 and on 64 bit Windows.

Consequentially, projects for which testing for _WIN64 is an important
design choice are windows-centric anyway and probably no serious target
for a Cygwin port.

Given that, I am inclined to simplify the problem by choosing point 3;
just define _WIN64 if a Windows header is included and then keep it
at that.

But I'm really not sure. So I ask for your opinion.


Thanks in advance,
Corinna

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen
Now comes the time for _WIN64. _WIN64 is used a *LOT* inside of the
Mingw64 headers to distinguish type definitions which differ from the
32 bit version, or to declare functions which only exist on 64 bit
machines, stuff like that.
1. Replace all
#ifdef _WIN64
with
#if defined (_WIN64) || defined (__CYGWIN64__)

Can't that just be #ifdef __x86_64__?

Also, I would suggest avoiding __CYGWIN64__: IIRC we used to use
__CYGWIN32__ until M$ trademarked "Win32", leaving us with just
__CYGWIN__; what happens if they decide to trademark "Win64"? Instead,
this should be __CYGWIN__ && __x86_64__, just like other platforms have
separate defines for OS and architecture.

Post by Corinna Vinschen
4. Let the Cygwin 64 bit gcc define _WIN64 by default.

No way, for the same reason we don't define _WIN32.


Yaakov

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
Now comes the time for _WIN64. _WIN64 is used a *LOT* inside of the
Mingw64 headers to distinguish type definitions which differ from the
32 bit version, or to declare functions which only exist on 64 bit
machines, stuff like that.
1. Replace all
#ifdef _WIN64
with
#if defined (_WIN64) || defined (__CYGWIN64__)

Can't that just be #ifdef __x86_64__?

Nope. Think Itanium.

Post by Yaakov (Cygwin/X)
Also, I would suggest avoiding __CYGWIN64__: IIRC we used to use
__CYGWIN32__ until M$ trademarked "Win32", leaving us with just
__CYGWIN__; what happens if they decide to trademark "Win64"?

I don't see the issue here. Cygwin is also a trademark and 32 bitg
gcc still defines __CYGWIN32__. We just discouraged the use of it.
I think the __CYGWIN__ and __CYGWIN32__ defines on 32 bit and the
__CYGWIN__ and __CYGWIN64__ defines on a 64 bit system make sense
and are an easy way to distinguish the platforms.

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
4. Let the Cygwin 64 bit gcc define _WIN64 by default.

No way, for the same reason we don't define _WIN32.

But what about 2 and 3?


Corinna

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
1. Replace all
#ifdef _WIN64
with
#if defined (_WIN64) || defined (__CYGWIN64__)

Can't that just be #ifdef __x86_64__?

Nope. Think Itanium.

Oh, right, I forgot about Itanium. Hmm, I wonder why? :-)

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
Also, I would suggest avoiding __CYGWIN64__: IIRC we used to use
__CYGWIN32__ until M$ trademarked "Win32", leaving us with just
__CYGWIN__; what happens if they decide to trademark "Win64"?

I don't see the issue here. Cygwin is also a trademark and 32 bitg
gcc still defines __CYGWIN32__. We just discouraged the use of it.
I think the __CYGWIN__ and __CYGWIN32__ defines on 32 bit and the
__CYGWIN__ and __CYGWIN64__ defines on a 64 bit system make sense
and are an easy way to distinguish the platforms.

BTW, __CYGWIN32__ will still be defined on x64, right?

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
4. Let the Cygwin 64 bit gcc define _WIN64 by default.

No way, for the same reason we don't define _WIN32.

But what about 2 and 3?

AFAICS 3 is the status quo; iff you #include <windows.h>, you get _WIN32
(and have to deal with the consequences), otherwise not. That's worked
pretty well so far, so let's stick with it.


Yaakov

[Christopher Faylor]

Post by Yaakov (Cygwin/X)
BTW, __CYGWIN32__ will still be defined on x64, right?

Maybe it's time to retire that one.

cgf

[Corinna Vinschen]

Post by Christopher Faylor

Post by Yaakov (Cygwin/X)
BTW, __CYGWIN32__ will still be defined on x64, right?

Maybe it's time to retire that one.

I would prefer it as well, but I am a bit concerned that there are still
projects using it. I just googled for __CYGWIN32__ and the third hit
was this one:

http://boinc.berkeley.edu/svn/trunk/boinc/lib/boinc_win.h

I don't know if that's representative, but still...


Corinna

[Christopher Faylor]

Post by Corinna Vinschen

Post by Christopher Faylor

Post by Yaakov (Cygwin/X)
BTW, __CYGWIN32__ will still be defined on x64, right?

Maybe it's time to retire that one.

I would prefer it as well, but I am a bit concerned that there are still
projects using it. I just googled for __CYGWIN32__ and the third hit
http://boinc.berkeley.edu/svn/trunk/boinc/lib/boinc_win.h
I don't know if that's representative, but still...

I know that there is stuff that probably uses it but keeping it around
for a 64-bit Windows compiler doesn't make any sense.

[Corinna Vinschen]

Post by Christopher Faylor

Post by Corinna Vinschen

Post by Christopher Faylor

Post by Yaakov (Cygwin/X)
BTW, __CYGWIN32__ will still be defined on x64, right?

Maybe it's time to retire that one.

I would prefer it as well, but I am a bit concerned that there are still
projects using it. I just googled for __CYGWIN32__ and the third hit
http://boinc.berkeley.edu/svn/trunk/boinc/lib/boinc_win.h
I don't know if that's representative, but still...

I know that there is stuff that probably uses it but keeping it around
for a 64-bit Windows compiler doesn't make any sense.

Well, _WIN32 is defined on 64 bit windows as well. If you build an
application which uses __CYGWIN32__ to decide whether it's built for
Cygwin, it will be broken when built under 64 bit Cygwin.

The question is if we deliberately don't define it to enforce using
__CYGWIN__. I have no strong opinion, but I'm wondering if it's
worth the hassle. It doesn't cost us anything but might help other
projects along which worked fine the last couple of years.


Corinna

[Larry Hall (Cygwin Developers)]

Post by Corinna Vinschen

Post by Christopher Faylor

Post by Corinna Vinschen

Post by Christopher Faylor

Post by Yaakov (Cygwin/X)
BTW, __CYGWIN32__ will still be defined on x64, right?

Maybe it's time to retire that one.

I would prefer it as well, but I am a bit concerned that there are still
projects using it. I just googled for __CYGWIN32__ and the third hit
http://boinc.berkeley.edu/svn/trunk/boinc/lib/boinc_win.h
I don't know if that's representative, but still...

I know that there is stuff that probably uses it but keeping it around
for a 64-bit Windows compiler doesn't make any sense.

Well, _WIN32 is defined on 64 bit windows as well. If you build an
application which uses __CYGWIN32__ to decide whether it's built for
Cygwin, it will be broken when built under 64 bit Cygwin.
The question is if we deliberately don't define it to enforce using
__CYGWIN__. I have no strong opinion, but I'm wondering if it's
worth the hassle. It doesn't cost us anything but might help other
projects along which worked fine the last couple of years.

I'd vote for removing __CYGWIN32__ unless there's a need to keep it.
Having multiple defines available that effectively mean the same thing
makes it confusing to anyone picking this stuff up, either in old code
or working on a new port. Better to have a minimal set of defines so
it's clear what they are there for. But that's just my opinion.

[Earnie Boyd]

Post by Larry Hall (Cygwin Developers)
I'd vote for removing __CYGWIN32__ unless there's a need to keep it.
Having multiple defines available that effectively mean the same thing
makes it confusing to anyone picking this stuff up, either in old code
or working on a new port. Better to have a minimal set of defines so
it's clear what they are there for. But that's just my opinion.

Yes, please remove it and don't create __CYGWIN64__.

[Christopher Faylor]

Post by Larry Hall (Cygwin Developers)

Post by Corinna Vinschen

Post by Christopher Faylor

Post by Corinna Vinschen

Post by Christopher Faylor

Post by Yaakov (Cygwin/X)
BTW, __CYGWIN32__ will still be defined on x64, right?

Maybe it's time to retire that one.

I would prefer it as well, but I am a bit concerned that there are still
projects using it. I just googled for __CYGWIN32__ and the third hit
http://boinc.berkeley.edu/svn/trunk/boinc/lib/boinc_win.h
I don't know if that's representative, but still...

I know that there is stuff that probably uses it but keeping it around
for a 64-bit Windows compiler doesn't make any sense.

Well, _WIN32 is defined on 64 bit windows as well. If you build an
application which uses __CYGWIN32__ to decide whether it's built for
Cygwin, it will be broken when built under 64 bit Cygwin.
The question is if we deliberately don't define it to enforce using
__CYGWIN__. I have no strong opinion, but I'm wondering if it's
worth the hassle. It doesn't cost us anything but might help other
projects along which worked fine the last couple of years.

I'd vote for removing __CYGWIN32__ unless there's a need to keep it.
Having multiple defines available that effectively mean the same thing
makes it confusing to anyone picking this stuff up, either in old code
or working on a new port. Better to have a minimal set of defines so
it's clear what they are there for. But that's just my opinion.

Yeah. It's a legacy define. At some point you have to get rid of the
legacy cruft. If you don't then it isn't really legacy at all.

cgf

[Corinna Vinschen]

Post by Christopher Faylor

Post by Larry Hall (Cygwin Developers)

Post by Corinna Vinschen

Post by Christopher Faylor

Post by Corinna Vinschen

Post by Christopher Faylor

Post by Yaakov (Cygwin/X)
BTW, __CYGWIN32__ will still be defined on x64, right?

Maybe it's time to retire that one.

I would prefer it as well, but I am a bit concerned that there are still
projects using it. I just googled for __CYGWIN32__ and the third hit
http://boinc.berkeley.edu/svn/trunk/boinc/lib/boinc_win.h
I don't know if that's representative, but still...

I know that there is stuff that probably uses it but keeping it around
for a 64-bit Windows compiler doesn't make any sense.

Well, _WIN32 is defined on 64 bit windows as well. If you build an
application which uses __CYGWIN32__ to decide whether it's built for
Cygwin, it will be broken when built under 64 bit Cygwin.
The question is if we deliberately don't define it to enforce using
__CYGWIN__. I have no strong opinion, but I'm wondering if it's
worth the hassle. It doesn't cost us anything but might help other
projects along which worked fine the last couple of years.

I'd vote for removing __CYGWIN32__ unless there's a need to keep it.
Having multiple defines available that effectively mean the same thing
makes it confusing to anyone picking this stuff up, either in old code
or working on a new port. Better to have a minimal set of defines so
it's clear what they are there for. But that's just my opinion.

Yeah. It's a legacy define. At some point you have to get rid of the
legacy cruft. If you don't then it isn't really legacy at all.

Ok. Consequentially we won't invent __CYGWIN64__ either.


Corinna

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
1. Replace all
#ifdef _WIN64
with
#if defined (_WIN64) || defined (__CYGWIN64__)

Can't that just be #ifdef __x86_64__?

Nope. Think Itanium.

Oh, right, I forgot about Itanium. Hmm, I wonder why? :-)

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)
Also, I would suggest avoiding __CYGWIN64__: IIRC we used to use
__CYGWIN32__ until M$ trademarked "Win32", leaving us with just
__CYGWIN__; what happens if they decide to trademark "Win64"?

I don't see the issue here. Cygwin is also a trademark and 32 bitg
gcc still defines __CYGWIN32__. We just discouraged the use of it.
I think the __CYGWIN__ and __CYGWIN32__ defines on 32 bit and the
__CYGWIN__ and __CYGWIN64__ defines on a 64 bit system make sense
and are an easy way to distinguish the platforms.

BTW, __CYGWIN32__ will still be defined on x64, right?

I have a preliminary toolchain (just tools, nothing else) created by a
collegue of mine. We discussed this briefly and right now it only
defines __CYGWIN__ and __CYGWIN64__.

Since we deprecated __CYGWIN32__ long ago, it didn't seem prudent to
define it for the 64 bit target, but this early in the game I'm open for
discussion.

There *may* still be projects out in the wild which test for
__CYGWIN32__, so it could be a good idea to define __CYGWIN32__ on 64
bit as well...

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
4. Let the Cygwin 64 bit gcc define _WIN64 by default.

No way, for the same reason we don't define _WIN32.

But what about 2 and 3?

AFAICS 3 is the status quo; iff you #include <windows.h>, you get
_WIN32 (and have to deal with the consequences), otherwise not.

No, that's not correct. _WIN32, together with its friends WIN32,
__WIN32, and __WIN32__, are defined by the compiler. A Mingw32 or
Mingw64 compiler defines trhem by default, a Cygwin compiler only
defines them if you use the -mwin32 option.

A 64 bit targeting Mingw64 compiler also defines it's WIN64 cousins.
A 64 bit Cygwin compiler may or may not add the -mwin32 option and,
if so, will do the same.

Post by Yaakov (Cygwin/X)
That's worked pretty well so far, so let's stick with it.

Corinna

[Earnie Boyd]

Post by Corinna Vinschen
Hi guys,
Here's a problem I need feedback for.
I'm currently working on making Mingw64 headers 64 bit Cygwin aware.
One, IMHO pretty tough problem is the definition of _WIN64.
A Cygwin-targeting gcc does not define WIN32, _WIN32, __WIN32 and
__WIN32__ by default. The original reason is that we had (and probably
still have) a lot of projects, which test for _WIN32 one way or the
other to decide if a POSIX or a Windows function should be called,
the latter typically to be avoided.
Now comes the time for _WIN64. _WIN64 is used a *LOT* inside of the
Mingw64 headers to distinguish type definitions which differ from the
32 bit version, or to declare functions which only exist on 64 bit
machines, stuff like that.

Is it needed always or just during compilation of Cygwin? (but read on
before answering)

Post by Corinna Vinschen
1. Replace all
#ifdef _WIN64
with
#if defined (_WIN64) || defined (__CYGWIN64__)

Ugly, what happens now with _WIN32 headers?

Post by Corinna Vinschen
#if defined (_WIN64) || defined (__CYGWIN64__)
#define _WINX64
#endif
Then replace all `#ifdef _WIN64' with `#ifdef _WINX64'.

I don't see this happening; too easy to break.

Post by Corinna Vinschen
#ifdef __CYGWIN64__
#define _WIN64
#endif

If you only need _WIN64 defined during the Cygwin build then put this
in a Cygwin local definition else put it in the mingw64 headers.

Post by Corinna Vinschen
4. Let the Cygwin 64 bit gcc define _WIN64 by default.
I think all of these variations have up- and downsides. I just can't
decide which is the best way to handle the problem. So, let me tell
1. Most straightforward, but uglifies the headers extremly. All
later added ifdefs have to be checked so that they don't exclude
__CYGWIN64__.
2. Better than 1 as far as readability and ugliness are concerned.
But also requires constant vigilance so that _WIN64 doesn't creep in
again.
3. If _WIN64 is defined in a Mingw64 header, then all projects which
don't include windows headers are off the hook. configure is off
the hook as well. Only projects which use `#ifdef _WIN64' within
the code may be in trouble.
4. What can I say? This is exaclty the situation we'd like to avoid.
Concerning point 3 and 4, the question on the Mingw64 IRC channel was
this: Is that really a serious problem? Projects testing for windows
targets usually test for _WIN32, not for _WIN64, since _WIN32 is always
defined, on 32 and on 64 bit Windows.

I would argue that point, I could see some project use _WIN64 for
specific abilities of the API. Yes both are defined by default.

Post by Corinna Vinschen
Consequentially, projects for which testing for _WIN64 is an important
design choice are windows-centric anyway and probably no serious target
for a Cygwin port.

Maybe not always though. As _WIN64 specifics begin to creep into
those now supporting _WIN32.

Post by Corinna Vinschen
Given that, I am inclined to simplify the problem by choosing point 3;
just define _WIN64 if a Windows header is included and then keep it
at that.

I like this. If it is always needed then do it in the mingw64 headers
otherwise do it locally.

[Corinna Vinschen]

This post might be inappropriate. Click to display it.

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Earnie Boyd

Post by Corinna Vinschen
Consequentially, projects for which testing for _WIN64 is an important
design choice are windows-centric anyway and probably no serious target
for a Cygwin port.

Maybe not always though. As _WIN64 specifics begin to creep into
those now supporting _WIN32.

Thing is, an application which calls two different Windows functions
depending on _WIN64 needs the _WIN64 define anyway when building its
code. So, if we define _WIN64 from within the Windows headers, we
might even help the project along.
On the other hand, an application which provides Windows and POSIX
#ifdef _WIN32
#ifdef _WIN64
call foo_win64
#else
call foo_win32
#endif
#else
call foo_posix
#endif
And since Cygwin doesn't provide _WIN32, we will be default still not
call the Windows functions, even on 64 bit with _WIN64 defined if a
WIndows header is included.

...and apart from that, the inclusion of the Windows header itself
will be bound to the definition of _WIN32 as well, so there's only
a low chance that _WIN64 is defined accidentally.


Corinna

[Christopher Faylor]

Post by Corinna Vinschen

Post by Earnie Boyd

Post by Corinna Vinschen
Now comes the time for _WIN64. _WIN64 is used a *LOT* inside of the
Mingw64 headers to distinguish type definitions which differ from the
32 bit version, or to declare functions which only exist on 64 bit
machines, stuff like that.

Is it needed always or just during compilation of Cygwin? (but read on
before answering)

The _WIN64 define is needed for building Cygwin as well as for building
Cygwin applications accessing the Windows API.

Why would we worry about hypothetical nonexistent people who are trying
to build a 64-bit Cygwin app with 64-bit Windows headers? Couldn't we
just tell them "Define _WIN64_ somewhere if you want to do this" ? And
then we could use -D_WIN64_ on the Cygwin command line.

I think making this somewhat hard might actually help clarify that, when
building an app, Cygwin should not be conflated with Windows.

cgf

[Corinna Vinschen]

Post by Christopher Faylor

Post by Corinna Vinschen

Post by Earnie Boyd

Post by Corinna Vinschen
Now comes the time for _WIN64. _WIN64 is used a *LOT* inside of the
Mingw64 headers to distinguish type definitions which differ from the
32 bit version, or to declare functions which only exist on 64 bit
machines, stuff like that.

Is it needed always or just during compilation of Cygwin? (but read on
before answering)

The _WIN64 define is needed for building Cygwin as well as for building
Cygwin applications accessing the Windows API.

Why would we worry about hypothetical nonexistent people who are trying
to build a 64-bit Cygwin app with 64-bit Windows headers? Couldn't we

It's hypothetical at this point, but it's not hypothetical as soon as
the first Cygwin/Windows mixed application is supposed to be ported to
64 bit Cygwin. The problem with _WIN64 is not that it will be used
inside of an application, but that it is used inside the Windows headers,
for instance to create different structure layouts depending on running
on 32 or 64 bit Windows. Typical example, just one of many:

#if defined(_WIN64)
typedef struct DECLSPEC_ALIGN(16) _SLIST_HEADER {
ULONGLONG Alignment;
ULONGLONG Region;
} SLIST_HEADER;

typedef struct _SLIST_HEADER *PSLIST_HEADER;
#else
typedef union _SLIST_HEADER {
ULONGLONG Alignment;
__C89_NAMELESS struct {
SLIST_ENTRY Next;
WORD Depth;
WORD Sequence;
} DUMMYSTRUCTNAME;
} SLIST_HEADER,*PSLIST_HEADER;
#endif

Post by Christopher Faylor
just tell them "Define _WIN64_ somewhere if you want to do this" ? And
then we could use -D_WIN64_ on the Cygwin command line.
I think making this somewhat hard might actually help clarify that, when
building an app, Cygwin should not be conflated with Windows.

Why do you want to make life harder for Andy or Jon or Yaakov? Mintty
or the X server are valid applications which we're happy to exist while
they having a perfectly good reason to include Windows headers.

The big difference between _WIN64 and _WIN32 is that _WIN32 is just
some abused compiler-defined variable, while _WIN64 is needed inside
the Mingw64 headers to distinguish different definitions based on the
platform.

So, while we don't need the _WIN64 as a default setting in the compiler,
it should be taken care of inside the Windows headers to not treat Cygwin
applications wrong just because they are built for the 64 bit target.


Corinna

[Christopher Faylor]

Post by Corinna Vinschen

Post by Christopher Faylor

Post by Corinna Vinschen

Post by Earnie Boyd

Post by Corinna Vinschen
Now comes the time for _WIN64. _WIN64 is used a *LOT* inside of the
Mingw64 headers to distinguish type definitions which differ from the
32 bit version, or to declare functions which only exist on 64 bit
machines, stuff like that.

Is it needed always or just during compilation of Cygwin? (but read on
before answering)

The _WIN64 define is needed for building Cygwin as well as for building
Cygwin applications accessing the Windows API.

Why would we worry about hypothetical nonexistent people who are trying
to build a 64-bit Cygwin app with 64-bit Windows headers? Couldn't we

It's hypothetical at this point, but it's not hypothetical as soon as
the first Cygwin/Windows mixed application is supposed to be ported to
64 bit Cygwin. The problem with _WIN64 is not that it will be used
inside of an application, but that it is used inside the Windows headers,
for instance to create different structure layouts depending on running
#if defined(_WIN64)
typedef struct DECLSPEC_ALIGN(16) _SLIST_HEADER {
ULONGLONG Alignment;
ULONGLONG Region;
} SLIST_HEADER;
typedef struct _SLIST_HEADER *PSLIST_HEADER;
#else
typedef union _SLIST_HEADER {
ULONGLONG Alignment;
__C89_NAMELESS struct {
SLIST_ENTRY Next;
WORD Depth;
WORD Sequence;
} DUMMYSTRUCTNAME;
} SLIST_HEADER,*PSLIST_HEADER;
#endif

Right. Didn't you already explain this? This is certainly what I would
expect the headers to look like.

Post by Corinna Vinschen

Post by Christopher Faylor
just tell them "Define _WIN64_ somewhere if you want to do this" ? And
then we could use -D_WIN64_ on the Cygwin command line.
I think making this somewhat hard might actually help clarify that, when
building an app, Cygwin should not be conflated with Windows.

Why do you want to make life harder for Andy or Jon or Yaakov? Mintty
or the X server are valid applications which we're happy to exist while
they having a perfectly good reason to include Windows headers.

This is hardly difficult. They will have two different versions to
compile. They can define _WIN64 if they want the 64-bit variant. This
will be the least of anyone's worries if they are porting code from
32-bit to 64-bit Windows.

I really don't see why the Mingw64 project should have to accommodate
Cygwin. Maybe if we put a #define _WIN64 in a Cygwin header, I'd feel
slightly better about this but I don't see why another project should
have to change to accommodate us. Should they also have defines for
Wine and ReactOS? That doesn't seem like the right way to go.

cgf

[Corinna Vinschen]

Post by Christopher Faylor
I really don't see why the Mingw64 project should have to accommodate
Cygwin. Maybe if we put a #define _WIN64 in a Cygwin header, I'd feel
slightly better about this but I don't see why another project should
have to change to accommodate us. Should they also have defines for
Wine and ReactOS? That doesn't seem like the right way to go.

They are happy to accomodate us. Some of the problems we have are
shared with the wine project, so the advantages are partially mutual.
Mingw64 has already a header called _cygwin.h which is indirectly
included if a Cygwin project includes any Windows header. It's no
problem to add

#ifdef __CYGWIN64__
#define _WIN64
#endif

to this file.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen
Mingw64 has already a header called _cygwin.h which is indirectly
included if a Cygwin project includes any Windows header. It's no
problem to add
#ifdef __CYGWIN64__

or, FWIW,

#ifdef __x86_64__

Post by Corinna Vinschen
#define _WIN64
#endif

Corinna

[Christopher Faylor]

Post by Corinna Vinschen

Post by Christopher Faylor
I really don't see why the Mingw64 project should have to accommodate
Cygwin. Maybe if we put a #define _WIN64 in a Cygwin header, I'd feel
slightly better about this but I don't see why another project should
have to change to accommodate us. Should they also have defines for
Wine and ReactOS? That doesn't seem like the right way to go.

They are happy to accomodate us. Some of the problems we have are
shared with the wine project, so the advantages are partially mutual.
Mingw64 has already a header called _cygwin.h which is indirectly
included if a Cygwin project includes any Windows header. It's no
problem to add
#ifdef __CYGWIN64__
#define _WIN64
#endif
to this file.

Oh boy. Another project like newlib where we have to get permission
to make Cygwin-specific changes.

cgf

[Christopher Faylor]

Post by Corinna Vinschen

Post by Christopher Faylor
I really don't see why the Mingw64 project should have to accommodate
Cygwin. Maybe if we put a #define _WIN64 in a Cygwin header, I'd feel
slightly better about this but I don't see why another project should
have to change to accommodate us. Should they also have defines for
Wine and ReactOS? That doesn't seem like the right way to go.

They are happy to accomodate us. Some of the problems we have are
shared with the wine project, so the advantages are partially mutual.
Mingw64 has already a header called _cygwin.h which is indirectly
included if a Cygwin project includes any Windows header. It's no
problem to add
#ifdef __CYGWIN64__
#define _WIN64
#endif
to this file.

Oh boy. Another project like newlib where we have to get permission to
make Cygwin-specific changes.

Sorry. My sarcasm there did not explain my actual concern.

I think that the more we can isolate Cygwin decisions to the
winsup/cygwin and directly related directories, the better off we are.

We don't have many problems adding stuff to newlib until someone wants a
few tweaks for RTEMS or something similar. And, sure, they are not a
big deal. They take time, though, and force us to worry about concerns
that are not directly Cygwin related.

We probably wouldn't have many issues getting code into MinGW* either.
But, there is a whole other set of developers whose buyin is required
for changes. They are probably very reasonable people but, if we can
help it, I'd rather opt for not having to gain consensus from people who
don't have Cygwin as their priority.

[Christopher Faylor]

Post by Christopher Faylor

Post by Corinna Vinschen

Post by Christopher Faylor
I really don't see why the Mingw64 project should have to accommodate
Cygwin. Maybe if we put a #define _WIN64 in a Cygwin header, I'd feel
slightly better about this but I don't see why another project should
have to change to accommodate us. Should they also have defines for
Wine and ReactOS? That doesn't seem like the right way to go.

They are happy to accomodate us. Some of the problems we have are
shared with the wine project, so the advantages are partially mutual.
Mingw64 has already a header called _cygwin.h which is indirectly
included if a Cygwin project includes any Windows header. It's no
problem to add
#ifdef __CYGWIN64__
#define _WIN64
#endif
to this file.

Oh boy. Another project like newlib where we have to get permission to
make Cygwin-specific changes.

Sorry. My sarcasm there did not explain my actual concern.
I think that the more we can isolate Cygwin decisions to the
winsup/cygwin and directly related directories, the better off we are.
We don't have many problems adding stuff to newlib until someone wants a
few tweaks for RTEMS or something similar. And, sure, they are not a
big deal. They take time, though, and force us to worry about concerns
that are not directly Cygwin related.
We probably wouldn't have many issues getting code into MinGW* either.
But, there is a whole other set of developers whose buyin is required
for changes. They are probably very reasonable people but, if we can
help it, I'd rather opt for not having to gain consensus from people who
don't have Cygwin as their priority.

And, all of that said, if everyone thinks modifying a mingw64 header file
is the way to handle this or doesn't care enough to argue any other way,
I'm fine with whatever is decided.

cgf

[Peter Rosin]

Post by Corinna Vinschen
On the other hand, an application which provides Windows and POSIX
#ifdef _WIN32
#ifdef _WIN64
call foo_win64
#else
call foo_win32
#endif
#else
call foo_posix
#endif

Some would perhaps write that as:

#if defiend _WIN64
call foo_win64
#elif defined _WIN32
call foo_win32
#else
call foo_posix
#endif

Cheers,
Peter

[Corinna Vinschen]

Post by Peter Rosin

Post by Corinna Vinschen
On the other hand, an application which provides Windows and POSIX
#ifdef _WIN32
#ifdef _WIN64
call foo_win64
#else
call foo_win32
#endif
#else
call foo_posix
#endif

#if defiend _WIN64
call foo_win64
#elif defined _WIN32
call foo_win32
#else
call foo_posix
#endif

Yes, that's the possible danger. But still, the chance that the Windows
headers are included guarded by an #ifdef _WIN32 are extremly high. If
so, the _WIN64 will not be defined when compiling the code, considering
solution 3. The chance to meet such an application seems to be pretty
low.

I had a more or less sleepless night thinking about this stuff, but the
more I think about it, the more I think that just #defining _WIN64 in
the Windows headers if called from a x86_64-targeting Cygwin compiler is
the right thing to do. On one hand a 64 bit Cygwin application will
get the correct Windows definitions, on the other hand the impact on the
Mingw64 headers is minimal.


Corinna

[Pedro Alves]

Post by Corinna Vinschen
I had a more or less sleepless night thinking about this stuff, but the
more I think about it, the more I think that just #defining _WIN64 in
the Windows headers if called from a x86_64-targeting Cygwin compiler is
the right thing to do. On one hand a 64 bit Cygwin application will
get the correct Windows definitions, on the other hand the impact on the
Mingw64 headers is minimal.

You might even get zero impact on the Mingw64 headers, if you find a central
Windows header that all other headers include first (ISTR there used to be one,
windef.h, mingw.h or something like that on the w32api side), and put a Cygwin-specific
one with the same name earlier on the Cygwin system include search paths
that just does:

#define _WIN64
#include_next <foo_central_header_whatever_its_called_maybe_windef.h>

This header would be controlled and shipped by Cygwin.

[Corinna Vinschen]

Post by Pedro Alves

Post by Corinna Vinschen
I had a more or less sleepless night thinking about this stuff, but the
more I think about it, the more I think that just #defining _WIN64 in
the Windows headers if called from a x86_64-targeting Cygwin compiler is
the right thing to do. On one hand a 64 bit Cygwin application will
get the correct Windows definitions, on the other hand the impact on the
Mingw64 headers is minimal.

You might even get zero impact on the Mingw64 headers, if you find a central
Windows header that all other headers include first (ISTR there used to be one,
windef.h, mingw.h or something like that on the w32api side), and put a Cygwin-specific
one with the same name earlier on the Cygwin system include search paths
#define _WIN64
#include_next <foo_central_header_whatever_its_called_maybe_windef.h>
This header would be controlled and shipped by Cygwin.

Right, but since we already have our own header in Mingw64 which is
included practically always, that's not much of a problem. I can
pretty much define what I want in that file.


Corinna

[Charles Wilson]

Post by Corinna Vinschen
#ifdef __CYGWIN64__
#define _WIN64
#endif

This is basically what happens with _WIN32 and WIN32, right now, and the
existing w32api headers (see windef.h). (And, when you talk of "Mingw64
headers" with regards to how a cygwin compiler would use them, you
/must/ be talking about that portion of mingw64 that is "w32api-like"
and not the parts that are "mingw-runtime-like" correct?)

So, I really don't see that this is any different than the current
situation: if you #include any w32api headers, you need to be careful in
your own code about #ifdef _WIN32, and guard it with &&
!defined(__CYGWIN__) unless you want those windows-isms -- and as good
practice and for clarity, amplify with || defined(__CYGWIN__) if you
really want those windows-isms, just so some well-meaning chap doesn't
come along and "fix" it for you later.

I *wish* there was a better way, but at least this is no worse than
status quo, wrt the current w32api headers.

--
Chuck

[Corinna Vinschen]

Post by Charles Wilson

Post by Corinna Vinschen
#ifdef __CYGWIN64__
#define _WIN64
#endif

This is basically what happens with _WIN32 and WIN32, right now, and
the existing w32api headers (see windef.h). (And, when you talk of

Oh boy! Would you believe that I didn't know that? Since WIN32 and
friends are defined by the (mingw or cygwin with -mwin32) compiler, I
never searched the w32api headers for that definition.

That does not happen in the Mingw64 headers, they don't... erm...

[...time passes...]

...they do, kind of. _WIN32 is only defined by the compiler, but
WIN32 (no underscore) in ole2.h. Interesting.

Post by Charles Wilson
"Mingw64 headers" with regards to how a cygwin compiler would use
them, you /must/ be talking about that portion of mingw64 that is
"w32api-like" and not the parts that are "mingw-runtime-like"
correct?)

Of course. We're exclusively taking about the PSDK portion of
the Mingw64 headers and libs, plus a handful of CRT headers which
are required to make the PSDK headers work.

Post by Charles Wilson
So, I really don't see that this is any different than the current
situation: if you #include any w32api headers, you need to be
careful in your own code about #ifdef _WIN32, and guard it with &&
!defined(__CYGWIN__) unless you want those windows-isms -- and as
good practice and for clarity, amplify with || defined(__CYGWIN__)
if you really want those windows-isms, just so some well-meaning
chap doesn't come along and "fix" it for you later.
I *wish* there was a better way, but at least this is no worse than
status quo, wrt the current w32api headers.

Thanks, that was an important point. And a lesson to look *first* in
the headers before claiming something about what they do and not do.


Corinna