X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org C373D3858D37
Authentication-Results:	sourceware.org; dmarc=none (p=none dis=none)
	header.from=SystematicSw.ab.ca
Authentication-Results:	sourceware.org;
	spf=none smtp.mailfrom=systematicsw.ab.ca
X-Authority-Analysis:	v=2.4 cv=e9cV9Il/ c=1 sm=1 tr=0 ts=61e115d9
	a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17
	a=IkcTkHD0fZMA:10 a=meDerTAkmQ8pbOtrlwYA:9 a=QEXdDO2ut3YA:10
Message-ID:	<4e9a2d3a-828d-a4e4-a66a-a39985cf5954@SystematicSw.ab.ca>
Date:	Thu, 13 Jan 2022 23:19:04 -0700
MIME-Version:	1.0
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
	Thunderbird/91.4.1
Subject:	Re: ExitProcess does not work in Cygwin?
To:	cygwin AT cygwin DOT com
References:	<MWHPR1401MB1951896B7184CC9CC408CD07E6539 AT MWHPR1401MB1951 DOT namprd14 DOT prod DOT outlook DOT com>
	<1f98eb84-e3d7-bf0d-875c-3d4818e41aef AT cs DOT umass DOT edu>
	<72e0f0601676717a2702ff13beb45b80 AT mail DOT kylheku DOT com>
	<4f1b70a7-22e0-685b-ab00-9af895ed4e51 AT SystematicSw DOT ab DOT ca>
	<MWHPR1401MB1951C6A27882346C9E2234C2E6539 AT MWHPR1401MB1951 DOT namprd14 DOT prod DOT outlook DOT com>
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Organization:	Systematic Software
In-Reply-To:	<MWHPR1401MB1951C6A27882346C9E2234C2E6539@MWHPR1401MB1951.namprd14.prod.outlook.com>
X-CMAE-Envelope:	MS4xfOVR5cCt6L7ETf+L4fxn9uBEXbU90onhVqjMBR8JLL6OtY8w3B4nlnfimYlZ7NT/JhX+l0JTbooisf404yI/tbi6A7H6Ywtty7ezp0IHxIOCeSGqNZwY
	JzpGOF0GhczKHtRfYWXawM9ezhQkjhzyP+hhU66gxxidCh+eWtDlAVz+bw3Y0pSJVSlL2riugpO3ubE6m9hOo0hctNpLG1V/JnM=
X-Spam-Status:	No, score=-1160.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL,
	SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version:	SpamAssassin 3.4.4 (2020-01-24) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Reply-To:	cygwin AT cygwin DOT com
Errors-To:	cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On 2022-01-13 16:15, Jay K wrote:
> On Thursday, January 13, 2022 5:19 PM, Brian Inglis wrote:
>> On 2022-01-13 10:07, Kaz Kylheku wrote:
>>> On 2022-01-13 05:40, Eliot Moss wrote:
>>>> On 1/13/2022 1:39 AM, Jay K wrote:

>>>>> ExitProcess does not work in Cygwin?

>> Just use POSIX exit(3)!

> I did switch my code:
> 
> #ifdef __CYGWIN__
>   exit(x);
> #else
>   ExitProcess(x);
> #endif
> .
> 
> I think the problem is actually in how "Cygwin bash"
> aka Cygwin, computes the exit code in exec/spawn/system.
> 
> i.e. it recognizes it is running a Cygwin exe or a native
> exe and does things differently.

...attempts to determine whether...

> I admit I didn't read or debug much.
> 
> In one run I was debugging I did seem to see a crash
> in some DllMain(process detach), without symbols, and then I seemed to see
> ExitProcess(1 or 2) become ExitProcess(0xXX00) and
> then I started wondering if Cygwin somewhere is only
> taking the lower 8 bits, since I know that is a thing in some code.

Cygwin follows POSIX and returns only the lower eight bits ORed with the 
child exit wait status flags (see wait(3p)) which may be tested with the 
macros in sys/wait.h (see sys_wait.h(0p)).

> But I didn't dig into this further before trying the simple case,
> which I don't think crashes and really does NtTerminateProcess(1).

> Just use POSIX exit(3)!

>>> ExitProcess does not appear to be a POSIX function.

>> This is a real issue worth looking into. Though ExitProcess isn't a POSIX
>> function, Cygwin can capture the termination status of non-Cygwin programs.
>>
>> The concept of termination status cannot be entirely walled off in a
>> private Cygwin garden; it belongs to the underlying platform.

You can do a lot of things under Cygwin, but only POSIX/Linux-like 
operation should be expected; some other things work, but may not be 
consistent, and are unlikely to be considered bugs e.g. using Windows 
paths, TTY line terminators, or more than 8 bit exit codes.

>> In Cygwin, I can do this:
>>
>>     C:\Cygwin\cygwin64\home\kaz>exit 1
>>     1:BLACKBOX:~$
>>     1:BLACKBOX:~$ echo $?
>>     1
>>     0:BLACKBOX:~$ cmd
>>     Microsoft Windows [Version 10.0.19042.1052]
>>     (c) Microsoft Corporation. All rights reserved.
>>
>>     C:\Cygwin\cygwin64\home\kaz>exit 0
>>     0:BLACKBOX:~$
>>
>> The number in my Bash prompt is the last exit code. As you can see,
>> the non-Cygwin CMD.EXE program produces a termination code which
>> is recognized in the Cygwin world.
>>
>> Most likely it does that via ExitProcess.
>>
>> It is odd if calling ExitProcess in a Cygwin process causes
>> a Cygwin parent not to similarly process the status, as seems
>> to be shown by Jay's test cases.
>>
>> Cygwin supports non-POSIX programming; you can write GUI applications
>> using Win32 calls for instance.

GUI e.g. Cygwin Setup program setup-x86/_64 and also Windows console 
apps e.g. cygcheck, cygwin-console-helper, ldh, strace, but those are 
all built with {i686,x86_64}-w64-mingw32-g++ and linked to MS msvcrt.dll 
*NOT* Cygwin cygwin1.dll startup and runtime.

The default terminal console app mintty is a hybrid case.

>> (Now I agree that for exiting your process, even if it's a GUI
>> application using numerous win32 calls, you should probably do it the
>> Cygwin way, and use exit, or return from main. But still ...)
> 
> Cygwin installs at-exit handlers and it is likely that when these have
> finished, they return a Cygwin exit status if passed by the POSIX
> function, perhaps unless some error has occurred during at-exit handling.

-- 
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.
[Data in binary units and prefixes, physical quantities in SI.]

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

- Raw text -