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: Windows 9X without KernelEx Date: Sun, 16 Jun 2024 08:36:28 +0300 Message-ID: <86r0cxsb37.fsf@gnu.org> References: <875xub8sn8.fsf.ref@yahoo.com> <875xub8sn8.fsf@yahoo.com> <8634pfy289.fsf@gnu.org> <87sexe7sgm.fsf@yahoo.com> <87o7827r1t.fsf@yahoo.com> <86ed8ywuoz.fsf@gnu.org> <87frte7jry.fsf@yahoo.com> <86a5jmwt2r.fsf@gnu.org> <874j9u7dla.fsf@yahoo.com> <86h6dutirt.fsf@gnu.org> <875xua5lxs.fsf@yahoo.com> <86bk42tfw7.fsf@gnu.org> <868qz6tctn.fsf@gnu.org> <87wmmp4pdy.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27793"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 16 07:37:30 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 1sIia2-00074T-2d for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Jun 2024 07:37:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sIiZ7-0007pG-Nb; Sun, 16 Jun 2024 01:36:33 -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 1sIiZ5-0007oo-Vj for emacs-devel@gnu.org; Sun, 16 Jun 2024 01:36:32 -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 1sIiZ5-0003zw-Mg; Sun, 16 Jun 2024 01:36:31 -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=3baSYMUHDbNSYHWqCaumLhR1hYjXGLNGPq8q1SJnpKs=; b=lx5xJjxm4jiv BXxMCUechD0/fpEGZhlqGPV1OwbVB/bjqIqgTOybdgkwUjlQ1kXjIgJX1gvntq4fa8xHLVGnxEdsi SrsyUj+61IH6cIDlljGTAsLAqSoPVSEuxk5Kxc2ech+ZN8IFvMHNvZEZEaQ6wY8DIF5UOss+q1x1O I9iGpjAdaZYnqXE7IIq0EQedawnS1qrQaMMa+xdEsqatAL5IOOMj3aYsSZRP08mF87fDARisNUCa7 FPYdnvWc9HTJe/UPjRdp6eZoFRfKIK1jHMFuKPF5CVJpD2Tgf49okJmwuoLNwFjEv3ulN7R+0aNwt u9DyrPAET05BtE3DdEesOQ==; In-Reply-To: <87wmmp4pdy.fsf@yahoo.com> (message from Po Lu on Sun, 16 Jun 2024 10:01:29 +0800) 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:320176 Archived-At: > From: Po Lu > Cc: stefankangas@gmail.com, emacs-devel@gnu.org > Date: Sun, 16 Jun 2024 10:01:29 +0800 > > Eli Zaretskii writes: > > > The GDI32.DLL part is specific to the functions used by w32font.c. > > But the idea is general: all of the APIs that we call directly are > > supposed to be present in some system DLL, even though some of them > > have stub implementations. For example, I have SHELL32.DLL (dated Sep > > 1998!) from my old Windows 9X system, and in it I see both > > ShellExecuteW and SHFileOperationW exports. > > Mine reports a creation time of May 11th 1998, but upon running `nm' I > see that it indeed exports those two functions, and a test program > compiled in MinGW: > > int > main () > { > extern int ShellExecuteW (); > extern int SHFileOperationW (); > char *x = (char *) &ShellExecuteW; > char *y = (char *) &SHFileOperationW; > } > > starts and exits with no error dialog, and yet Emacs still does not link > if it imports either symbol. Might there perhaps be symbol versioning > mechanisms or parameters in object files that influence its view of > external symbols? I'm lost, sorry. I think the reason is we don't link with -lshell32 anymore. We used to do that until Emacs 25, but dropped that since for some reason. Can you see if adding that to the link command fixes this problem? > > What prevents us from calling globals_of_w32 before > > w32_init_current_directory? > > It resets numerous other variables and also initializes the "console > ctrl handler", which gave me plenty of pause. Does it solve the problem, though? The variables it resets need all to be reset anyway, and in the pdumper build this reset is a no-op (they are static variables not recorded in the pdumper file). So I don't necessarily see why moving it up would cause any problem.