emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Windows 9X without KernelEx


From: Eli Zaretskii
Subject: Re: Windows 9X without KernelEx
Date: Sat, 15 Jun 2024 16:52:54 +0300

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

ReadDirectoryChangesW is indeed absent from UNICOWS.DLL, so I think
globals_of_w32notify should attempt to load it, and if not available,
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);
    }

> > We should have discussed this before your writing the code, to prevent
> > the unnecessary efforts.  I'm sorry for your wasted time, but I have
> > said many times before: this kind of issues should be discussed first.
> > I will keep saying that, in the hope that at some point this will
> > sink.
> 
> I re-read the following twice and considerably moderated its tone, but
> it might continue to read as a flame to the sensitive, so, trigger
> warning.  In nowise is it meant as a personal reflection on anyone in
> this thread, though if anyone who passes by recognizes himself in the
> same, he would do well to change his ways.

I don't think what you wrote there is relevant here, sorry.  (We
definitely cannot be responsible for what nasty things people say on
SourceForge or in other forums.)

In general, any non-trivial work on something that is meant to improve
Emacs support for very old systems should be discussed first, even
before any significant research, to avoid waste of time and efforts.
I think we should limit such support to the minimum: what worked there
should continue working, and if some code prevents Emacs from starting
or being a useful editor there, we should fix that as simply and
safely as possible.

I cannot possibly prevent people from investing significant efforts
before starting a discussion, but then I cannot guarantee that we will
accept the resulting code changes, and so the risk of wasting those
efforts will be greater.

FTR, I still have on my system old files and system directories from
Windows 9X and from XP, and can at least explore what they exported
using 'pexports' and the likes.  I alsi have a list of symbols
exported by UNCOWS.DLL and an old Win32 API documentation which
indicates which APIs were available on Windows 9X.  So if you need to
do similar research in the future, you could ask me first.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]