Ben Wing wrote:
 
 OK, it looks like your whole problem is due to low-memory warnings.  i see why
you're
 getting an infinite loop, and i can fix that; but i still don't know why you're
 getting low-memory warnings at all.  could you set a breakpoint at
 check_memory_limits and step through it and see what values you're getting for
 data_start, lim_data, cp, and warnlevel?
  
In check_memory_limits
+	cp	0x09250000 ""
	data_size	135245148
+	data_space_start	0x011552a4 "End of Emacs initialized data"
	warn_function	0x0101e4fc malloc_warning(const char *)
	warnlevel	0
	lim_data	116391936
The value of lim_data is bogus, and I spent some time looking why:
Looks like those variables that should have UNINIT_PTR values
unsigned char *data_region_base = UNINIT_PTR;
unsigned char *data_region_end = UNINIT_PTR;
unsigned char *real_data_region_end = UNINIT_PTR;
from ntheap.c have instead values like 
+	data_region_base	0x09100000 ""
+	data_region_end	0x0910c000 ""
+	real_data_region_end	0x0910c000 ""
when entering main().  Thus in ntheap.c, sbrk()
  if (data_region_base == UNINIT_PTR) 
condition is never true, and data_region_size is never initialized.
This looks like a compiler/linker bug to me, but almost too elementary
to be believable. Unfortunately I don't quickly see how to go around
that.  I quickly tried initializing those in the beginning of main, but
it crashed elsewhere.
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
Maybe you have a suggestion?  In the meanwhile I'll try to get the
latest Visual C++ service pack, just in case that it has a cure for
this.
Harri