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: Mon, 29 Jul 2024 14:25:23 +0300 Message-ID: <86h6c8zbh8.fsf@gnu.org> References: <86h6ca1xfz.fsf@gnu.org> <867cd61412.fsf@gnu.org> <86y15lzjg6.fsf@gnu.org> <86ttg9zgpb.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9859"; 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 Mon Jul 29 13:26:16 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 1sYOW8-0002Md-AM for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Jul 2024 13:26:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sYOVU-0005zA-8w; Mon, 29 Jul 2024 07:25:36 -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 1sYOVS-0005ys-H7 for emacs-devel@gnu.org; Mon, 29 Jul 2024 07:25:34 -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 1sYOVS-0005Lr-0p; Mon, 29 Jul 2024 07:25:34 -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=/cxg0yU6EFEJUuND3esxX+ocHImpeLUG0XPIa7cwZuc=; b=BNxUQ2Kgfhud ZWH5mOhOInXjTAdp7+TKPTHanRKU6HfeEIXwasKX8vhOr7Oyx1CFCGcz8ndDhRjVV0dKUe6czSo4e qN4Hz9VgBtBbdNinRkRZlbN1yKzlCAO8Ncxp0YnrGRjVKVHNGPdhhj/dZjwjueM5Jv8B35MV7MAUY yJUTXKZjMzm3t/traXinQSgC3J/ZBwWX+IG//RmIxjYz79Mcy1Si+67V+3QxZsMIonDgkaxxta9DO dvcvb+f50tG+DhCk4uJI03GMilg21USI1ScB6QVEl9pc+bx1T232nASKr9/Dv5soNLDD3EUJmC9Fq fukdFqEuYaDfcKuup7FLMw==; In-Reply-To: (message from Pip Cet on Sun, 28 Jul 2024 20:22:40 +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:322192 Archived-At: > Date: Sun, 28 Jul 2024 20:22:40 +0000 > From: Pip Cet > Cc: emacs-devel@gnu.org, rms@gnu.org > > On Sunday, July 28th, 2024 at 15:20, Eli Zaretskii wrote: > > > 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. > > I've verified this by running a GitHub action (I won't provide a link because it's probably impossible to use without running proprietary GitHub JavaScript), though I couldn't work out how to make clang link against msvcrt rather than its own libraries. 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. All of that requires a volunteer who will take upon him/herself to implement and test the possible solutions on the actual platform, and then maintaining that and the rest of UCRT-specific stuff for some reasonably observable future. IOW, this needs a dedicated support person. > > And, as I > > said, support for UCRT will only become official if someone volunteers > > to come on board and handle that build. > > That's what I meant by "if and when the time comes". > > > > 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. > > Of course, and I think it's more likely it will cease being official than other builds becoming 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. > > I think the community of Emacs developers decides by consensus (or bickering) what to work on. My understanding was that we're considering whether to stop working on at least some variants of the Windows port. The community of Emacs developers cannot allocate resources that don't exist. And even when they do exist, the ability of the community to redirect those resources is limited by the opinions and limitations of the people whose resources need to be redirected. > > Since we don't have them, this is entirely academic. > > Well, I disagree. Official guidance by the GNU Emacs project does have some influence on what volunteers will work on. I consider that a resource. I'm around for enough time to know that it is almost never a resource we can control. And the effectiveness of such guidance is severely limited even in easier cases, see the recent arguments about naming packages and similar stuff. > > 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. > > Are you working on MINGW64 systems at all, or is it mingw exclusively? I'm using MinGW and don't intend to install MinGW64 any time soon. And, as I said earlier on the list, even supporting the MSVCRT build is becoming too much if I have to do that alone, together with my main responsibilities here.