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
64bits.patch