Re: Building Emacs with MSVC

[Christoph]

On 4/6/2010 9:13 PM, Eli Zaretskii wrote:
> Yes, Studio 2003 is the last version known to build a working binary.
>    
OK.

> That's a known problem.  I forget the details (you can find them in
> the archives), but there's some problem with the library functions
> supplied by later versions of Studio, and/or conflicts with our
> customized malloc, that cause the crash.
>    
Yes, one issue is the library libc.lib (single threaded) which was 
replaced by libcmt.lib (multithreaded). But there were other issues like 
shadowing functions, for example sys_ctime and utime.

Also, maybe this is interesting for you Eli: bidi.c failed because MSVC 
does not support the inline keyword for C files (only for C++ files). 
__inline is the correct keyword for C files 
(http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx) in MSVC.

It might not matter, since GCC compiles fine, but I though I'd mention 
it anyway.

> What for?  If we cannot build a working binary, why pollute the
> sources with more MSVC-specific patches?
>    
The patch is actually for a bug in the existing MSVC makefile in 
lib-src. I am pretty sure even older versions would not run with this, 
since nmake fails right away:

=== modified file 'lib-src/makefile.w32-in'
--- lib-src/makefile.w32-in    2010-04-03 01:54:24 +0000
+++ lib-src/makefile.w32-in    2010-04-06 03:06:03 +0000
@@ -195,8 +195,8 @@
     $(lispsource)term/pc-win.elc \
     $(lispsource)x-dnd.elc \
     $(lispsource)term/x-win.elc \
-    ${lispsource}emacs-lisp/easymenu.elc \
-    ${lispsource}term/ns-win.elc
+    $(lispsource)emacs-lisp/easymenu.elc \
+    $(lispsource)term/ns-win.elc

> Right.  And since MinGW is available and in pretty good shape, we
> decided at the time not to invest any effort in MSVC.
>    
I agree. MinGW works absolutely fine, so is there even any reason to 
keep the MSVC stuff around? Was MSVC supported earlier than MinGW? I 
surely don't want to start another discussion about backwards 
compatibility and supporting older versions but a lot areas could be 
cleaned up quite a bit if MSVC/nmake support was dropped in favor of 
MinGW/gmake. The only reason for the zipdist batch file was nmake, which 
turns out to be horribly limited compared to gmake.

Just my $0.02,
Christoph