Re: Another try at portable dumping on Windows
Some time ago, Mike Alexander wrote...
I added code to sysdep.c (for now, until a better place is decided on)
that looks for the dump data first in a file called xemacs.dmp (in the same directory as
the .exe on Windows, in the current directory on Unix) and then
I think the same place as binary is good on Unix too.
in the resource section of the .exe. Doing things in this order means
that people can redump into a file and XEmacs will ignore the data in the resource
section. This should answer one of the objections for doing it this way.
I think that you should compare dates. Only if the dmp file is strictly
newer than the executable, and has its signature compatible with the
binary (when OG is done with the signatures) then we use it.
If it reads it from a file, it uses mmap if available on Unix and uses
CreateFileMapping on Windows. I think I did this in a way that will be compatible with
Win95 but someone will have to try this to be sure.
Memory mapped files work ok on Windows95. This is the main mechanism to
load executables into memory, so do not worry, they are debugged well.
One thing I wonder about is what sort of boundary alignment
requirement there is for the dumped data. If it mallocs space for it, it aligns it on a
256 byte boundary, but if I use the data directly out of the resource without copying it,
it only guaranteed a boundary of 8. Is this going to cause problems? I thought that
might be why it was crashing earlier, but when I changed this it didn't help, so that
wasn't the problem.
Olivier?
Some time ago, Jan Vroonhof wrote...
"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com>
writes:
> No. From the time you have xemacs.dmp, you just re-link xemacs.exe.
> Yes, you must keep all the object files.
Which is a big nono... One of the reasons I like pdump is that it
allows redumping. (On ELF platforms you can change a section of the
binary without a full relink. I thought you would be able to do the
same on windows).
Technically, it is possible, no doubt. The PE format aka COFF is
documented very well, as is Win32 defined resource format. The problem
is that we humans always seek easiest ways to achieve a result. The
MS evil empire created a biggest temptation for us: One can put a
binary chunk into an existing module resource section in 3 calls on
NT (open-put-close), but this API does not exist on Windows95. As
long as we seem to have fought this temptation, we are choosing the
next easiest way...
Big K