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&gt; 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...