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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 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> <72c5e82b-38f0-8701-93fe-5682176017b6 AT SystematicSw DOT ab DOT ca> <726f278f-c0b5-7578-a594-e7e249981104 AT agner DOT 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