At 04:15 PM 2/22/00 , Kirill 'Big K' Katsnelson wrote:
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.
These are all good ideas, but I didn't do anything about that since I got
the impression that the algorithm for finding the dump file was in a state
of flux. Whatever comes out of that can easily be merged with what I did
if that's what people want.
>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.
Good point.
>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...
Replacing the dump data in the resource section isn't hard, as you say, but
if we look for the file first and then only look for the resource if the
file doesn't exist (or is the wrong version) then you can have it both
ways. Redump to a file if you want, but the separate dump file is not
required normally.
Also people shouldn't be concerned that we're doing something skanky or
which will cause problems later. The resource section in a binary file is
intended for precisely this sort of thing. Right now XEmacs doesn't put
much there, but other Windows apps have all sorts of things squirreled away
there.
Mike Alexander Arbortext, Inc.
mta(a)arbortext.com +1-734-327-6803