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 22:18:23 +0800
> 
> Eli Zaretskii <eliz@gnu.org> 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?