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.