From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Interest in nt_load_image? Date: Tue, 31 Mar 2020 16:31:00 +0300 Message-ID: <83y2rg1wiz.fsf@gnu.org> References: <86369r0xcv.fsf@csic.es> <83k1324m60.fsf@gnu.org> <86imimwa4t.fsf@csic.es> <838sji3qhx.fsf@gnu.org> <86lfnhsyei.fsf@csic.es> <83v9ml3kpx.fsf@gnu.org> <86r1x9rf7w.fsf@csic.es> <86zhbx6jh1.fsf@csic.es> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="8752"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Juan =?utf-8?Q?Jos=C3=A9_Garc=C3=ADa-Ripoll?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 31 15:32:24 2020 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 1jJH0C-0002D0-7E for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 15:32:24 +0200 Original-Received: from localhost ([::1]:38120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJH0B-0000XJ-9V for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 09:32:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43193) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJGyj-0006pk-15 for emacs-devel@gnu.org; Tue, 31 Mar 2020 09:30:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jJGyi-0001j3-T3; Tue, 31 Mar 2020 09:30:52 -0400 Original-Received: from [176.228.60.248] (port=2150 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jJGyf-0003Ki-3i; Tue, 31 Mar 2020 09:30:52 -0400 In-Reply-To: <86zhbx6jh1.fsf@csic.es> (juanjose.garciaripoll@gmail.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:246094 Archived-At: > From: Juan José García-Ripoll > > Date: Tue, 31 Mar 2020 10:01:46 +0200 > > I have build GDI+ as a built-in back-end with which to compile Emacs. An > Emacs built with GDI+ requires UTF-16 support and thus will not run on > Windows 98, but it will run on Windows XP on later. GDI+ support is > optional because it can be selected at build time, not because it can be > chosen at compilation time. The problem with such selection of features at build time is that the resulting binary will flatly refuse to start on systems where the optional functionality (in this case, GDI+) is not available, even if there's no call at runtime to any of the optional functions. Windows refuses to run a program which has a function in its import table that cannot be found in the shared libraries against which the program was linked, or if the program was linked against a shared library that is not available on the target system. And on Windows we frequently see that people are using binaries someone else compiled, so we cannot rely on the end-user to build Emacs according to what will be available on the end-user's system. That is why we never link Emacs on Windows against any optional libraries, but instead load them at runtime when the corresponding feature is first requested. The features whose DLL couldn't be loaded, or where the DLL doesn't have the required functions -- those features will not become available, but at least Emacs will start and allow you to use it for other jobs. In the case of GDI+, I'm quite sure we will want to have runtime control on whether it is used even if available, at least initially, until it becomes the default (if it ever does). This is good for maintenance (debugging problems people report), if nothing else. I could even envision users who'd prefer libpng etc. for some other reason, whether technical or otherwise. Therefore, catering to systems without GDI+ is very simple: the respective variable(s) should be set up at startup to indicate that GDI+ shouldn't be used.