unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: stefankangas@gmail.com, emacs-devel@gnu.org
Subject: Re: Windows 9X without KernelEx
Date: Sat, 15 Jun 2024 19:01:24 +0300	[thread overview]
Message-ID: <868qz6tctn.fsf@gnu.org> (raw)
In-Reply-To: <s541q4yi6es.fsf@yahoo.com> (message from Po Lu on Sat, 15 Jun 2024 23:15:23 +0800)

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 23:15:23 +0800
> 
> > 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.
> 
> Yes, that's strange.  Is the comment meant to apply to all DLLs, or just
> GDI32.DLL?

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.

> > I'd add the condition that ReadDirectoryChangesW couldn't be loaded
> > from UNICOWS.DLL.  Maybe.
> 
> Is that possible on NT?

Maybe.  My references say it's available even in Windows NT, though.

> >> 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?
> 
> w32_init_current_directory is called before globals_of_w32, and acts
> upon values set on the build machine.

What prevents us from calling globals_of_w32 before
w32_init_current_directory?



  reply	other threads:[~2024-06-15 16:01 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <875xub8sn8.fsf.ref@yahoo.com>
2024-06-14 15:12 ` Windows 9X without KernelEx Po Lu via Emacs development discussions.
2024-06-14 15:26   ` Eli Zaretskii
2024-06-14 15:37     ` Po Lu
2024-06-14 16:06       ` Eli Zaretskii
2024-06-15  1:42         ` Po Lu
2024-06-15  2:42         ` Po Lu
2024-06-15  6:58           ` Eli Zaretskii
2024-06-15  7:12             ` Po Lu
2024-06-15  7:37               ` Eli Zaretskii
2024-06-15  7:45                 ` Po Lu
2024-06-15  7:50                   ` Eli Zaretskii
2024-06-15  9:39                     ` Po Lu
2024-06-15 12:38                       ` Eli Zaretskii
2024-06-15 13:10                         ` Po Lu
2024-06-15 13:22                           ` Eli Zaretskii
2024-06-15 13:31                             ` Po Lu
2024-06-15  4:07     ` Stefan Kangas
2024-06-15  4:14       ` Po Lu
2024-06-15  4:45         ` Po Lu
2024-06-15  7:07           ` Eli Zaretskii
2024-06-15  7:22             ` Po Lu
2024-06-15  7:42               ` Eli Zaretskii
2024-06-15  9:35                 ` Po Lu via Emacs development discussions.
2024-06-15 13:52                   ` Eli Zaretskii
2024-06-15 14:18                     ` Po Lu
2024-06-15 14:55                       ` Eli Zaretskii
2024-06-15 15:15                         ` Po Lu
2024-06-15 16:01                           ` Eli Zaretskii [this message]
2024-06-16  2:01                             ` Po Lu
2024-06-16  5:36                               ` Eli Zaretskii
2024-06-16  5:50                                 ` Eli Zaretskii
2024-06-16  6:53                                   ` Po Lu
2024-06-16 11:34                                     ` Po Lu
2024-06-16 12:21                                       ` Eli Zaretskii
2024-06-23  8:35                                       ` Po Lu
2024-06-23  9:16                                         ` Eli Zaretskii
2024-06-23 20:25                                           ` Ken Brown
2024-06-24  2:30                                             ` Eli Zaretskii
2024-06-24  3:53                                               ` Po Lu
2024-06-25 19:20                                               ` Corwin Brust
2024-06-24 17:17                                             ` Ken Brown
2024-06-24 22:11                                               ` Ken Brown
2024-06-25 22:41                                                 ` Ken Brown
2024-06-27  1:59                                                 ` Po Lu
2024-06-27 13:18                                                   ` Ken Brown
2024-06-27 13:42                                                     ` Po Lu
2024-06-27 13:47                                                       ` Po Lu
2024-06-27 14:52                                                         ` Ken Brown
2024-06-30  2:07                                                           ` Po Lu
2024-06-15  7:01       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=868qz6tctn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).