X-Recipient: archive-cygwin@delorie.com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:subject:from:to:date:in-reply-to
	:references:content-type:mime-version:content-transfer-encoding;
	 q=dns; s=default; b=W3Nn4rAaPx26KirBD4bimbgsBz23KRSU0yjsIao+4jd
	BM/GjhHfMl9PDco2RD9Yn9FVniHQ9rhVMQK4hi9nEwv6gh+T683Ek9CAr8gG/SNp
	Zg8MnM8tCTVNMIvNAMuJH3THw9x7mGVvRSwRaImfUsBdj50qDNsEmnTbFjwj8+zA
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:subject:from:to:date:in-reply-to
	:references:content-type:mime-version:content-transfer-encoding;
	 s=default; bh=AaRykp/gvrDwacNF0nyyu4e6zZ4=; b=Xd0n1+CC9hHS2XP5E
	zMoRbzT2nZBf76x1TH5FA1LigQ5lNJApXEAHOi5WKqpDRLf/tZmsdDVQNiUE+b9z
	P5ZArFhhHDB6N2ApNUpmpVUSO0qyJHk6k5TEQkmnEJvWZ5FG7AmDeY3o7qXSJvIZ
	+6X2RF0KHTJe98AEFV7nAH6FkE=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=Assembly, H*F:D*cygwin.com
X-HELO: mx1.redhat.com
Message-ID: <86d42b246539bb22769fbea863f825de93921654.camel@cygwin.com>
Subject: Re: Why is __unix__ defined, and not __WINDOWS__ ?
From: Yaakov Selkowitz <yselkowitz@cygwin.com>
To: cygwin@cygwin.com
Date: Mon, 13 May 2019 12:16:44 -0400
In-Reply-To: <726f278f-c0b5-7578-a594-e7e249981104@agner.org>
References: <5fbb6229-da17-c056-19b9-9819c684a8ad@agner.org>	 <8e9bfbb4-2139-639d-afaa-dfbacac1a8d9@t-online.de>	 <dfd043fb-620a-81a1-1611-91a982fc96cd@agner.org>	 <72c5e82b-38f0-8701-93fe-5682176017b6@SystematicSw.ab.ca>	 <726f278f-c0b5-7578-a594-e7e249981104@agner.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5 (3.30.5-1.fc29)
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

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

