Re: Pure space

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  pipcet@protonmail.com,
>   emacs-devel@gnu.org
> Date: Sat, 17 Aug 2024 21:36:38 +0800
> 
> >> > Portable dumping doesn't function on Windows 98 or DOS.  Please fix or
> >> > implement pdumper on these two platforms first, or hack their unexec
> >> > builds not to require pure space, which should not be terribly
> >> > difficult.
> >> 
> >> In my view, that's not a blocker for removing the unexec build.
> >
> > Agreed.
> 
> The Windows 98 build is: it has many users and it is in a satisfactory
> condition at present, so it would be a terrible regression.

Then the interested users and developers should come forward and help
us find and fix whatever causes the crashes.  I have not seen any such
users, with you being the single exception, for a long time.  If you
can get someone motivated to work with us on fixing pdumper.c on
Windows 9X, please do, and let's take it from there.  Such an effort
will at least be an investment in the future.

> It crashes 100% of the time, actually, not merely "too much", which I
> can't investigate without a functioning gdb, and which is very much
> against the spirit of the word "portable".  Unless one of you are
> willing to show me a GDB that is newer than Code::Blocks provides and
> which groks recent DWARF debug info, I don't forsee any solution.

There's such a thing as printf debugging.  It is far from ideal, but
it's doable.

> > If we want to keep the MSDOS port, the way forward is to switch it to
> > pdumper.  There's already an implementation in pdumper.c that uses
> > malloc and write instead of the missing mmap, it just was never tried
> > with the MSDOS port.  I don't see any reasons why it couldn't work.
> 
> Why can't unexecoff be retained without pure space?

Because Emacs never used this combination, and because no one has time
or knowhow to debug the MSDOS port anymore (which still uses COFF
debug info, which makes the job of finding a proper GDB even harder).
I might be the last person who can do that, and I don't have time to
do that seriously, when significant problems pop up.

> There's also no reason against this enormously simpler solution

It is simple source code wise, but it is not a solution, it is a
problem.  We never used Emacs that way, and I'm quite sure this will
trigger strange bugs that I don't want us to need to debug.

Keeping the MSDOS build alive means keeping it in good health.  While
the current code base has some significant number of years under its
belt (although that, too, becomes smaller and smaller as years go by
and more significant code changes are installed) the version without
pure space was never used before.