Windows 64 port

Windows 64 port

[AJMR]

Hi all,

I would love to start to contribute to the GNU community and I thought
that porting Emacs 23 to Windows 64, could be a good useful entry.

However, I have no idea on how to, or where, start. I read here[1] that
I could use this list for the topic.

I would appreciate if anyone could point me to a starting point.


Many thanks!



[1] http://ftp.gnu.org/pub/gnu/emacs/windows/

Re: Windows 64 port

[Eli Zaretskii]

> Date: Sun, 19 Feb 2012 21:18:00 +0100
> From: AJMR <ajmr@ilovetortilladepatatas.com>
> 
> I would love to start to contribute to the GNU community and I thought
> that porting Emacs 23 to Windows 64, could be a good useful entry.

Thanks, it will.

> However, I have no idea on how to, or where, start.

Start with bug #9960, where some of this was discussed.  Maybe Fabrice
could post the patches he has till now.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1.1: Type: text/plain, Size: 1322 bytes --]

Hi Eli,

Here is my Windows 64 bits patch. It is quite crude and only attempts to
make it possible to compile
a 64bits emacs with the MS Sdk.
I have sent the paperwork to the FSF last week, so this patch could be
reviewed and maybe integrated soon.
It is against emacs-24, current trunk.
Not everything is taken cared of: the heap allocation scheme should
probably be reworked. Anyway,
I was able to run an emacs and make it allocate everything available on my
Windows 64 machine
(4Gb of Ram + around 10Gb of swap). It just did it without crashing.

Best regards,

Fabrice


2012/2/19 Eli Zaretskii <eliz@gnu.org>

> > Date: Sun, 19 Feb 2012 21:18:00 +0100
> > From: AJMR <ajmr@ilovetortilladepatatas.com>
> >
> > I would love to start to contribute to the GNU community and I thought
> > that porting Emacs 23 to Windows 64, could be a good useful entry.
>
> Thanks, it will.
>
> > However, I have no idea on how to, or where, start.
>
> Start with bug #9960, where some of this was discussed.  Maybe Fabrice
> could post the patches he has till now.
>



-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #1.2: Type: text/html, Size: 1902 bytes --]

[-- Attachment #2: emacs-64bits.patch --]
[-- Type: application/octet-stream, Size: 36509 bytes --]

=== modified file 'lib/strftime.c'
--- lib/strftime.c	2011-03-31 04:24:03 +0000
+++ lib/strftime.c	2011-12-05 13:09:35 +0000
@@ -36,9 +36,13 @@
 #include <ctype.h>
 #include <time.h>
 
+#ifdef _MSC_VER
+#define tzname _tzname
+#else
 #if HAVE_TZNAME && !HAVE_DECL_TZNAME
 extern char *tzname[];
 #endif
+#endif
 
 /* Do multibyte processing if multibytes are supported, unless
    multibyte sequences are safe in formats.  Multibyte sequences are

=== modified file 'nt/addsection.c'
--- nt/addsection.c	2012-01-19 07:21:25 +0000
+++ nt/addsection.c	2012-02-05 20:06:34 +0000
@@ -36,9 +36,9 @@
 
 PIMAGE_NT_HEADERS
 (__stdcall * pfnCheckSumMappedFile) (LPVOID BaseAddress,
-				     DWORD FileLength,
-				     LPDWORD HeaderSum,
-				     LPDWORD CheckSum);
+				     DWORD_PTR FileLength,
+				     PDWORD_PTR HeaderSum,
+				     PDWORD_PTR CheckSum);
 
 #undef min
 #undef max
@@ -164,7 +164,7 @@
 /* Return pointer to section header for section containing the given
    relative virtual address. */
 IMAGE_SECTION_HEADER *
-rva_to_section (DWORD rva, IMAGE_NT_HEADERS * nt_header)
+rva_to_section (DWORD_PTR rva, IMAGE_NT_HEADERS * nt_header)
 {
   PIMAGE_SECTION_HEADER section;
   int i;
@@ -179,7 +179,7 @@
 	 some very old exes (eg. gzip dated Dec 1993).  Since
 	 w32_executable_type relies on this function to work reliably,
 	 we need to cope with this.  */
-      DWORD real_size = max (section->SizeOfRawData,
+      DWORD_PTR real_size = max (section->SizeOfRawData,
 			     section->Misc.VirtualSize);
       if (rva >= section->VirtualAddress
 	  && rva < section->VirtualAddress + real_size)
@@ -192,7 +192,7 @@
 /* Return pointer to section header for section containing the given
    offset in its raw data area. */
 IMAGE_SECTION_HEADER *
-offset_to_section (DWORD offset, IMAGE_NT_HEADERS * nt_header)
+offset_to_section (DWORD_PTR offset, IMAGE_NT_HEADERS * nt_header)
 {
   PIMAGE_SECTION_HEADER section;
   int i;
@@ -212,8 +212,8 @@
 /* Return offset to an object in dst, given offset in src.  We assume
    there is at least one section in both src and dst images, and that
    the some sections may have been added to dst (after sections in src).  */
-static DWORD
-relocate_offset (DWORD offset,
+static DWORD_PTR
+relocate_offset (DWORD_PTR offset,
 		 IMAGE_NT_HEADERS * src_nt_header,
 		 IMAGE_NT_HEADERS * dst_nt_header)
 {
@@ -247,32 +247,32 @@
 }
 
 #define OFFSET_TO_RVA(offset, section) \
-	  (section->VirtualAddress + ((DWORD)(offset) - section->PointerToRawData))
+	  (section->VirtualAddress + ((DWORD_PTR)(offset) - section->PointerToRawData))
 
 #define RVA_TO_OFFSET(rva, section) \
-	  (section->PointerToRawData + ((DWORD)(rva) - section->VirtualAddress))
+	  (section->PointerToRawData + ((DWORD_PTR)(rva) - section->VirtualAddress))
 
 #define RVA_TO_SECTION_OFFSET(rva, section) \
-	  ((DWORD)(rva) - section->VirtualAddress)
+	  ((DWORD_PTR)(rva) - section->VirtualAddress)
 
 /* Convert address in executing image to RVA.  */
-#define PTR_TO_RVA(ptr) ((DWORD)(ptr) - (DWORD) GetModuleHandle (NULL))
+#define PTR_TO_RVA(ptr) ((DWORD_PTR)(ptr) - (DWORD_PTR) GetModuleHandle (NULL))
 
 #define PTR_TO_OFFSET(ptr, pfile_data) \
           ((unsigned const char *)(ptr) - (pfile_data)->file_base)
 
 #define OFFSET_TO_PTR(offset, pfile_data) \
-          ((pfile_data)->file_base + (DWORD)(offset))
+          ((pfile_data)->file_base + (DWORD_PTR)(offset))
 
-#define ROUND_UP(p, align)   (((DWORD)(p) + (align)-1) & ~((align)-1))
-#define ROUND_DOWN(p, align) ((DWORD)(p) & ~((align)-1))
+#define ROUND_UP(p, align)   (((DWORD_PTR)(p) + (align)-1) & ~((align)-1))
+#define ROUND_DOWN(p, align) ((DWORD_PTR)(p) & ~((align)-1))
 
 
 static void
 copy_executable_and_add_section (file_data *p_infile,
 				 file_data *p_outfile,
 				 const char *new_section_name,
-				 DWORD new_section_size)
+				 DWORD_PTR new_section_size)
 {
   unsigned char *dst;
   PIMAGE_DOS_HEADER dos_header;
@@ -280,7 +280,7 @@
   PIMAGE_NT_HEADERS dst_nt_header;
   PIMAGE_SECTION_HEADER section;
   PIMAGE_SECTION_HEADER dst_section;
-  DWORD offset;
+  DWORD_PTR offset;
   int i;
   int be_verbose = GetEnvironmentVariable ("DEBUG_DUMP", NULL, 0) > 0;
 
@@ -324,10 +324,10 @@
   dst = (unsigned char *) p_outfile->file_base;
 
   COPY_CHUNK ("Copying DOS header...", dos_header,
-	      (DWORD) nt_header - (DWORD) dos_header, be_verbose);
+	      (DWORD_PTR) nt_header - (DWORD_PTR) dos_header, be_verbose);
   dst_nt_header = (PIMAGE_NT_HEADERS) dst;
   COPY_CHUNK ("Copying NT header...", nt_header,
-	      (DWORD) section - (DWORD) nt_header, be_verbose);
+	      (DWORD_PTR) section - (DWORD_PTR) nt_header, be_verbose);
   dst_section = (PIMAGE_SECTION_HEADER) dst;
   COPY_CHUNK ("Copying section table...", section,
 	      nt_header->FileHeader.NumberOfSections * sizeof (*section),
@@ -509,8 +509,8 @@
   /* Patch up header fields; profiler is picky about this. */
   {
     HANDLE hImagehelp = LoadLibrary ("imagehlp.dll");
-    DWORD  headersum;
-    DWORD  checksum;
+    DWORD_PTR  headersum;
+    DWORD_PTR  checksum;
 
     dos_header = (PIMAGE_DOS_HEADER) out_file.file_base;
     nt_header = (PIMAGE_NT_HEADERS) ((char *) dos_header + dos_header->e_lfanew);

=== modified file 'nt/config.nt'
--- nt/config.nt	2012-01-29 15:46:05 +0000
+++ nt/config.nt	2012-02-05 20:06:34 +0000
@@ -433,7 +433,11 @@
 
    See m/template.h for documentation on writing m/MACHINE.h files.  */
 #undef config_machfile
+#ifdef _WIN64
+#include "m/amdx86-64.h"
+#else
 #include "m/intel386.h"
+#endif
 
 /* Define `subprocesses' should be defined if you want to
    have code for asynchronous subprocesses

=== modified file 'nt/emacs.rc'
--- nt/emacs.rc	2012-02-09 07:48:22 +0000
+++ nt/emacs.rc	2012-02-05 20:06:34 +0000
@@ -1,6 +1,10 @@
 Emacs ICON   icons\emacs.ico
 32649 CURSOR icons\hand.cur
-1 24 "emacs.manifest"
+#ifdef WIN64
+1 24 "emacs-x64.manifest"
+#else
+1 24 "emacs-x86.manifest"
+#endif
 
 #ifndef VS_VERSION_INFO
 #define VS_VERSION_INFO 1

=== modified file 'nt/nmake.defs'
--- nt/nmake.defs	2012-02-05 20:40:36 +0000
+++ nt/nmake.defs	2012-02-19 21:54:33 +0000
@@ -86,7 +86,11 @@
 !    if "$(PROCESSOR_ARCHITECTURE)" == "PPC"
 ARCH		= ppc
 !    else
-!     error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
+!     if "$(PROCESSOR_ARCHITECTURE)" == "AMD64"
+ARCH		= AMD64
+!     else
+!      error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
+!     endif
 !    endif
 !   endif
 !  endif
@@ -105,11 +109,11 @@
 CC_OUT		= -Fo
 LINK		= link
 LINK_OUT	= -out:
-RC		= rc
+RC		= rc $(ARCH_RCFLAGS)
 RC_OUT		= -Fo
 RC_INCLUDE	= -i
 
-USE_CRT_DLL	= 1
+# USE_CRT_DLL	= 1
 
 !ifdef USE_CRT_DLL
 libc		= msvcrt$(D).lib
@@ -151,20 +155,17 @@
 !endif
 
 CFLAGS          = -I. $(ARCH_CFLAGS) \
+		  -D_CRT_SECURE_NO_WARNINGS \
 		  $(DEBUG_CFLAGS) $(CHECKING_CFLAGS) $(USER_CFLAGS) $(LOCAL_FLAGS)
 ESC_CFLAGS      = -I. $(ARCH_CFLAGS) \
+		  -D_CRT_SECURE_NO_WARNINGS \
 		  $(DEBUG_CFLAGS) $(CHECKING_CFLAGS) $(ESC_USER_CFLAGS) $(LOCAL_FLAGS)
 
 #SYS_LDFLAGS	= -nologo -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
-!ifdef NOOPT
-SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -debug -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
-!else
-SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
-!endif
+SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -incremental:no -version:5.10 -swaprun:cd -swaprun:net setargv.obj
 
 # see comments in allocate_heap in w32heap.c before changing any of the
-# -stack, -heap, or -base settings.
-TEMACS_EXTRA_LINK = -stack:0x00800000 -heap:0x00100000 -base:0x01000000 -pdb:$(BLD)\temacs.pdb -machine:$(ARCH) $(SUBSYSTEM_CONSOLE) -entry:_start -map:$(BLD)\temacs.map $(EXTRA_LINK)
+TEMACS_EXTRA_LINK = -stack:0x00800000 -heap:0x00100000 -base:0x01000000 -pdb:$(BLD)\temacs.pdb -machine:$(TARGET_CPU) $(SUBSYSTEM_CONSOLE) -entry:_start -map:$(BLD)\temacs.map $(EXTRA_LINK)
 
 !ifdef NOOPT
 OBJDIR          = obj
@@ -195,7 +196,7 @@
 
 !ifdef NODEBUG
 DEBUG_FLAG =
-DEBUG_LINK =
+DEBUG_LINK = -release
 D =
 !else
 DEBUG_FLAG = -Zi
@@ -233,15 +234,28 @@
 !else
 !if "$(ARCH)" == "ppc"
 # These flags are a guess...if they don't work, please send me mail.
-ARCH_CFLAGS	= -D_PPC_=1 -c -Ze -Zi -W2 -Od
 ARCH_LDFLAGS	= $(SYS_LDFLAGS)
 
 !else
+!if "$(ARCH)" == "AMD64"
+# These flags are a guess...if they don't work, please send me mail.
+!ifdef NOOPT
+#ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Od -G3d -Zp8 $(DEBUG_FLAG)
+ARCH_CFLAGS     = -nologo -D_AMD64_=1 -DWIN64 -D_WIN64 -DWIN32 -D_WIN32 -c -Zl -Zp8 -W2 -Od -Gd $(DEBUG_FLAG)
+!else
+#ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 $(DEBUG_FLAG)
+ARCH_CFLAGS     = -nologo -D_AMD64_=1 -DWIN64 -D_WIN64 -DWIN32 -D_WIN32 -c -Zl -Zp8 -W2 -Oi -Ot -Oy- -Ob2 -GF -Gy -Gd $(DEBUG_FLAG)
+!endif
+ARCH_LDFLAGS	= $(SYS_LDFLAGS) -machine:x64
+ARCH_RCFLAGS	= -DWIN64
+
+!else
 !ERROR Unknown architecture type "$(ARCH)".
 !endif
 !endif
 !endif
 !endif
+!endif
 
 LINK_FLAGS	= $(ARCH_LDFLAGS) $(DEBUG_LINK) $(USER_LDFLAGS)
 

=== modified file 'src/alloc.c'
--- src/alloc.c	2012-01-19 07:21:25 +0000
+++ src/alloc.c	2012-02-05 20:06:34 +0000
@@ -64,6 +64,7 @@
 
 #ifdef WINDOWSNT
 #include "w32.h"
+#include "w32heap.h"
 #endif
 
 #ifdef DOUG_LEA_MALLOC
@@ -1150,7 +1151,8 @@
 
   if (2 > (intptr_t) ABLOCKS_BUSY (abase))
     { /* All the blocks are free.  */
-      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
+      int i = 0;
+      intptr_t aligned = (intptr_t) ABLOCKS_BUSY (abase);
       struct ablock **tem = &free_ablock;
       struct ablock *atop = &abase->blocks[aligned ? ABLOCKS_SIZE : ABLOCKS_SIZE - 1];
 
@@ -2967,7 +2969,7 @@
 /* Allocate other vector-like structures.  */
 
 struct Lisp_Vector *
-allocate_pseudovector (int memlen, int lisplen, EMACS_INT tag)
+allocate_pseudovector (size_t memlen, size_t lisplen, EMACS_INT tag)
 {
   struct Lisp_Vector *v = allocate_vectorlike (memlen);
   int i;
@@ -5029,13 +5031,13 @@
 	    /* If a buffer's gap size is more than 10% of the buffer
 	       size, or larger than 2000 bytes, then shrink it
 	       accordingly.  Keep a minimum size of 20 bytes.  */
-	    int size = min (2000, max (20, (nextb->text->z_byte / 10)));
+	    size_t size = min (2000, max (20, (nextb->text->z_byte / 10)));
 
 	    if (nextb->text->gap_size > size)
 	      {
 		struct buffer *save_current = current_buffer;
 		current_buffer = nextb;
-		make_gap (-(nextb->text->gap_size - size));
+		make_gap ((size - nextb->text->gap_size));
 		current_buffer = save_current;
 	      }
 	  }

=== modified file 'src/dosfns.c'
--- src/dosfns.c	2012-01-19 07:21:25 +0000
+++ src/dosfns.c	2012-02-05 20:06:34 +0000
@@ -542,7 +542,7 @@
       double pmem;
       EXFUN (Fget_internal_run_time, 0);
 #ifndef SYSTEM_MALLOC
-      extern unsigned long ret_lim_data ();
+      extern size_t ret_lim_data ();
 #endif
 
       uid = getuid ();
@@ -579,7 +579,7 @@
 #ifndef SYSTEM_MALLOC
       /* ret_lim_data is on vm-limit.c, which is not compiled in under
 	 SYSTEM_MALLOC.  */
-      pmem = (double)((unsigned long) sbrk (0)) / ret_lim_data () * 100.0;
+      pmem = (double)((size_t) sbrk (0)) / ret_lim_data () * 100.0;
       if (pmem > 100)
 #endif
 	pmem = 100;

=== modified file 'src/editfns.c'
--- src/editfns.c	2012-01-19 07:21:25 +0000
+++ src/editfns.c	2012-02-05 20:06:34 +0000
@@ -82,6 +82,8 @@
 
 #ifdef WINDOWSNT
 extern Lisp_Object w32_get_internal_run_time (void);
+
+extern struct tm *localtime (const time_t *t);
 #endif
 
 static void time_overflow (void) NO_RETURN;

=== modified file 'src/eval.c'
--- src/eval.c	2012-02-15 04:00:34 +0000
+++ src/eval.c	2012-02-19 21:54:33 +0000
@@ -1408,7 +1408,7 @@
    rather than passed in a list.  Used by Fbyte_code.  */
 
 Lisp_Object
-internal_lisp_condition_case (volatile Lisp_Object var, Lisp_Object bodyform,
+internal_lisp_condition_case (/* volatile */ Lisp_Object var, Lisp_Object bodyform,
 			      Lisp_Object handlers)
 {
   Lisp_Object val;

=== modified file 'src/frame.c'
--- src/frame.c	2012-01-19 07:21:25 +0000
+++ src/frame.c	2012-02-05 20:06:34 +0000
@@ -812,6 +812,7 @@
 #ifdef HAVE_WINDOW_SYSTEM
   if (track && FRAME_WINDOW_P (XFRAME (frame)))
     {
+      extern Lisp_Object x_get_focus_frame(struct frame *);
       Lisp_Object focus, xfocus;
 
       xfocus = x_get_focus_frame (XFRAME (frame));

=== modified file 'src/gmalloc.c'
--- src/gmalloc.c	2011-09-09 01:06:52 +0000
+++ src/gmalloc.c	2011-12-05 14:55:54 +0000
@@ -56,6 +56,7 @@
 
 #endif	/* _MALLOC_INTERNAL.  */
 
+#include <w32heap.h>
 
 #ifdef	__cplusplus
 extern "C"
@@ -459,7 +460,7 @@
      __malloc_size_t size;
 {
   __ptr_t result;
-  unsigned long int adj;
+  intptr_t adj;
 
   /* align accepts an unsigned argument, but __morecore accepts a
      signed one.  This could lead to trouble if SIZE overflows a
@@ -469,8 +470,8 @@
     result = 0;
   else
     result = (*__morecore) (size);
-  adj = (unsigned long int) ((unsigned long int) ((char *) result -
-						  (char *) NULL)) % BLOCKSIZE;
+  adj = (intptr_t) (((char *) result -
+                     (char *) NULL)) % BLOCKSIZE;
   if (adj != 0)
     {
       __ptr_t new;
@@ -539,7 +540,7 @@
   _heapinfo[block].busy.info.size = blocks;
   /* Leave back-pointers for malloc_find_address.  */
   while (--blocks > 0)
-    _heapinfo[block + blocks].busy.info.size = -blocks;
+    _heapinfo[block + blocks].busy.info.size = -((__malloc_ptrdiff_t)blocks);
 }
 
 #ifdef USE_PTHREAD
@@ -715,7 +716,7 @@
  	  /* Did it fail?  */
  	  if (newinfo == NULL)
  	    {
- 	      (*__morecore) (-size);
+ 	      (*__morecore) (-((__malloc_ptrdiff_t)size));
  	      return NULL;
  	    }
 
@@ -727,7 +728,7 @@
  	    break;
 
  	  /* Must try again.  First give back most of what we just got.  */
- 	  (*__morecore) (- newsize * sizeof (malloc_info));
+ 	  (*__morecore) (- ((ptrdiff_t)newsize * sizeof (malloc_info)));
  	  newsize *= 2;
   	}
 
@@ -809,8 +810,8 @@
 	    next->next->prev = next->prev;
 	  block = BLOCK (result);
 	  if (--_heapinfo[block].busy.info.frag.nfree != 0)
-	    _heapinfo[block].busy.info.frag.first = (unsigned long int)
-	      ((unsigned long int) ((char *) next->next - (char *) NULL)
+	    _heapinfo[block].busy.info.frag.first = (intptr_t)
+	      (((char *) next->next - (char *) NULL)
 	       % BLOCKSIZE) >> log;
 
 	  /* Update the statistics.  */
@@ -951,7 +952,7 @@
 	 first with a negative number so you can find the first block by
 	 adding that adjustment.  */
       while (--blocks > 0)
-	_heapinfo[block + blocks].busy.info.size = -blocks;
+	_heapinfo[block + blocks].busy.info.size = -((ptrdiff_t)blocks);
     }
 
   PROTECT_MALLOC_STATE (1);
@@ -1224,7 +1225,7 @@
 	    {
 	      register __malloc_size_t bytes = blocks * BLOCKSIZE;
 	      _heaplimit -= blocks;
-	      (*__morecore) (-bytes);
+	      (*__morecore) (-((__malloc_ptrdiff_t)bytes));
 	      _heapinfo[_heapinfo[block].free.prev].free.next
 		= _heapinfo[block].free.next;
 	      _heapinfo[_heapinfo[block].free.next].free.prev
@@ -1295,8 +1296,8 @@
 	     it is the first free fragment of this block. */
 	  prev = (struct list *) ptr;
 	  _heapinfo[block].busy.info.frag.nfree = 1;
-	  _heapinfo[block].busy.info.frag.first = (unsigned long int)
-	    ((unsigned long int) ((char *) ptr - (char *) NULL)
+	  _heapinfo[block].busy.info.frag.first = (intptr_t)
+	    ((intptr_t) ((char *) ptr - (char *) NULL)
 	     % BLOCKSIZE >> type);
 	  prev->next = _fraghead[type].next;
 	  prev->prev = &_fraghead[type];
@@ -1689,7 +1690,7 @@
      __malloc_size_t size;
 {
   __ptr_t result;
-  unsigned long int adj, lastadj;
+  intptr_t adj, lastadj;
   __ptr_t (*hook) (__malloc_size_t, __malloc_size_t) = __memalign_hook;
 
   if (hook)
@@ -1703,7 +1704,7 @@
 
   /* Figure out how much we will need to pad this particular block
      to achieve the required alignment.  */
-  adj = (unsigned long int) ((char *) result - (char *) NULL) % alignment;
+  adj = (intptr_t) ((char *) result - (char *) NULL) % alignment;
 
   do
     {
@@ -1714,7 +1715,7 @@
 	return NULL;
 
       lastadj = adj;
-      adj = (unsigned long int) ((char *) result - (char *) NULL) % alignment;
+      adj = (intptr_t) ((char *) result - (char *) NULL) % alignment;
       /* It's conceivable we might have been so unlucky as to get a
 	 different block with weaker alignment.  If so, this block is too
 	 short to contain SIZE after alignment correction.  So we must
@@ -1904,7 +1905,7 @@
 struct hdr
   {
     __malloc_size_t size;		/* Exact size requested by user.  */
-    unsigned long int magic;	/* Magic number to check header integrity.  */
+    uint64_t magic;	/* Magic number to check header integrity.  */
   };
 
 static enum mcheck_status checkhdr (const struct hdr *);

=== modified file 'src/lisp.h'
--- src/lisp.h	2012-01-19 07:21:25 +0000
+++ src/lisp.h	2012-02-05 20:06:34 +0000
@@ -483,7 +483,7 @@
 /* For integers known to be positive, XFASTINT provides fast retrieval
    and XSETFASTINT provides fast storage.  This takes advantage of the
    fact that Lisp_Int is 0.  */
-#define XFASTINT(a) ((a) + 0)
+#define XFASTINT(a) ((int)((a) + 0))
 #define XSETFASTINT(a, b) ((a) = (b))
 
 /* Extract the value of a Lisp_Object as a (un)signed integer.  */
@@ -2811,7 +2811,7 @@
 EXFUN (Fmake_bool_vector, 2);
 extern Lisp_Object Qchar_table_extra_slots;
 extern struct Lisp_Vector *allocate_vector (EMACS_INT);
-extern struct Lisp_Vector *allocate_pseudovector (int memlen, int lisplen, EMACS_INT tag);
+extern struct Lisp_Vector *allocate_pseudovector (size_t memlen, size_t lisplen, EMACS_INT tag);
 #define ALLOCATE_PSEUDOVECTOR(typ,field,tag)				\
   ((typ*)								\
    allocate_pseudovector						\

=== modified file 'src/m/amdx86-64.h'
--- src/m/amdx86-64.h	2012-01-19 07:21:25 +0000
+++ src/m/amdx86-64.h	2012-02-05 20:06:34 +0000
@@ -17,7 +17,8 @@
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 
-#define BITS_PER_LONG           64
+#define BITS_PER_LONG           32
+#define BITS_PER_LONG_LONG      64
 #define BITS_PER_EMACS_INT      64
 
 /* Now define a symbol for the cpu type, if your compiler
@@ -27,9 +28,11 @@
 /* __x86_64 defined automatically.  */
 
 /* Define the type to use.  */
-#define EMACS_INT               long
-#define pI			"l"
-#define EMACS_UINT              unsigned long
+#define EMACS_INT               __int64
+#define EMACS_UINT              unsigned __int64
+#define pI			"ll"
+#define VIRT_ADDR_VARIES
+#define DATA_START 	get_data_start ()
 
 /* Define XPNTR to avoid or'ing with DATA_SEG_BITS */
 #undef DATA_SEG_BITS

=== modified file 'src/makefile.w32-in'
--- src/makefile.w32-in	2012-01-19 07:21:25 +0000
+++ src/makefile.w32-in	2012-02-05 20:06:34 +0000
@@ -25,7 +25,7 @@
 EMACSLOADPATH=$(CURDIR)/../lisp
 
 # Size in MBs of the static heap in temacs.exe.
-HEAPSIZE = 27
+HEAPSIZE = 42
 
 #
 # HAVE_CONFIG_H is required by some generic gnu sources stuck into

=== modified file 'src/ralloc.c'
--- src/ralloc.c	2012-02-01 16:51:20 +0000
+++ src/ralloc.c	2012-02-05 20:06:34 +0000
@@ -24,6 +24,10 @@
 
 #ifdef emacs
 
+#define WIN32_LEAN_AND_MEAN
+#include <windows.h>
+#define SIZE ESIZE
+
 #include <config.h>
 #include <setjmp.h>
 #include "lisp.h"		/* Needed for VALBITS.  */
@@ -76,7 +80,7 @@
 /* Declarations for working with the malloc, ralloc, and system breaks.  */
 
 /* Function to set the real break value.  */
-POINTER (*real_morecore) (long int);
+POINTER (*real_morecore) (intptr_t);
 
 /* The break value, as seen by malloc.  */
 static POINTER virtual_break_value;
@@ -95,20 +99,20 @@
 /* Macros for rounding.  Note that rounding to any value is possible
    by changing the definition of PAGE.  */
 #define PAGE (getpagesize ())
-#define ALIGNED(addr) (((unsigned long int) (addr) & (page_size - 1)) == 0)
-#define ROUNDUP(size) (((unsigned long int) (size) + page_size - 1) \
+#define ALIGNED(addr) (((intptr_t) (addr) & (page_size - 1)) == 0)
+#define ROUNDUP(size) (((intptr_t) (size) + page_size - 1) \
 		       & ~(page_size - 1))
 #define ROUND_TO_PAGE(addr) (addr & (~(page_size - 1)))
 
 #define MEM_ALIGN sizeof (double)
-#define MEM_ROUNDUP(addr) (((unsigned long int)(addr) + MEM_ALIGN - 1) \
+#define MEM_ROUNDUP(addr) (((intptr_t)(addr) + MEM_ALIGN - 1) \
 				   & ~(MEM_ALIGN - 1))
 
 /* The hook `malloc' uses for the function which gets more space
    from the system.  */
 
 #ifndef SYSTEM_MALLOC
-extern POINTER (*__morecore) (long int);
+extern POINTER (*__morecore) (intptr_t);
 #endif
 
 
@@ -315,7 +319,7 @@
 relinquish (void)
 {
   register heap_ptr h;
-  long excess = 0;
+  ptrdiff_t excess = 0;
 
   /* Add the amount of space beyond break_value
      in all heaps which have extend beyond break_value at all.  */
@@ -370,7 +374,7 @@
 /* Return the total size in use by relocating allocator,
    above where malloc gets space.  */
 
-long
+intptr_t
 r_alloc_size_in_use (void)
 {
   return (char *) break_value - (char *) virtual_break_value;
@@ -749,7 +753,7 @@
    GNU malloc package.  */
 
 POINTER
-r_alloc_sbrk (long int size)
+r_alloc_sbrk (ptrdiff_t size)
 {
   register bloc_ptr b;
   POINTER address;
@@ -1020,7 +1024,7 @@
    malloc must return a null pointer.  */
 
 void
-r_alloc_freeze (long int size)
+r_alloc_freeze (intptr_t size)
 {
   if (! r_alloc_initialized)
     r_alloc_init ();

=== modified file 'src/s/ms-w32.h'
--- src/s/ms-w32.h	2012-01-19 07:21:25 +0000
+++ src/s/ms-w32.h	2012-02-05 20:06:34 +0000
@@ -281,13 +281,14 @@
 #define utimbuf	  _utimbuf
 #endif
 #define strdup    _strdup
+#define strtoll   _strtoi64
 #define strupr    _strupr
 #define strnicmp  _strnicmp
 #define stricmp   _stricmp
 #define tzset     _tzset
 
+#if !defined (_MSC_VER) /* || (_MSC_VER < 1400) */
 #define tzname    _tzname
-#if !defined (_MSC_VER) || (_MSC_VER < 1400)
 #undef  utime
 #define utime	  _utime
 #endif

=== modified file 'src/unexw32.c'
--- src/unexw32.c	2012-01-19 07:21:25 +0000
+++ src/unexw32.c	2012-02-05 20:06:34 +0000
@@ -67,18 +67,18 @@
 /* Cached info about the .data section in the executable.  */
 PIMAGE_SECTION_HEADER data_section;
 PCHAR  data_start = 0;
-DWORD  data_size = 0;
+DWORD_PTR  data_size = 0;
 
 /* Cached info about the .bss section in the executable.  */
 PIMAGE_SECTION_HEADER bss_section;
 PCHAR  bss_start = 0;
-DWORD  bss_size = 0;
-DWORD  extra_bss_size = 0;
+DWORD_PTR  bss_size = 0;
+DWORD_PTR  extra_bss_size = 0;
 /* bss data that is static might be discontiguous from non-static.  */
 PIMAGE_SECTION_HEADER bss_section_static;
 PCHAR  bss_start_static = 0;
-DWORD  bss_size_static = 0;
-DWORD  extra_bss_size_static = 0;
+DWORD_PTR  bss_size_static = 0;
+DWORD_PTR  extra_bss_size_static = 0;
 
 PIMAGE_SECTION_HEADER heap_section;
 
@@ -231,7 +231,7 @@
 /* Return pointer to section header for section containing the given
    relative virtual address. */
 IMAGE_SECTION_HEADER *
-rva_to_section (DWORD rva, IMAGE_NT_HEADERS * nt_header)
+rva_to_section (DWORD_PTR rva, IMAGE_NT_HEADERS * nt_header)
 {
   PIMAGE_SECTION_HEADER section;
   int i;
@@ -246,7 +246,7 @@
 	 some very old exes (eg. gzip dated Dec 1993).  Since
 	 w32_executable_type relies on this function to work reliably,
 	 we need to cope with this.  */
-      DWORD real_size = max (section->SizeOfRawData,
+      DWORD_PTR real_size = max (section->SizeOfRawData,
 			     section->Misc.VirtualSize);
       if (rva >= section->VirtualAddress
 	  && rva < section->VirtualAddress + real_size)
@@ -259,7 +259,7 @@
 /* Return pointer to section header for section containing the given
    offset in its raw data area. */
 IMAGE_SECTION_HEADER *
-offset_to_section (DWORD offset, IMAGE_NT_HEADERS * nt_header)
+offset_to_section (DWORD_PTR offset, IMAGE_NT_HEADERS * nt_header)
 {
   PIMAGE_SECTION_HEADER section;
   int i;
@@ -279,8 +279,8 @@
 /* Return offset to an object in dst, given offset in src.  We assume
    there is at least one section in both src and dst images, and that
    the some sections may have been added to dst (after sections in src).  */
-DWORD
-relocate_offset (DWORD offset,
+DWORD_PTR
+relocate_offset (DWORD_PTR offset,
 		 IMAGE_NT_HEADERS * src_nt_header,
 		 IMAGE_NT_HEADERS * dst_nt_header)
 {
@@ -314,16 +314,16 @@
 }
 
 #define OFFSET_TO_RVA(offset, section) \
-	  (section->VirtualAddress + ((DWORD)(offset) - section->PointerToRawData))
+	  (section->VirtualAddress + ((DWORD_PTR)(offset) - section->PointerToRawData))
 
 #define RVA_TO_OFFSET(rva, section) \
-	  (section->PointerToRawData + ((DWORD)(rva) - section->VirtualAddress))
+	  (section->PointerToRawData + ((DWORD_PTR)(rva) - section->VirtualAddress))
 
 #define RVA_TO_SECTION_OFFSET(rva, section) \
-	  ((DWORD)(rva) - section->VirtualAddress)
+	  ((DWORD_PTR)(rva) - section->VirtualAddress)
 
 /* Convert address in executing image to RVA.  */
-#define PTR_TO_RVA(ptr) ((DWORD)(ptr) - (DWORD) GetModuleHandle (NULL))
+#define PTR_TO_RVA(ptr) ((DWORD_PTR)(ptr) - (DWORD_PTR) GetModuleHandle (NULL))
 
 #define RVA_TO_PTR(var,section,filedata) \
 	  ((void *)(RVA_TO_OFFSET (var,section) + (filedata).file_base))
@@ -332,7 +332,7 @@
           ((unsigned char *)(ptr) - (pfile_data)->file_base)
 
 #define OFFSET_TO_PTR(offset, pfile_data) \
-          ((pfile_data)->file_base + (DWORD)(offset))
+          ((pfile_data)->file_base + (DWORD_PTR)(offset))
 
 
 /* Flip through the executable and cache the info necessary for dumping.  */
@@ -349,7 +349,7 @@
       printf ("Unknown EXE header in %s...bailing.\n", p_infile->name);
       exit (1);
     }
-  nt_header = (PIMAGE_NT_HEADERS) (((unsigned long) dos_header) +
+  nt_header = (PIMAGE_NT_HEADERS) (((DWORD_PTR) dos_header) +
 				   dos_header->e_lfanew);
   if (nt_header == NULL)
     {
@@ -488,7 +488,7 @@
   PIMAGE_NT_HEADERS dst_nt_header;
   PIMAGE_SECTION_HEADER section;
   PIMAGE_SECTION_HEADER dst_section;
-  DWORD offset;
+  DWORD_PTR offset;
   int i;
   int be_verbose = GetEnvironmentVariable ("DEBUG_DUMP", NULL, 0) > 0;
 
@@ -541,17 +541,17 @@
      Note that dst is updated implicitly by each COPY_CHUNK.  */
 
   dos_header = (PIMAGE_DOS_HEADER) p_infile->file_base;
-  nt_header = (PIMAGE_NT_HEADERS) (((unsigned long) dos_header) +
+  nt_header = (PIMAGE_NT_HEADERS) (((DWORD_PTR) dos_header) +
 				   dos_header->e_lfanew);
   section = IMAGE_FIRST_SECTION (nt_header);
 
   dst = (unsigned char *) p_outfile->file_base;
 
   COPY_CHUNK ("Copying DOS header...", dos_header,
-	      (DWORD) nt_header - (DWORD) dos_header, be_verbose);
+	      (DWORD_PTR) nt_header - (DWORD_PTR) dos_header, be_verbose);
   dst_nt_header = (PIMAGE_NT_HEADERS) dst;
   COPY_CHUNK ("Copying NT header...", nt_header,
-	      (DWORD) section - (DWORD) nt_header, be_verbose);
+	      (DWORD_PTR) section - (DWORD_PTR) nt_header, be_verbose);
   dst_section = (PIMAGE_SECTION_HEADER) dst;
   COPY_CHUNK ("Copying section table...", section,
 	      nt_header->FileHeader.NumberOfSections * sizeof (*section),
@@ -627,8 +627,8 @@
 	}
       if (section == heap_section)
 	{
-	  DWORD heap_start = (DWORD) get_heap_start ();
-	  DWORD heap_size = get_committed_heap_size ();
+	  DWORD_PTR heap_start = (DWORD_PTR) get_heap_start ();
+	  DWORD_PTR heap_size = get_committed_heap_size ();
 
 	  /* Dump the used portion of the predump heap, adjusting the
              section's size to the appropriate size.  */

=== modified file 'src/vm-limit.c'
--- src/vm-limit.c	2012-01-19 07:21:25 +0000
+++ src/vm-limit.c	2012-02-05 20:06:34 +0000
@@ -20,7 +20,7 @@
 #include <setjmp.h>
 #include "lisp.h"
 #include "mem-limits.h"
-
+#include "w32heap.h"
 /*
   Level number of warnings already issued.
   0 -- no warnings issued.
@@ -41,7 +41,7 @@
 static POINTER data_space_start;
 
 /* Number of bytes of writable memory we can expect to be able to get.  */
-static unsigned long lim_data;
+static size_t lim_data;
 \f
 
 #if defined (HAVE_GETRLIMIT) && defined (RLIMIT_AS)
@@ -79,7 +79,7 @@
     lim_data = ULIMIT_BREAK_VALUE;
 #endif
 
-  lim_data -= (long) data_space_start;
+  lim_data -= (intptr_t) data_space_start;
 }
 
 #else /* not USG */
@@ -88,7 +88,7 @@
 static void
 get_lim_data (void)
 {
-  extern unsigned long reserved_heap_size;
+  extern size_t reserved_heap_size;
   lim_data = reserved_heap_size;
 }
 
@@ -127,7 +127,7 @@
     lim_data = 512U * 1024U * 1024U;
 }
 
-unsigned long
+size_t
 ret_lim_data (void)
 {
   get_lim_data ();
@@ -166,13 +166,13 @@
 check_memory_limits (void)
 {
 #ifdef REL_ALLOC
-  extern POINTER (*real_morecore) (long);
+  extern POINTER (*real_morecore) (__malloc_ptrdiff_t);
 #endif
-  extern POINTER (*__morecore) (long);
+  extern POINTER (*__morecore) (__malloc_ptrdiff_t);
 
   register POINTER cp;
-  unsigned long five_percent;
-  unsigned long data_size;
+  size_t five_percent;
+  size_t data_size;
   enum warnlevel new_warnlevel;
 
   if (lim_data == 0)

=== modified file 'src/w32.c'
--- src/w32.c	2012-02-04 13:48:38 +0000
+++ src/w32.c	2012-02-05 20:06:34 +0000
@@ -1703,7 +1703,8 @@
       /* FIXME: should use substring of get_emacs_configuration ().
 	 But I don't think the Windows build supports alpha, mips etc
          anymore, so have taken the easy option for now.  */
-      else if (p && xstrcasecmp (p, "\\i386") == 0)
+      else if (p && (xstrcasecmp (p, "\\i386") == 0
+                     || xstrcasecmp (p, "\\AMD64") == 0))
 	{
 	  *p = 0;
 	  p = strrchr (modname, '\\');
@@ -1861,7 +1862,12 @@
     case PROCESSOR_INTEL_386:
     case PROCESSOR_INTEL_486:
     case PROCESSOR_INTEL_PENTIUM:
+    case PROCESSOR_AMD_X8664:
+#ifdef _WIN64
+      arch = "amd64";
+#else
       arch = "i386";
+#endif
       break;
 #endif
 
@@ -2400,7 +2406,7 @@
 	return NULL;
     }
 
-  if (!(dirp = (DIR *) malloc (sizeof (DIR))))
+  if (!(dirp = (DIR *) xmalloc (sizeof (DIR))))
     return NULL;
 
   dirp->dd_fd = 0;

=== modified file 'src/w32heap.c'
--- src/w32heap.c	2012-01-19 07:21:25 +0000
+++ src/w32heap.c	2012-02-05 20:06:34 +0000
@@ -27,7 +27,7 @@
 #include "w32heap.h"
 #include "lisp.h"  /* for VALMASK */
 
-#define RVA_TO_PTR(rva) ((unsigned char *)((DWORD)(rva) + (DWORD)GetModuleHandle (NULL)))
+#define RVA_TO_PTR(rva) ((unsigned char *)((DWORD_PTR)(rva) + (DWORD_PTR)GetModuleHandle (NULL)))
 
 /* This gives us the page size and the size of the allocation unit on NT.  */
 SYSTEM_INFO sysinfo_cache;
@@ -98,7 +98,7 @@
 unsigned char *data_region_base = NULL;
 unsigned char *data_region_end = NULL;
 unsigned char *real_data_region_end = NULL;
-unsigned long  reserved_heap_size = 0;
+size_t  reserved_heap_size = 0;
 
 /* The start of the data segment.  */
 unsigned char *
@@ -122,11 +122,11 @@
      the preload heap section up to the usable address limit.  Since GNU
      malloc can handle gaps in the memory it gets from sbrk, we can
      simply set the sbrk pointer to the base of the new heap region.  */
-  unsigned long base =
+  DWORD_PTR base =
     ROUND_UP ((RVA_TO_PTR (preload_heap_section->VirtualAddress)
 	       + preload_heap_section->Misc.VirtualSize),
 	      get_allocation_unit ());
-  unsigned long end  = 1 << VALBITS; /* 256MB */
+  DWORD_PTR end  = 1 << VALBITS; /* 256MB */
   void *ptr = NULL;
 
   while (!ptr && (base < end))
@@ -145,7 +145,11 @@
 static char *
 allocate_heap (void)
 {
-  unsigned long size = 0x80000000; /* start by asking for 2GB */
+#ifdef _WIN64
+  size_t size = 0x800000000i64; /* start by asking for 32GB */
+#else
+  size_t size = 0x80000000; /* start by asking for 2GB */
+#endif
   void *ptr = NULL;
 
   while (!ptr && size > 0x00100000)
@@ -167,17 +171,17 @@
    be the address of the _start_ (not end) of the new block in case of
    success, and zero (not -1) in case of failure.  */
 void *
-sbrk (unsigned long increment)
+sbrk (size_t increment)
 {
   void *result;
-  long size = (long) increment;
+  ptrdiff_t size = (ptrdiff_t)increment;
 
   result = data_region_end;
 
   /* If size is negative, shrink the heap by decommitting pages.  */
   if (size < 0)
     {
-      int new_size;
+      ptrdiff_t new_size;
       unsigned char *new_data_region_end;
 
       size = -size;
@@ -190,7 +194,7 @@
 	 partial deallocation [cga].  */
       new_data_region_end = (data_region_end - size);
       new_data_region_end = (unsigned char *)
-	((long) (new_data_region_end + syspage_mask) & ~syspage_mask);
+	((DWORD_PTR) (new_data_region_end + syspage_mask) & ~syspage_mask);
       new_size = real_data_region_end - new_data_region_end;
       real_data_region_end = new_data_region_end;
       if (new_size > 0)
@@ -221,7 +225,7 @@
       /* We really only commit full pages, so record where
 	 the real end of committed memory is [cga].  */
       real_data_region_end = (unsigned char *)
-	  ((long) (data_region_end + syspage_mask) & ~syspage_mask);
+	  ((DWORD_PTR) (data_region_end + syspage_mask) & ~syspage_mask);
     }
 
   return result;
@@ -246,7 +250,7 @@
   PIMAGE_NT_HEADERS nt_header;
 
   dos_header = (PIMAGE_DOS_HEADER) RVA_TO_PTR (0);
-  nt_header = (PIMAGE_NT_HEADERS) (((unsigned long) dos_header) +
+  nt_header = (PIMAGE_NT_HEADERS) (((DWORD_PTR) dos_header) +
 				   dos_header->e_lfanew);
   preload_heap_section = find_section ("EMHEAP", nt_header);
 
@@ -262,7 +266,7 @@
 #if !defined (USE_LISP_UNION_TYPE) && !defined (USE_LSB_TAG)
       /* Ensure that the addresses don't use the upper tag bits since
 	 the Lisp type goes there.  */
-      if (((unsigned long) data_region_base & ~VALMASK) != 0)
+      if (((DWORD_PTR) data_region_base & ~VALMASK) != 0)
 	{
 	  printf ("Error: The heap was allocated in upper memory.\n");
 	  exit (1);
@@ -285,13 +289,13 @@
 
 /* Round the heap up to the given alignment.  */
 void
-round_heap (unsigned long align)
+round_heap (DWORD_PTR align)
 {
-  unsigned long needs_to_be;
-  unsigned long need_to_alloc;
+  DWORD_PTR needs_to_be;
+  DWORD_PTR need_to_alloc;
 
-  needs_to_be = (unsigned long) ROUND_UP (get_heap_end (), align);
-  need_to_alloc = needs_to_be - (unsigned long) get_heap_end ();
+  needs_to_be = (DWORD_PTR) ROUND_UP (get_heap_end (), align);
+  need_to_alloc = needs_to_be - (DWORD_PTR) get_heap_end ();
 
   if (need_to_alloc)
     sbrk (need_to_alloc);

=== modified file 'src/w32heap.h'
--- src/w32heap.h	2012-01-19 07:21:25 +0000
+++ src/w32heap.h	2012-02-05 20:06:34 +0000
@@ -24,8 +24,8 @@
 
 #include <windows.h>
 
-#define ROUND_UP(p, align)   (((DWORD)(p) + (align)-1) & ~((align)-1))
-#define ROUND_DOWN(p, align) ((DWORD)(p) & ~((align)-1))
+#define ROUND_UP(p, align)   (((DWORD_PTR)(p) + (align)-1) & ~((align)-1))
+#define ROUND_DOWN(p, align) ((DWORD_PTR)(p) & ~((align)-1))
 
 /*
  * Heap related stuff.
@@ -42,7 +42,7 @@
 
 extern unsigned char *get_data_start (void);
 extern unsigned char *get_data_end (void);
-extern unsigned long  reserved_heap_size;
+extern size_t         reserved_heap_size;
 extern SYSTEM_INFO    sysinfo_cache;
 extern OSVERSIONINFO  osinfo_cache;
 extern BOOL   	      using_dynamic_heap;
@@ -58,13 +58,13 @@
 extern int os_subtype;
 
 /* Emulation of Unix sbrk().  */
-extern void *sbrk (unsigned long size);
+extern void *sbrk (size_t size);
 
 /* Initialize heap structures for sbrk on startup.  */
 extern void init_heap (void);
 
 /* Round the heap to this size.  */
-extern void round_heap (unsigned long size);
+extern void round_heap (size_t size);
 
 /* Cache system info, e.g., the NT page size.  */
 extern void cache_system_info (void);
@@ -89,7 +89,7 @@
 
 /* Return pointer to section header for section containing the given
    relative virtual address. */
-IMAGE_SECTION_HEADER * rva_to_section (DWORD rva, IMAGE_NT_HEADERS * nt_header);
+IMAGE_SECTION_HEADER * rva_to_section (DWORD_PTR rva, IMAGE_NT_HEADERS * nt_header);
 
 #endif /* NTHEAP_H_ */
 

=== modified file 'src/w32proc.c'
--- src/w32proc.c	2012-01-19 07:21:25 +0000
+++ src/w32proc.c	2012-02-05 20:06:34 +0000
@@ -63,7 +63,7 @@
 
 #define RVA_TO_PTR(var,section,filedata) \
   ((void *)((section)->PointerToRawData					\
-	    + ((DWORD)(var) - (section)->VirtualAddress)		\
+	    + ((DWORD_PTR)(var) - (section)->VirtualAddress)		\
 	    + (filedata).file_base))
 
 Lisp_Object Qhigh, Qlow;
@@ -111,7 +111,7 @@
 child_process child_procs[ MAX_CHILDREN ];
 child_process *dead_child = NULL;
 
-static DWORD WINAPI reader_thread (void *arg);
+static DWORD_PTR WINAPI reader_thread (void *arg);
 
 /* Find an unused process slot.  */
 child_process *


[-- Attachment #3: amdx86-64.h --]
[-- Type: text/x-chdr, Size: 1366 bytes --]

/* machine description file for AMD x86-64.

Copyright (C) 2002-2012  Free Software Foundation, Inc.

This file is part of GNU Emacs.

GNU Emacs is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */

#define BITS_PER_LONG           32
#define BITS_PER_LONG_LONG      64
#define BITS_PER_EMACS_INT      64

/* Now define a symbol for the cpu type, if your compiler
   does not define it automatically:
   Ones defined so far include vax, m68000, ns16000, pyramid,
   orion, tahoe, APOLLO and many others */
/* __x86_64 defined automatically.  */

/* Define the type to use.  */
#define EMACS_INT               __int64
#define EMACS_UINT              unsigned __int64
#define pI			"ll"
#define VIRT_ADDR_VARIES
#define DATA_START 	get_data_start ()

/* Define XPNTR to avoid or'ing with DATA_SEG_BITS */
#undef DATA_SEG_BITS

Re: Windows 64 port

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Sun, 19 Feb 2012 23:05:52 +0100
> Cc: AJMR <ajmr@ilovetortilladepatatas.com>, emacs-devel@gnu.org
> 
> Here is my Windows 64 bits patch. It is quite crude and only
> attempts to make it possible to compile a 64bits emacs with the MS
> Sdk.

Thanks.

> I have sent the paperwork to the FSF last week, so this patch could be
> reviewed and maybe integrated soon.

Thanks.  We will need to wait until the v24 release branch is cut,
though.

Re: Windows 64 port

[Paul Eggert]

I took a quick look, found several problems, and thought
I'd write one or two down before I forgot them....

The patch is too intrusive to the mainline code
and many of its changes should be omitted.
Generally speaking it's OK (for portability to future
POSIX hosts) to replace 'long' with 'ptrdiff_t' or 'ssize_t'
or 'intptr_t' when appropriate, and to replace 'unsigned long'
with 'size_t' or 'uintptr_t' as appropriate, but other
type replacements are dubious and should generally be omitted.
For example:

-      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
+      int i = 0;
+      intptr_t aligned = (intptr_t) ABLOCKS_BUSY (abase);

Here, the value of 'aligned' is either 0 or 1, so there's
no need to change its type.

The changes to src/m/amdx86-64.h would break GNU/Linux and
need to be backed out and redone.

This mishandles Emacs integers outside the signed 32-bit range:

-#define XFASTINT(a) ((a) + 0)
+#define XFASTINT(a) ((int)((a) + 0))

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

>
> with 'size_t' or 'uintptr_t' as appropriate, but other
> type replacements are dubious and should generally be omitted.
>

I don't think so. Windows and Linux does not follow the same 64 bits rules
(LLP64 vs LP64).


> For example:
>
> -      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
> +      int i = 0;
> +      intptr_t aligned = (intptr_t) ABLOCKS_BUSY (abase);
>

Here, the value of 'aligned' is either 0 or 1, so there's
> no need to change its type.
>

It is kinf of strange to cast to intptr_t to store the result in a variable
of different type ?



> The changes to src/m/amdx86-64.h would break GNU/Linux and
> need to be backed out and redone.
>

This mishandles Emacs integers outside the signed 32-bit range:
>
> -#define XFASTINT(a) ((a) + 0)
> +#define XFASTINT(a) ((int)((a) + 0))
>

I'll look into these ones.

-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 1687 bytes --]

Re: Windows 64 port

[Paul Eggert]

On 02/20/2012 11:20 AM, Fabrice Popineau wrote:
> Windows and Linux does not follow the same 64 bits rules (LLP64 vs LP64).

Yes, and that was why I suggested the heuristic that I suggested.

The Emacs code is currently quite portable to standard GNU hosts,
which are LP64 or ILP32 or ILP32LL64.  If code portable to these
hosts uses 'int', there should be no need to change the 'int' to
'intptr_t', because such a change would already be needed for the
LP64 port.  Most of your patch's changes to the mainline sources
were of this nature, and should therefore be omitted.  The only
changes actually needed for porting to an IL32LLP64 host should be
the relatively small number of changes that I mentioned in my
previous message.

>     -      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
>     +      int i = 0;
>     +      intptr_t aligned = (intptr_t) ABLOCKS_BUSY (abase);
>      
>     Here, the value of 'aligned' is either 0 or 1, so there's
>     no need to change its type.
> 
> It is kind of strange to cast to intptr_t to store the result
> in a variable of different type ?

The cast to intptr_t (instead of to int) is to avoid GCC warnings
about casting a pointer to an integer of a different size.  Using
intptr_t is helpful, because these warnings are typically useful
and in the rare cases where they're not (such as here) it's
helpful to insert a cast so that GCC does not cry wolf.

In contrast, there is no need to declare 'aligned' to be wider
than 'int'.  Generally the Emacs source code uses 'int' for random
integers that are guaranteed to fit in int range, which is the
case here, so we should leave the 'int' alone.

This is just one example, but I hope you get the general idea:
please minimize the changes made to the mainline source code.
Ideally any changes for Windows 64 would be only to the
Windows-specific part of the code, so that we don't need to worry
about its effect on GNU hosts.  In practice we can't always
achieve this ideal, but nevertheless it's important to minimize
the changes to mainline code, as this saves everybody's time.

Re: Windows 64 port

[Eli Zaretskii]

> Date: Mon, 20 Feb 2012 12:43:34 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, AJMR <ajmr@ilovetortilladepatatas.com>, 
>  emacs-devel@gnu.org
> 
> Ideally any changes for Windows 64 would be only to the
> Windows-specific part of the code, so that we don't need to worry
> about its effect on GNU hosts.

gmalloc.c and ralloc.c must be exceptions from this rule, for obvious
reasons.  (Though the 64-bit Windows build probably is, or will be,
the only 64-bit platform to use these two.)

I'd also take a very good look at all the EMACS_UINT uses, and a few
`long's and `unsigned long's in regex.c.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

I'll check this patch again before the end of the week since we don't seem
to be in a hurry.

All I can say for sure is that in several places the compiler (not gcc, but
msvc)
inserted sign extent instructions. I tracked them down to mismatches
between ints and intptr_t
or ptrdiff_t. I fixed them by removing all compiler warnings of this kind.
I also had to convert all DWORD uses for adresses to DWORD_PTR (MS
recommended
way of dealing with 32/64 bits).

For the record and to make sure everyone is aware of it, compiling with
msvc for x64, you get :

C:\Temp>long
short 2
int 4
long 4
long long 8
void* 8

The only difference with x86 is the size of the pointer which is 4 bytes
(obviously).

Regards,

Fabrice


2012/2/20 Eli Zaretskii <eliz@gnu.org>

> > Date: Mon, 20 Feb 2012 12:43:34 -0800
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > CC: Eli Zaretskii <eliz@gnu.org>, AJMR <ajmr@ilovetortilladepatatas.com
> >,
> >  emacs-devel@gnu.org
> >
> > Ideally any changes for Windows 64 would be only to the
> > Windows-specific part of the code, so that we don't need to worry
> > about its effect on GNU hosts.
>
> gmalloc.c and ralloc.c must be exceptions from this rule, for obvious
> reasons.  (Though the 64-bit Windows build probably is, or will be,
> the only 64-bit platform to use these two.)
>
> I'd also take a very good look at all the EMACS_UINT uses, and a few
> `long's and `unsigned long's in regex.c.
>



-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #2: Type: text/html, Size: 2592 bytes --]

Re: Windows 64 port

[Paul Eggert]

On 02/20/2012 03:11 PM, Fabrice Popineau wrote:
> in several places the compiler (not gcc, but msvc) inserted sign
> extent instructions.  I tracked them down to mismatches between
> ints and intptr_t or ptrdiff_t. I fixed them by removing all
> compiler warnings of this kind.

OK, but we need to worry only about code that is actually wrong
unless the types are changed.  Extending an int to a long long is
not a bug by itself, and most likely won't even lead to a bug
since it cannot lose information, so most likely there's no need
to worry about inserted sign-extend instructions.  Even converting
a long long to an int is not necessarily a bug: it's a problem
only if the actual value at run-time does not fit in int range.

In short, we need not worry about size mismatches in general; only
mismatches that cause real problems.  In this context an MSVC
warning by itself does not count as a real problem.

Re: Windows 64 port

[Stefan Monnier]

> It is kinf of strange to cast to intptr_t to store the result in a variable
> of different type ?

It deserves a comment, indeed.


        Stefan

Re: Windows 64 port

[Paul Eggert]

On 02/21/2012 05:22 AM, Stefan Monnier wrote:
> It deserves a comment, indeed.

There is a comment earlier in the code, next to the declaration
of 'abase'.  It would help, I think, to encapsulate the ABLOCKS_BUSY
stuff better into new macros, that handle casting to intptr_t or
whatever, and which state the actual ranges of the results.
All this should wait until after 24.1 of course.

Re: Windows 64 port

[Richard Stallman]

    I don't think so. Windows and Linux does not follow the same 64 bits rules
    (LLP64 vs LP64).

Windows is a system, but Linux is a kernel.  Do you mean the GNU/Linux
system?  I don't think these conventions come from Linux at all;
they come from GCC, GNU libc, etc.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Windows 64 port

[Eli Zaretskii]

> Date: Wed, 22 Feb 2012 05:39:17 -0500
> From: Richard Stallman <rms@gnu.org>
> CC: eggert@cs.ucla.edu, eliz@gnu.org, ajmr@ilovetortilladepatatas.com,
> 	emacs-devel@gnu.org
> 
>     I don't think so. Windows and Linux does not follow the same 64 bits rules
>     (LLP64 vs LP64).
> 
> Windows is a system, but Linux is a kernel.  Do you mean the GNU/Linux
> system?

No, he means the ABI supported by the development environment.

Re: Windows 64 port

[Richard Stallman]

    > Windows is a system, but Linux is a kernel.  Do you mean the GNU/Linux
    > system?

    No, he means the ABI supported by the development environment.

The ABI of the GNU/Linux system comes from GNU libc, not from Linux.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Windows 64 port

[Aurélien]

Richard Stallman <rms@gnu.org> writes:

>     > Windows is a system, but Linux is a kernel.  Do you mean the GNU/Linux
>     > system?
>
>     No, he means the ABI supported by the development environment.
>
> The ABI of the GNU/Linux system comes from GNU libc, not from Linux.
<#secure method=pgpmime mode=sign>

The story is horribly simple ... and the reality turn it too complex
side, here is the fact why people which do not use and try to go a bit
more far in GNU / Linux just not understand the true of the situation.

Wikipedia example ::

Search GNU -> first you fall on the beast ... on disanbiguation you have
lot of choice and GNU :: http://en.wikipedia.org/wiki/GNU

Search GNU / Linux it bring you on a page which title Linux and describe
it as an operating system :: http://en.wikipedia.org/wiki/GNU_Linux

As i ask #wikipedia on irc.freenode.net ok so if it is an operating
system, where is the iso? at this time they search ...

But they don't correct the title and the article ... so imagine, most of
people coming from windows and apple which try to have some information
about what they know ... most of time Linux, they just rarely, for
"best" of them find the true.

Neuro marketing victims ... maybe but not only.

At this time, in front the true, wikipedia have not correct the article,
and have not correct the title.


-- 
Aurelien - Animateur P@m-Sarte
http://libreplanet.org/wiki/User:Aurelien
Free Software & Zen Minimalism Hactivist
Fight for your freedom rights! Join FSF.org
Fully Free Operating System at GNU.org


      	   	     	    (   )
			     ° °
			      ·

Re: Windows 64 port

[Lennart Borgman]

On Thu, Feb 23, 2012 at 20:16, Aurélien <gnu.tek@gmx.com> wrote:
>
> As i ask #wikipedia on irc.freenode.net ok so if it is an operating
> system, where is the iso? at this time they search ...
>
> But they don't correct the title and the article ... so imagine, most of
> people coming from windows and apple which try to have some information
> about what they know ... most of time Linux, they just rarely, for
> "best" of them find the true.
>
> Neuro marketing victims ... maybe but not only.
>
> At this time, in front the true, wikipedia have not correct the article,
> and have not correct the title.

Please go to the article in Wikipedia and discuss it there. I think
that is the way to get it corrected.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

>
> But they don't correct the title and the article ... so imagine, most of
> people coming from windows and apple which try to have some information
> about what they know ... most of time Linux, they just rarely, for
> "best" of them find the true.
>

Speaking for myself, I have contributed in the early days of Linux (0.98)
to various distribs and sent patches to
several parts of them (except the kernel). Most of these (small) patches
were to GNU Software. Just to say that I know
the difference between the kernel and the rest of the packages and were
they come  from. But take it for language
lazyness / failure to impose a brand / penalty for success ... all people
around me (students, colleagues in France)
use "Linux" for the GNU/Linux system. (On the other hand they would
possibly say that Linux is FSF sofware.)

(No offense intended!)

Best regards,

-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #2: Type: text/html, Size: 1513 bytes --]

Re: Windows 64 port

[Aurélien]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

>     But they don't correct the title and the article ... so imagine, most of
>     people coming from windows and apple which try to have some information
>     about what they know ... most of time Linux, they just rarely, for
>     "best" of them find the true.
>
> Speaking for myself, I have contributed in the early days of Linux (0.98) to various distribs and sent patches to 
> several parts of them (except the kernel). Most of these (small) patches were to GNU Software. Just to say that I know
> the difference between the kernel and the rest of the packages and were they come  from. But take it for language
> lazyness / failure to impose a brand / penalty for success ... all people around me (students, colleagues in France)
> use "Linux" for the GNU/Linux system. (On the other hand they would possibly say that Linux is FSF sofware.)
>
> (No offense intended!)
>
> Best regards,
>
> --
> Fabrice Popineau
> -----------------------------
> SUPELEC
> Département Informatique
> 3, rue Joliot Curie
> 91192 Gif/Yvette Cedex
> Tel direct : +33 (0) 169851950
> Standard : +33 (0) 169851212
> ------------------------------
>
<#secure method=pgpmime mode=sign>

There is no offense, but, i will get the time to bring you back into
reality, i live in Corsica, not far from you, have made most of my study
in France.

Last time i have works for the French Educationnal System, most of
teacher just not know the word GNU. It is not because of the fact of
public school but just the fact they are the first victim of the
politics. (and our childrens just after)

For private school, it "seems" to goes better, but from what i saw after
12 hour of speach with a student from supinfo et does not know about
what really GNU / Linux is and just never heard of GNU / Linux-libre and
the distro corresponding. (but he was very please to put on the table
lot of crappy trademark technology.)

The fact is that when the "super supinfo" student see GNU Emacs out of X
and the fact that video is possible, he O_O and understand that it's own
"superschool" and "supteach" make them missed a serious point.

I am not offensed, by you, but my country, for the time they make me
loose during my own studies, because of obscurantism and offense today
for my childrens which have to pay the price of idiocraty.

Please don't tell me that people in France know about FSF, i have spread
about the FSF existance in Corsica from 2 years, and just before that,
no one have ever hear about that.

So no i am not offense by you, but no, i will not anymore loose my time with
"superwin&app" thinkers.

A guy have wrote one day "Free Software, Free Society", please get time
to think and spread about that, for my point, i go back in silent, and
try to upgrade my mind with GNU Emacs.

Thanks to the Dr ;-D


P.S.: for wikipedia, at this time, with that sort of people, (Don't
forget that behind the CIA there is the "skull & bones") i prefer the
silent too. But i will say what i think of what they are doing is so
lazy, that here is someone which have already respond to them :: 
"You get more easely things with a gun and a smile than just a smile"
--Al Capone 

-- 
Aurelien - Animateur P@m-Sarte
http://libreplanet.org/wiki/User:Aurelien
Free Software & Zen Minimalism Hactivist
Fight for your freedom rights! Join FSF.org
Fully Free Operating System at GNU.org


      	   	     	    (   )
			     ° °
			      ·

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

>
> The patch is too intrusive to the mainline code
> and many of its changes should be omitted.
>

I maintain my point of view. Most of my patch is to ensure that 32bits and
64bits values are not mixed up,
and that unsigned and signed values aren't either. Maybe some of it can be
omitted, that doesn't mean one day
or another they won't be missed.

>
> -      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
> +      int i = 0;
> +      intptr_t aligned = (intptr_t) ABLOCKS_BUSY (abase);
>
> Here, the value of 'aligned' is either 0 or 1, so there's
> no need to change its type.
>

Then

int aligned = (ABLOCKS_BUSY(abase) != NULL);

would have been cleaner.

The changes to src/m/amdx86-64.h would break GNU/Linux and
> need to be backed out and redone.


Obviously, they need to be made dependent on the target platform.
(Done in the patch to come).


> This mishandles Emacs integers outside the signed 32-bit range:
>
> -#define XFASTINT(a) ((a) + 0)
> +#define XFASTINT(a) ((int)((a) + 0))
>

Oops. Sorry for this one. It was a leftover.

There is something wrong around lib/strftime.c:946
          if (negative_number)
            u_number_value = - u_number_value;

u_number_value being unsigned, this is wrong. I haven't look for a proper
fix.

In src/dispnew.c:6402, height and width should probably be unsigned. The
checking by
INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral
constant overflow
because it tries to compute (INTMIN - 2) which obviously is out of range.
The value is not used in this case, but the compiler may emit the warning
anyway.

Best regards,

-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 2589 bytes --]

Re: Windows 64 port

[Paul Eggert]

On 02/28/2012 01:00 PM, Fabrice Popineau wrote:

> int aligned = (ABLOCKS_BUSY(abase) != NULL);
> 
> would have been cleaner.

Perhaps, but it'd also be a bit slower, and at any rate
this should be a separate patch, since the change
is independent of the Windows 64 port.  Any Windows 64
patch should be limited to issues that are actually
needed for a Windows 64 port.

> There is something wrong around lib/strftime.c:946
>           if (negative_number)
>             u_number_value = - u_number_value;
> 
> u_number_value being unsigned, this is wrong.

I don't see anything wrong there.  The value of
-X is well-defined if X is unsigned int; it's
equivalent to ~X + 1.  Can you supply a test case
illustrating the actual bug?

Please bear in mind that the code is already
tested to LP64 hosts.  Any bug related to this
particular code would also be a bug on LP64 hosts,
no?  So, it's not likely that any bug here is specific
to Windows 64.  If there is a bug, it should be
describable and fixable independently of Windows 64.

> In src/dispnew.c:6402, height and width should probably be unsigned. The
> checking by
> INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral
> constant overflow
> because it tries to compute (INTMIN - 2) which obviously is out of range.
> The value is not used in this case, but the compiler may emit the warning
> anyway.

We don't need to modify the mainline Emacs code in order to
pacify third-party compilers that issue incorrect warnings.
We can safely ignore these warnings and leave the code alone.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]

>
>
> > There is something wrong around lib/strftime.c:946
> >           if (negative_number)
> >             u_number_value = - u_number_value;
> >
> > u_number_value being unsigned, this is wrong.
>
> I don't see anything wrong there.  The value of
> -X is well-defined if X is unsigned int; it's
> equivalent to ~X + 1.  Can you supply a test case
> illustrating the actual bug?
>
>
When my compiler issues a warning like :

unsigned.c
unsigned.c(3) : warning C4146: unary minus operator applied to unsigned
type, result still unsigned

I tend to care about it. If it is on purpose, then I'm ok with it albeit I
would have prefered something less error prone
(I mean human interpretation error :-) )


>  > In src/dispnew.c:6402, height and width should probably be unsigned. The
> > checking by
> > INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral
> > constant overflow
> > because it tries to compute (INTMIN - 2) which obviously is out of range.
> > The value is not used in this case, but the compiler may emit the warning
> > anyway.
>
> We don't need to modify the mainline Emacs code in order to
> pacify third-party compilers that issue incorrect warnings.
> We can safely ignore these warnings and leave the code alone.
>

My past experience with stuff like pdftex (many years !)
is that compiling with a completely different
compiler may reveal useful to find errors in already tested source code.
The cleaner, the safer.

I don't know to which extent the FSF wants to support compilation of emacs
x64 (but that applies to x86 too) with the MS tools (even if they are
freely available).
I did it because I'm using it this way, but that should be doable with
MINGW x64 (or so I guess).
With the MS tools, emacs does not compile out of the box. There are errors.
There are also lots of warnings and when something does not work, I try to
remove warnings first.
All in all,  at least for the record, it may help people who would need an
emacs/x64/windows this way.

Best regards,

Fabrice

[-- Attachment #2: Type: text/html, Size: 2763 bytes --]

Re: Windows 64 port

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Tue, 28 Feb 2012 23:39:46 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, AJMR <ajmr@ilovetortilladepatatas.com>, emacs-devel@gnu.org
> 
> > > There is something wrong around lib/strftime.c:946
> > >           if (negative_number)
> > >             u_number_value = - u_number_value;
> > >
> > > u_number_value being unsigned, this is wrong.
> >
> > I don't see anything wrong there.  The value of
> > -X is well-defined if X is unsigned int; it's
> > equivalent to ~X + 1.  Can you supply a test case
> > illustrating the actual bug?
> >
> >
> When my compiler issues a warning like :
> 
> unsigned.c
> unsigned.c(3) : warning C4146: unary minus operator applied to unsigned
> type, result still unsigned
> 
> I tend to care about it. If it is on purpose, then I'm ok with it albeit I
> would have prefered something less error prone
> (I mean human interpretation error :-) )

I agree that such confusing code, even if it does its job correctly,
is bad for maintainability.  At the very least, it warrants a comment
explaining why things are done that way.  Rewriting it not to negate
unsigned values with arithmetic operations would be even better.

> I did it because I'm using it this way, but that should be doable with
> MINGW x64 (or so I guess).
> With the MS tools, emacs does not compile out of the box. There are errors.
> There are also lots of warnings and when something does not work, I try to
> remove warnings first.

Please go on, I have no doubt that resolving these issues will make
the code cleaner and clearer, and of course will also help the MinGW64
build when the time comes.

> All in all,  at least for the record, it may help people who would need an
> emacs/x64/windows this way.

Right.  Thanks.

Re: Windows 64 port

[Paul Eggert]

On 02/29/2012 10:08 AM, Eli Zaretskii wrote:
> I agree that such confusing code, even if it does its job correctly,
> is bad for maintainability.

This particular code is fairly clear when you look
at the code's context (and it's also clear that there's no bug
that the patch would fix).  Any patch that adds a comment should
take that context into account.  Also, since this code is imported
from gnulib the patch should be sent to bug-gnulib.

Re: Windows 64 port

[Eli Zaretskii]

> Date: Tue, 28 Feb 2012 14:09:03 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, AJMR <ajmr@ilovetortilladepatatas.com>, 
>  emacs-devel@gnu.org
> 
> > In src/dispnew.c:6402, height and width should probably be unsigned. The
> > checking by
> > INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral
> > constant overflow
> > because it tries to compute (INTMIN - 2) which obviously is out of range.
> > The value is not used in this case, but the compiler may emit the warning
> > anyway.
> 
> We don't need to modify the mainline Emacs code in order to
> pacify third-party compilers that issue incorrect warnings.

What is incorrect about that warning?  Did Fabrice describe the issue
incorrectly?  If so, would you mind explaining where his reasoning
about the validity of INT_MIN - 2 was wrong?

> We can safely ignore these warnings and leave the code alone.

We don't need to, but we might consider that anyway.  If some
compiler tells us something valuable about the code, we
need not ignore it just because it's "third-party".  My experience is
similar to that of Fabrice: compiling a program with several different
compilers helps find more problematic, unclean, and unsafe code.  I'm
quite sure I saw this advice in some textbooks.

Re: Windows 64 port

[Paul Eggert]

>> We don't need to modify the mainline Emacs code in order to
>> pacify third-party compilers that issue incorrect warnings.
> 
> What is incorrect about that warning?

As Fabrice explained, the warning is about code that is never executed
on his platform, because it's inside a conditional that is always
false, and so the bug cannot possibly occur.

The conditional itself is a constant, and decent compiler
will optimize away the code in question.  The conditional is present
precisely to avoid the overflow that the compiler is mistakenly warning
about.  There is no easy way to rewrite the code that will both
pacify the broken compiler and keep the code modular and portable.

Cases like these are an an easy call: leave the code alone and
ignore the bogus warning.  If possible, pass a flag to the compiler
telling it not to issue bogus warnings like that.  Or get the
compiler bug fixed.  Whatever.

> If some compiler tells us something valuable about the code, we
> need not ignore it just because it's "third-party".

True, but it appears that many of the fixes in his patch are to
pacify warnings like the above.  That is, it appears that a class
of warnings are often bogus and do not correspond to real bugs.
This is an easy call: leave the code alone.

Re: Windows 64 port

[Eli Zaretskii]

> Date: Wed, 29 Feb 2012 11:43:28 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: fabrice.popineau@supelec.fr, ajmr@ilovetortilladepatatas.com, 
>  emacs-devel@gnu.org
> 
> >> We don't need to modify the mainline Emacs code in order to
> >> pacify third-party compilers that issue incorrect warnings.
> > 
> > What is incorrect about that warning?
> 
> As Fabrice explained, the warning is about code that is never executed
> on his platform, because it's inside a conditional that is always
> false, and so the bug cannot possibly occur.
> 
> The conditional itself is a constant, and decent compiler
> will optimize away the code in question.  The conditional is present
> precisely to avoid the overflow that the compiler is mistakenly warning
> about.  There is no easy way to rewrite the code that will both
> pacify the broken compiler and keep the code modular and portable.

Thanks for explaining this.

> > If some compiler tells us something valuable about the code, we
> > need not ignore it just because it's "third-party".
> 
> True, but it appears that many of the fixes in his patch are to
> pacify warnings like the above.

Which ones are those?  I see many changes that qualify existing
declarations with `const', which cannot possibly be wrong.  I also see
replacements of `unsigned long' with a `size_t', which cannot be
wrong, either.  Using ptrdiff_t instead of long or some such is
required for LLP64 platforms.  Most of the rest is in Windows-specific
files.

So which fixes are for the bogus warnings?

Re: Windows 64 port

[Paul Eggert]

On 02/29/2012 01:24 PM, Eli Zaretskii wrote:
> I see many changes that qualify existing
> declarations with `const', which cannot possibly be wrong.

It's not an issue of whether the patch is *wrong*.
It's whether the patch is *needed*.  I can think of
hundreds of places where I could put 'const' into the
Emacs code, without breaking Emacs.  But these changes
are irrelevant to the Windows 64 port, and we should
consider these changes independently of the Windows 64
changes.

It's a significant alteration to the Emacs internal
programming style to use "const" when possible
(instead of when it's required), and any such
change should be considered on its own merits.
I happen to prefer "const" myself, but I realize that
many folks consider it to be unnecessary verbiage,
and we shouldn't introduce "const" under the argument
that it's needed for Windows 64 when in fact it's
not needed for that.

> I also see
> replacements of `unsigned long' with a `size_t', which cannot be
> wrong, either.

Same thing.  Some of those replacements are needed for Windows
64, but many (most?) are not.  I addressed this point in more
detail in my previous message that I sent out a few minutes ago.

Re: Windows 64 port

[Eli Zaretskii]

> Date: Wed, 29 Feb 2012 19:34:37 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: fabrice.popineau@supelec.fr, emacs-devel@gnu.org,
> 	ajmr@ilovetortilladepatatas.com
> 
> On 02/29/2012 01:24 PM, Eli Zaretskii wrote:
> > I see many changes that qualify existing
> > declarations with `const', which cannot possibly be wrong.
> 
> It's not an issue of whether the patch is *wrong*.
> It's whether the patch is *needed*.

That's not what you originally claimed.  You said many changes are to
pacify the Microsoft compiler's bogus warnings.  There's nothing bogus
about using the right data type or declare a variable or an argument
`const' when it is.

I agree that these changes should go in a separate commit.  But then I
asked several times to do the same for texinfo.tex when you sync with
gnulib, and you declined.  So I guess Fabrice is not the only one who
does that...

Re: Windows 64 port

[Paul Eggert]

On 02/29/2012 08:03 PM, Eli Zaretskii wrote:
> There's nothing bogus about using the right data type

But the code in question is already using a correct data type.
That is, for the diffs marked "Not needed for Windows 64" in
<http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00762.html>,
Emacs is already using data types that work,
both on mainstream platforms and on Windows 64.

>  or declare a variable or an argument `const' when it is.

Suppose someone proposed lots of patches like this:
                                          
-  size_t len = strlen (string);                                                
+  size_t const len = strlen (string);

on the grounds that the XYZ Corp. compiler warns whenever
code fails to use 'const' at every opportunity.
That would be bogus -- that's not the Emacs
programming style, and we shouldn't slavishly alter
mainstream code merely to pacify a third-party compiler
that prefers a different style.

> I asked several times to do the same for texinfo.tex when you sync with
> gnulib, and you declined.

Those patches were automatically merged from an already-debugged
and well-modularized upstream, and it's trivial to see which parts
affect texinfo.tex.

In contrast, here we're dealing with a handwritten patch that is
tickling core Emacs internals in tricky, low-level ways, a patch that
almost surely still contains bugs, partly because it is trying to do
too much at once.  It's entirely appropriate to spend more time with
such a patch, to see which parts are really needed for Windows 64, and
to isolate the changes as much as possible to the Windows-specific
code base.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

>
> Suppose someone proposed lots of patches like this:
>
> -  size_t len = strlen (string);
> +  size_t const len = strlen (string);
>
> on the grounds that the XYZ Corp. compiler warns whenever
> code fails to use 'const' at every opportunity.
> That would be bogus -- that's not the Emacs
> programming style, and we shouldn't slavishly alter
> mainstream code merely to pacify a third-party compiler
> that prefers a different style.
>
>
The const fixes I proposed are easily isolated: they affect only the
src/regex.c file.
You are free to submit it or to forget about it.
In this file, const is used in a few places only, resulting in dozens of
warnings. Either
remove the use of const or use it everywhere it is needed.
There is always the option to #define const to nothing, but I won't favor
it.

Fabrice

[-- Attachment #2: Type: text/html, Size: 1131 bytes --]

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

About this code / suggested patch :


> In src/dispnew.c:6402, height and width should probably be unsigned. The
> checking by
> INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral
> constant overflow
> because it tries to compute (INTMIN - 2) which obviously is out of range.
> The value is not used in this case, but the compiler may emit the warning
> anyway.

You wrote :

We don't need to modify the mainline Emacs code in order to
pacify third-party compilers that issue incorrect warnings.
We can safely ignore these warnings and leave the code alone.

And next :

2012/2/29 Paul Eggert <eggert@cs.ucla.edu>

> >> We don't need to modify the mainline Emacs code in order to
> >> pacify third-party compilers that issue incorrect warnings.
> >
> > What is incorrect about that warning?
>
> As Fabrice explained, the warning is about code that is never executed
> on his platform, because it's inside a conditional that is always
> false, and so the bug cannot possibly occur.
>
> The conditional itself is a constant, and decent compiler
> will optimize away the code in question.  The conditional is present
> precisely to avoid the overflow that the compiler is mistakenly warning
> about.  There is no easy way to rewrite the code that will both
> pacify the broken compiler and keep the code modular and portable.
>
> Cases like these are an an easy call: leave the code alone and
> ignore the bogus warning.  If possible, pass a flag to the compiler
> telling it not to issue bogus warnings like that.  Or get the
> compiler bug fixed.  Whatever.


The constant is generated by the preprocessor.
So it is not a compiler bug but a good catch from the compiler.
Luckily, the code is not executed. Given the rather deep stack
of macros, if it were executed without any warning, it would be
difficult to catch by hand.

-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 2503 bytes --]

Re: Windows 64 port

[Paul Eggert]

On 03/22/2012 10:31 AM, Fabrice Popineau wrote:
> The constant is generated by the preprocessor.
> So it is not a compiler bug but a good catch from the compiler.
> Luckily, the code is not executed. Given the rather deep stack
> of macros, if it were executed without any warning, it would be
> difficult to catch by hand.

The code cannot possibly be executed, so it's not a good
catch by the compiler.  Here's a simpler example:

  #define Z 0
  #define FOO (Z == 0 ? INT_MAX : 1000 / Z)
  int i = FOO;

Here, the compiler should not complain about division by zero,
even though the constant is generated by the preprocessor,
because FOO's body is designed to divide by Z only when
Z is nonzero, and the expression 1000 / Z cannot possibly be
executed when Z is zero.  Of course compilers are free to generate
warnings whenever they like, and some will indeed warn about this
example if you enable the right flags, but this warning is harmful
and not helpful: it should be ignored and the code should not be
changed and you're better off simply disabling the compiler warning.

The situation with the INT_RANGE_OVERFLOW check is similar, except
there the macro is more like this:

  #define a 2147483647
  #define b 1
  #define FOO (INT_ADD_OVERFLOW (a,b) ? INT_MAX : (a)+(b))
  int i = FOO;

Again, any compiler that warns about potential overflow of
2147483647+1 should be ignored, because the expression
2147483647+1 cannot possibly be evaluated.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

>
> The situation with the INT_RANGE_OVERFLOW check is similar, except
> there the macro is more like this:
>
>  #define a 2147483647
>  #define b 1
>  #define FOO (INT_ADD_OVERFLOW (a,b) ? INT_MAX : (a)+(b))
>  int i = FOO;
>
> Again, any compiler that warns about potential overflow of
> 2147483647+1 should be ignored, because the expression
> 2147483647+1 cannot possibly be evaluated.
>

Ok. I read the intprops.h file and I agree with this example.
Pity there is no other (simpler) way to handle this.

Thanks for the explanations.

Fabrice




-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #2: Type: text/html, Size: 1346 bytes --]

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]

2012/2/28 Paul Eggert <eggert@cs.ucla.edu>

> > There is something wrong around lib/strftime.c:946
> >           if (negative_number)
> >             u_number_value = - u_number_value;
> >
> > u_number_value being unsigned, this is wrong.
>
> I don't see anything wrong there.  The value of
> -X is well-defined if X is unsigned int; it's
> equivalent to ~X + 1.  Can you supply a test case
> illustrating the actual bug?
>
> Please bear in mind that the code is already
> tested to LP64 hosts.  Any bug related to this
> particular code would also be a bug on LP64 hosts,
> no?  So, it's not likely that any bug here is specific
> to Windows 64.  If there is a bug, it should be
> describable and fixable independently of Windows 64.


I don't see things that way. Some things that would pass on LP64 because
ints are 64 bits may turn into a crash because of sign extension on Windows
64
promoting 32bits ints to 64bits ints. So I'm definitely more confident when
ints are used
without any abuse of any kind. I don't see the point with using an unsigned
int to negate
it.

-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 1512 bytes --]

Re: Windows 64 port

[Andreas Schwab]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

> I don't see things that way. Some things that would pass on LP64 because
> ints are 64 bits

They aren't.

> I don't see the point with using an unsigned int to negate it.

Using int results in undefined behaviour.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 314 bytes --]

>
> > I don't see things that way. Some things that would pass on LP64 because
> > ints are 64 bits
>
> They aren't.
>
> Ok, sorry, long not int.


> > I don't see the point with using an unsigned int to negate it.
>
> Using int results in undefined behaviour.
>

You mean you can't negate a signed int ?

Fabrice

[-- Attachment #2: Type: text/html, Size: 752 bytes --]

Re: Windows 64 port

[Andreas Schwab]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

> You mean you can't negate a signed int ?

Yes, it can overflow.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

2012/3/22 Andreas Schwab <schwab@linux-m68k.org>

> Fabrice Popineau <fabrice.popineau@supelec.fr> writes:
>
> > You mean you can't negate a signed int ?
>
> Yes, it can overflow.
>
>
Well ... the range is not wider with an unsigned int.
Maybe I'm too naive but if x is unsigned, I don't expect to
see -x . The implicit semantics for unsigned is x >= 0.

Sorry to be so stubborn, but I hate those sign extensions that can arise
anywhere. My point is that even if the effect is intended by using unsigned
this way, if the same variable is upgraded to long, the sign extension will
occur, probably unintented, and not flagged harder by the compiler.

-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 1180 bytes --]

Re: Windows 64 port

[Andreas Schwab]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

> Well ... the range is not wider with an unsigned int.

Unsigned arithmetics can never overflow.

> Maybe I'm too naive but if x is unsigned, I don't expect to
> see -x . The implicit semantics for unsigned is x >= 0.

-x is well defined for any value of unsigned integer type.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Windows 64 port

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  Eli Zaretskii <eliz@gnu.org>,  AJMR <ajmr@ilovetortilladepatatas.com>,  emacs-devel@gnu.org
> Date: Fri, 23 Mar 2012 00:38:04 +0100
> 
> > Maybe I'm too naive but if x is unsigned, I don't expect to
> > see -x . The implicit semantics for unsigned is x >= 0.
> 
> -x is well defined for any value of unsigned integer type.

Perhaps so, but using that obfuscates the code, so it's undesirable if
it can be avoided.  That's what Fabrice's comments boil down to, no
more no less.

Re: Windows 64 port

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Paul Eggert <eggert@cs.ucla.edu>,  Eli Zaretskii <eliz@gnu.org>,  AJMR <ajmr@ilovetortilladepatatas.com>,  emacs-devel@gnu.org
>> Date: Fri, 23 Mar 2012 00:38:04 +0100
>> 
>> > Maybe I'm too naive but if x is unsigned, I don't expect to
>> > see -x . The implicit semantics for unsigned is x >= 0.
>> 
>> -x is well defined for any value of unsigned integer type.
>
> Perhaps so, but using that obfuscates the code, so it's undesirable if
> it can be avoided.

There is no obfuscation.  This is the only way to make it work
correctly.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

>
> > Perhaps so, but using that obfuscates the code, so it's undesirable if
> > it can be avoided.
>
> There is no obfuscation.  This is the only way to make it work
> correctly.
>
> Well ... maybe write it :

          if (negative_number)
            u_number_value = ~ u_number_value + 1;

which would more closely match the earlier comment in the code
and avoid lame guys like me to ask about it.
(And also avoid stupid compiler warnings).

I have another question related to strftime.c : is there any reason not to
use the system one on Windows ?

Fabrice

[-- Attachment #2: Type: text/html, Size: 911 bytes --]

Re: Windows 64 port

[Andreas Schwab]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

>> Well ... maybe write it :

I didn't write that.

>           if (negative_number)
>             u_number_value = ~ u_number_value + 1;

That would obfuscate its purpose, namely to negate the number.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Windows 64 port

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Fri, 23 Mar 2012 11:27:15 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu, ajmr@ilovetortilladepatatas.com, 
> 	emacs-devel@gnu.org
> 
> I have another question related to strftime.c : is there any reason not to
> use the system one on Windows ?

Yes, there is: the one in Windows runtime libraries doesn't support
some of the time format specifiers provided by the gnulib version we
have in lib/.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

Another mostly cosmetic question.
Does GCC support:
static NO_RETURN void fatal (const char *s1, const char *s2);
rather than
static void fatal (const char *s1, const char *s2) NO_RETURN;

Fabrice

[-- Attachment #2: Type: text/html, Size: 298 bytes --]

Re: Windows 64 port

[Paul Eggert]

On 03/23/2012 03:11 AM, Fabrice Popineau wrote:
> Does GCC support:
> static NO_RETURN void fatal (const char *s1, const char *s2);

Yes.

Re: Windows 64 port

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Sun, 19 Feb 2012 23:05:52 +0100
> Cc: AJMR <ajmr@ilovetortilladepatatas.com>, emacs-devel@gnu.org
> 
> Here is my Windows 64 bits patch. It is quite crude and only attempts to
> make it possible to compile a 64bits emacs with the MS Sdk.

I have a few questions about the patch (below).

> the heap allocation scheme should probably be reworked

Can you tell which parts of the current scheme need to be reworked,
and why do you think so?

> === modified file 'lib/strftime.c'
> --- lib/strftime.c	2011-03-31 04:24:03 +0000
> +++ lib/strftime.c	2011-12-05 13:09:35 +0000
> @@ -36,9 +36,13 @@
>  #include <ctype.h>
>  #include <time.h>
>  
> +#ifdef _MSC_VER
> +#define tzname _tzname
> +#else
>  #if HAVE_TZNAME && !HAVE_DECL_TZNAME
>  extern char *tzname[];
>  #endif
> +#endif

This seems to be unrelated to 64-bit hosts.  Why is it needed, when
s/ms-w32.h has the same #define (which your patch #ifdef's away)?
What is the issue here?

> === modified file 'src/editfns.c'
> --- src/editfns.c	2012-01-19 07:21:25 +0000
> +++ src/editfns.c	2012-02-05 20:06:34 +0000
> @@ -82,6 +82,8 @@
>  
>  #ifdef WINDOWSNT
>  extern Lisp_Object w32_get_internal_run_time (void);
> +
> +extern struct tm *localtime (const time_t *t);
>  #endif

Why is this needed?  It seems also unrelated to 64-bit Windows.

> -internal_lisp_condition_case (volatile Lisp_Object var, Lisp_Object bodyform,
> +internal_lisp_condition_case (/* volatile */ Lisp_Object var, Lisp_Object bodyform,

Does MSVC have problems with the `volatile' qualifier?

> --- src/frame.c	2012-01-19 07:21:25 +0000
> +++ src/frame.c	2012-02-05 20:06:34 +0000
> @@ -812,6 +812,7 @@
>  #ifdef HAVE_WINDOW_SYSTEM
>    if (track && FRAME_WINDOW_P (XFRAME (frame)))
>      {
> +      extern Lisp_Object x_get_focus_frame(struct frame *);

This should go into w32term.h (it is already in xterm.h and nsterm.h).

> --- src/m/amdx86-64.h	2012-01-19 07:21:25 +0000
> +++ src/m/amdx86-64.h	2012-02-05 20:06:34 +0000
> @@ -17,7 +17,8 @@
>  You should have received a copy of the GNU General Public License
>  along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
>  
> -#define BITS_PER_LONG           64
> +#define BITS_PER_LONG           32

Here Windows and Posix systems differ, so it's wrong to do this
unconditionally.  Does the 64-bit Windows define _LLP64 or some such
somewhere on its headers?  If so, perhaps we could condition the above
on that macro, vs _LP64 on Posix hosts.

>  /* Define the type to use.  */
> -#define EMACS_INT               long
> -#define pI			"l"
> -#define EMACS_UINT              unsigned long
> +#define EMACS_INT               __int64
> +#define EMACS_UINT              unsigned __int64
> +#define pI			"ll"
> +#define VIRT_ADDR_VARIES
> +#define DATA_START 	get_data_start ()

Likewise here.

Thanks.

Re: Windows 64 port

[AJMR]

Hi everyone,

First of all, my gratitude for all the replies to the thread.

Secondly, it is not that I got scared (although, to be honest I feel
a bit overwhelmed for the depth of some details in this first contact).
However, most of time I can make nowadays is on weekends.

Thirdly, I have been reading any developers guides / instructions that
I could find and diving into the code. However, I am not sure whether
this is the correct approach. Any comments related to this topic will
be extra welcomed.

Finally, mainly to Eli and Fabrice, would it be OK if I contacted you
(via direct e-mail) in order to plan a more task-oriented roadmap? 

======== This is probably quite off topic ======
Dear Dr. Richard Stallman,

First of all, many, many, many thanks for all your contributions
already made (and hopefully more to come). I tip my hat to you.

I also appreciate your concern about porting myself completely to
GNU/Linux and even becoming a 100% free software user. However, not
being free is a sacrifice I have chosen to make. Temporary. The target
is to be once again really free.

Meanwhile, I would love to add something to the GNU and free
software world. Of course, I would love even more to contribute with an
extremely useful application which would improve people's life.
Nevertheless, I thought about going step by step and join into an
already existing project. I even thought that a port would be well
defined and narrowly scoped so I could gain momentum.

Of course, I may be wrong.

With all that in mind, I thought about helping with the free software I
have used the most. I guessed that it would not be a piece of cake, but
nothing is ever easy.
================================================


Thanks,
Alfredo.

On Mon, 20 Feb 2012 22:47:23 +0200
Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> > Date: Sun, 19 Feb 2012 23:05:52 +0100
> > Cc: AJMR <ajmr@ilovetortilladepatatas.com>, emacs-devel@gnu.org
> > 
> > Here is my Windows 64 bits patch. It is quite crude and only
> > attempts to make it possible to compile a 64bits emacs with the MS
> > Sdk.
> 
> I have a few questions about the patch (below).
> 
> > the heap allocation scheme should probably be reworked
> 
> Can you tell which parts of the current scheme need to be reworked,
> and why do you think so?
> 
> > === modified file 'lib/strftime.c'
> > --- lib/strftime.c	2011-03-31 04:24:03 +0000
> > +++ lib/strftime.c	2011-12-05 13:09:35 +0000
> > @@ -36,9 +36,13 @@
> >  #include <ctype.h>
> >  #include <time.h>
> >  
> > +#ifdef _MSC_VER
> > +#define tzname _tzname
> > +#else
> >  #if HAVE_TZNAME && !HAVE_DECL_TZNAME
> >  extern char *tzname[];
> >  #endif
> > +#endif
> 
> This seems to be unrelated to 64-bit hosts.  Why is it needed, when
> s/ms-w32.h has the same #define (which your patch #ifdef's away)?
> What is the issue here?
> 
> > === modified file 'src/editfns.c'
> > --- src/editfns.c	2012-01-19 07:21:25 +0000
> > +++ src/editfns.c	2012-02-05 20:06:34 +0000
> > @@ -82,6 +82,8 @@
> >  
> >  #ifdef WINDOWSNT
> >  extern Lisp_Object w32_get_internal_run_time (void);
> > +
> > +extern struct tm *localtime (const time_t *t);
> >  #endif
> 
> Why is this needed?  It seems also unrelated to 64-bit Windows.
> 
> > -internal_lisp_condition_case (volatile Lisp_Object var,
> > Lisp_Object bodyform, +internal_lisp_condition_case (/* volatile */
> > Lisp_Object var, Lisp_Object bodyform,
> 
> Does MSVC have problems with the `volatile' qualifier?
> 
> > --- src/frame.c	2012-01-19 07:21:25 +0000
> > +++ src/frame.c	2012-02-05 20:06:34 +0000
> > @@ -812,6 +812,7 @@
> >  #ifdef HAVE_WINDOW_SYSTEM
> >    if (track && FRAME_WINDOW_P (XFRAME (frame)))
> >      {
> > +      extern Lisp_Object x_get_focus_frame(struct frame *);
> 
> This should go into w32term.h (it is already in xterm.h and nsterm.h).
> 
> > --- src/m/amdx86-64.h	2012-01-19 07:21:25 +0000
> > +++ src/m/amdx86-64.h	2012-02-05 20:06:34 +0000
> > @@ -17,7 +17,8 @@
> >  You should have received a copy of the GNU General Public License
> >  along with GNU Emacs.  If not, see
> > <http://www.gnu.org/licenses/>.  */ 
> > -#define BITS_PER_LONG           64
> > +#define BITS_PER_LONG           32
> 
> Here Windows and Posix systems differ, so it's wrong to do this
> unconditionally.  Does the 64-bit Windows define _LLP64 or some such
> somewhere on its headers?  If so, perhaps we could condition the above
> on that macro, vs _LP64 on Posix hosts.
> 
> >  /* Define the type to use.  */
> > -#define EMACS_INT               long
> > -#define pI			"l"
> > -#define EMACS_UINT              unsigned long
> > +#define EMACS_INT               __int64
> > +#define EMACS_UINT              unsigned __int64
> > +#define pI			"ll"
> > +#define VIRT_ADDR_VARIES
> > +#define DATA_START 	get_data_start ()
> 
> Likewise here.
> 
> Thanks.
> 

Re: Windows 64 port

[Eli Zaretskii]

> Date: Sun, 26 Feb 2012 21:17:46 +0100
> From: AJMR <ajmr@ilovetortilladepatatas.com>
> 
> Finally, mainly to Eli and Fabrice, would it be OK if I contacted you
> (via direct e-mail) in order to plan a more task-oriented roadmap? 

I'd prefer that you CC this list, so that the discussions get
archived, and so others could chime in as needed.

Thanks.

Re: Windows 64 port

[AJMR]

On Sun, 26 Feb 2012 23:25:35 +0200
Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 26 Feb 2012 21:17:46 +0100
> > From: AJMR <ajmr@ilovetortilladepatatas.com>
> > 
> > Finally, mainly to Eli and Fabrice, would it be OK if I contacted
> > you (via direct e-mail) in order to plan a more task-oriented
> > roadmap? 
> 
> I'd prefer that you CC this list, so that the discussions get
> archived, and so others could chime in as needed.
> 
> Thanks.
> 

No problem, I will do it that way :)


Thanks

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1.1: Type: text/plain, Size: 3965 bytes --]

>
> Can you tell which parts of the current scheme need to be reworked,
> and why do you think so?
>
> > === modified file 'lib/strftime.c'
> > --- lib/strftime.c    2011-03-31 04:24:03 +0000
> > +++ lib/strftime.c    2011-12-05 13:09:35 +0000
> > @@ -36,9 +36,13 @@
> >  #include <ctype.h>
> >  #include <time.h>
> >
> > +#ifdef _MSC_VER
> > +#define tzname _tzname
> > +#else
> >  #if HAVE_TZNAME && !HAVE_DECL_TZNAME
> >  extern char *tzname[];
> >  #endif
> > +#endif
>
> This seems to be unrelated to 64-bit hosts.  Why is it needed, when
> s/ms-w32.h has the same #define (which your patch #ifdef's away)?
> What is the issue here?
>

I compile with USE_CRT_DLL=1. If I define tzname as _tzname is ms-w32.h, I
get an error when including MS time.h
on some function returning an array. If I don't define it this way in
strftime, I get on error when linking because msvcrt has _tzname, not
tzname.



> > === modified file 'src/editfns.c'
> > --- src/editfns.c     2012-01-19 07:21:25 +0000
> > +++ src/editfns.c     2012-02-05 20:06:34 +0000
> > @@ -82,6 +82,8 @@
> >
> >  #ifdef WINDOWSNT
> >  extern Lisp_Object w32_get_internal_run_time (void);
> > +
> > +extern struct tm *localtime (const time_t *t);
> >  #endif
>
> Why is this needed?  It seems also unrelated to 64-bit Windows.


To remove a warning on localtime not define, hence supposed to return an
int
which has not the same size as a pointer (now).



>

> -internal_lisp_condition_case (volatile Lisp_Object var, Lisp_Object
> bodyform,
> > +internal_lisp_condition_case (/* volatile */ Lisp_Object var,
> Lisp_Object bodyform,
>
> Does MSVC have problems with the `volatile' qualifier?
>
>
Nope. A leftover. Sorry.


> > --- src/frame.c       2012-01-19 07:21:25 +0000
> > +++ src/frame.c       2012-02-05 20:06:34 +0000
> > @@ -812,6 +812,7 @@
> >  #ifdef HAVE_WINDOW_SYSTEM
> >    if (track && FRAME_WINDOW_P (XFRAME (frame)))
> >      {
> > +      extern Lisp_Object x_get_focus_frame(struct frame *);
>
> This should go into w32term.h (it is already in xterm.h and nsterm.h).
>
> > --- src/m/amdx86-64.h 2012-01-19 07:21:25 +0000
> > +++ src/m/amdx86-64.h 2012-02-05 20:06:34 +0000
> > @@ -17,7 +17,8 @@
> >  You should have received a copy of the GNU General Public License
> >  along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
> >
> > -#define BITS_PER_LONG           64
> > +#define BITS_PER_LONG           32
>
> Here Windows and Posix systems differ, so it's wrong to do this
> unconditionally.  Does the 64-bit Windows define _LLP64 or some such
> somewhere on its headers?  If so, perhaps we could condition the above
> on that macro, vs _LP64 on Posix hosts.


I have added WIN64 and _WIN64 as symbols in nmake.defs because this is the
way MS does it
(they used WIN32 and _WIN32). The latter is defined by the compiler when
targetting x64.

I have attached a more complete version of my patch. It fixes many
compilation warnings too in several ways :
- including headers in various places (w32.h mostly), check
- const problems in regex.c (large patch, but harmless)
- errno error codes in sys/socket.h that are already defined by the system
errno.h
- turn off compiler warnings of 3 kinds (harmless, but frequent in emacs
code)

It will also fix link time warnings about malloc; realloc and free by
preventing their libc counterparts
to be declared by the standard headers (given we use gmalloc on Windows, I
hope it is not a problem).

Finally, there are the 64 bits patches. As I said, the heap allocation
scheme should probably be rewritten.
I did the simplest thing : limit the heap to 32Gb (else it was trying
allocate a heap of 2^61 - base adress bytes,
failing to do that, it tried again by diminishing the size 1Mb by 1Mb!).

There are many ways to compile emacs for windows  (mingw, msvc, msvcrt,
libc etc.). I can't check all
of them so feel free to use veto any part. I'll try to find other ways to
achieve the same effect.

Best regards,

Fabrice

[-- Attachment #1.2: Type: text/html, Size: 5477 bytes --]

[-- Attachment #2: 64bits.patch --]
[-- Type: application/octet-stream, Size: 59737 bytes --]

=== modified file 'lib-src/etags.c'
--- lib-src/etags.c	2012-01-19 07:21:25 +0000
+++ lib-src/etags.c	2012-02-27 23:33:17 +0000
@@ -140,6 +140,7 @@
 #ifdef WINDOWSNT
 # include <fcntl.h>
 # include <direct.h>
+# define getcwd _getcwd
 # include <io.h>
 # define MAXPATHLEN _MAX_PATH
 # undef HAVE_NTGUI

=== modified file 'lib/strftime.c'
--- lib/strftime.c	2011-03-31 04:24:03 +0000
+++ lib/strftime.c	2011-12-05 13:09:35 +0000
@@ -36,9 +36,13 @@
 #include <ctype.h>
 #include <time.h>
 
+#ifdef _MSC_VER
+#define tzname _tzname
+#else
 #if HAVE_TZNAME && !HAVE_DECL_TZNAME
 extern char *tzname[];
 #endif
+#endif
 
 /* Do multibyte processing if multibytes are supported, unless
    multibyte sequences are safe in formats.  Multibyte sequences are

=== modified file 'lisp/term/w32-win.el'
--- lisp/term/w32-win.el	2012-01-19 07:21:25 +0000
+++ lisp/term/w32-win.el	2012-02-05 20:06:34 +0000
@@ -192,20 +192,20 @@
 ;;; Set default known names for external libraries
 (setq dynamic-library-alist
       (list
-       '(xpm "libxpm.dll" "xpm4.dll" "libXpm-nox4.dll")
+       '(xpm "xt19xpm.dll" "libxpm.dll" "xpm4.dll" "libXpm-nox4.dll")
        ;; Versions of libpng 1.4.x and later are incompatible with
        ;; earlier versions.  Set up the list of libraries according to
        ;; the version we were compiled against.  (If we were compiled
        ;; without PNG support, libpng-version's value is -1.)
        (if (>= libpng-version 10400)
 	   ;; libpng14-14.dll is libpng 1.4.3 from GTK+
-	   '(png "libpng14-14.dll" "libpng14.dll")
-	 '(png "libpng12d.dll" "libpng12.dll" "libpng3.dll" "libpng.dll"
+	   '(png "xt19png.dll" "libpng14-14.dll" "libpng14.dll")
+	 '(png "xt19png.dll" "libpng12d.dll" "libpng12.dll" "libpng3.dll" "libpng.dll"
 	       ;; these are libpng 1.2.8 from GTK+
 	       "libpng13d.dll" "libpng13.dll"))
-       '(jpeg "jpeg62.dll" "libjpeg.dll" "jpeg-62.dll" "jpeg.dll")
-       '(tiff "libtiff3.dll" "libtiff.dll")
-       '(gif "giflib4.dll" "libungif4.dll" "libungif.dll")
+       '(jpeg "xt19jpeg.dll" "jpeg62.dll" "libjpeg.dll" "jpeg-62.dll" "jpeg.dll")
+       '(tiff "xt19tiff.dll" "libtiff3.dll" "libtiff.dll")
+       '(gif "xt19gif.dll" "giflib4.dll" "libungif4.dll" "libungif.dll")
        '(svg "librsvg-2-2.dll")
        '(gdk-pixbuf "libgdk_pixbuf-2.0-0.dll")
        '(glib "libglib-2.0-0.dll")

=== modified file 'nt/addsection.c'
--- nt/addsection.c	2012-01-19 07:21:25 +0000
+++ nt/addsection.c	2012-02-05 20:06:34 +0000
@@ -36,9 +36,9 @@
 
 PIMAGE_NT_HEADERS
 (__stdcall * pfnCheckSumMappedFile) (LPVOID BaseAddress,
-				     DWORD FileLength,
-				     LPDWORD HeaderSum,
-				     LPDWORD CheckSum);
+				     DWORD_PTR FileLength,
+				     PDWORD_PTR HeaderSum,
+				     PDWORD_PTR CheckSum);
 
 #undef min
 #undef max
@@ -164,7 +164,7 @@
 /* Return pointer to section header for section containing the given
    relative virtual address. */
 IMAGE_SECTION_HEADER *
-rva_to_section (DWORD rva, IMAGE_NT_HEADERS * nt_header)
+rva_to_section (DWORD_PTR rva, IMAGE_NT_HEADERS * nt_header)
 {
   PIMAGE_SECTION_HEADER section;
   int i;
@@ -179,7 +179,7 @@
 	 some very old exes (eg. gzip dated Dec 1993).  Since
 	 w32_executable_type relies on this function to work reliably,
 	 we need to cope with this.  */
-      DWORD real_size = max (section->SizeOfRawData,
+      DWORD_PTR real_size = max (section->SizeOfRawData,
 			     section->Misc.VirtualSize);
       if (rva >= section->VirtualAddress
 	  && rva < section->VirtualAddress + real_size)
@@ -192,7 +192,7 @@
 /* Return pointer to section header for section containing the given
    offset in its raw data area. */
 IMAGE_SECTION_HEADER *
-offset_to_section (DWORD offset, IMAGE_NT_HEADERS * nt_header)
+offset_to_section (DWORD_PTR offset, IMAGE_NT_HEADERS * nt_header)
 {
   PIMAGE_SECTION_HEADER section;
   int i;
@@ -212,8 +212,8 @@
 /* Return offset to an object in dst, given offset in src.  We assume
    there is at least one section in both src and dst images, and that
    the some sections may have been added to dst (after sections in src).  */
-static DWORD
-relocate_offset (DWORD offset,
+static DWORD_PTR
+relocate_offset (DWORD_PTR offset,
 		 IMAGE_NT_HEADERS * src_nt_header,
 		 IMAGE_NT_HEADERS * dst_nt_header)
 {
@@ -247,32 +247,32 @@
 }
 
 #define OFFSET_TO_RVA(offset, section) \
-	  (section->VirtualAddress + ((DWORD)(offset) - section->PointerToRawData))
+	  (section->VirtualAddress + ((DWORD_PTR)(offset) - section->PointerToRawData))
 
 #define RVA_TO_OFFSET(rva, section) \
-	  (section->PointerToRawData + ((DWORD)(rva) - section->VirtualAddress))
+	  (section->PointerToRawData + ((DWORD_PTR)(rva) - section->VirtualAddress))
 
 #define RVA_TO_SECTION_OFFSET(rva, section) \
-	  ((DWORD)(rva) - section->VirtualAddress)
+	  ((DWORD_PTR)(rva) - section->VirtualAddress)
 
 /* Convert address in executing image to RVA.  */
-#define PTR_TO_RVA(ptr) ((DWORD)(ptr) - (DWORD) GetModuleHandle (NULL))
+#define PTR_TO_RVA(ptr) ((DWORD_PTR)(ptr) - (DWORD_PTR) GetModuleHandle (NULL))
 
 #define PTR_TO_OFFSET(ptr, pfile_data) \
           ((unsigned const char *)(ptr) - (pfile_data)->file_base)
 
 #define OFFSET_TO_PTR(offset, pfile_data) \
-          ((pfile_data)->file_base + (DWORD)(offset))
+          ((pfile_data)->file_base + (DWORD_PTR)(offset))
 
-#define ROUND_UP(p, align)   (((DWORD)(p) + (align)-1) & ~((align)-1))
-#define ROUND_DOWN(p, align) ((DWORD)(p) & ~((align)-1))
+#define ROUND_UP(p, align)   (((DWORD_PTR)(p) + (align)-1) & ~((align)-1))
+#define ROUND_DOWN(p, align) ((DWORD_PTR)(p) & ~((align)-1))
 
 
 static void
 copy_executable_and_add_section (file_data *p_infile,
 				 file_data *p_outfile,
 				 const char *new_section_name,
-				 DWORD new_section_size)
+				 DWORD_PTR new_section_size)
 {
   unsigned char *dst;
   PIMAGE_DOS_HEADER dos_header;
@@ -280,7 +280,7 @@
   PIMAGE_NT_HEADERS dst_nt_header;
   PIMAGE_SECTION_HEADER section;
   PIMAGE_SECTION_HEADER dst_section;
-  DWORD offset;
+  DWORD_PTR offset;
   int i;
   int be_verbose = GetEnvironmentVariable ("DEBUG_DUMP", NULL, 0) > 0;
 
@@ -324,10 +324,10 @@
   dst = (unsigned char *) p_outfile->file_base;
 
   COPY_CHUNK ("Copying DOS header...", dos_header,
-	      (DWORD) nt_header - (DWORD) dos_header, be_verbose);
+	      (DWORD_PTR) nt_header - (DWORD_PTR) dos_header, be_verbose);
   dst_nt_header = (PIMAGE_NT_HEADERS) dst;
   COPY_CHUNK ("Copying NT header...", nt_header,
-	      (DWORD) section - (DWORD) nt_header, be_verbose);
+	      (DWORD_PTR) section - (DWORD_PTR) nt_header, be_verbose);
   dst_section = (PIMAGE_SECTION_HEADER) dst;
   COPY_CHUNK ("Copying section table...", section,
 	      nt_header->FileHeader.NumberOfSections * sizeof (*section),
@@ -509,8 +509,8 @@
   /* Patch up header fields; profiler is picky about this. */
   {
     HANDLE hImagehelp = LoadLibrary ("imagehlp.dll");
-    DWORD  headersum;
-    DWORD  checksum;
+    DWORD_PTR  headersum;
+    DWORD_PTR  checksum;
 
     dos_header = (PIMAGE_DOS_HEADER) out_file.file_base;
     nt_header = (PIMAGE_NT_HEADERS) ((char *) dos_header + dos_header->e_lfanew);

=== modified file 'nt/config.nt'
--- nt/config.nt	2012-02-27 03:20:00 +0000
+++ nt/config.nt	2012-02-28 06:40:01 +0000
@@ -433,7 +433,11 @@
 
    See m/template.h for documentation on writing m/MACHINE.h files.  */
 #undef config_machfile
+#ifdef _WIN64
+#include "m/amdx86-64.h"
+#else
 #include "m/intel386.h"
+#endif
 
 /* Define `subprocesses' should be defined if you want to
    have code for asynchronous subprocesses

=== modified file 'nt/configure.bat'
--- nt/configure.bat	2012-01-19 07:21:25 +0000
+++ nt/configure.bat	2012-02-05 20:06:34 +0000
@@ -96,8 +96,8 @@
 set profile=N
 set nocygwin=N
 set COMPILER=
-set usercflags=
-set escusercflags=
+set usercflags=-I../src -I../nt/inc -I../lib -Ic:/source/XEmTeX/source/libs/w32compat -Ic:/source/XEmTeX/source/libs/zlib-1.2.5 -Ic:/source/XEmTeX/source/libs/libpng-1.5.4 -Ic:/source/XEmTeX/source/libs/jpeg-8b -Ic:/source/XEmTeX/source/libs/tiff-3.9.5/libtiff -Ic:/source/XEmTeX/source/libs/giflib-4.1.6/lib -Ic:/source/XEmTeX/source/libs/xpm-3.4k -Ic:/source/XEmTeX/source/libs/xpm-3.4k/lib
+set escusercflags=-I../src -I../nt/inc -I../lib -Ic:/source/XEmTeX/source/libs/w32compat -Ic:/source/XEmTeX/source/libs/zlib-1.2.5 -Ic:/source/XEmTeX/source/libs/libpng-1.5.4 -Ic:/source/XEmTeX/source/libs/jpeg-8b -Ic:/source/XEmTeX/source/libs/tiff-3.9.5/libtiff -Ic:/source/XEmTeX/source/libs/giflib-4.1.6/lib -Ic:/source/XEmTeX/source/libs/xpm-3.4k -Ic:/source/XEmTeX/source/libs/xpm-3.4k/lib
 set docflags=
 set userldflags=
 set escuserldflags=

=== modified file 'nt/emacs.rc'
--- nt/emacs.rc	2012-02-27 03:20:00 +0000
+++ nt/emacs.rc	2012-02-28 06:40:01 +0000
@@ -1,6 +1,10 @@
 Emacs ICON   icons\emacs.ico
 32649 CURSOR icons\hand.cur
-1 24 "emacs.manifest"
+#ifdef WIN64
+1 24 "emacs-x64.manifest"
+#else
+1 24 "emacs-x86.manifest"
+#endif
 
 #ifndef VS_VERSION_INFO
 #define VS_VERSION_INFO 1

=== modified file 'nt/inc/sys/socket.h'
--- nt/inc/sys/socket.h	2012-01-19 07:21:25 +0000
+++ nt/inc/sys/socket.h	2012-02-27 23:33:16 +0000
@@ -126,42 +126,147 @@
 extern int h_errno;
 
 /* map winsock error codes to standard names */
+#if defined(EWOULDBLOCK)
+#undef EWOULDBLOCK
+#endif
 #define EWOULDBLOCK             WSAEWOULDBLOCK
+#if defined(EINPROGRESS)
+#undef EINPROGRESS
+#endif
 #define EINPROGRESS             WSAEINPROGRESS
+#if defined(EALREADY)
+#undef EALREADY
+#endif
 #define EALREADY                WSAEALREADY
+#if defined(ENOTSOCK)
+#undef ENOTSOCK
+#endif
 #define ENOTSOCK                WSAENOTSOCK
+#if defined(EDESTADDRREQ)
+#undef EDESTADDRREQ
+#endif
 #define EDESTADDRREQ            WSAEDESTADDRREQ
+#if defined(EMSGSIZE)
+#undef EMSGSIZE
+#endif
 #define EMSGSIZE                WSAEMSGSIZE
+#if defined(EPROTOTYPE)
+#undef EPROTOTYPE
+#endif
 #define EPROTOTYPE              WSAEPROTOTYPE
+#if defined(ENOPROTOOPT)
+#undef ENOPROTOOPT
+#endif
 #define ENOPROTOOPT             WSAENOPROTOOPT
+#if defined(EPROTONOSUPPORT)
+#undef EPROTONOSUPPORT
+#endif
 #define EPROTONOSUPPORT         WSAEPROTONOSUPPORT
+#if defined(ESOCKTNOSUPPORT)
+#undef ESOCKTNOSUPPORT
+#endif
 #define ESOCKTNOSUPPORT         WSAESOCKTNOSUPPORT
+#if defined(EOPNOTSUPP)
+#undef EOPNOTSUPP
+#endif
 #define EOPNOTSUPP              WSAEOPNOTSUPP
+#if defined(EPFNOSUPPORT)
+#undef EPFNOSUPPORT
+#endif
 #define EPFNOSUPPORT            WSAEPFNOSUPPORT
+#if defined(EAFNOSUPPORT)
+#undef EAFNOSUPPORT
+#endif
 #define EAFNOSUPPORT            WSAEAFNOSUPPORT
+#if defined(EADDRINUSE)
+#undef EADDRINUSE
+#endif
 #define EADDRINUSE              WSAEADDRINUSE
+#if defined(EADDRNOTAVAIL)
+#undef EADDRNOTAVAIL
+#endif
 #define EADDRNOTAVAIL           WSAEADDRNOTAVAIL
+#if defined(ENETDOWN)
+#undef ENETDOWN
+#endif
 #define ENETDOWN                WSAENETDOWN
+#if defined(ENETUNREACH)
+#undef ENETUNREACH
+#endif
 #define ENETUNREACH             WSAENETUNREACH
+#if defined(ENETRESET)
+#undef ENETRESET
+#endif
 #define ENETRESET               WSAENETRESET
+#if defined(ECONNABORTED)
+#undef ECONNABORTED
+#endif
 #define ECONNABORTED            WSAECONNABORTED
+#if defined(ECONNRESET)
+#undef ECONNRESET
+#endif
 #define ECONNRESET              WSAECONNRESET
+#if defined(ENOBUFS)
+#undef ENOBUFS
+#endif
 #define ENOBUFS                 WSAENOBUFS
+#if defined(EISCONN)
+#undef EISCONN
+#endif
 #define EISCONN                 WSAEISCONN
+#if defined(ENOTCONN)
+#undef ENOTCONN
+#endif
 #define ENOTCONN                WSAENOTCONN
+#if defined(ESHUTDOWN)
+#undef ESHUTDOWN
+#endif
 #define ESHUTDOWN               WSAESHUTDOWN
+#if defined(ETOOMANYREFS)
+#undef ETOOMANYREFS
+#endif
 #define ETOOMANYREFS            WSAETOOMANYREFS
+#if defined(ETIMEDOUT)
+#undef ETIMEDOUT
+#endif
 #define ETIMEDOUT               WSAETIMEDOUT
+#if defined(ECONNREFUSED)
+#undef ECONNREFUSED
+#endif
 #define ECONNREFUSED            WSAECONNREFUSED
+#if defined(ELOOP)
+#undef ELOOP
+#endif
 #define ELOOP                   WSAELOOP
 /* #define ENAMETOOLONG            WSAENAMETOOLONG */
+#if defined(EHOSTDOWN)
+#undef EHOSTDOWN
+#endif
 #define EHOSTDOWN               WSAEHOSTDOWN
+#if defined(EHOSTUNREACH)
+#undef EHOSTUNREACH
+#endif
 #define EHOSTUNREACH            WSAEHOSTUNREACH
 /* #define ENOTEMPTY               WSAENOTEMPTY */
+#if defined(EPROCLIM)
+#undef EPROCLIM
+#endif
 #define EPROCLIM                WSAEPROCLIM
+#if defined(EUSERS)
+#undef EUSERS
+#endif
 #define EUSERS                  WSAEUSERS
+#if defined(EDQUOT)
+#undef EDQUOT
+#endif
 #define EDQUOT                  WSAEDQUOT
+#if defined(ESTALE)
+#undef ESTALE
+#endif
 #define ESTALE                  WSAESTALE
+#if defined(EREMOTE)
+#undef EREMOTE
+#endif
 #define EREMOTE                 WSAEREMOTE
 
 #endif /* _SOCKET_H_ */

=== modified file 'nt/nmake.defs'
--- nt/nmake.defs	2012-02-05 20:40:36 +0000
+++ nt/nmake.defs	2012-02-19 21:54:33 +0000
@@ -86,7 +86,11 @@
 !    if "$(PROCESSOR_ARCHITECTURE)" == "PPC"
 ARCH		= ppc
 !    else
-!     error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
+!     if "$(PROCESSOR_ARCHITECTURE)" == "AMD64"
+ARCH		= AMD64
+!     else
+!      error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
+!     endif
 !    endif
 !   endif
 !  endif
@@ -105,11 +109,11 @@
 CC_OUT		= -Fo
 LINK		= link
 LINK_OUT	= -out:
-RC		= rc
+RC		= rc $(ARCH_RCFLAGS)
 RC_OUT		= -Fo
 RC_INCLUDE	= -i
 
-USE_CRT_DLL	= 1
+# USE_CRT_DLL	= 1
 
 !ifdef USE_CRT_DLL
 libc		= msvcrt$(D).lib
@@ -151,20 +155,17 @@
 !endif
 
 CFLAGS          = -I. $(ARCH_CFLAGS) \
+		  -D_CRT_SECURE_NO_WARNINGS \
 		  $(DEBUG_CFLAGS) $(CHECKING_CFLAGS) $(USER_CFLAGS) $(LOCAL_FLAGS)
 ESC_CFLAGS      = -I. $(ARCH_CFLAGS) \
+		  -D_CRT_SECURE_NO_WARNINGS \
 		  $(DEBUG_CFLAGS) $(CHECKING_CFLAGS) $(ESC_USER_CFLAGS) $(LOCAL_FLAGS)
 
 #SYS_LDFLAGS	= -nologo -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
-!ifdef NOOPT
-SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -debug -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
-!else
-SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj
-!endif
+SYS_LDFLAGS	= -nologo -manifest -dynamicbase:no -incremental:no -version:5.10 -swaprun:cd -swaprun:net setargv.obj
 
 # see comments in allocate_heap in w32heap.c before changing any of the
-# -stack, -heap, or -base settings.
-TEMACS_EXTRA_LINK = -stack:0x00800000 -heap:0x00100000 -base:0x01000000 -pdb:$(BLD)\temacs.pdb -machine:$(ARCH) $(SUBSYSTEM_CONSOLE) -entry:_start -map:$(BLD)\temacs.map $(EXTRA_LINK)
+TEMACS_EXTRA_LINK = -stack:0x00800000 -heap:0x00100000 -base:0x01000000 -pdb:$(BLD)\temacs.pdb -machine:$(TARGET_CPU) $(SUBSYSTEM_CONSOLE) -entry:_start -map:$(BLD)\temacs.map $(EXTRA_LINK)
 
 !ifdef NOOPT
 OBJDIR          = obj
@@ -195,7 +196,7 @@
 
 !ifdef NODEBUG
 DEBUG_FLAG =
-DEBUG_LINK =
+DEBUG_LINK = -release
 D =
 !else
 DEBUG_FLAG = -Zi
@@ -233,15 +234,28 @@
 !else
 !if "$(ARCH)" == "ppc"
 # These flags are a guess...if they don't work, please send me mail.
-ARCH_CFLAGS	= -D_PPC_=1 -c -Ze -Zi -W2 -Od
 ARCH_LDFLAGS	= $(SYS_LDFLAGS)
 
 !else
+!if "$(ARCH)" == "AMD64"
+# These flags are a guess...if they don't work, please send me mail.
+!ifdef NOOPT
+#ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Od -G3d -Zp8 $(DEBUG_FLAG)
+ARCH_CFLAGS     = -nologo -D_AMD64_=1 -DWIN64 -D_WIN64 -DWIN32 -D_WIN32 -c -Zl -Zp8 -W2 -Od -Gd $(DEBUG_FLAG)
+!else
+#ARCH_CFLAGS     = -nologo -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 $(DEBUG_FLAG)
+ARCH_CFLAGS     = -nologo -D_AMD64_=1 -DWIN64 -D_WIN64 -DWIN32 -D_WIN32 -c -Zl -Zp8 -W2 -Oi -Ot -Oy- -Ob2 -GF -Gy -Gd $(DEBUG_FLAG)
+!endif
+ARCH_LDFLAGS	= $(SYS_LDFLAGS) -machine:x64
+ARCH_RCFLAGS	= -DWIN64
+
+!else
 !ERROR Unknown architecture type "$(ARCH)".
 !endif
 !endif
 !endif
 !endif
+!endif
 
 LINK_FLAGS	= $(ARCH_LDFLAGS) $(DEBUG_LINK) $(USER_LDFLAGS)
 

=== modified file 'src/alloc.c'
--- src/alloc.c	2012-02-26 01:09:59 +0000
+++ src/alloc.c	2012-02-28 06:40:01 +0000
@@ -64,6 +64,7 @@
 
 #ifdef WINDOWSNT
 #include "w32.h"
+#include "w32heap.h"
 #endif
 
 #ifdef DOUG_LEA_MALLOC
@@ -1150,7 +1151,7 @@
 
   if (2 > (intptr_t) ABLOCKS_BUSY (abase))
     { /* All the blocks are free.  */
-      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
+      int i = 0, aligned = (ABLOCKS_BUSY (abase) != NULL);
       struct ablock **tem = &free_ablock;
       struct ablock *atop = &abase->blocks[aligned ? ABLOCKS_SIZE : ABLOCKS_SIZE - 1];
 
@@ -2982,7 +2983,7 @@
 /* Allocate other vector-like structures.  */
 
 struct Lisp_Vector *
-allocate_pseudovector (int memlen, int lisplen, EMACS_INT tag)
+allocate_pseudovector (size_t memlen, size_t lisplen, EMACS_INT tag)
 {
   struct Lisp_Vector *v = allocate_vectorlike (memlen);
   int i;
@@ -5056,13 +5057,13 @@
 	    /* If a buffer's gap size is more than 10% of the buffer
 	       size, or larger than 2000 bytes, then shrink it
 	       accordingly.  Keep a minimum size of 20 bytes.  */
-	    int size = min (2000, max (20, (nextb->text->z_byte / 10)));
+	    size_t size = min (2000, max (20, (nextb->text->z_byte / 10)));
 
 	    if (nextb->text->gap_size > size)
 	      {
 		struct buffer *save_current = current_buffer;
 		current_buffer = nextb;
-		make_gap (-(nextb->text->gap_size - size));
+		make_gap ((size - nextb->text->gap_size));
 		current_buffer = save_current;
 	      }
 	  }

=== modified file 'src/coding.c'
--- src/coding.c	2012-02-09 07:48:22 +0000
+++ src/coding.c	2012-02-27 23:33:18 +0000
@@ -298,6 +298,10 @@
 #include "frame.h"
 #include "termhooks.h"
 
+#ifdef WINDOWSNT
+#include "w32.h"
+#endif
+
 Lisp_Object Vcoding_system_hash_table;
 
 static Lisp_Object Qcoding_system, Qeol_type;

=== modified file 'src/dispnew.c'
--- src/dispnew.c	2012-02-04 11:29:29 +0000
+++ src/dispnew.c	2012-02-27 23:33:18 +0000
@@ -49,6 +49,7 @@
 #endif /* HAVE_X_WINDOWS */
 
 #ifdef HAVE_NTGUI
+#include "w32.h"
 #include "w32term.h"
 #endif /* HAVE_NTGUI */
 

=== modified file 'src/dosfns.c'
--- src/dosfns.c	2012-01-19 07:21:25 +0000
+++ src/dosfns.c	2012-02-05 20:06:34 +0000
@@ -542,7 +542,7 @@
       double pmem;
       EXFUN (Fget_internal_run_time, 0);
 #ifndef SYSTEM_MALLOC
-      extern unsigned long ret_lim_data ();
+      extern size_t ret_lim_data ();
 #endif
 
       uid = getuid ();
@@ -579,7 +579,7 @@
 #ifndef SYSTEM_MALLOC
       /* ret_lim_data is on vm-limit.c, which is not compiled in under
 	 SYSTEM_MALLOC.  */
-      pmem = (double)((unsigned long) sbrk (0)) / ret_lim_data () * 100.0;
+      pmem = (double)((size_t) sbrk (0)) / ret_lim_data () * 100.0;
       if (pmem > 100)
 #endif
 	pmem = 100;

=== modified file 'src/editfns.c'
--- src/editfns.c	2012-01-19 07:21:25 +0000
+++ src/editfns.c	2012-02-27 23:33:18 +0000
@@ -81,6 +81,7 @@
 #endif
 
 #ifdef WINDOWSNT
+#include "w32.h"
 extern Lisp_Object w32_get_internal_run_time (void);
 #endif
 

=== modified file 'src/fileio.c'
--- src/fileio.c	2012-02-25 09:07:23 +0000
+++ src/fileio.c	2012-02-28 06:40:01 +0000
@@ -52,6 +52,7 @@
 #define NOMINMAX 1
 #include <windows.h>
 #include <fcntl.h>
+#include "w32.h"
 #endif /* not WINDOWSNT */
 
 #ifdef MSDOS

=== modified file 'src/frame.c'
--- src/frame.c	2012-01-19 07:21:25 +0000
+++ src/frame.c	2012-02-05 20:06:34 +0000
@@ -812,6 +812,7 @@
 #ifdef HAVE_WINDOW_SYSTEM
   if (track && FRAME_WINDOW_P (XFRAME (frame)))
     {
+      extern Lisp_Object x_get_focus_frame(struct frame *);
       Lisp_Object focus, xfocus;
 
       xfocus = x_get_focus_frame (XFRAME (frame));

=== modified file 'src/gmalloc.c'
--- src/gmalloc.c	2011-09-09 01:06:52 +0000
+++ src/gmalloc.c	2012-02-27 23:33:18 +0000
@@ -56,6 +56,7 @@
 
 #endif	/* _MALLOC_INTERNAL.  */
 
+#include <w32heap.h>
 
 #ifdef	__cplusplus
 extern "C"
@@ -459,7 +460,7 @@
      __malloc_size_t size;
 {
   __ptr_t result;
-  unsigned long int adj;
+  intptr_t adj;
 
   /* align accepts an unsigned argument, but __morecore accepts a
      signed one.  This could lead to trouble if SIZE overflows a
@@ -469,8 +470,8 @@
     result = 0;
   else
     result = (*__morecore) (size);
-  adj = (unsigned long int) ((unsigned long int) ((char *) result -
-						  (char *) NULL)) % BLOCKSIZE;
+  adj = (intptr_t) (((char *) result -
+                     (char *) NULL)) % BLOCKSIZE;
   if (adj != 0)
     {
       __ptr_t new;
@@ -539,7 +540,7 @@
   _heapinfo[block].busy.info.size = blocks;
   /* Leave back-pointers for malloc_find_address.  */
   while (--blocks > 0)
-    _heapinfo[block + blocks].busy.info.size = -blocks;
+    _heapinfo[block + blocks].busy.info.size = -((__malloc_ptrdiff_t)blocks);
 }
 
 #ifdef USE_PTHREAD
@@ -715,7 +716,7 @@
  	  /* Did it fail?  */
  	  if (newinfo == NULL)
  	    {
- 	      (*__morecore) (-size);
+ 	      (*__morecore) (-((__malloc_ptrdiff_t)size));
  	      return NULL;
  	    }
 
@@ -727,7 +728,7 @@
  	    break;
 
  	  /* Must try again.  First give back most of what we just got.  */
- 	  (*__morecore) (- newsize * sizeof (malloc_info));
+ 	  (*__morecore) (- ((ptrdiff_t)(newsize * sizeof (malloc_info))));
  	  newsize *= 2;
   	}
 
@@ -809,8 +810,8 @@
 	    next->next->prev = next->prev;
 	  block = BLOCK (result);
 	  if (--_heapinfo[block].busy.info.frag.nfree != 0)
-	    _heapinfo[block].busy.info.frag.first = (unsigned long int)
-	      ((unsigned long int) ((char *) next->next - (char *) NULL)
+	    _heapinfo[block].busy.info.frag.first = (intptr_t)
+	      (((char *) next->next - (char *) NULL)
 	       % BLOCKSIZE) >> log;
 
 	  /* Update the statistics.  */
@@ -951,7 +952,7 @@
 	 first with a negative number so you can find the first block by
 	 adding that adjustment.  */
       while (--blocks > 0)
-	_heapinfo[block + blocks].busy.info.size = -blocks;
+	_heapinfo[block + blocks].busy.info.size = -((ptrdiff_t)blocks);
     }
 
   PROTECT_MALLOC_STATE (1);
@@ -1224,7 +1225,7 @@
 	    {
 	      register __malloc_size_t bytes = blocks * BLOCKSIZE;
 	      _heaplimit -= blocks;
-	      (*__morecore) (-bytes);
+	      (*__morecore) (-((__malloc_ptrdiff_t)bytes));
 	      _heapinfo[_heapinfo[block].free.prev].free.next
 		= _heapinfo[block].free.next;
 	      _heapinfo[_heapinfo[block].free.next].free.prev
@@ -1295,8 +1296,8 @@
 	     it is the first free fragment of this block. */
 	  prev = (struct list *) ptr;
 	  _heapinfo[block].busy.info.frag.nfree = 1;
-	  _heapinfo[block].busy.info.frag.first = (unsigned long int)
-	    ((unsigned long int) ((char *) ptr - (char *) NULL)
+	  _heapinfo[block].busy.info.frag.first = (intptr_t)
+	    ((intptr_t) ((char *) ptr - (char *) NULL)
 	     % BLOCKSIZE >> type);
 	  prev->next = _fraghead[type].next;
 	  prev->prev = &_fraghead[type];
@@ -1373,6 +1374,9 @@
 #include <malloc.h>
 #endif
 
+#ifdef min
+#undef min
+#endif
 
 #define min(A, B) ((A) < (B) ? (A) : (B))
 
@@ -1689,7 +1693,7 @@
      __malloc_size_t size;
 {
   __ptr_t result;
-  unsigned long int adj, lastadj;
+  intptr_t adj, lastadj;
   __ptr_t (*hook) (__malloc_size_t, __malloc_size_t) = __memalign_hook;
 
   if (hook)
@@ -1703,7 +1707,7 @@
 
   /* Figure out how much we will need to pad this particular block
      to achieve the required alignment.  */
-  adj = (unsigned long int) ((char *) result - (char *) NULL) % alignment;
+  adj = (intptr_t) ((char *) result - (char *) NULL) % alignment;
 
   do
     {
@@ -1714,7 +1718,7 @@
 	return NULL;
 
       lastadj = adj;
-      adj = (unsigned long int) ((char *) result - (char *) NULL) % alignment;
+      adj = (intptr_t) ((char *) result - (char *) NULL) % alignment;
       /* It's conceivable we might have been so unlucky as to get a
 	 different block with weaker alignment.  If so, this block is too
 	 short to contain SIZE after alignment correction.  So we must
@@ -1904,7 +1908,7 @@
 struct hdr
   {
     __malloc_size_t size;		/* Exact size requested by user.  */
-    unsigned long int magic;	/* Magic number to check header integrity.  */
+    uint64_t magic;	/* Magic number to check header integrity.  */
   };
 
 static enum mcheck_status checkhdr (const struct hdr *);

=== modified file 'src/image.c'
--- src/image.c	2012-02-15 06:40:08 +0000
+++ src/image.c	2012-02-19 21:54:33 +0000
@@ -16,6 +16,10 @@
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 
+#ifdef _MSC_VER
+#define _W32COMPAT_H_ 1
+#endif
+
 #include <config.h>
 #include <stdio.h>
 #include <math.h>

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2012-02-24 08:34:09 +0000
+++ src/keyboard.c	2012-02-28 06:40:01 +0000
@@ -66,6 +66,7 @@
 #endif
 
 #ifdef HAVE_NTGUI
+#include "w32.h"
 #include "w32term.h"
 #endif /* HAVE_NTGUI */
 

=== modified file 'src/lisp.h'
--- src/lisp.h	2012-02-25 19:39:42 +0000
+++ src/lisp.h	2012-02-28 06:40:01 +0000
@@ -489,7 +489,7 @@
 /* For integers known to be positive, XFASTINT provides fast retrieval
    and XSETFASTINT provides fast storage.  This takes advantage of the
    fact that Lisp_Int is 0.  */
-#define XFASTINT(a) ((a) + 0)
+#define XFASTINT(a) (((a) + 0))
 #define XSETFASTINT(a, b) ((a) = (b))
 
 /* Extract the value of a Lisp_Object as a (un)signed integer.  */
@@ -2817,7 +2817,7 @@
 EXFUN (Fmake_bool_vector, 2);
 extern Lisp_Object Qchar_table_extra_slots;
 extern struct Lisp_Vector *allocate_vector (EMACS_INT);
-extern struct Lisp_Vector *allocate_pseudovector (int memlen, int lisplen, EMACS_INT tag);
+extern struct Lisp_Vector *allocate_pseudovector (size_t memlen, size_t lisplen, EMACS_INT tag);
 #define ALLOCATE_PSEUDOVECTOR(typ,field,tag)				\
   ((typ*)								\
    allocate_pseudovector						\

=== modified file 'src/lread.c'
--- src/lread.c	2012-01-26 06:30:49 +0000
+++ src/lread.c	2012-02-27 23:33:18 +0000
@@ -44,6 +44,10 @@
 #include "msdos.h"
 #endif
 
+#ifdef WINDOWSNT
+#include "w32.h"
+#endif
+
 #include <unistd.h>
 #include <math.h>
 

=== modified file 'src/m/amdx86-64.h'
--- src/m/amdx86-64.h	2012-01-19 07:21:25 +0000
+++ src/m/amdx86-64.h	2012-02-28 07:00:30 +0000
@@ -17,7 +17,13 @@
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 
-#define BITS_PER_LONG           64
+#ifdef _WIN64
+# define BITS_PER_LONG           32
+# define BITS_PER_LONG_LONG      64
+#else
+# define BITS_PER_LONG           64
+#endif
+
 #define BITS_PER_EMACS_INT      64
 
 /* Now define a symbol for the cpu type, if your compiler
@@ -27,9 +33,17 @@
 /* __x86_64 defined automatically.  */
 
 /* Define the type to use.  */
-#define EMACS_INT               long
-#define pI			"l"
-#define EMACS_UINT              unsigned long
+#ifdef _WIN64
+# define EMACS_INT               __int64
+# define EMACS_UINT              unsigned __int64
+# define pI			"ll"
+# define VIRT_ADDR_VARIES
+# define DATA_START 	get_data_start ()
+#else
+# define EMACS_INT               long
+# define pI			"l"
+# define EMACS_UINT              unsigned long
+#endif
 
 /* Define XPNTR to avoid or'ing with DATA_SEG_BITS */
 #undef DATA_SEG_BITS

=== modified file 'src/makefile.w32-in'
--- src/makefile.w32-in	2012-01-19 07:21:25 +0000
+++ src/makefile.w32-in	2012-02-05 20:06:34 +0000
@@ -25,7 +25,7 @@
 EMACSLOADPATH=$(CURDIR)/../lisp
 
 # Size in MBs of the static heap in temacs.exe.
-HEAPSIZE = 27
+HEAPSIZE = 42
 
 #
 # HAVE_CONFIG_H is required by some generic gnu sources stuck into

=== modified file 'src/ralloc.c'
--- src/ralloc.c	2012-02-01 16:51:20 +0000
+++ src/ralloc.c	2012-02-27 23:33:18 +0000
@@ -24,6 +24,8 @@
 
 #ifdef emacs
 
+#define SIZE ESIZE
+
 #include <config.h>
 #include <setjmp.h>
 #include "lisp.h"		/* Needed for VALBITS.  */
@@ -76,7 +78,7 @@
 /* Declarations for working with the malloc, ralloc, and system breaks.  */
 
 /* Function to set the real break value.  */
-POINTER (*real_morecore) (long int);
+POINTER (*real_morecore) (intptr_t);
 
 /* The break value, as seen by malloc.  */
 static POINTER virtual_break_value;
@@ -95,20 +97,20 @@
 /* Macros for rounding.  Note that rounding to any value is possible
    by changing the definition of PAGE.  */
 #define PAGE (getpagesize ())
-#define ALIGNED(addr) (((unsigned long int) (addr) & (page_size - 1)) == 0)
-#define ROUNDUP(size) (((unsigned long int) (size) + page_size - 1) \
+#define ALIGNED(addr) (((intptr_t) (addr) & (page_size - 1)) == 0)
+#define ROUNDUP(size) (((intptr_t) (size) + page_size - 1) \
 		       & ~(page_size - 1))
 #define ROUND_TO_PAGE(addr) (addr & (~(page_size - 1)))
 
 #define MEM_ALIGN sizeof (double)
-#define MEM_ROUNDUP(addr) (((unsigned long int)(addr) + MEM_ALIGN - 1) \
+#define MEM_ROUNDUP(addr) (((intptr_t)(addr) + MEM_ALIGN - 1) \
 				   & ~(MEM_ALIGN - 1))
 
 /* The hook `malloc' uses for the function which gets more space
    from the system.  */
 
 #ifndef SYSTEM_MALLOC
-extern POINTER (*__morecore) (long int);
+extern POINTER (*__morecore) (intptr_t);
 #endif
 
 
@@ -315,7 +317,7 @@
 relinquish (void)
 {
   register heap_ptr h;
-  long excess = 0;
+  ptrdiff_t excess = 0;
 
   /* Add the amount of space beyond break_value
      in all heaps which have extend beyond break_value at all.  */
@@ -370,7 +372,7 @@
 /* Return the total size in use by relocating allocator,
    above where malloc gets space.  */
 
-long
+intptr_t
 r_alloc_size_in_use (void)
 {
   return (char *) break_value - (char *) virtual_break_value;
@@ -749,7 +751,7 @@
    GNU malloc package.  */
 
 POINTER
-r_alloc_sbrk (long int size)
+r_alloc_sbrk (ptrdiff_t size)
 {
   register bloc_ptr b;
   POINTER address;
@@ -1020,7 +1022,7 @@
    malloc must return a null pointer.  */
 
 void
-r_alloc_freeze (long int size)
+r_alloc_freeze (intptr_t size)
 {
   if (! r_alloc_initialized)
     r_alloc_init ();

=== modified file 'src/regex.c'
--- src/regex.c	2012-01-19 07:21:25 +0000
+++ src/regex.c	2012-02-27 23:33:18 +0000
@@ -161,8 +161,8 @@
   do {									     \
     if (target_multibyte)						     \
       {									     \
-	re_char *dtemp = (p) == (str2) ? (end1) : (p);			     \
-	re_char *dlimit = ((p) > (str2) && (p) <= (end2)) ? (str2) : (str1); \
+	const re_char *dtemp = (p) == (str2) ? (end1) : (p);			     \
+	const re_char *dlimit = ((p) > (str2) && (p) <= (end2)) ? (str2) : (str1); \
 	while (dtemp-- > dlimit && !CHAR_HEAD_P (*dtemp));		     \
 	c = STRING_CHAR (dtemp);					     \
       }									     \
@@ -541,8 +541,8 @@
 #define true 1
 
 static regoff_t re_match_2_internal _RE_ARGS ((struct re_pattern_buffer *bufp,
-					       re_char *string1, size_t size1,
-					       re_char *string2, size_t size2,
+					       const re_char *string1, size_t size1,
+					       const re_char *string2, size_t size2,
 					       ssize_t pos,
 					       struct re_registers *regs,
 					       ssize_t stop));
@@ -825,8 +825,8 @@
   do									\
     {									\
       re_wchar_t range_start, range_end;				\
-      re_char *rtp;							\
-      re_char *range_table_end						\
+      const re_char *rtp;							\
+      const re_char *range_table_end						\
 	= CHARSET_RANGE_TABLE_END ((range_table), (count));		\
 									\
       for (rtp = (range_table); rtp < range_table_end; rtp += 2 * 3)	\
@@ -1368,7 +1368,7 @@
 
 union fail_stack_elt
 {
-  re_char *pointer;
+  const re_char *pointer;
   /* This should be the biggest `int' that's no bigger than a pointer.  */
   long integer;
 };
@@ -1659,7 +1659,7 @@
 \f
 /* Subroutine declarations and macros for regex_compile.  */
 
-static reg_errcode_t regex_compile _RE_ARGS ((re_char *pattern, size_t size,
+static reg_errcode_t regex_compile _RE_ARGS ((const re_char *pattern, size_t size,
 					      reg_syntax_t syntax,
 					      struct re_pattern_buffer *bufp));
 static void store_op1 _RE_ARGS ((re_opcode_t op, unsigned char *loc, int arg));
@@ -1669,14 +1669,14 @@
 				  int arg, unsigned char *end));
 static void insert_op2 _RE_ARGS ((re_opcode_t op, unsigned char *loc,
 				  int arg1, int arg2, unsigned char *end));
-static boolean at_begline_loc_p _RE_ARGS ((re_char *pattern,
-					   re_char *p,
-					   reg_syntax_t syntax));
-static boolean at_endline_loc_p _RE_ARGS ((re_char *p,
-					   re_char *pend,
-					   reg_syntax_t syntax));
-static re_char *skip_one_char _RE_ARGS ((re_char *p));
-static int analyse_first _RE_ARGS ((re_char *p, re_char *pend,
+static boolean at_begline_loc_p _RE_ARGS ((const re_char *pattern,
+					   const re_char *p,
+					   reg_syntax_t syntax));
+static boolean at_endline_loc_p _RE_ARGS ((const re_char *p,
+					   const re_char *pend,
+					   reg_syntax_t syntax));
+static const re_char *skip_one_char _RE_ARGS ((const re_char *p));
+static int analyse_first _RE_ARGS ((const re_char *p, const re_char *pend,
 				    char *fastmap, const int multibyte));
 
 /* Fetch the next character in the uncompiled pattern, with no
@@ -2484,9 +2484,9 @@
   /* `const' makes AIX compiler fail.  */
   unsigned char *p = pattern;
 #else
-  re_char *p = pattern;
+  const re_char *p = pattern;
 #endif
-  re_char *pend = pattern + size;
+  const re_char *pend = pattern + size;
 
   /* How to translate the characters in the pattern.  */
   RE_TRANSLATE_TYPE translate = bufp->translate;
@@ -2507,7 +2507,7 @@
 
   /* Place in the uncompiled pattern (i.e., the {) to
      which to go back if the interval is invalid.  */
-  re_char *beg_interval;
+  const re_char *beg_interval;
 
   /* Address of the place where a forward jump should go to the end of
      the containing expression.  Each alternative of an `or' -- except the
@@ -2525,9 +2525,9 @@
 
   /* These hold the values of p, pattern, and pend from the main
      pattern when we have pushed into a subpattern.  */
-  re_char *main_p IF_LINT (= NULL);
-  re_char *main_pattern IF_LINT (= NULL);
-  re_char *main_pend IF_LINT (= NULL);
+  const re_char *main_p IF_LINT (= NULL);
+  const re_char *main_pattern IF_LINT (= NULL);
+  const re_char *main_pend IF_LINT (= NULL);
 
 #ifdef DEBUG
   debug++;
@@ -2616,7 +2616,7 @@
 	{
 	case ' ':
 	  {
-	    re_char *p1 = p;
+	    const re_char *p1 = p;
 
 	    /* If there's no special whitespace regexp, treat
 	       spaces normally.  And don't try to do this recursively.  */
@@ -2837,7 +2837,7 @@
 
 	case '[':
 	  {
-	    re_char *p1;
+	    const re_char *p1;
 
 	    CLEAR_RANGE_TABLE_WORK_USED (range_table_work);
 
@@ -3215,7 +3215,7 @@
 		  }
 		else
 		  /* It's really shy.  */
-		  regnum = - bufp->re_nsub;
+		  regnum = - ((int)bufp->re_nsub);
 
 		if (COMPILE_STACK_FULL)
 		  {
@@ -3831,7 +3831,7 @@
 static boolean
 at_begline_loc_p (const re_char *pattern, const re_char *p, reg_syntax_t syntax)
 {
-  re_char *prev = p - 2;
+  const re_char *prev = p - 2;
   boolean prev_prev_backslash = prev > pattern && prev[-1] == '\\';
 
   return
@@ -3853,9 +3853,9 @@
 static boolean
 at_endline_loc_p (const re_char *p, const re_char *pend, reg_syntax_t syntax)
 {
-  re_char *next = p;
+  const re_char *next = p;
   boolean next_backslash = *next == '\\';
-  re_char *next_next = p + 1 < pend ? p + 1 : 0;
+  const re_char *next_next = p + 1 < pend ? p + 1 : 0;
 
   return
        /* Before a subexpression?  */
@@ -3931,7 +3931,7 @@
 	    3..9: <body>
 	    10: on_failure_jump 3
 	 as used for the *? operator.  */
-      re_char *p1 = p;
+      const re_char *p1 = p;
 
       switch (SWITCH_ENUM_CAST ((re_opcode_t) *p++))
 	{
@@ -4521,9 +4521,9 @@
 	  /* Update STARTPOS to the previous character boundary.  */
 	  if (multibyte)
 	    {
-	      re_char *p = POS_ADDR_VSTRING (startpos) + 1;
-	      re_char *p0 = p;
-	      re_char *phead = HEAD_ADDR_VSTRING (startpos);
+	      const re_char *p = POS_ADDR_VSTRING (startpos) + 1;
+	      const re_char *p0 = p;
+	      const re_char *phead = HEAD_ADDR_VSTRING (startpos);
 
 	      /* Find the head of multibyte form.  */
 	      PREV_CHAR_BOUNDARY (p, phead);
@@ -4541,7 +4541,7 @@
 \f
 /* Declarations and macros for re_match_2.  */
 
-static int bcmp_translate _RE_ARGS ((re_char *s1, re_char *s2,
+static int bcmp_translate _RE_ARGS ((const re_char *s1, const re_char *s2,
                                      register ssize_t len,
                                      RE_TRANSLATE_TYPE translate,
                                      const int multibyte));
@@ -4638,7 +4638,7 @@
 
 /* If the operation is a match against one or more chars,
    return a pointer to the next operation, else return NULL.  */
-static re_char *
+static const re_char *
 skip_one_char (const re_char *p)
 {
   switch (SWITCH_ENUM_CAST (*p++))
@@ -4680,7 +4680,7 @@
 
 
 /* Jump over non-matching operations.  */
-static re_char *
+static const re_char *
 skip_noops (const re_char *p, const re_char *pend)
 {
   int mcnt;
@@ -4976,24 +4976,24 @@
   size_t reg;
 
   /* Just past the end of the corresponding string.  */
-  re_char *end1, *end2;
+  const re_char *end1, *end2;
 
   /* Pointers into string1 and string2, just past the last characters in
      each to consider matching.  */
-  re_char *end_match_1, *end_match_2;
+  const re_char *end_match_1, *end_match_2;
 
   /* Where we are in the data, and the end of the current string.  */
-  re_char *d, *dend;
+  const re_char *d, *dend;
 
   /* Used sometimes to remember where we were before starting matching
      an operator so that we can go back in case of failure.  This "atomic"
      behavior of matching opcodes is indispensable to the correctness
      of the on_failure_keep_string_jump optimization.  */
-  re_char *dfail;
+  const re_char *dfail;
 
   /* Where we are in the pattern, and the end of the pattern.  */
-  re_char *p = bufp->buffer;
-  re_char *pend = p + bufp->used;
+  const re_char *p = bufp->buffer;
+  const re_char *pend = p + bufp->used;
 
   /* We use this to map every character in the string.	*/
   RE_TRANSLATE_TYPE translate = bufp->translate;
@@ -5037,7 +5037,7 @@
      stopped matching the regnum-th subexpression.  (The zeroth register
      keeps track of what the whole pattern matches.)  */
 #ifdef MATCH_MAY_ALLOCATE /* otherwise, these are global.  */
-  re_char **regstart, **regend;
+  const re_char **regstart, **regend;
 #endif
 
   /* The following record the register info as found in the above
@@ -5046,7 +5046,7 @@
      turn happens only if we have not yet matched the entire string. */
   unsigned best_regs_set = false;
 #ifdef MATCH_MAY_ALLOCATE /* otherwise, these are global.  */
-  re_char **best_regstart, **best_regend;
+  const re_char **best_regstart, **best_regend;
 #endif
 
   /* Logically, this is `best_regend[0]'.  But we don't want to have to
@@ -5057,7 +5057,7 @@
      the end of the best match so far in a separate variable.  We
      initialize this to NULL so that when we backtrack the first time
      and need to test it, it's not garbage.  */
-  re_char *match_end = NULL;
+  const re_char *match_end = NULL;
 
 #ifdef DEBUG
   /* Counts the total number of registers pushed.  */
@@ -5484,7 +5484,7 @@
 
 	    /* Start of actual range_table, or end of bitmap if there is no
 	       range table.  */
-	    re_char *range_table IF_LINT (= NULL);
+	    const re_char *range_table IF_LINT (= NULL);
 
 	    /* Nonzero if there is a range table.  */
 	    int range_table_exists;
@@ -5626,7 +5626,7 @@
 	   followed by the numeric value of <digit> as the register number.  */
 	case duplicate:
 	  {
-	    register re_char *d2, *dend2;
+	    const register re_char *d2, *dend2;
 	    int regno = *p++;	/* Get which register to match against.  */
 	    DEBUG_PRINT2 ("EXECUTING duplicate %d.\n", regno);
 
@@ -5854,7 +5854,7 @@
 	  DEBUG_PRINT3 ("EXECUTING on_failure_jump_smart %d (to %p).\n",
 			mcnt, p + mcnt);
 	  {
-	    re_char *p1 = p; /* Next operation.  */
+	    const re_char *p1 = p; /* Next operation.  */
 	    /* Here, we discard `const', making re_match non-reentrant.  */
 	    unsigned char *p2 = (unsigned char*) p + mcnt; /* Jump dest.  */
 	    unsigned char *p3 = (unsigned char*) p - 3; /* opcode location.  */
@@ -6251,7 +6251,7 @@
       IMMEDIATE_QUIT_CHECK;
       if (!FAIL_STACK_EMPTY ())
 	{
-	  re_char *str, *pat;
+	  const re_char *str, *pat;
 	  /* A restart point is known.  Restore to that state.  */
 	  DEBUG_PRINT1 ("\nFAIL:\n");
 	  POP_FAILURE_POINT (str, pat);
@@ -6309,9 +6309,9 @@
 bcmp_translate (const re_char *s1, const re_char *s2, register ssize_t len,
 		RE_TRANSLATE_TYPE translate, const int target_multibyte)
 {
-  register re_char *p1 = s1, *p2 = s2;
-  re_char *p1_end = s1 + len;
-  re_char *p2_end = s2 + len;
+  const register re_char *p1 = s1, *p2 = s2;
+  const re_char *p1_end = s1 + len;
+  const re_char *p2_end = s2 + len;
 
   /* FIXME: Checking both p1 and p2 presumes that the two strings might have
      different lengths, but relying on a single `len' would break this. -sm  */

=== modified file 'src/s/ms-w32.h'
--- src/s/ms-w32.h	2012-01-19 07:21:25 +0000
+++ src/s/ms-w32.h	2012-02-28 14:08:20 +0000
@@ -191,6 +191,14 @@
 #include <sys/timeb.h>
 #include <sys/stat.h>
 #include <signal.h>
+#include <string.h>
+#include <stdio.h>
+extern void *e_malloc(size_t);
+extern void e_free(void *);
+extern void *e_realloc(void *, size_t);
+#ifndef _CRT_ALLOCATION_DEFINED
+#define _CRT_ALLOCATION_DEFINED
+#endif
 
 /* MSVC gets link-time errors without these redirections.  */
 #define fstat(a, b) sys_fstat(a, b)
@@ -281,13 +289,14 @@
 #define utimbuf	  _utimbuf
 #endif
 #define strdup    _strdup
+#define strtoll   _strtoi64
 #define strupr    _strupr
 #define strnicmp  _strnicmp
 #define stricmp   _stricmp
 #define tzset     _tzset
 
+#if !defined (_MSC_VER) /* || (_MSC_VER < 1400) */
 #define tzname    _tzname
-#if !defined (_MSC_VER) || (_MSC_VER < 1400)
 #undef  utime
 #define utime	  _utime
 #endif
@@ -406,5 +415,12 @@
 #define DebPrint(stuff)
 #endif
 
+#ifdef _MSC_VER
+#if _MSC_VER >= 800 && !defined(__cplusplus)
+#pragma warning(disable:4116)
+#pragma warning(disable:4715)
+#pragma warning(disable:4244)
+#endif
+#endif
 
 /* ============================================================ */

=== modified file 'src/unexw32.c'
--- src/unexw32.c	2012-01-19 07:21:25 +0000
+++ src/unexw32.c	2012-02-05 20:06:34 +0000
@@ -67,18 +67,18 @@
 /* Cached info about the .data section in the executable.  */
 PIMAGE_SECTION_HEADER data_section;
 PCHAR  data_start = 0;
-DWORD  data_size = 0;
+DWORD_PTR  data_size = 0;
 
 /* Cached info about the .bss section in the executable.  */
 PIMAGE_SECTION_HEADER bss_section;
 PCHAR  bss_start = 0;
-DWORD  bss_size = 0;
-DWORD  extra_bss_size = 0;
+DWORD_PTR  bss_size = 0;
+DWORD_PTR  extra_bss_size = 0;
 /* bss data that is static might be discontiguous from non-static.  */
 PIMAGE_SECTION_HEADER bss_section_static;
 PCHAR  bss_start_static = 0;
-DWORD  bss_size_static = 0;
-DWORD  extra_bss_size_static = 0;
+DWORD_PTR  bss_size_static = 0;
+DWORD_PTR  extra_bss_size_static = 0;
 
 PIMAGE_SECTION_HEADER heap_section;
 
@@ -231,7 +231,7 @@
 /* Return pointer to section header for section containing the given
    relative virtual address. */
 IMAGE_SECTION_HEADER *
-rva_to_section (DWORD rva, IMAGE_NT_HEADERS * nt_header)
+rva_to_section (DWORD_PTR rva, IMAGE_NT_HEADERS * nt_header)
 {
   PIMAGE_SECTION_HEADER section;
   int i;
@@ -246,7 +246,7 @@
 	 some very old exes (eg. gzip dated Dec 1993).  Since
 	 w32_executable_type relies on this function to work reliably,
 	 we need to cope with this.  */
-      DWORD real_size = max (section->SizeOfRawData,
+      DWORD_PTR real_size = max (section->SizeOfRawData,
 			     section->Misc.VirtualSize);
       if (rva >= section->VirtualAddress
 	  && rva < section->VirtualAddress + real_size)
@@ -259,7 +259,7 @@
 /* Return pointer to section header for section containing the given
    offset in its raw data area. */
 IMAGE_SECTION_HEADER *
-offset_to_section (DWORD offset, IMAGE_NT_HEADERS * nt_header)
+offset_to_section (DWORD_PTR offset, IMAGE_NT_HEADERS * nt_header)
 {
   PIMAGE_SECTION_HEADER section;
   int i;
@@ -279,8 +279,8 @@
 /* Return offset to an object in dst, given offset in src.  We assume
    there is at least one section in both src and dst images, and that
    the some sections may have been added to dst (after sections in src).  */
-DWORD
-relocate_offset (DWORD offset,
+DWORD_PTR
+relocate_offset (DWORD_PTR offset,
 		 IMAGE_NT_HEADERS * src_nt_header,
 		 IMAGE_NT_HEADERS * dst_nt_header)
 {
@@ -314,16 +314,16 @@
 }
 
 #define OFFSET_TO_RVA(offset, section) \
-	  (section->VirtualAddress + ((DWORD)(offset) - section->PointerToRawData))
+	  (section->VirtualAddress + ((DWORD_PTR)(offset) - section->PointerToRawData))
 
 #define RVA_TO_OFFSET(rva, section) \
-	  (section->PointerToRawData + ((DWORD)(rva) - section->VirtualAddress))
+	  (section->PointerToRawData + ((DWORD_PTR)(rva) - section->VirtualAddress))
 
 #define RVA_TO_SECTION_OFFSET(rva, section) \
-	  ((DWORD)(rva) - section->VirtualAddress)
+	  ((DWORD_PTR)(rva) - section->VirtualAddress)
 
 /* Convert address in executing image to RVA.  */
-#define PTR_TO_RVA(ptr) ((DWORD)(ptr) - (DWORD) GetModuleHandle (NULL))
+#define PTR_TO_RVA(ptr) ((DWORD_PTR)(ptr) - (DWORD_PTR) GetModuleHandle (NULL))
 
 #define RVA_TO_PTR(var,section,filedata) \
 	  ((void *)(RVA_TO_OFFSET (var,section) + (filedata).file_base))
@@ -332,7 +332,7 @@
           ((unsigned char *)(ptr) - (pfile_data)->file_base)
 
 #define OFFSET_TO_PTR(offset, pfile_data) \
-          ((pfile_data)->file_base + (DWORD)(offset))
+          ((pfile_data)->file_base + (DWORD_PTR)(offset))
 
 
 /* Flip through the executable and cache the info necessary for dumping.  */
@@ -349,7 +349,7 @@
       printf ("Unknown EXE header in %s...bailing.\n", p_infile->name);
       exit (1);
     }
-  nt_header = (PIMAGE_NT_HEADERS) (((unsigned long) dos_header) +
+  nt_header = (PIMAGE_NT_HEADERS) (((DWORD_PTR) dos_header) +
 				   dos_header->e_lfanew);
   if (nt_header == NULL)
     {
@@ -488,7 +488,7 @@
   PIMAGE_NT_HEADERS dst_nt_header;
   PIMAGE_SECTION_HEADER section;
   PIMAGE_SECTION_HEADER dst_section;
-  DWORD offset;
+  DWORD_PTR offset;
   int i;
   int be_verbose = GetEnvironmentVariable ("DEBUG_DUMP", NULL, 0) > 0;
 
@@ -541,17 +541,17 @@
      Note that dst is updated implicitly by each COPY_CHUNK.  */
 
   dos_header = (PIMAGE_DOS_HEADER) p_infile->file_base;
-  nt_header = (PIMAGE_NT_HEADERS) (((unsigned long) dos_header) +
+  nt_header = (PIMAGE_NT_HEADERS) (((DWORD_PTR) dos_header) +
 				   dos_header->e_lfanew);
   section = IMAGE_FIRST_SECTION (nt_header);
 
   dst = (unsigned char *) p_outfile->file_base;
 
   COPY_CHUNK ("Copying DOS header...", dos_header,
-	      (DWORD) nt_header - (DWORD) dos_header, be_verbose);
+	      (DWORD_PTR) nt_header - (DWORD_PTR) dos_header, be_verbose);
   dst_nt_header = (PIMAGE_NT_HEADERS) dst;
   COPY_CHUNK ("Copying NT header...", nt_header,
-	      (DWORD) section - (DWORD) nt_header, be_verbose);
+	      (DWORD_PTR) section - (DWORD_PTR) nt_header, be_verbose);
   dst_section = (PIMAGE_SECTION_HEADER) dst;
   COPY_CHUNK ("Copying section table...", section,
 	      nt_header->FileHeader.NumberOfSections * sizeof (*section),
@@ -627,8 +627,8 @@
 	}
       if (section == heap_section)
 	{
-	  DWORD heap_start = (DWORD) get_heap_start ();
-	  DWORD heap_size = get_committed_heap_size ();
+	  DWORD_PTR heap_start = (DWORD_PTR) get_heap_start ();
+	  DWORD_PTR heap_size = get_committed_heap_size ();
 
 	  /* Dump the used portion of the predump heap, adjusting the
              section's size to the appropriate size.  */

=== modified file 'src/vm-limit.c'
--- src/vm-limit.c	2012-01-19 07:21:25 +0000
+++ src/vm-limit.c	2012-02-05 20:06:34 +0000
@@ -20,7 +20,7 @@
 #include <setjmp.h>
 #include "lisp.h"
 #include "mem-limits.h"
-
+#include "w32heap.h"
 /*
   Level number of warnings already issued.
   0 -- no warnings issued.
@@ -41,7 +41,7 @@
 static POINTER data_space_start;
 
 /* Number of bytes of writable memory we can expect to be able to get.  */
-static unsigned long lim_data;
+static size_t lim_data;
 \f
 
 #if defined (HAVE_GETRLIMIT) && defined (RLIMIT_AS)
@@ -79,7 +79,7 @@
     lim_data = ULIMIT_BREAK_VALUE;
 #endif
 
-  lim_data -= (long) data_space_start;
+  lim_data -= (intptr_t) data_space_start;
 }
 
 #else /* not USG */
@@ -88,7 +88,7 @@
 static void
 get_lim_data (void)
 {
-  extern unsigned long reserved_heap_size;
+  extern size_t reserved_heap_size;
   lim_data = reserved_heap_size;
 }
 
@@ -127,7 +127,7 @@
     lim_data = 512U * 1024U * 1024U;
 }
 
-unsigned long
+size_t
 ret_lim_data (void)
 {
   get_lim_data ();
@@ -166,13 +166,13 @@
 check_memory_limits (void)
 {
 #ifdef REL_ALLOC
-  extern POINTER (*real_morecore) (long);
+  extern POINTER (*real_morecore) (__malloc_ptrdiff_t);
 #endif
-  extern POINTER (*__morecore) (long);
+  extern POINTER (*__morecore) (__malloc_ptrdiff_t);
 
   register POINTER cp;
-  unsigned long five_percent;
-  unsigned long data_size;
+  size_t five_percent;
+  size_t data_size;
   enum warnlevel new_warnlevel;
 
   if (lim_data == 0)

=== modified file 'src/w32.c'
--- src/w32.c	2012-02-04 13:48:38 +0000
+++ src/w32.c	2012-02-27 23:33:18 +0000
@@ -19,6 +19,9 @@
 /*
    Geoff Voelker (voelker@cs.washington.edu)                         7-29-94
 */
+
+#define _CRT_ALLOCATION_DEFINED
+
 #include <stddef.h> /* for offsetof */
 #include <stdlib.h>
 #include <stdio.h>
@@ -1703,7 +1706,8 @@
       /* FIXME: should use substring of get_emacs_configuration ().
 	 But I don't think the Windows build supports alpha, mips etc
          anymore, so have taken the easy option for now.  */
-      else if (p && xstrcasecmp (p, "\\i386") == 0)
+      else if (p && (xstrcasecmp (p, "\\i386") == 0
+                     || xstrcasecmp (p, "\\AMD64") == 0))
 	{
 	  *p = 0;
 	  p = strrchr (modname, '\\');
@@ -1861,7 +1865,12 @@
     case PROCESSOR_INTEL_386:
     case PROCESSOR_INTEL_486:
     case PROCESSOR_INTEL_PENTIUM:
+    case PROCESSOR_AMD_X8664:
+#ifdef _WIN64
+      arch = "amd64";
+#else
       arch = "i386";
+#endif
       break;
 #endif
 
@@ -2400,7 +2409,7 @@
 	return NULL;
     }
 
-  if (!(dirp = (DIR *) malloc (sizeof (DIR))))
+  if (!(dirp = (DIR *) xmalloc (sizeof (DIR))))
     return NULL;
 
   dirp->dd_fd = 0;

=== modified file 'src/w32.h'
--- src/w32.h	2012-01-19 07:21:25 +0000
+++ src/w32.h	2012-02-27 23:33:18 +0000
@@ -159,5 +159,9 @@
                                   const void* buf, size_t sz);
 #endif /* HAVE_GNUTLS */
 
+extern struct tm *sys_localtime (const time_t *t);
+extern char *sys_strerror(int error_no);
+extern FILE *sys_fopen (const char * path, const char * mode);
+
 #endif /* EMACS_W32_H */
 

=== modified file 'src/w32fns.c'
--- src/w32fns.c	2012-01-19 07:21:25 +0000
+++ src/w32fns.c	2012-02-27 23:33:18 +0000
@@ -74,7 +74,6 @@
 void globals_of_w32fns (void);
 
 extern void free_frame_menubar (struct frame *);
-extern double atof (const char *);
 extern int w32_console_toggle_lock_key (int, Lisp_Object);
 extern void w32_menu_display_help (HWND, HMENU, UINT, UINT);
 extern void w32_free_menu_strings (HWND);

=== modified file 'src/w32heap.c'
--- src/w32heap.c	2012-01-19 07:21:25 +0000
+++ src/w32heap.c	2012-02-28 14:03:03 +0000
@@ -27,7 +27,7 @@
 #include "w32heap.h"
 #include "lisp.h"  /* for VALMASK */
 
-#define RVA_TO_PTR(rva) ((unsigned char *)((DWORD)(rva) + (DWORD)GetModuleHandle (NULL)))
+#define RVA_TO_PTR(rva) ((unsigned char *)((DWORD_PTR)(rva) + (DWORD_PTR)GetModuleHandle (NULL)))
 
 /* This gives us the page size and the size of the allocation unit on NT.  */
 SYSTEM_INFO sysinfo_cache;
@@ -98,7 +98,7 @@
 unsigned char *data_region_base = NULL;
 unsigned char *data_region_end = NULL;
 unsigned char *real_data_region_end = NULL;
-unsigned long  reserved_heap_size = 0;
+size_t  reserved_heap_size = 0;
 
 /* The start of the data segment.  */
 unsigned char *
@@ -122,16 +122,20 @@
      the preload heap section up to the usable address limit.  Since GNU
      malloc can handle gaps in the memory it gets from sbrk, we can
      simply set the sbrk pointer to the base of the new heap region.  */
-  unsigned long base =
+  DWORD_PTR base =
     ROUND_UP ((RVA_TO_PTR (preload_heap_section->VirtualAddress)
 	       + preload_heap_section->Misc.VirtualSize),
 	      get_allocation_unit ());
-  unsigned long end  = 1 << VALBITS; /* 256MB */
+  DWORD_PTR end  = ((unsigned __int64)1) << VALBITS; /* 256MB */
   void *ptr = NULL;
 
   while (!ptr && (base < end))
     {
+#ifdef _WIN64
+      reserved_heap_size = min(end - base, 0x800000000i64); /* Limit to 32Gb */
+#else
       reserved_heap_size = end - base;
+#endif
       ptr = VirtualAlloc ((void *) base,
 			  get_reserved_heap_size (),
 			  MEM_RESERVE,
@@ -145,7 +149,11 @@
 static char *
 allocate_heap (void)
 {
-  unsigned long size = 0x80000000; /* start by asking for 2GB */
+#ifdef _WIN64
+  size_t size = 0x800000000i64; /* start by asking for 32GB */
+#else
+  size_t size = 0x80000000; /* start by asking for 2GB */
+#endif
   void *ptr = NULL;
 
   while (!ptr && size > 0x00100000)
@@ -167,17 +175,17 @@
    be the address of the _start_ (not end) of the new block in case of
    success, and zero (not -1) in case of failure.  */
 void *
-sbrk (unsigned long increment)
+sbrk (size_t increment)
 {
   void *result;
-  long size = (long) increment;
+  ptrdiff_t size = (ptrdiff_t)increment;
 
   result = data_region_end;
 
   /* If size is negative, shrink the heap by decommitting pages.  */
   if (size < 0)
     {
-      int new_size;
+      ptrdiff_t new_size;
       unsigned char *new_data_region_end;
 
       size = -size;
@@ -190,7 +198,7 @@
 	 partial deallocation [cga].  */
       new_data_region_end = (data_region_end - size);
       new_data_region_end = (unsigned char *)
-	((long) (new_data_region_end + syspage_mask) & ~syspage_mask);
+	((DWORD_PTR) (new_data_region_end + syspage_mask) & ~syspage_mask);
       new_size = real_data_region_end - new_data_region_end;
       real_data_region_end = new_data_region_end;
       if (new_size > 0)
@@ -221,7 +229,7 @@
       /* We really only commit full pages, so record where
 	 the real end of committed memory is [cga].  */
       real_data_region_end = (unsigned char *)
-	  ((long) (data_region_end + syspage_mask) & ~syspage_mask);
+	  ((DWORD_PTR) (data_region_end + syspage_mask) & ~syspage_mask);
     }
 
   return result;
@@ -246,7 +254,7 @@
   PIMAGE_NT_HEADERS nt_header;
 
   dos_header = (PIMAGE_DOS_HEADER) RVA_TO_PTR (0);
-  nt_header = (PIMAGE_NT_HEADERS) (((unsigned long) dos_header) +
+  nt_header = (PIMAGE_NT_HEADERS) (((DWORD_PTR) dos_header) +
 				   dos_header->e_lfanew);
   preload_heap_section = find_section ("EMHEAP", nt_header);
 
@@ -262,7 +270,7 @@
 #if !defined (USE_LISP_UNION_TYPE) && !defined (USE_LSB_TAG)
       /* Ensure that the addresses don't use the upper tag bits since
 	 the Lisp type goes there.  */
-      if (((unsigned long) data_region_base & ~VALMASK) != 0)
+      if (((DWORD_PTR) data_region_base & ~VALMASK) != 0)
 	{
 	  printf ("Error: The heap was allocated in upper memory.\n");
 	  exit (1);
@@ -285,13 +293,13 @@
 
 /* Round the heap up to the given alignment.  */
 void
-round_heap (unsigned long align)
+round_heap (DWORD_PTR align)
 {
-  unsigned long needs_to_be;
-  unsigned long need_to_alloc;
+  DWORD_PTR needs_to_be;
+  DWORD_PTR need_to_alloc;
 
-  needs_to_be = (unsigned long) ROUND_UP (get_heap_end (), align);
-  need_to_alloc = needs_to_be - (unsigned long) get_heap_end ();
+  needs_to_be = (DWORD_PTR) ROUND_UP (get_heap_end (), align);
+  need_to_alloc = needs_to_be - (DWORD_PTR) get_heap_end ();
 
   if (need_to_alloc)
     sbrk (need_to_alloc);

=== modified file 'src/w32heap.h'
--- src/w32heap.h	2012-01-19 07:21:25 +0000
+++ src/w32heap.h	2012-02-05 20:06:34 +0000
@@ -24,8 +24,8 @@
 
 #include <windows.h>
 
-#define ROUND_UP(p, align)   (((DWORD)(p) + (align)-1) & ~((align)-1))
-#define ROUND_DOWN(p, align) ((DWORD)(p) & ~((align)-1))
+#define ROUND_UP(p, align)   (((DWORD_PTR)(p) + (align)-1) & ~((align)-1))
+#define ROUND_DOWN(p, align) ((DWORD_PTR)(p) & ~((align)-1))
 
 /*
  * Heap related stuff.
@@ -42,7 +42,7 @@
 
 extern unsigned char *get_data_start (void);
 extern unsigned char *get_data_end (void);
-extern unsigned long  reserved_heap_size;
+extern size_t         reserved_heap_size;
 extern SYSTEM_INFO    sysinfo_cache;
 extern OSVERSIONINFO  osinfo_cache;
 extern BOOL   	      using_dynamic_heap;
@@ -58,13 +58,13 @@
 extern int os_subtype;
 
 /* Emulation of Unix sbrk().  */
-extern void *sbrk (unsigned long size);
+extern void *sbrk (size_t size);
 
 /* Initialize heap structures for sbrk on startup.  */
 extern void init_heap (void);
 
 /* Round the heap to this size.  */
-extern void round_heap (unsigned long size);
+extern void round_heap (size_t size);
 
 /* Cache system info, e.g., the NT page size.  */
 extern void cache_system_info (void);
@@ -89,7 +89,7 @@
 
 /* Return pointer to section header for section containing the given
    relative virtual address. */
-IMAGE_SECTION_HEADER * rva_to_section (DWORD rva, IMAGE_NT_HEADERS * nt_header);
+IMAGE_SECTION_HEADER * rva_to_section (DWORD_PTR rva, IMAGE_NT_HEADERS * nt_header);
 
 #endif /* NTHEAP_H_ */
 

=== modified file 'src/w32proc.c'
--- src/w32proc.c	2012-01-19 07:21:25 +0000
+++ src/w32proc.c	2012-02-27 23:33:15 +0000
@@ -21,6 +21,8 @@
      Adapted from alarm.c by Tim Fleehart
 */
 
+#define _CRT_ALLOCATION_DEFINED
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <errno.h>
@@ -63,7 +65,7 @@
 
 #define RVA_TO_PTR(var,section,filedata) \
   ((void *)((section)->PointerToRawData					\
-	    + ((DWORD)(var) - (section)->VirtualAddress)		\
+	    + ((DWORD_PTR)(var) - (section)->VirtualAddress)		\
 	    + (filedata).file_base))
 
 Lisp_Object Qhigh, Qlow;

=== modified file 'src/xfaces.c'
--- src/xfaces.c	2012-02-06 08:19:09 +0000
+++ src/xfaces.c	2012-02-27 23:33:18 +0000
@@ -226,6 +226,7 @@
 #endif
 
 #ifdef WINDOWSNT
+#include "w32.h"
 #include "w32term.h"
 #include "fontset.h"
 /* Redefine X specifics to W32 equivalents to avoid cluttering the

Re: Windows 64 port

[Paul Eggert]

On 02/28/2012 01:32 PM, Fabrice Popineau wrote:

> If I define tzname as _tzname is ms-w32.h, I get an error when
> including MS time.h on some function returning an array.

It should be possible to work around this problem without having to
modify lib/strftime.c.  For example, src/s/ms-w32.h can do something like this:

   /* Include <time.h> before defining tzname, to avoid DLL clash.  */
   #include <time.h>
   #define tzname _tzname

This should avoid the diagnostic, since tzname isn't defined until
after <time.h> is included.  It's better to keep Microsoft-specific
stuff in Microsoft-specific source files when possible, as seems to
be the case here.


>     >  #ifdef WINDOWSNT
>     >  extern Lisp_Object w32_get_internal_run_time (void);
>     > +
>     > +extern struct tm *localtime (const time_t *t);
>     >  #endif
> 
>     Why is this needed?  It seems also unrelated to 64-bit Windows.
> 
> To remove a warning on localtime not define.

Surely this should be done via "#include <time.h>", not by repeating
some of the internals of time.h.

> - const problems in regex.c (large patch, but harmless)

None of the regex.c changes are needed for Windows 64.  The code works
fine without it and the patch does not fix any bugs.  Perhaps regex.c
should be made cleaner, const-wise, but that's an independent issue
and if we want to make that change it be as part of an independent patch.

From now on, when I say "Not needed for Windows 64", I mean that any
such patch should be proposed independently of the Windows 64 patch,
since the code works fine as-is on Windows 64.  This is not to say or
imply that the patch isn't helpful; just that it should be considered
separately and independently.

> - turn off compiler warnings of 3 kinds (harmless, but frequent in emacs code)

Not needed for Windows 64, since these warnings are harmless.


Here is a more-detailed review of the latest patch you sent.

> -      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
> +      int i = 0, aligned = (ABLOCKS_BUSY (abase) != NULL);

Not needed for Windows 64.  The change slows the code down a bit, and
it might not work on unusual hosts that have filler bits in their
pointers.  Anyway, if we're going to change the usage of ABLOCKS_BUSY
when it is (ab)used as an integer, such a change should be systematic,
and not just to the single use that MSVC happens to diagnose.

> -allocate_pseudovector (int memlen, int lisplen, EMACS_INT tag)
> +allocate_pseudovector (size_t memlen, size_t lisplen, EMACS_INT tag)

Not needed for Windows 64, since the arguments are all in int range.

> -	    int size = min (2000, max (20, (nextb->text->z_byte / 10)));
> +	    size_t size = min (2000, max (20, (nextb->text->z_byte / 10)));

Not needed for Windows 64, since 'size' is in int range.

> -		make_gap (-(nextb->text->gap_size - size));
> +		make_gap ((size - nextb->text->gap_size));

Not needed for Windows 64, since the expressions are equivalent.

> +      extern Lisp_Object x_get_focus_frame(struct frame *);

This should be done via an include file, not by putting an
extern function declaration inside some block.

> -  unsigned long int adj;
> +  intptr_t adj;

Not needed for Windows 64; the value is always in unsigned long range.

> -  adj = (unsigned long int) ((unsigned long int) ((char *) result -
> -						  (char *) NULL)) % BLOCKSIZE;
> +  adj = (intptr_t) (((char *) result -
> +                     (char *) NULL)) % BLOCKSIZE;

Not needed for Windows 64, since BLOCKSIZE is a power of 2 and the
arithmetic is well-defined.  Also, the proposed replacement code is
wrong, since it might make adj go negative.

> -    _heapinfo[block + blocks].busy.info.size = -blocks;
> +    _heapinfo[block + blocks].busy.info.size = -((__malloc_ptrdiff_t)blocks);

Not needed for Windows 64.

> - 	      (*__morecore) (-size);
> + 	      (*__morecore) (-((__malloc_ptrdiff_t)size));

Not needed for Windows 64.

> - 	  (*__morecore) (- newsize * sizeof (malloc_info));
> + 	  (*__morecore) (- ((ptrdiff_t)(newsize * sizeof (malloc_info))));

Not needed for Windows 64.

> -	    _heapinfo[block].busy.info.frag.first = (unsigned long int)
> -	      ((unsigned long int) ((char *) next->next - (char *) NULL)
> +	    _heapinfo[block].busy.info.frag.first = (intptr_t)
> +	      (((char *) next->next - (char *) NULL)
>  	       % BLOCKSIZE) >> log;

Not needed for Windows 64, since BLOCKSIZE is a small power of 2.
Also, the replacement mishandles the sign bit of the pointer.

> -	_heapinfo[block + blocks].busy.info.size = -blocks;
> +	_heapinfo[block + blocks].busy.info.size = -((ptrdiff_t)blocks);

Not needed for Windows 64.

> -	      (*__morecore) (-bytes);
> +	      (*__morecore) (-((__malloc_ptrdiff_t)bytes));

Not needed for Windows 64.

> -	  _heapinfo[block].busy.info.frag.first = (unsigned long int)
> -	    ((unsigned long int) ((char *) ptr - (char *) NULL)
> +	  _heapinfo[block].busy.info.frag.first = (intptr_t)
> +	    ((intptr_t) ((char *) ptr - (char *) NULL)
>  	     % BLOCKSIZE >> type);

Not needed for Windows 64.  Also, mishandles the sign bit of the difference.

> +#ifdef min
> +#undef min
> +#endif

Why is this needed?  If it's merely to suppress a warning then it's
not needed for Windows 64.  If not, please explain.

> -  unsigned long int adj, lastadj;
> +  intptr_t adj, lastadj;

Not needed for Windows 64.

> -  adj = (unsigned long int) ((char *) result - (char *) NULL) % alignment;
> +  adj = (intptr_t) ((char *) result - (char *) NULL) % alignment;

Not needed for Windows 64, since the alignment is a small power of two.
(This is also buggy with the sign bit.)

> -      adj = (unsigned long int) ((char *) result - (char *) NULL) % alignment;
> +      adj = (intptr_t) ((char *) result - (char *) NULL) % alignment;

Not needed for Windows 64, since the alignment is a small power of two.
(This is also buggy with the sign bit.)

> -    unsigned long int magic;	/* Magic number to check header integrity.  */
> +    uint64_t magic;	/* Magic number to check header integrity.  */

Not needed for Windows 64, since the magic number fits in 32 bits.

> --- src/image.c	2012-02-15 06:40:08 +0000
> +++ src/image.c	2012-02-19 21:54:33 +0000
> @@ -16,6 +16,10 @@
>  You should have received a copy of the GNU General Public License
>  along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
>  
> +#ifdef _MSC_VER
> +#define _W32COMPAT_H_ 1
> +#endif

Why is this patch needed in mainline code?  Can't it be put into
src/s/ms-w32.h?

> -#define XFASTINT(a) ((a) + 0)
> +#define XFASTINT(a) (((a) + 0))

Not needed at all.  (Didn't we already discuss this one?)

> -extern struct Lisp_Vector *allocate_pseudovector (int memlen, int lisplen, EMACS_INT tag);
> +extern struct Lisp_Vector *allocate_pseudovector (size_t memlen, size_t lisplen, EMACS_INT tag);

Not needed for Windows 64, since the values fit in 'int'.

> === modified file 'src/m/amdx86-64.h'
> --- src/m/amdx86-64.h	2012-01-19 07:21:25 +0000
> +++ src/m/amdx86-64.h	2012-02-28 07:00:30 +0000
> @@ -17,7 +17,13 @@
>  You should have received a copy of the GNU General Public License
>  along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
>  
> -#define BITS_PER_LONG           64
> +#ifdef _WIN64
> +# define BITS_PER_LONG           32
> +# define BITS_PER_LONG_LONG      64
> +#else
> +# define BITS_PER_LONG           64
> +#endif

Since this stuff is normally defined by 'configure', it should be put
into nt/config.nt rather than into a src/m/* file; there shouldn't be
a need to use or to modify src/m/amdx86-64.h.  Similarly for the other
changes to src/m/amdx86-64.h.  I don't see how that file is used under
Windows 64; but if it is, we should fix that, and not change the file.

> +#define SIZE ESIZE

I don't see the reason for this #define; could you please explain?
If it is needed, let's just dump SIZE entirely, and use size_t instead.

> -#define ALIGNED(addr) (((unsigned long int) (addr) & (page_size - 1)) == 0)
> -#define ROUNDUP(size) (((unsigned long int) (size) + page_size - 1) \
> +#define ALIGNED(addr) (((intptr_t) (addr) & (page_size - 1)) == 0)
> +#define ROUNDUP(size) (((intptr_t) (size) + page_size - 1) \
>  		       & ~(page_size - 1))

Please use uintptr_t rather than intptr_t, since the original uses
the unsigned types.  That's safer.

> -#define MEM_ROUNDUP(addr) (((unsigned long int)(addr) + MEM_ALIGN - 1) \
> +#define MEM_ROUNDUP(addr) (((intptr_t)(addr) + MEM_ALIGN - 1) \
>  				   & ~(MEM_ALIGN - 1))

Likewise, use uintptr_t not intptr_t.

> -long
> +intptr_t
>  r_alloc_size_in_use (void)

ptrdiff_t, not intptr_t, since it's arrived at by subtracting pointers.

> === modified file 'src/regex.c'
> --- src/regex.c	2012-01-19 07:21:25 +0000
> +++ src/regex.c	2012-02-27 23:33:18 +0000

None of the changes to this file are needed for Windows 64.

>  #ifdef REL_ALLOC
> -  extern POINTER (*real_morecore) (long);
> +  extern POINTER (*real_morecore) (__malloc_ptrdiff_t);
>  #endif
> -  extern POINTER (*__morecore) (long);
> +  extern POINTER (*__morecore) (__malloc_ptrdiff_t);

I don't see how this change could work, since __malloc_ptrdiff_t is
not visible in vm-limit.c.  I suggest just using ptrdiff_t.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 5556 bytes --]

2012/3/1 Paul Eggert <eggert@cs.ucla.edu>

> On 02/28/2012 01:32 PM, Fabrice Popineau wrote:
>
> > If I define tzname as _tzname is ms-w32.h, I get an error when
> > including MS time.h on some function returning an array.
>
> It should be possible to work around this problem without having to
> modify lib/strftime.c.  For example, src/s/ms-w32.h can do something like
> this:
>
>   /* Include <time.h> before defining tzname, to avoid DLL clash.  */
>   #include <time.h>
>   #define tzname _tzname
>
> This should avoid the diagnostic, since tzname isn't defined until
> after <time.h> is included.  It's better to keep Microsoft-specific
> stuff in Microsoft-specific source files when possible, as seems to
> be the case here.
>
>
The problem is trickier than this and probably need a careful rewrite of
ms-w32.h.
In this file, names like tzname or fopen get rewired. Some of them need to
be rewired to sys_fopen or _fopen (example) depending on whether it is for
emacs or not.
So a more robust way of doing things would be to ensure that all system
headers are read once
for all, then doing the rewiring for emacs and for (not emacs). That should
avoid the problem
of tzname for example. In the mean time, this is the smallest change I
could come with.
What you propose didn't work (resulting in either : some function returns
an array, that is tzname,
or _tzname being undefined at link time).


> >     >  #ifdef WINDOWSNT
> >     >  extern Lisp_Object w32_get_internal_run_time (void);
> >     > +
> >     > +extern struct tm *localtime (const time_t *t);
> >     >  #endif
> >
> >     Why is this needed?  It seems also unrelated to 64-bit Windows.
>

Sure but the definition needs to be put somewhere because an int is not the
same
size as a pointer in windows 64.



>  > - const problems in regex.c (large patch, but harmless)
>
> None of the regex.c changes are needed for Windows 64.  The code works
>
> I anwsered in a separate message. I never claimed it is needed by Windows
64 either.
(My only claim is that the whole thing I sent is what I needed to get a
clean compile.)

> - turn off compiler warnings of 3 kinds (harmless, but frequent in emacs
> code)
>
> Not needed for Windows 64, since these warnings are harmless.
>

Sure, but unless the source code is fixed to avois the warnings, it gets me
a cleaner compilation listing.



> Here is a more-detailed review of the latest patch you sent.
>
> > -      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
> > +      int i = 0, aligned = (ABLOCKS_BUSY (abase) != NULL);
>
> Not needed for Windows 64.  The change slows the code down a bit, and
>

Prove it. I bet your compiler is much more clever than you think. twenty
years ago, I would
have agree, not today.


> it might not work on unusual hosts that have filler bits in their
> pointers.


The it is because the compiler is buggy, because this is a perfectly legal
and much more
right than the double cascading cast (one explicit,  one implicit).

> -allocate_pseudovector (int memlen, int lisplen, EMACS_INT tag)
> > +allocate_pseudovector (size_t memlen, size_t lisplen, EMACS_INT tag)
>
> Not needed for Windows 64, since the arguments are all in int range.
>

Who knows that ? Certainly not the compiler.



> > -         int size = min (2000, max (20, (nextb->text->z_byte / 10)));
> > +         size_t size = min (2000, max (20, (nextb->text->z_byte / 10)));
>
> Not needed for Windows 64, since 'size' is in int range.
>

Same remark.


> > -             make_gap (-(nextb->text->gap_size - size));
> > +             make_gap ((size - nextb->text->gap_size));
>
> Not needed for Windows 64, since the expressions are equivalent.


Depends on signed/unsigned.



> > -  unsigned long int adj;
> > +  intptr_t adj;
>
> Not needed for Windows 64; the value is always in unsigned long range.
>
>
I thank you for all those intptr_t -> uintptr_t catches.


> > +#ifdef min
> > +#undef min
> > +#endif
>
>
Just because it is redefined when it is a commonly defined macro in system
headers.


> > -    unsigned long int magic; /* Magic number to check header integrity.
>  */
> > +    uint64_t magic;  /* Magic number to check header integrity.  */
>
> Not needed for Windows 64, since the magic number fits in 32 bits.
>
> If it is a 32bits integer, then better make it this way everywhere.


>
> > -extern struct Lisp_Vector *allocate_pseudovector (int memlen, int
> lisplen, EMACS_INT tag);
> > +extern struct Lisp_Vector *allocate_pseudovector (size_t memlen, size_t
> lisplen, EMACS_INT tag);
>
> Not needed for Windows 64, since the values fit in 'int'.
>
>
Again, the compiler does not know it.

> > +#define SIZE ESIZE
>
> I don't see the reason for this #define; could you please explain?
> If it is needed, let's just dump SIZE entirely, and use size_t instead.
>
>
Not needed, that was a redifinition of a system header macro.



> > -long
> > +intptr_t
> >  r_alloc_size_in_use (void)
>
> ptrdiff_t, not intptr_t, since it's arrived at by subtracting pointers.
>
> OK.


>
> >  #ifdef REL_ALLOC
> > -  extern POINTER (*real_morecore) (long);
> > +  extern POINTER (*real_morecore) (__malloc_ptrdiff_t);
> >  #endif
> > -  extern POINTER (*__morecore) (long);
> > +  extern POINTER (*__morecore) (__malloc_ptrdiff_t);
>
> I don't see how this change could work, since __malloc_ptrdiff_t is
> not visible in vm-limit.c.  I suggest just using ptrdiff_t.
>
>
It should be else I won't have been able to compile it. Anyway no problem
with that.
I'm not even sure why there is a __malloc_ptrdiff_t at all.

Fabrice

[-- Attachment #2: Type: text/html, Size: 8912 bytes --]

Re: Windows 64 port

[Paul Eggert]

On 02/29/2012 11:24 PM, Fabrice Popineau wrote:

>     For example, src/s/ms-w32.h can do something like this:
> 
>       /* Include <time.h> before defining tzname, to avoid DLL clash.  */
>       #include <time.h>
>       #define tzname _tzname
> 
>     This should avoid the diagnostic, since tzname isn't defined until
>     after <time.h> is included.

> What you propose didn't work (resulting in either : some function
> returns an array, that is tzname, or _tzname being undefined at link
> time).

Sorry, I don't follow.  What exactly happens when you try the above
suggestion, and why?  And what does this have to do with functions
returning arrays?

Perhaps you can explain, by showing the preprocessor output of
the failed attempt.

> the definition needs to be put somewhere because an int is not the same
> size as a pointer in windows 64.

OK, thanks, it appears you fixed that in a different way in the last
patch, so the point is moot.

> unless the source code is fixed to avois the warnings,
> it gets me a cleaner compilation listing.

Surely there's some way to tell the compiler to not issue the warnings.
Or you can simply ignore these bogus messages.

>     Here is a more-detailed review of the latest patch you sent.
> 
>     > -      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
>     > +      int i = 0, aligned = (ABLOCKS_BUSY (abase) != NULL);
> 
>     Not needed for Windows 64.  The change slows the code down a bit, and
> 
> 
> Prove it.

I compiled it both ways (x86-64 GCC 4.6.2), and the "!= NULL" version
has an extra "cmpl" instruction, so it is indeed a bit fatter.

>     it might not work on unusual hosts that have filler bits in their
>     pointers.
> 
> The it is because the compiler is buggy, because this is a perfectly legal and much more
> right than the double cascading cast (one explicit,  one implicit).

Sorry, it sounds like my suggestion wasn't clear.  On some
architectures, pointers have unused bits, there are multiple
representations of NULL, and the test for whether a pointer is NULL is
not the same as testing whether its bit-pattern is all zeros.
Compilers on such systems are not buggy: they are simply implementing
the machine's architecture.

Admittedly this point is probably theoretical.  As far as I know among
Emacs targets only the s390 architecture has unused bits in its
pointers, and I don't know whether its comparisons to NULL ignore
those bits.  Still, the point remains that one must be careful when
making changes like this, and there's no need for this particular
change for the Windows 64 port.

>     Not needed for Windows 64, since the arguments are all in int range.
> 
> Who knows that ? Certainly not the compiler.

*You* know it, because I just told you.  (:-)  I've read the code.

Similarly for your other remarks about the compiler not knowing
things.  In all these cases, the compiler may not be smart enough to
figure things out, but the values are indeed in range and there's no
need to alter the types.

>     > -             make_gap (-(nextb->text->gap_size - size));
>     > +             make_gap ((size - nextb->text->gap_size));
> 
>     Not needed for Windows 64, since the expressions are equivalent.
> 
> Depends on signed/unsigned. 

On Windows 64 the two expressions are equivalent, so there's no need
for this patch in the Windows 64 port.

>     > -  unsigned long int adj;
>     > +  intptr_t adj;
> 
>     Not needed for Windows 64; the value is always in unsigned long range.
> 
> I thank you for all those intptr_t -> uintptr_t catches.

You're welcome, but this is not an example of that.  The declaration
does not need to be changed, because the value of 'adj' is always
in the range 0..ULONG_MAX, on Windows 64 and on mainline hosts.

>     > +#ifdef min
>     > +#undef min
>     > +#endif
> 
> Just because it is redefined when it is a commonly defined macro in
> system headers.

Which system header defined it, and what exactly was it defined to?
If a system header defines 'min' it may not be wise to change it.

>     > -    unsigned long int magic; /* Magic number to check header integrity.  */
>     > +    uint64_t magic;  /* Magic number to check header integrity.  */
> 
>     Not needed for Windows 64, since the magic number fits in 32 bits.
> 
> If it is a 32bits integer, then better make it this way everywhere.

Perhaps -- but then why use uint64_t for a 32-bit quantity?
And anyway, the patch is not needed for Windows 64, regardless of what
type (if any) is substituted for unsigned long.

> I'm not even sure why there is a __malloc_ptrdiff_t at all.

It's a relic of the older pre-C89 environment.  These days we
should just remove __malloc_ptrdiff_t and use ptrdiff_t.
(But as part of a separate patch; it's not needed for Windows 64.)

Re: Windows 64 port

[Eli Zaretskii]

> Date: Thu, 01 Mar 2012 00:58:02 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, ajmr@ilovetortilladepatatas.com, 
>  emacs-devel@gnu.org
> 
> On 02/29/2012 11:24 PM, Fabrice Popineau wrote:
> 
> >     For example, src/s/ms-w32.h can do something like this:
> > 
> >       /* Include <time.h> before defining tzname, to avoid DLL clash.  */
> >       #include <time.h>
> >       #define tzname _tzname
> > 
> >     This should avoid the diagnostic, since tzname isn't defined until
> >     after <time.h> is included.
> 
> > What you propose didn't work (resulting in either : some function
> > returns an array, that is tzname, or _tzname being undefined at link
> > time).
> 
> Sorry, I don't follow.  What exactly happens when you try the above
> suggestion, and why?  And what does this have to do with functions
> returning arrays?

The declaration of tzname on Windows is essentially (dropping some
decorations that just obfuscate the essence)

   char     *_tzname[2];

Anyway, there's no need for you to waste your time on this particular
issue.  I understand the issue very well, and will handle it, time
permitting.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

>
> >     Here is a more-detailed review of the latest patch you sent.
> >
> >     > -      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
> >     > +      int i = 0, aligned = (ABLOCKS_BUSY (abase) != NULL);
> >
> >     Not needed for Windows 64.  The change slows the code down a bit, and
> >
> >
> > Prove it.
>
> I compiled it both ways (x86-64 GCC 4.6.2), and the "!= NULL" version
> has an extra "cmpl" instruction, so it is indeed a bit fatter.
>
>
Just for fun :

version with != NULL :

; Line 1156
xor edx, edx
 test rax, rax
lea rcx, OFFSET FLAT:free_ablock
 setne dl
add rdx, 15
 shl rdx, 10
add rdx, rdi

version without it :

; Line 1156
xor edx, edx
 lea rcx, OFFSET FLAT:free_ablock
cmp DWORD PTR [rdi+1016], edx
 setne dl
add rdx, 15
 shl rdx, 10
add rdx, rdi

cmp on one side, test on the other side.

Fabrice

[-- Attachment #2: Type: text/html, Size: 3141 bytes --]

Re: Windows 64 port

[Eli Zaretskii]

> Date: Thu, 01 Mar 2012 00:58:02 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, ajmr@ilovetortilladepatatas.com, 
>  emacs-devel@gnu.org
> 
> >     Here is a more-detailed review of the latest patch you sent.
> > 
> >     > -      int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
> >     > +      int i = 0, aligned = (ABLOCKS_BUSY (abase) != NULL);
> > 
> >     Not needed for Windows 64.  The change slows the code down a bit, and
> > 
> > 
> > Prove it.
> 
> I compiled it both ways (x86-64 GCC 4.6.2), and the "!= NULL" version
> has an extra "cmpl" instruction, so it is indeed a bit fatter.

Was that an optimized compile or an unoptimized one?  If the latter,
the results have no practical effect on the speed of the production
binary; if the former, I'm not sure you can reliably tell which
instruction belongs to which source line, especially since that code
is in a function that is inlined by GCC when you compile with
optimizations.

In any case, even if your claim _is_ true (and I very much doubt
that), it is beyond ridiculous to say that a single extra clock cycle
in a program such as Emacs should be seriously considered as an
important factor to weigh against code cleanness and maintainability.

Re: Windows 64 port

[Paul Eggert]

On 03/02/2012 01:22 AM, Eli Zaretskii wrote:
> it is beyond ridiculous to say that a single extra clock cycle
> in a program such as Emacs should be seriously considered as an
> important factor to weigh against code cleanness and maintainability.

My primary objection to the change has always been maintainability
and cleanness; any extra instructions are in the noise.

ABLOCKS_BUSY is sometimes a pointer and sometimes an integer
(converted to a pointer).  At the point when this code is executed:

    int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);

ABLOCKS_BUSY is an integer.  Changing the code to look like this:

    int i = 0, aligned = (ABLOCKS_BUSY (abase) != NULL);

would cause a reader of the code to naturally make the
incorrect assumption that ABLOCKS_BUSY is a pointer.  On
this ground alone the patch is dubious.  The facts that
the patch is not needed for Windows 64 and that it might
slow things down a bit on some platforms are merely
icing on the cake.

I'm not saying the code can't be cleaned up -- it's pretty
messy and this one line is just one corner of the mess.  But
any cleanup can and should be done independently of the Windows 64
port, and should be systematic rather than just fiddling
with this one line and making this line inconsistent with
the (ab)use of ABLOCKS_BUSY in the rest of the module.

My compilation was an optimized one, not that this matters
much.

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

>
> ABLOCKS_BUSY is sometimes a pointer and sometimes an integer
> (converted to a pointer).  At the point when this code is executed:
>
>
So it is even worse than what I thought.



> I'm not saying the code can't be cleaned up -- it's pretty
> messy and this one line is just one corner of the mess.  But
> any cleanup can and should be done independently of the Windows 64
> port, and should be systematic rather than just fiddling
>

Ok. But in my defence, you may forget that I started from a point
where emacs didn't compile,  and when it compiled at least, it din't run.
In this case, the obvious strategy is to remove all the compilation
warnings, at least
those related to int/long/pointers datatypes.
And guess what ... once I did that, it worked.
Ok, it is not enough, but I spent already quite a time on it, I didn't see
myself testing the many combinations
of what was actually needed and what was optional.
Now, my patch may easily be split in as many parts as needed, and some
of them definitely omitted. I never expected that it could be taken "as is".
I only targeted a clean compile on my platform, and since I won't be able
to test
if it is harmless to other platforms, I'll let those who know judge what is
acceptable
and what needs to be rewritten.
I can only easily report if it still compiles and run on the MS platform
with their tools.

Best regards,

with this one line and making this line inconsistent with
> the (ab)use of ABLOCKS_BUSY in the rest of the module.
>
> My compilation was an optimized one, not that this matters
> much.
>



-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #2: Type: text/html, Size: 2667 bytes --]

Re: Windows 64 port

[Eli Zaretskii]

> Date: Fri, 02 Mar 2012 12:35:38 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: fabrice.popineau@supelec.fr, ajmr@ilovetortilladepatatas.com, 
>  emacs-devel@gnu.org
> 
> On 03/02/2012 01:22 AM, Eli Zaretskii wrote:
> > it is beyond ridiculous to say that a single extra clock cycle
> > in a program such as Emacs should be seriously considered as an
> > important factor to weigh against code cleanness and maintainability.
> 
> My primary objection to the change has always been maintainability
> and cleanness; any extra instructions are in the noise.

Then why did you bring up that argument in the first place?  If
nothing else, it had Fabrice and myself waste some of our time trying
to look at the code emitted by the compiler.

> ABLOCKS_BUSY is sometimes a pointer and sometimes an integer
> (converted to a pointer).  At the point when this code is executed:
> 
>     int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase);
> 
> ABLOCKS_BUSY is an integer.  Changing the code to look like this:
> 
>     int i = 0, aligned = (ABLOCKS_BUSY (abase) != NULL);
> 
> would cause a reader of the code to naturally make the
> incorrect assumption that ABLOCKS_BUSY is a pointer.  On
> this ground alone the patch is dubious.  The facts that
> the patch is not needed for Windows 64 and that it might
> slow things down a bit on some platforms are merely
> icing on the cake.

See, there's no cake here to ice.  The way I see it, Fabrice is trying
to contribute, and you discourage him on false pretenses.  That comes
nowhere near any cakes; that's simply unfair.

Re: Windows 64 port

[Paul Eggert]

>> My primary objection to the change has always been maintainability
>> and cleanness; any extra instructions are in the noise.
> Then why did you bring up that argument in the first place?

Because it seemed like a valid argument.  It was only one
line in my twenty-line email, and that was the fourth email
I sent about that particular change, and all these emails
focused on my main concern, which was keeping the Windows
64 changes simple and maintainable.  Unfortunately these
concerns didn't seem to be persuading you, so naturally I
cast about for other arguments.  But performance was never
my main point, and still isn't.

Since then, Fabrice and I seem to have come to a consensus
that much of the mainline part of the patch isn't needed for
Windows 64 and can be considered separately, so there's no
real technical controversy here.

> The way I see it, Fabrice is trying
> to contribute, and you discourage him on false pretenses.

A good way to react to a critical and honest code review is
to thank the reviewer, make changes that seem warranted,
and move on, which is what Fabrice is doing.  This is
standard practice in software engineering.  Unsupported and
incorrect accusations of bad faith are not helpful in this
process, as they tend to discourage people from reviewing
and thereby improving the code.

Re: Windows 64 port

[Eli Zaretskii]

> Date: Fri, 02 Mar 2012 21:42:49 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: fabrice.popineau@supelec.fr, ajmr@ilovetortilladepatatas.com, 
>  emacs-devel@gnu.org
> 
> > The way I see it, Fabrice is trying
> > to contribute, and you discourage him on false pretenses.
> 
> A good way to react to a critical and honest code review is
> to thank the reviewer, make changes that seem warranted,
> and move on, which is what Fabrice is doing.  This is
> standard practice in software engineering.  Unsupported and
> incorrect accusations of bad faith are not helpful in this
> process, as they tend to discourage people from reviewing
> and thereby improving the code.

Thank you, but your reviews are heavily biased, and expressed in a
form that discourages the contributors.  Please in the future try
improving your style of reviewing patches, in particular when they
come from users of tools and systems you happen to dislike very much.

Re: Windows 64 port

[Paul Eggert]

On 03/02/2012 11:18 PM, Eli Zaretskii wrote:
> Please in the future try improving your style of reviewing patches

I'm afraid that's a bit vague.  My review used the style I
normally use for contributions to Emacs and to other GNU
projects.  Evidently I struck a nerve, but without more
specific advice, such as identifying specific phrases that
were objectionable and specific phrases to use instead, I am
at a loss as to how to avoid striking the same nerve next time.

> in particular when they come from users of tools and systems
> you happen to dislike very much

This comment ascribes motivations to me that I do not have.

Re: Windows 64 port

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Thu, 1 Mar 2012 08:24:40 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, ajmr@ilovetortilladepatatas.com, emacs-devel@gnu.org
> 
> >   /* Include <time.h> before defining tzname, to avoid DLL clash.  */
> >   #include <time.h>
> >   #define tzname _tzname
> > [...]
> The problem is trickier than this and probably need a careful
> rewrite of ms-w32.h.  In this file, names like tzname or fopen get
> rewired. Some of them need to be rewired to sys_fopen or _fopen
> (example) depending on whether it is for emacs or not.  So a more
> robust way of doing things would be to ensure that all system
> headers are read once for all, then doing the rewiring for emacs and
> for (not emacs). That should avoid the problem of tzname for
> example. In the mean time, this is the smallest change I could come
> with.  What you propose didn't work (resulting in either : some
> function returns an array, that is tzname, or _tzname being
> undefined at link time).

Can you show me the error messages, please, and perhaps also the
relevant portions of the MS headers that trigger them?  Including
time.h before redefining tzname is exactly what you proposed (for
system headers to be included before redefining), so I'm puzzled about
what exactly went wrong in the case of tzname, and why what you
suggest as a general method of fixing these problems didn't work in
this particular case.

> > >     >  #ifdef WINDOWSNT
> > >     >  extern Lisp_Object w32_get_internal_run_time (void);
> > >     > +
> > >     > +extern struct tm *localtime (const time_t *t);
> > >     >  #endif
> > >
> > >     Why is this needed?  It seems also unrelated to 64-bit Windows.
> 
> Sure but the definition needs to be put somewhere because an int is
> not the same size as a pointer in windows 64.

But editfns.c includes "systime.h", which does this:

  #ifdef TIME_WITH_SYS_TIME
  #include <sys/time.h>
  #include <time.h>
  #else
  #ifdef HAVE_SYS_TIME_H
  #include <sys/time.h>
  #else
  #include <time.h>
  #endif
  #endif

On Windows, ms-w32.h defines TIME_WITH_SYS_TIME to 1, so the above
should have included the system header time.h, which I believe
includes the prototype of localtime.  So could you please look into
this some more and find out why all this isn't working for you?

TIA

Re: Windows 64 port

[Eli Zaretskii]

Ping!  Fabrice, could you please respond?

I'd like to have the 32-bit MSVC compilation to work when Emacs 24.1
is released.  So I need to resolve these issues and commit whatever
changes are needed for that.

TIA

> Date: Sat, 03 Mar 2012 09:58:10 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: emacs-devel@gnu.org
> 
> > From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> > Date: Thu, 1 Mar 2012 08:24:40 +0100
> > Cc: Eli Zaretskii <eliz@gnu.org>, ajmr@ilovetortilladepatatas.com, emacs-devel@gnu.org
> > 
> > >   /* Include <time.h> before defining tzname, to avoid DLL clash.  */
> > >   #include <time.h>
> > >   #define tzname _tzname
> > > [...]
> > The problem is trickier than this and probably need a careful
> > rewrite of ms-w32.h.  In this file, names like tzname or fopen get
> > rewired. Some of them need to be rewired to sys_fopen or _fopen
> > (example) depending on whether it is for emacs or not.  So a more
> > robust way of doing things would be to ensure that all system
> > headers are read once for all, then doing the rewiring for emacs and
> > for (not emacs). That should avoid the problem of tzname for
> > example. In the mean time, this is the smallest change I could come
> > with.  What you propose didn't work (resulting in either : some
> > function returns an array, that is tzname, or _tzname being
> > undefined at link time).
> 
> Can you show me the error messages, please, and perhaps also the
> relevant portions of the MS headers that trigger them?  Including
> time.h before redefining tzname is exactly what you proposed (for
> system headers to be included before redefining), so I'm puzzled about
> what exactly went wrong in the case of tzname, and why what you
> suggest as a general method of fixing these problems didn't work in
> this particular case.
> 
> > > >     >  #ifdef WINDOWSNT
> > > >     >  extern Lisp_Object w32_get_internal_run_time (void);
> > > >     > +
> > > >     > +extern struct tm *localtime (const time_t *t);
> > > >     >  #endif
> > > >
> > > >     Why is this needed?  It seems also unrelated to 64-bit Windows.
> > 
> > Sure but the definition needs to be put somewhere because an int is
> > not the same size as a pointer in windows 64.
> 
> But editfns.c includes "systime.h", which does this:
> 
>   #ifdef TIME_WITH_SYS_TIME
>   #include <sys/time.h>
>   #include <time.h>
>   #else
>   #ifdef HAVE_SYS_TIME_H
>   #include <sys/time.h>
>   #else
>   #include <time.h>
>   #endif
>   #endif
> 
> On Windows, ms-w32.h defines TIME_WITH_SYS_TIME to 1, so the above
> should have included the system header time.h, which I believe
> includes the prototype of localtime.  So could you please look into
> this some more and find out why all this isn't working for you?
> 
> TIA

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1.1: Type: text/plain, Size: 727 bytes --]

2012/3/1 Paul Eggert <eggert@cs.ucla.edu>

> > - const problems in regex.c (large patch, but harmless)
>
> None of the regex.c changes are needed for Windows 64.  The code works
> fine without it and the patch does not fix any bugs.  Perhaps regex.c
> should be made cleaner, const-wise, but that's an independent issue
> and if we want to make that change it be as part of an independent patch.


Actually, it is much simpler than my previous attempt.
MSVC supports const, and so does GCC. So, define unconditionaly
're_char' to be 'const unsigned char' and avoid the double 'const'
because of 'const re_char' in various places (why those few const anyway,
given that with gcc, every re_char is already const ?).

-- 
Fabrice

[-- Attachment #1.2: Type: text/html, Size: 1266 bytes --]

[-- Attachment #2: regex.c.diff --]
[-- Type: application/octet-stream, Size: 3734 bytes --]

=== modified file 'src/regex.c'
--- src/regex.c	2012-01-19 07:21:25 +0000
+++ src/regex.c	2012-03-22 09:41:01 +0000
@@ -530,11 +530,7 @@
 #define MIN(a, b) ((a) < (b) ? (a) : (b))
 
 /* Type of source-pattern and string chars.  */
-#ifdef _MSC_VER
-typedef unsigned char re_char;
-#else
 typedef const unsigned char re_char;
-#endif
 
 typedef char boolean;
 #define false 0
@@ -2068,7 +2064,7 @@
 
 /* Map a string to the char class it names (if any).  */
 re_wctype_t
-re_wctype (const re_char *str)
+re_wctype (re_char *str)
 {
   const char *string = (const char *) str;
   if      (STREQ (string, "alnum"))	return RECC_ALNUM;
@@ -2468,7 +2464,7 @@
   } while (0)
 
 static reg_errcode_t
-regex_compile (const re_char *pattern, size_t size, reg_syntax_t syntax, struct re_pattern_buffer *bufp)
+regex_compile (re_char *pattern, size_t size, reg_syntax_t syntax, struct re_pattern_buffer *bufp)
 {
   /* We fetch characters from PATTERN here.  */
   register re_wchar_t c, c1;
@@ -3215,7 +3211,7 @@
 		  }
 		else
 		  /* It's really shy.  */
-		  regnum = - bufp->re_nsub;
+		  regnum = - ((int)bufp->re_nsub);
 
 		if (COMPILE_STACK_FULL)
 		  {
@@ -3829,7 +3825,7 @@
    least one character before the ^.  */
 
 static boolean
-at_begline_loc_p (const re_char *pattern, const re_char *p, reg_syntax_t syntax)
+at_begline_loc_p (re_char *pattern, re_char *p, reg_syntax_t syntax)
 {
   re_char *prev = p - 2;
   boolean prev_prev_backslash = prev > pattern && prev[-1] == '\\';
@@ -3851,7 +3847,7 @@
    at least one character after the $, i.e., `P < PEND'.  */
 
 static boolean
-at_endline_loc_p (const re_char *p, const re_char *pend, reg_syntax_t syntax)
+at_endline_loc_p (re_char *p, re_char *pend, reg_syntax_t syntax)
 {
   re_char *next = p;
   boolean next_backslash = *next == '\\';
@@ -3895,7 +3891,7 @@
    Return -1 if fastmap was not updated accurately.  */
 
 static int
-analyse_first (const re_char *p, const re_char *pend, char *fastmap, const int multibyte)
+analyse_first (re_char *p, re_char *pend, char *fastmap, const int multibyte)
 {
   int j, k;
   boolean not;
@@ -4639,7 +4635,7 @@
 /* If the operation is a match against one or more chars,
    return a pointer to the next operation, else return NULL.  */
 static re_char *
-skip_one_char (const re_char *p)
+skip_one_char (re_char *p)
 {
   switch (SWITCH_ENUM_CAST (*p++))
     {
@@ -4681,7 +4677,7 @@
 
 /* Jump over non-matching operations.  */
 static re_char *
-skip_noops (const re_char *p, const re_char *pend)
+skip_noops (re_char *p, re_char *pend)
 {
   int mcnt;
   while (p < pend)
@@ -4708,7 +4704,7 @@
 
 /* Non-zero if "p1 matches something" implies "p2 fails".  */
 static int
-mutually_exclusive_p (struct re_pattern_buffer *bufp, const re_char *p1, const re_char *p2)
+mutually_exclusive_p (struct re_pattern_buffer *bufp, re_char *p1, re_char *p2)
 {
   re_opcode_t op2;
   const boolean multibyte = RE_MULTIBYTE_P (bufp);
@@ -4967,8 +4963,8 @@
 /* This is a separate function so that we can force an alloca cleanup
    afterwards.  */
 static regoff_t
-re_match_2_internal (struct re_pattern_buffer *bufp, const re_char *string1,
-		     size_t size1, const re_char *string2, size_t size2,
+re_match_2_internal (struct re_pattern_buffer *bufp, re_char *string1,
+		     size_t size1, re_char *string2, size_t size2,
 		     ssize_t pos, struct re_registers *regs, ssize_t stop)
 {
   /* General temporaries.  */
@@ -6306,7 +6302,7 @@
    bytes; nonzero otherwise.  */
 
 static int
-bcmp_translate (const re_char *s1, const re_char *s2, register ssize_t len,
+bcmp_translate (re_char *s1, re_char *s2, register ssize_t len,
 		RE_TRANSLATE_TYPE translate, const int target_multibyte)
 {
   register re_char *p1 = s1, *p2 = s2;

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

2012/3/1 Paul Eggert <eggert@cs.ucla.edu>

> > +#define SIZE ESIZE
>
> I don't see the reason for this #define; could you please explain?
> If it is needed, let's just dump SIZE entirely, and use size_t instead.
>

Yes, that would be better. The <windows.h> header file (or rather one of its
sub-header files) does define this symbol. I can provide the patch if it is
agreed.


-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 740 bytes --]

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

2012/3/1 Paul Eggert <eggert@cs.ucla.edu>

> > === modified file 'src/m/amdx86-64.h'
> > --- src/m/amdx86-64.h 2012-01-19 07:21:25 +0000
> > +++ src/m/amdx86-64.h 2012-02-28 07:00:30 +0000
> > @@ -17,7 +17,13 @@
> >  You should have received a copy of the GNU General Public License
> >  along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
> >
> > -#define BITS_PER_LONG           64
> > +#ifdef _WIN64
> > +# define BITS_PER_LONG           32
> > +# define BITS_PER_LONG_LONG      64
> > +#else
> > +# define BITS_PER_LONG           64
> > +#endif
>
> Since this stuff is normally defined by 'configure', it should be put
> into nt/config.nt rather than into a src/m/* file; there shouldn't be
> a need to use or to modify src/m/amdx86-64.h.  Similarly for the other
> changes to src/m/amdx86-64.h.  I don't see how that file is used under
> Windows 64; but if it is, we should fix that, and not change the file.
>

I used this file instead of src/m/i386.h because it seemed to have this
purpose of
holding machine dependent constants. I could probably put this stuff into
config.nt,
but in this case I wonder what is the purpose of the m/ directory? Surely,
every
other architecture could also rely on configure to guess the right values?

By the way, this is what I have currently :

=== modified file 'src/m/amdx86-64.h'
--- src/m/amdx86-64.h   2012-01-19 07:21:25 +0000
+++ src/m/amdx86-64.h   2012-02-28 07:00:30 +0000
@@ -17,7 +17,13 @@
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */

-#define BITS_PER_LONG           64
+#ifdef _WIN64
+# define BITS_PER_LONG           32
+# define BITS_PER_LONG_LONG      64
+#else
+# define BITS_PER_LONG           64
+#endif
+
 #define BITS_PER_EMACS_INT      64

 /* Now define a symbol for the cpu type, if your compiler
@@ -27,9 +33,17 @@
 /* __x86_64 defined automatically.  */

 /* Define the type to use.  */
-#define EMACS_INT               long
-#define pI                     "l"
-#define EMACS_UINT              unsigned long
+#ifdef _WIN64
+# define EMACS_INT               __int64
+# define EMACS_UINT              unsigned __int64
+# define pI                    "ll"
+# define VIRT_ADDR_VARIES
+# define DATA_START    get_data_start ()
+#else
+# define EMACS_INT               long
+# define pI                    "l"
+# define EMACS_UINT              unsigned long
+#endif

 /* Define XPNTR to avoid or'ing with DATA_SEG_BITS */
 #undef DATA_SEG_BITS

-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #2: Type: text/html, Size: 3985 bytes --]

Re: Windows 64 port

[Stefan Monnier]

> I used this file instead of src/m/i386.h because it seemed to have
> this purpose of holding machine dependent constants.  I could probably
> put this stuff into config.nt,

Please do.

> but in this case I wonder what is the purpose of the m/ directory?

Its a relic from the past, being slowly phased out,


        Stefan

Re: Windows 64 port

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

2012/3/1 Paul Eggert <eggert@cs.ucla.edu>

> > -    unsigned long int magic; /* Magic number to check header integrity.
>  */
> > +    uint64_t magic;  /* Magic number to check header integrity.  */
>
> Not needed for Windows 64, since the magic number fits in 32 bits.
>

If it fits in 32 bits, then it shouldn't be long in first place?
Unsigned int is enough and will be 32 bits wide ofr x86 and x64.

-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 759 bytes --]

Re: Windows 64 port

[Paul Eggert]

On 03/27/2012 05:47 AM, Fabrice Popineau wrote:
> 2012/3/1 Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>>
> 
>     > -    unsigned long int magic; /* Magic number to check header integrity.  */
>     > +    uint64_t magic;  /* Magic number to check header integrity.  */
> 
>     Not needed for Windows 64, since the magic number fits in 32 bits.
> 
> If it fits in 32 bits, then it shouldn't be long in first place? 

Yes, it'd be reasonable to change this.  However, any such change
is independent of the Windows 64 port (as it would be just
as reasonable to change it to 'unsigned int' for x86-64 GNU/Linux too),
and so it should be considered as a separate patch.

Re: Windows 64 port

[Richard Stallman]

    I would love to start to contribute to the GNU community and I thought
    that porting Emacs 23 to Windows 64, could be a good useful entry.

You can do it if you like, but note that this sort of change would
do nothing to advance the free world.  Thus, how about porting yourself
to GNU/Linux, and writing improvements that benefit GNU/Linux?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Windows 64 port

[Dani Moncayo]

>    I would love to start to contribute to the GNU community and I thought
>    that porting Emacs 23 to Windows 64, could be a good useful entry.
>
> You can do it if you like, but note that this sort of change would
> do nothing to advance the free world.  Thus, how about porting yourself
> to GNU/Linux, and writing improvements that benefit GNU/Linux?

There are many people who, like me, are tied to a MS Windows OS at
work (that's not up to me).  Those people could not use and contribute
to GNU Emacs if it wasn't because there is a port for that platform.

Therefore, I think that the ports of Emacs for other platforms
(specially Windows) is useful for the free world, because they extend
the number of users and contributors of GNU Emacs (which is  part of
"the free world").

-- 
Dani Moncayo

Re: Windows 64 port

[Richard Stallman]

    There are many people who, like me, are tied to a MS Windows OS at
    work (that's not up to me).  Those people could not use and contribute
    to GNU Emacs if it wasn't because there is a port for that platform.

That's a valid point, in general, but if you want to live in freedom
you need to change your work situation.  Can you bring your own
computer to do the work on?  Can you boot GNU/Linux on that machine
from a live CD?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/