Re: Pure space

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Sat, 17 Aug 2024 05:10:29 -0700
>> Cc: Eli Zaretskii <eliz@gnu.org>, Pip Cet <pipcet@protonmail.com>, emacs-devel@gnu.org
>> 
>> Po Lu <luangruo@yahoo.com> writes:
>> 
>> > 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.

>> We would take patches to fix MS-DOS and/or Windows 98, I think.
>
> On Windows 9X the pdumper build does work, it just crashes too much.
> So it sounds like some problem that could be fixed.

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.

> 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?  There's also no
reason against this enormously simpler solution, and the same is true of
the Solaris unexec, which is no more than 13 lines of trivial code.  You
need not concern yourself with them at all, while MS-DOS users receive a
new Emacs, and Solaris users, a binary that starts 110 ms faster, and
doesn't require juggling with dumper files whenever an installation or
its binaries are created or moved.