Why is __unix__ defined, and not __WINDOWS__ ?

Why is __unix__ defined, and not __WINDOWS__ ?

[Agner Fog]

I have noticed that the gcc and clang compilers have defined the 
preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 
when compiling a windows executable.

Why is this?

A C/C++ program will check for these macros if it wants to know which 
operating system you are compiling for, and this will give the wrong result.




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Houder]

On Sun, 12 May 2019 20:22:36, Agner Fog  wrote:
> I have noticed that the gcc and clang compilers have defined the 
> preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 
> when compiling a windows executable.
> 
> Why is this?
> 
> A C/C++ program will check for these macros if it wants to know which 
> operating system you are compiling for, and this will give the wrong result.

????? (or: I dont quite follow your drift)

Henri

64-@@ x86_64-w64-mingw32-gcc -dM -E - < /dev/null | grep -i win
#define _WIN32 1
#define _WIN64 1
#define __WINT_MAX__ 0xffff
#define __WINT_MIN__ 0
#define __WIN32 1
#define __WIN64 1
#define __WINNT 1
#define __WINNT__ 1
#define __WIN32__ 1
#define __SIZEOF_WINT_T__ 2
#define WIN32 1
#define WIN64 1
#define __WINT_TYPE__ short unsigned int
#define __WINT_WIDTH__ 16
#define WINNT 1
#define __WIN64__ 1
64-@@ x86_64-w64-mingw32-g++ -dM -E -x c++ - < /dev/null | grep -i win
#define _WIN32 1
#define _WIN64 1
#define __WINT_MAX__ 0xffff
#define __WINT_MIN__ 0
#define __WIN32 1
#define __WIN64 1
#define __WINNT 1
#define __WINNT__ 1
#define __WIN32__ 1
#define __SIZEOF_WINT_T__ 2
#define WIN32 1
#define WIN64 1
#define __WINT_TYPE__ short unsigned int
#define __WINT_WIDTH__ 16
#define WINNT 1
#define __WIN64__ 1

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Hans-Bernhard Bröker]

Am 12.05.2019 um 20:22 schrieb Agner Fog:

> I have noticed that the gcc and clang compilers have defined the
> preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64
> when compiling a windows executable.
> 
> Why is this?

Because it's correct that way.  Cygwin runs on Windows, but it _is_ not
Windows.

> A C/C++ program will check for these macros if it wants to know which
> operating system you are compiling for, and this will give the wrong
> result.

No.  It gives the correct result.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Lee]

On 5/12/19, Hans-Bernhard Bröker wrote:
> Am 12.05.2019 um 20:22 schrieb Agner Fog:
>
>> I have noticed that the gcc and clang compilers have defined the
>> preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64
>> when compiling a windows executable.
>>
>> Why is this?
>
> Because it's correct that way.  Cygwin runs on Windows, but it _is_ not
> Windows.

Or you can use a cross-compiler to create a 'native' windows
executable that doesn't require any of the cygwin dlls.

$ echo | gcc -dM -E -xc - | grep '#define _WIN32 '

$ echo | i686-w64-mingw32-gcc -dM -E -xc - | grep '#define _WIN32 '
#define _WIN32 1

Lee

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Mike Gran via cygwin]

On Sun, May 12, 2019 at 08:22:36PM +0200, Agner Fog wrote:
> I have noticed that the gcc and clang compilers have defined the
> preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 when
> compiling a windows executable.
> 
> Why is this?

As I understand it, when using the cygwin compiler to compile for the
cygwin target, these defines are intentionally not defined, because
Cygwin is supposed to look and feel like a Posix platform, not a
windows one.

The various MinGW compilers do define these constants because the target
is native windows.

I think these days the canonical defines are (somebody correct me if
I'm wrong)

  __CYGWIN__ for Cygwin

  _WIN32 as 1 on MinGW when the compilation target is Windows 32-bit
  ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.

  _WIN64 as 1 on MinGW when the compilation target is Windows 64-bit
  ARM or x64. Otherwise, undefined

I am not a maintainer.

-
Mike Gran
 

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Houder]

On Sun, 12 May 2019 13:33:30, Mike Gran via cygwin"  wrote:
[snip]

> I think these days the canonical defines are (somebody correct me if
> I'm wrong)
> 
>   __CYGWIN__ for Cygwin
> 
>   _WIN32 as 1 on MinGW when the compilation target is Windows 32-bit
>   ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.
> 
>   _WIN64 as 1 on MinGW when the compilation target is Windows 64-bit
>   ARM or x64. Otherwise, undefined

https://sourceforge.net/p/predef/wiki/Home/

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Houder]

On Sun, 12 May 2019 20:22:36, Agner Fog  wrote:
> I have noticed that the gcc and clang compilers have defined the 
> preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 
> when compiling a windows executable.
> 
> Why is this?
> 
> A C/C++ program will check for these macros if it wants to know which 
> operating system you are compiling for, and this will give the wrong result.

Hans-Bernhard Bröker is correct ...

But if you were thinking of a "mixed" executable (be careful), then
the _WIN* mnemonics will be defined by gcc/g++.

(see the /include/w32api/{_mingw,_cygwin}.h headers)

Henri

64-@@ printf '#include <windows.h>' | gcc -dM -E - | grep -i win64
#define PROCESSOR_ARCHITECTURE_IA32_ON_WIN64 10
#define _WIN64
#define __RPC_WIN64__
64-@@ printf '#include <windows.h>' | g++ -dM -E -x c++ - | grep -i win64
#define PROCESSOR_ARCHITECTURE_IA32_ON_WIN64 10
#define _WIN64
#define __RPC_WIN64__

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Houder]

On Sun, 12 May 2019 23:59:55, Houder  wrote:
[snip]

> But if you were thinking of a "mixed" executable (be careful), then
> the _WIN* mnemonics will be defined by gcc/g++.
                                      using gcc/g++
--


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Agner Fog]

But the compiler generates a Windows executable following most of the 
Windows ABI (object file format, calling convention, etc.)


On 12/05/2019 21.53, Hans-Bernhard Bröker wrote:
> Am 12.05.2019 um 20:22 schrieb Agner Fog:
>
>> I have noticed that the gcc and clang compilers have defined the
>> preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64
>> when compiling a windows executable.
>>
>> Why is this?
> Because it's correct that way.  Cygwin runs on Windows, but it _is_ not
> Windows.
>
>> A C/C++ program will check for these macros if it wants to know which
>> operating system you are compiling for, and this will give the wrong
>> result.
> No.  It gives the correct result.
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Brian Inglis]

On 2019-05-12 14:54, Houder wrote:
> On Sun, 12 May 2019 13:33:30, Mike Gran via cygwin"  wrote:

>> I think these days the canonical defines are (somebody correct me if
>> I'm wrong)
>>   __CYGWIN__ for Cygwin
>>   _WIN32 as 1 on MinGW when the compilation target is Windows 32-bit
>>   ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.
>>   _WIN64 as 1 on MinGW when the compilation target is Windows 64-bit
>>   ARM or x64. Otherwise, undefined

> https://sourceforge.net/p/predef/wiki/Home/

That information is 15 years out of date, a lot of the platforms are dead or
obsolete, and compilers are gone or changed a lot. There is no attempt at
discrimination across clang or gcc platforms, and no mention of Cygwin or Mingw
platforms, newlib or musl libraries, nor mention of other feature test macros:
better do "man feature_test_macros" for currently useful information.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Brian Inglis]

On 2019-05-12 22:12, Agner Fog wrote:
> On 12/05/2019 21.53, Hans-Bernhard Bröker wrote:
>> Am 12.05.2019 um 20:22 schrieb Agner Fog:
>>> I have noticed that the gcc and clang compilers have defined the
>>> preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64
>>> when compiling a windows executable.
>>> Why is this?
>> Because it's correct that way.  Cygwin runs on Windows, but it _is_ not
>> Windows.
>>> A C/C++ program will check for these macros if it wants to know which
>>> operating system you are compiling for, and this will give the wrong
>>> result.
>> No.  It gives the correct result.> But the compiler generates a Windows executable following most of the
> Windows ABI (object file format, calling convention, etc.)
Not quite I believe Cygwin 64 bit programs follow the Unix 64 bit LP64 C
programming memory model and the System V AMD64 ABI *NOT* the Windows 64 bit
ILP64 C programming memory model and Microsoft x64 calling convention; see:
	http://www.unix.org/version2/whatsnew/lp64_wp.html
	https://en.wikipedia.org/wiki/X86_calling_conventions
- the interface has to be managed by the Cygwin1 dll.

On 32 bit the Unix and Windows C programming memory models are both ILP32 I
believe, but Cygwin does not support the Pascal left to right argument calling
convention and callee pop, and probably handles registers differently.

The Cygwin host, build, target platform triplets are
{x86_64,i686}-{pc-cygwin,w64-mingw32} - the OS is Cygwin or Mingw, neither Unix
nor Windows.

If a Cygwin build defines Windows macros, few GNU, BSD, or other Unix packages
will build correctly, and no definitions expected by Windows programs or from MS
compilers are available, so no Windows packages will build correctly.

The Cygwin C library libc is newlib not glibc so not a lot of GNU nor all Posix
interfaces are available.

Mingw includes sufficient compatible Windows definitions to allow Windows
interfaces to be built and run natively for interoperability.

As far as I know, all gcc compilers target gas DEC/AT&T assembler pseudo-ops and
instruction formats not MS or Intel pseudo-ops and/or instruction formats.

The full Windows definitions are proprietary and are only available if a MS
compiler is installed.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Why is __unix__ defined, and not __WINDOWS__ ?

[Soegtrop, Michael]

Dear Agner,

> But the compiler generates a Windows executable following most of the
> Windows ABI (object file format, calling convention, etc.)

Still cygwin is intentionally very different from Windows, e.g. on Cygwin you use / as path separator, on Windows you use \ as path separator. Cygwin console executables produce \n line endings, MinGW produce \r\n line endings. Cygwin executables go through path translation (C:\ is /cygdrive/c/) ... Many C programs will consult __WINDOWS__ to find out what the path separator should be and this would go wrong if cygwin gcc would define __WINDOWS__. I would see Cygwin as a lightweight Posix virtual environment on Windows. If you run gcc on the Linux Subsystem for Windows you also wouldn't expect it to define __WINDOWS__. In a sense the reason Cygwin exists is that it has a gcc which defined __unix__.

As was mentioned before, if you goal is to create Windows ABI compatible binaries, you should use the MinGW cross compiler, which is available as package for Cygwin (mingw64-x86_64-... ). Please note that you should use a 64 bit cygwin to create 64 bit binaries and a 32 bit Cygwin to create 32 bit binaries. This is because the Windows filesystem has a hack that 32 and 64 bit DLLs have the same filename and which one you get depends on if you are a 32 bit or 64 bit executable. So 64 bit linker which is a 32 bit executable trying to create a 64 bit binary would see the wrong DLLs and vice versa.

Another option is to use a MinGW, MSys or MSys2 distribution - I personally prefer Cygwin exactly because it does this stricter separation between a Posix world and a Windows world. But if you main goal is to have a gcc for Windows, Cygwin might not be the best choice for you.

Best regards,

Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Houder]

On Sun, 12 May 2019 22:40:48, Brian Inglis  wrote:
> On 2019-05-12 14:54, Houder wrote:
> > On Sun, 12 May 2019 13:33:30, Mike Gran via cygwin"  wrote:
> 
> >> I think these days the canonical defines are (somebody correct me if
> >> I'm wrong)
> >>   __CYGWIN__ for Cygwin
> >>   _WIN32 as 1 on MinGW when the compilation target is Windows 32-bit
> >>   ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.
> >>   _WIN64 as 1 on MinGW when the compilation target is Windows 64-bit
> >>   ARM or x64. Otherwise, undefined
> 
> > https://sourceforge.net/p/predef/wiki/Home/
> 
> That information is 15 years out of date, a lot of the platforms are dead or

True ...

Ok, from the horse's mouth then (wrt the *WIN* mnemonics):

    https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=vs-2019
    (for as long as it lasts)

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Agner Fog]

On 13/05/2019 07.39, Brian Inglis wrote:
> Not quite I believe Cygwin 64 bit programs follow the Unix 64 bit LP64 C
> programming memory model and the System V AMD64 ABI *NOT* the Windows 64 bit
> ILP64 C programming memory model and Microsoft x64 calling convention; see:
> 	http://www.unix.org/version2/whatsnew/lp64_wp.html
> 	https://en.wikipedia.org/wiki/X86_calling_conventions
> - the interface has to be managed by the Cygwin1 dll.

I tried this:

> int test (int x) {
>     return x + 1;
> }
g++ -S -O2 t.cpp

Assembly output from g++ or clang:

> _Z4testi:
> .LFB0:
>         .seh_endprologue
>         leal    1(%rcx), %eax
>         ret
>         .seh_endproc

The Win64 ABI has the paramter in ecx or rcx, the SysV ABI has it in edi.

A dump of the object file shows it is in COFF64 format.

The object file obeys the Win64 ABI and links directly into a Win64 
project. The cygwin dll is not needed if the rest of the executable is 
made with another compiler.

The executable runs under Windows, not under Linux.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is __unix__ defined, and not __WINDOWS__ ?

[Yaakov Selkowitz]

On Mon, 2019-05-13 at 16:49 +0200, Agner Fog wrote:
> On 13/05/2019 07.39, Brian Inglis wrote:
> > Not quite I believe Cygwin 64 bit programs follow the Unix 64 bit LP64 C
> > programming memory model and the System V AMD64 ABI *NOT* the Windows 64 bit
> > ILP64 C programming memory model and Microsoft x64 calling convention; see:
> > 	http://www.unix.org/version2/whatsnew/lp64_wp.html
> > 	https://en.wikipedia.org/wiki/X86_calling_conventions
> > - the interface has to be managed by the Cygwin1 dll.
> 
> I tried this:
> 
> > int test (int x) {
> >     return x + 1;
> > }
> g++ -S -O2 t.cpp
> 
> Assembly output from g++ or clang:
> 
> > _Z4testi:
> > .LFB0:
> >         .seh_endprologue
> >         leal    1(%rcx), %eax
> >         ret
> >         .seh_endproc
> 
> The Win64 ABI has the paramter in ecx or rcx, the SysV ABI has it in edi.
> 
> A dump of the object file shows it is in COFF64 format.
> 
> The object file obeys the Win64 ABI and links directly into a Win64 
> project. The cygwin dll is not needed if the rest of the executable is 
> made with another compiler.
> 
> The executable runs under Windows, not under Linux.

The point of Cygwin is that the underlying Windows kernel and APIs are
abstracted, so that code meant for *NIX platforms just compiles and
runs as if it would elsewhere.

The current behaviour is correct and is not going to be changed.  If
you want to use Windows APIs, you can use our MinGW-w64 toolchains to
cross-compile.

--
Yaakov



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple