Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 15 Jun 2024 17:35:45 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > If you add usp10.dll (and unicows.dll) to Windows 98, does Emacs start
>> > then?  Or do any of the other missing APIs prevent it from starting?
>> 
>> I cannot test with USP10.DLL at the moment, but that aside, as I said,
>> all of the following prevent Emacs from starting on Windows 98:
>> 
>>   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?

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

> 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, from SHELL32/USER32.DLL, or the runtime link editor
(what is the proper nomenclature for this component on Windows?) will
fail to locate symbols imported by emacs.exe.  Which is all taken care
of in the patch I posted.

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

> 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?  `os_subtype == OS_SUBTYPE_9X' should
address all the 9X systems, right?

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.