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: Sat, 03 Aug 2024 12:23:51 +0300 Message-ID: <86frrmufh4.fsf@gnu.org> References: <86y15lzjg6.fsf@gnu.org> <86ttg9zgpb.fsf@gnu.org> <86h6c8zbh8.fsf@gnu.org> <86ikwly80l.fsf@gnu.org> <875xsixcxw.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16600"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, rms@gnu.org To: pipcet@protonmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 03 11:24:48 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 1saB0J-0004Af-Oz for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Aug 2024 11:24:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1saAza-0003Ly-Tu; Sat, 03 Aug 2024 05:24:02 -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 1saAzY-0003La-Ew for emacs-devel@gnu.org; Sat, 03 Aug 2024 05:24: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 1saAzY-0006Pd-5f; Sat, 03 Aug 2024 05:24: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=QjYGsWOICW4R30Bp3PXA+sllcIuvEHfOvNm2/RNLyvQ=; b=DsijllcUReaV KFsolqMZcOj0yDBkOEF0iNssc5XUrdPN+9dQZTCHfJgednjFKR6bwA9dhx+zGpfFQfXZRj0Gw9rQO xZsmBS5L7RfznjATA1tBM9qbwRPLlFnGL3uBUXuAF/QPS+7Jepl6XUA36bZ4tC7lyiKHUXENbcBR8 wdMpXcL3IJ8SUiCBEA8Q4fJy8IwarMF+2hIFzhOg6lpwB6HUqmdW/JuWCLqSdfd37oXRGqbbz3kEX DPxebvNNQlZhfT4b36c+bqkT6tTeFjCUSMcp5QFbnQEmL6J2s0jEo1yVjF3FoBgSuZEnnpCgB5p8s /8XlHiV9QnF2kvMyQEZ5/Q==; In-Reply-To: <875xsixcxw.fsf@protonmail.com> (pipcet@protonmail.com) 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:322300 Archived-At: > Date: Sat, 03 Aug 2024 07:50:21 +0000 > From: pipcet@protonmail.com > Cc: emacs-devel@gnu.org, rms@gnu.org > > "Eli Zaretskii" writes: > > >> Date: Wed, 31 Jul 2024 06:18:16 +0000 > >> From: Pip Cet > >> Cc: emacs-devel@gnu.org, rms@gnu.org > >> > >> > Thanks, but this is just a first small step in the right direction. > >> > We need this verified with Emacs, not a small separate test program, > >> > and we need then some serious testing of whatever solution we decide > >> > to implement. > >> > >> I think the bar is slightly lower than that: the code in Emacs is > >> clearly buggy, because it relies on strange and peculiar > >> implementation details that go far beyond anything guaranteed by the > >> API (and that may break at any point on new systems). Replacing it > >> is necessary. > > > > I disagree. > > If you disagree that it relies on details that aren't guaranteed by the > API, can you provide an API reference that backs you up? I disagree that the bar is lower than what I described. The existing code relies on undocumented features, yes, but we have quite a lot of that in the Windows and MSDOS ports, and there's nothing in particular wrong with that. When the undocumented features stop working in some situations, we need to find a solution for those situations, and those solutions must be tested within Emacs, not a toy test program, and they must be tested thoroughly, including (in this case) the verification that the handle is not inherited by Emacs sub-processes. > >> One thing we can certainly stop doing is to discourage people from > >> even looking at stuff. Closing actual bugs as "wontfix" without a > >> sensible explanation, for example, seems counterproductive to me. > > > > Which bugs where "closed as wontfix without a sensible explanation"? > > 72335 That bug is not closed. > >> > I'm using MinGW and don't intend to install MinGW64 any time soon. > >> > >> Maybe it's time to make that port unofficial, or at least to stop directing people to it rather than the MinGW64 port. > > > > We have been advertising MinGW64 (with MSVCRT) for a long time, see > > nt/INSTALL.W64. But since it doesn't support Windows versions older > > than Vista (or maybe even that is not supported anymore), we also > > advertise MinGW, which does. > > Indeed, but people look at nt/INSTALL first, usually If they read it, it tells them that those instructions are for older versions of Windows. > and that's about an entirely different port which hardly anyone > considers usable at this point, as far as I can tell. It isn't an entirely different port, no. The code commonality between the two is close to 100%, and so is the functionality, the only difference is that one is 32-bit, the other 64-bit.