Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

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

Perhaps this is so, but I cannot be expected to reproduce 1:1 a PC that
has stood beneath a desk handling confidential information, and which
has been in continuous service, since 2008, in a virtual machine.

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

Yes, that's strange.  Is the comment meant to apply to all DLLs, or just
GDI32.DLL?

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

Is that possible on NT?

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