From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: Win64 testers? Date: Sun, 28 Jul 2024 17:20:57 +0300 Message-ID: <86y15lzjg6.fsf@gnu.org> References: <86ttgb1186.fsf@gnu.org> <86le1m24tx.fsf@gnu.org> <86jzh622p4.fsf@gnu.org> <86h6ca1xfz.fsf@gnu.org> <867cd61412.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25240"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 28 16:21:39 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sY4mJ-0006MS-0A for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jul 2024 16:21:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sY4lh-0007jh-H2; Sun, 28 Jul 2024 10:21:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sY4lg-0007jW-Pu for emacs-devel@gnu.org; Sun, 28 Jul 2024 10:21:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sY4lg-0001fi-HI; Sun, 28 Jul 2024 10:21:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Y8friuGVyagsK3zUY86cYbDjQIi1oFTWeegxeFEaxWg=; b=XFlUooZKem8g dwcVbOn3kN73VJHIaflf9I3GiKIhnlKOpN4iPU6vD996d87181Ga7eLYbi+5Lr+Xe37HntmyBPmmH 9NL0B9om4wfLl6yRQb7UTXUMlhKzIypKkXHz1h9cJPz67vePKjVacVEGcrQgu+3ElZNXNP42EpOW5 aI0lIBrg3jnFvNNV4sbOOaPqIU6MiyU0hvJn8eqOJbhQ0i2HWloPNDQxcGzOQM1J/FMMrTbHQ3NHc 2NCgk5bgSGmFK6jW4D4PN4eSi9nqPxGmz1RNIB/R/ri1hmEQSRq2WdoJ5D5/DkyPtCQYCdz+xTVH5 cLVm84zJVpKA5mYP/qv1og==; In-Reply-To: (message from Pip Cet on Sun, 28 Jul 2024 13:00:20 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322167 Archived-At: > Date: Sun, 28 Jul 2024 13:00:20 +0000 > From: Pip Cet > Cc: emacs-devel@gnu.org > > On Sunday, July 28th, 2024 at 05:25, Eli Zaretskii wrote: > > > Date: Sat, 27 Jul 2024 20:22:34 +0000 > > > From: Pip Cet pipcet@protonmail.com > > > Cc: emacs-devel@gnu.org > > > It's been that way since 2004, if the git history is to be believed. > > > > I guess they have some unsolved issues with the standard streams, > > which is why they don't dare reusing their slots. Which means closing > > these standard streams is a no-no on Wine. > > I don't know. I suspect they just never thought (20 years ago!) that anyone would want to close a standard stream. Any idea what UCRT does? It seems to be doing the same as MSVCRT, at least if the UCRT sources available out there are to be believed. > > But if this is what Wine does, then what do you get from the various > > fprintf debugging code in Emacs? For example, if you build with the > > "--enable-checking='yes,glyphs'" option, you get the trace-redisplay > > command which outputs debugging information about redisplay to stderr, > > and also the dump-glyph-matrix command which prints the glyph matrix > > to stderr. Do these print-outs still work although stderr was closed > > in init_ntproc? > > I tried with GDB, and fprintf(stderr, ...) stops working in init_ntproc. So they do fclose the stream, just don't provide a way of reopening a standard stream. Is there any way for a program running on Wine to detect that this is what happens? like some special version number or something? If so, I'd just avoid all that code in init_ntproc on Wine, since leaving the standard streams inheritable is a much smaller trouble than losing the standard streams. > As for the code in question, if I understand it correctly, the current Windows idiom would be simply (I assume _open_osfhandle clears the flag?): > > SetHandleInformation (GetStdHandle (STD_INPUT_HANDLE), HANDLE_FLAG_INHERIT, 0); I'm not sure you can do this without closing the stream, since the program has already started by that time. And SetHandleInformation is only available since Windows 2K, so we'd need to call it through a function pointer. Not sure if that is justified just to support Wine (which probably has quite a few other incompatibilities). > The version information for availability of "SetHandleInformation" and "DuplicateHandle" is the same, so any idea why we're not just doing that, or is it just lost in history? See above: we still strive to support Windows 9X and NT.