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 18:20:16 +0300 Message-ID: <86ttg9zgpb.fsf@gnu.org> References: <86le1m24tx.fsf@gnu.org> <86jzh622p4.fsf@gnu.org> <86h6ca1xfz.fsf@gnu.org> <867cd61412.fsf@gnu.org> <86y15lzjg6.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40707"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, rms@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 28 17:21:23 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 1sY5i7-000AQd-37 for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jul 2024 17:21:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sY5hQ-0006s8-90; Sun, 28 Jul 2024 11:20:40 -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 1sY5hO-0006lv-L7 for emacs-devel@gnu.org; Sun, 28 Jul 2024 11:20:39 -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 1sY5hN-0003bT-Tg; Sun, 28 Jul 2024 11:20:37 -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=ynvRaI1zULlnOOZbiYMMeK16SiuGTV6VJW0ARSSS/o4=; b=biROrWDFiMp0 IUJbXwH4kVS0+YIoU+4u48D6S7jbsWpAbKvY267OA25JX7uRq6Ro6oMNAUEPZnlPI+us8TKU8GD61 AVCaTFypqv51FMHIGPc7OnFrS7OybgkDaQCv3V8BJXi50xpvlobmkYD6RQF8lQ7b1EY89YU5255jy /FDgpeaqdFbO922mClXBzutIBRnjzP+gVQj8LyAt2HTmJkG8nkosFy/KOj6ubRC+0YsrppXoz+T5B rTbXSqCgjiTsb57yM/LZHlACSYTYfFl9809pHwOyr+D3JOlkPfI3MwBFkcn3LkBTYyEPBEt7CIGCK K1SQUMc9fOX1pj2cKX1yfA==; In-Reply-To: (message from Pip Cet on Sun, 28 Jul 2024 15:00:52 +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:322169 Archived-At: > Date: Sun, 28 Jul 2024 15:00:52 +0000 > From: Pip Cet > Cc: emacs-devel@gnu.org, "rms@gnu.org" > > > It seems to be doing the same as MSVCRT, at least if the UCRT sources > > available out there are to be believed. > > By my reading of the source code I found, it's doing the same as Wine, not as MSVCRT. If someone steps through that code in the UCRT build and reports that fdopen returns a different FILE pointer, I will believe you. > > 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. > > I don't think we should have Wine-specific workarounds, particularly not for such questionable code. IIUC, Wine discourages attempts of programs to detect whether they're running on Wine or Microsoft Windows. We don't have to behave like Wine intends us to behave. We have our own considerations. So I don't really care whether Wine endorses detection of Wine, if we decide we need that. > > > 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. > > Thanks. Microsoft doesn't appear to provide version information pre-Windows-2000... I use this resource to overcome the deficiencies of the official docs: http://winapi.freetechsecrets.com/win32/ > > Not sure if that is justified just to support Wine > > And UCRT, if and when the time comes. If that's the same problem, which we are not yet sure. And, as I said, support for UCRT will only become official if someone volunteers to come on board and handle that build. > And any other implementation of the Windows API that doesn't provide bug-for-bug compatibility with MSVCRT. For now, only the MSVCRT support is official. > Wine is the only significant free implementation of the Windows API, so I disagree with the "just". If I understand RMS correctly, whether there is a free implementation of an OS is an important factor in deciding to redirect resources to supporting it in GNU software. Such decisions can only be relevant if there are resources to allocate and redirect. Since we don't have them, this is entirely academic. For now, the only person who actively works on the Windows port is myself, and I'm unable to support UCRT, for more than one reason. > > > 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. > > You're right, thanks. Do we have people testing such systems? We do, although not as much as I'd like to.