Re: Windows 9X without KernelEx

[Eli Zaretskii]

> 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?