Re: scratch/windows-98 18e7a9f3d0c: Restore functionality on Windows 98

Re: scratch/windows-98 18e7a9f3d0c: Restore functionality on Windows 98

[Stefan Kangas]

Po Lu via Mailing list for Emacs changes <emacs-diffs@gnu.org> writes:

> branch: scratch/windows-98
> commit 18e7a9f3d0c27385f8efeb2b1ef80b3446dca288
> Author: Po Lu <luangruo@yahoo.com>
> Commit: Po Lu <luangruo@yahoo.com>
>
>     Restore functionality on Windows 98

What does "restore functionality" mean here?

In what state has the Windows 98 build been, and for how long?

Re: scratch/windows-98 18e7a9f3d0c: Restore functionality on Windows 98

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> In what state has the Windows 98 build been, and for how long?

Please read last week's Windows 9X thread and the ChangeLog entry, where
all this was elaborated upon at great length.  Just remember that,
whatever you should conclude, _there is no pretext on which to abandon
support for Windows 98 to be had from this change_, or in the existing
condition of NTEmacs.

Thanks.

Re: scratch/windows-98 18e7a9f3d0c: Restore functionality on Windows 98

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> In what state has the Windows 98 build been, and for how long?
>
> Please read last week's Windows 9X thread and the ChangeLog entry, where
> all this was elaborated upon at great length.
>
> Thanks.

Thanks, I read that, but it didn't answer my questions.

Let me try to reformulate what I'm asking:
- Is the Windows 98 build currently broken?
- How long has the Windows 98 build been broken?

These questions are important, because they will tell us something about
how much use this platform is seeing.  If it's been broken for 10+ years
and no users have noticed, then, well...

> Just remember that, whatever you should conclude, _there is no pretext
> on which to abandon support for Windows 98 to be had from this
> change_, or in the existing condition of NTEmacs.

Tempting as it is to propose that we abandon support for museum machines
(that should properly be running museum software), that's not my
intention here.  I'm merely trying to understand the state of Emacs as
it is now, and what we are planning to do.

At some point, we will abandon support for Windows 98 (and presumably
MS-DOS too) in modern Emacs.  Dropping such support will simplify
various parts of our codebase.  When that will happen is not really my
decision.  I think Eli is the one to say when we should pull the plug.

Re: scratch/windows-98 18e7a9f3d0c: Restore functionality on Windows 98

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 23 Jun 2024 06:36:58 -0700
> Cc: emacs-devel@gnu.org
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Stefan Kangas <stefankangas@gmail.com> writes:
> >
> >> In what state has the Windows 98 build been, and for how long?
> >
> > Please read last week's Windows 9X thread and the ChangeLog entry, where
> > all this was elaborated upon at great length.
> >
> > Thanks.
> 
> Thanks, I read that, but it didn't answer my questions.
> 
> Let me try to reformulate what I'm asking:
> - Is the Windows 98 build currently broken?

Yes.

> - How long has the Windows 98 build been broken?

Several months at least.

> These questions are important, because they will tell us something about
> how much use this platform is seeing.

Not much, but then the fixes are also quite simple.

> I think Eli is the one to say when we should pull the plug.

I say not yet, at least for Windows 9X.

Re: scratch/windows-98 18e7a9f3d0c: Restore functionality on Windows 98

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Thanks, I read that, but it didn't answer my questions.
>
> Let me try to reformulate what I'm asking:
> - Is the Windows 98 build currently broken?
> - How long has the Windows 98 build been broken?
>
> These questions are important, because they will tell us something about
> how much use this platform is seeing.  If it's been broken for 10+ years
> and no users have noticed, then, well...

All these questions are answered in that thread, as is the question why
many of these problems were not detected by other users of Windows 98.

> At some point, we will abandon support for Windows 98 (and presumably
> MS-DOS too) in modern Emacs.  

Over my dead body.  Supporting Windows 98 is a bare necessity, at least
so long as I must print documents with a government-registered printer
from time to time, and the MS-DOS port is an interesting technical
project, absent which Emacs development will be considerably more dull
than it is now.  Furthermore, it is today possible to run Emacs on an
up-to-date MS-DOS system that is 100% Free Software, as not only
FreeDOS, but the original MS-DOS, are or have apparently been released
under free licenses, and Emacs is capable of bootstrapping under at
least the former system.

What's more, the MS-DOS port was well and truly nonfunctional over
several non-contiguous periods lasting multiple years each, most
recently during the entire lifespan of Emacs 27.  Few users noticed and
fewer still reported this problem, and did it delay or impact Emacs
development one whit?  No.  Just as neither was Emacs's advancement on
GNU systems affected when yours truly resurrected the port for Emacs 28.

I propose to simply let the sleeping dogs lie, developers who are not
concerned with the MS-DOS port modify, change, refactor, and rearchitect
Emacs as they please, and we who have volunteered to devote parts of our
lives to the upkeep of this port discharge this responsibility at a pace
we ourselves find comfortable.  As was repeatedly demonstrated, no
burden is placed on any developer by code that appears to be disused and
which they are not obliged to maintain.

Re: scratch/windows-98 18e7a9f3d0c: Restore functionality on Windows 98

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Over my dead body.  Supporting Windows 98 is a bare necessity, at least
> so long as I must print documents with a government-registered printer
> from time to time, and the MS-DOS port is an interesting technical
> project, absent which Emacs development will be considerably more dull
> than it is now.  Furthermore, it is today possible to run Emacs on an
> up-to-date MS-DOS system that is 100% Free Software, as not only
> FreeDOS, but the original MS-DOS, are or have apparently been released
> under free licenses, and Emacs is capable of bootstrapping under at
> least the former system.

I understand that you feel strongly about this and enjoy working on it,
but if it's true that it's easy to maintain inside of Emacs, then it
should also be easy to maintain a FreeDOS/MS-DOS version of Emacs
externally, if it comes to that.

Since we aren't planning to make any changes, I guess we can leave it
there.

Re: scratch/windows-98 18e7a9f3d0c: Restore functionality on Windows 98

[Po Lu]

Reposting to the list, as I selected "Reply" rather than "Follow-up" by
accident.

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> I understand that you feel strongly about this and enjoy working on
>> it, but if it's true that it's easy to maintain inside of Emacs,
>> then
>> it should also be easy to maintain a FreeDOS/MS-DOS version of Emacs
>> externally, if it comes to that.
>
> Any external version (I read this as a euphemism for "fork") of Emacs
> will be denied the advantage of the existing infrastructure and
> recognition Emacs enjoys, and not only will this pall the special
> appeal of the port and impede its distribution, but also alienate the
> persons concerned with it, so that it is impossible to interpet a
> demand to separate its development from Emacs but as a deliberate
> expression of hostiliy to these developers.  If only for this reason,
> maintaining the DJGPP port externally is simply a non-starter.
>
> Not that I didn't state the practical aspects of this when the future
> of the Android port was in question.