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: Sat, 15 Jun 2024 17:55:04 +0300 Message-ID: <86bk42tfw7.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18203"; 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 Sat Jun 15 16:56:02 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 1sIUoz-0004T7-8M for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Jun 2024 16:56:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sIUoB-0007Jc-Mt; Sat, 15 Jun 2024 10:55:11 -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 1sIUo9-0007J2-H0 for emacs-devel@gnu.org; Sat, 15 Jun 2024 10:55:09 -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 1sIUo9-0006Ah-1p; Sat, 15 Jun 2024 10:55:09 -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=OJPFbaRgU7UGOKZaOPiMPCdA9CAXuAl9vib5XibZi4I=; b=qcvFsT8g3nF/ xVp+ejxwxdu8ytqiEtsMB8qkpLZLnPinp12RfaCOz8uNQBfHKi5TE3USB6tXS+GYTsyFhGyjNNvKH GS6+IwgvIy83K4ucrnExqy3hVpO5mUkX9ALNPV5WnMaSXrZZZYtf8aaZIyoCk2vgE36w40sqSxByG vKm1HAgaK96K5k9E4aqbvlWBLdQfw9OZ7j7Ycokx9ffyhC+HWr1MqosJqaPPy3zTavQ8IUU63ZGKM WYvRuW9M9VRvpXT3oFmgWwEMWu5gQkOO2MwvWkBxdBpa/HwicVYrIfL5mWL2/OHrOdfqStTYpOcG7 PHxetJ2L9hklhE+gnEi4BQ==; In-Reply-To: <875xua5lxs.fsf@yahoo.com> (message from Po Lu on Sat, 15 Jun 2024 22:18:23 +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:320151 Archived-At: > From: Po Lu > Cc: stefankangas@gmail.com, emacs-devel@gnu.org > Date: Sat, 15 Jun 2024 22:18:23 +0800 > > Eli Zaretskii writes: > > >> Shell_NotifyIconW > >> ShellExecuteExW > >> SHFileOperationW > >> ReadDirectoryChangesW > > > > This is strange. Most of those are present in Emacs for a long time, > > Perhaps everyone else had installed KernelEx? It was you who ran Emacs on those systems, so you should ask yourself. Maybe every Windows 9X system that is in real use does indeed have KernelEx and whatever else is needed, because both IE and Office are known to bring such system DLLs with them. > > and I was somehow under the impression that Emacs did start on Windows > > 9X after their introduction. Did you start Emacs with UNICOWS.DLL > > available? > > I did, indeed. But -lunicows is absent from the linker command line, so > emacs.exe is required to load the library, and its exports into function > pointers, at runtime, and I don't understand how symbol conflicts > between it and OS exports on NT systems are resolved. The way it's supposed to be resolved is that the system DLLs on Windows 9X are supposed to have these symbols, whose implementations are stubs that do nothing or fail. This is clearly stated, for example, in this comment in w32font.c: /* Several "wide" functions we use to support the font backends are unavailable on Windows 9X, unless UNICOWS.DLL is installed (their versions in the default libraries are non-functional stubs). On NT and later systems, these functions are in GDI32.DLL. The following helper function attempts to load UNICOWS.DLL on Windows 9X, and refuses to let Emacs start up if that library is not found. On NT and later versions, it simply loads GDI32.DLL, which should always be available. */ static HMODULE w32_load_unicows_or_gdi32 (void) { return maybe_load_unicows_dll (); } So I think we are missing something here, because this clearly used to work in the past, on real Windows 9X systems. > > My references indicate that UNICOWS.DLL has the first 3 of the above 4 > > APIs. So I'd suggest to do for these 3 what we do for > > MultiByteToWideChar, see w32.c:maybe_load_unicows_dll, and then see if > > the problem is solved. If that doesn't solve the problem, > > i.e. doesn't allow Emacs to start, we can discuss what to do about > > each of these 3 APIs. > > The issue is that these functions don't appear to be defined elsewhere > than UNICOWS.DLL, even as stubs, with the result that they must be > loaded at runtime See above: that's not what our (very old) comments say to me. > > ReadDirectoryChangesW is indeed absent from UNICOWS.DLL, so I think > > globals_of_w32notify should attempt to load it, and if not available, > > This is taken care of in the patch, though in a new function, which > could be consolidated into globals_of_w32notify if it is run during > startup in dumped Emacs binaries. Like I said: let's discuss each issue separately, not as a single large patch which attempts to resolve several issues. > > disable the file notifications by modifying the code we already have > > in w32notify-add-watch: > > > > /* The underlying features are available only since XP. */ > > if (os_subtype == OS_SUBTYPE_9X > > || (w32_major_version == 5 && w32_minor_version < 1)) > > { > > errno = ENOSYS; > > report_file_notify_error ("Watching filesystem events is not supported", > > Qnil); > > } > > What's to be modified here? I'd add the condition that ReadDirectoryChangesW couldn't be loaded from UNICOWS.DLL. Maybe. > Finally, how say you to the change to w32_init_file_name_codepage? It > is required to run binaries on 9X that are dumped on NT, and in its > absence, w32_unicode_filenames and is_windows_9x both return FALSE > during the early stages of initialization. I don't think I understand the issue. Which static variables are not reinitialized at startup and cause the above? I see that globals_of_w is unconditionally called during startup, and resets g_b_init_is_windows_9x to zero; it thereafter calls is_windows_9x and sets w32_unicode_filenames to zero on Windows 9X. So I don't think I understand the problem. What did I miss?