X-Recipient:	archive-cygwin AT delorie DOT 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 AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT 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 AT cygwin DOT com>
To:	cygwin AT cygwin DOT 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 AT agner DOT org> <8e9bfbb4-2139-639d-afaa-dfbacac1a8d9 AT t-online DOT de> <dfd043fb-620a-81a1-1611-91a982fc96cd AT agner DOT org> <72c5e82b-38f0-8701-93fe-5682176017b6 AT SystematicSw DOT ab DOT ca> <726f278f-c0b5-7578-a594-e7e249981104 AT agner DOT org>
User-Agent:	Evolution 3.30.5 (3.30.5-1.fc29)
MIME-Version:	1.0

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

- Raw text -