Patch attached.<div><br></div><div>I guess I can explain the reason for all of it, albeit the solution I have taken may not be the easiest to maintain in the source tree.</div><div>Apparently the ANSI C spec says that bit fields are unsigned, and enum are signed, hence the patch in lisp.h for various bit fields.</div>

<div>Anyway, the MS compiler did extend sign and that was the main failure. Almost everything else is about linking with the right functions in msvcrt.</div><div><br></div><div>I have traced through the whole initialization process and I have not seen any interference between gmalloc.c and the msvcrt allocator. In fact I wonder if the gmalloc heap initialization has to occur that sooner. It seems to me that malloc()/gmalloc.c is called for the first time when sorting arguments from the command line, so quite late.</div>

<div><br></div><div>The &quot;-dynamicbase:no&quot; linker option is mandatory, else emacs is relocated at some different address in memory, and that makes it crash, especially because of some function pointers dumped into the exe. Hard to trace exactly, because the crash is always with a corrupt stack, albeit always in gmalloc.c or alloc.c. But the flag fixed the problem.</div>

<div><br></div><div>The portable dumper (once written for emacs 21 and avalaible in xemacs) would be a very good idea.</div><div><br></div><div>Best regards,</div><div><br></div><div>Fabrice<br><br></div>