11:03 p.m.
Small fixes for building under MS Visual Studio 20050 (mainly embedding
xemacs.exe.manifest in the executable) and turns on Visual Themes. Patch
and new files attached.
Unfortunately make-docfile is still crashing for me.
Not tested under older versions of Visual Studio.
src/ChangeLog:
2005-11-13 Jonathan Harris <jonathan(a)xemacs.org>
* dumper.c (pdump): Don't try to close pdump_fd twice.
* s/windowsnt.h:
Suppress warnings about deprecated POSIX APIs under VS 2005.
lib-src/ChangeLog:
2005-11-13 Jonathan Harris <jonathan(a)xemacs.org>
* lib-src\make-docfile.c (main):
Don't open text files in binary mode on WIN32_NATIVE.
nt/ChangeLog:
2005-11-13 Jonathan Harris <jonathan(a)xemacs.org>
* README: Document MS Visual Studio 2005.
* xemacs.rc:
* xemacs.mak:
Fixes for VS 2005 - embed manifest in executable.
Turn on Visual Themes on WinXP and later.
Add --no-validate and --force flags to makeinfo.
* xemacs.ico:
* file.ico:
Updated and added WinXP-style icons with drop-shadow.
Index: lib-src/make-docfile.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/lib-src/make-docfile.c,v
retrieving revision 1.17
diff -u -r1.17 make-docfile.c
--- lib-src/make-docfile.c 2005/02/22 08:05:58 1.17
+++ lib-src/make-docfile.c 2005/11/13 21:08:18
＠＠ -168,7 +168,6 ＠＠
/* Don't put CRs in the DOC file. */
#ifdef WIN32_NATIVE
- _fmode = O_BINARY;
_setmode (fileno (stdout), O_BINARY);
#endif /* WIN32_NATIVE */
Index: nt/README
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/nt/README,v
retrieving revision 1.27
diff -u -r1.27 README
--- nt/README 2005/09/26 08:13:00 1.27
+++ nt/README 2005/11/13 21:08:18
＠＠ -20,24 +20,24 ＠＠
* Required tools and sources
============================
-1. You will need Visual C++ V6.0, Visual Studio .NET or later to compile
- everything.
+1. You will need Visual Visual Studio .NET or later to compile everything.
- Note that Visual C++ assumes that the environment variables INCLUDE and
- LIB are set to specify the location of the includes and libraries.
+ Note that Visual Studio assumes that the environment variables INCLUDE
+ and LIB are set to specify the location of the includes and libraries.
Your PATH environment variable also needs to include the Visual Studio
vc\bin and sharedide\bin directories.
- Visual C++ V6.0 installs a batch file called vcvars32.bat in
- c:\Program Files\Microsoft Visual Studio\VC98\bin\ (or wherever you
- installed it) that you can run before building to set up all of these
- environment variables. Alternatively, you can choose at setup time to
- have these environment variables automatically set up in the registry,
- which is generally a good idea.
+ Visual Studio .NET & 2005 installs a batch file called vcvars32.bat in
+ C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools or
+ C:\Program Files\Microsoft Visual Studio 8\Common7\Tools (or wherever
+ you installed it) that you can run before building to set up all of
+ these environment variables. Alternatively, you can choose at setup
+ time to have these environment variables automatically set up in the
+ registry, which is generally a good idea.
- Visual Studio .NET calls this batch file vsvars32.bat and installs it in
- $Installdir\Common7\Tools, but doesn't offer at install time to
- automatically set these environment variables up in the registry.
+ If you're building with a Microsoft Platform SDK (rather than the SDK
+ that comes with the full version of Visual Studio) then also run
+ C:\Program Files\Microsoft Platform SDK\setenv.cmd.
2. Grab the latest XEmacs source from
Index: nt/xemacs.mak
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/nt/xemacs.mak,v
retrieving revision 1.118
diff -u -r1.118 xemacs.mak
--- nt/xemacs.mak 2005/11/10 15:45:13 1.118
+++ nt/xemacs.mak 2005/11/13 21:08:20
＠＠ -424,6 +424,10 ＠＠
XEMACS_VERSION_STRING=$(XEMACS_VERSION_STRING).$(emacs_beta_version)
!endif
!endif
+XEMACS_RC_VERSION=$(XEMACS_VERSION_STRING:-=.)
+XEMACS_RC_ASSVERSION=$(XEMACS_VERSION_STRING:-b=.).0
+XEMACS_RC_FILEVERSION=$(XEMACS_RC_ASSVERSION:.=,)
+
PROGRAM_DEFINES= \
-DPATH_VERSION=\"$(XEMACS_VERSION_STRING)\" \
-DPATH_PROGNAME=\"xemacs\" \
＠＠ -1330,10 +1334,6 ＠＠
cd $(BLDSRC)
$(BLDLIB_SRC)\make-dump-id.exe
-$(OUTDIR)\temacs.res: $(NT)\xemacs.rc
- cd $(NT)
- rc -Fo$＠ xemacs.rc
-
## (2) Link the XEmacs executable
!if $(USE_PORTABLE_DUMPER)
＠＠ -1387,22 +1387,25 ＠＠
## (5) Dump
-!if $(USE_PORTABLE_DUMPER)
-$(DUMP_TARGET): $(NT)\xemacs.rc
-!endif
-
# This rule dumps xemacs and then possibly spawns sub-make if PURESPACE
# requirements have changed.
-$(DUMP_TARGET): $(DOC) $(RAW_EXE) $(BLDSRC)\NEEDTODUMP
+$(DUMP_TARGET): $(DOC) $(RAW_EXE) $(BLDSRC)\NEEDTODUMP $(NT)\xemacs.rc
$(TEMACS_BATCH) -l $(LISP)\loadup.el dump
+ ＠type $(NT)\xemacs.manifest1.txt> $(OUTDIR)\xemacs.exe.manifest
+ ＠echo "$(XEMACS_RC_ASSVERSION)">> $(OUTDIR)\xemacs.exe.manifest
+ ＠type $(NT)\xemacs.manifest2.txt>> $(OUTDIR)\xemacs.exe.manifest
+!if $(MSC_VER) >= 1400
+ ＠findstr /c:depend /c:assemblyIdentity $(RAW_EXE).manifest>>
$(OUTDIR)\xemacs.exe.manifest
+!endif
+ ＠type $(NT)\xemacs.manifest3.txt>> $(OUTDIR)\xemacs.exe.manifest
!if $(USE_PORTABLE_DUMPER)
cd $(BLDSRC)
- rc -d INCLUDE_DUMP -Fo $(OUTDIR)\xemacs.res $(NT)\xemacs.rc
+ rc -d INCLUDE_DUMP -Fo $(OUTDIR)\xemacs.res
-dXEMACS_RC_VERSION=\"$(XEMACS_RC_VERSION)\"
-dXEMACS_RC_FILEVERSION=$(XEMACS_RC_FILEVERSION) $(NT)\xemacs.rc
# Make the resource section read/write since almost all of it is the dump
# data which needs to be writable. This avoids having to copy it.
link.exe ＠<<
- $(XEMACS_LFLAGS) -section:.rsrc,rw -out:$(BLDSRC)\xemacs.exe $(TEMACS_OBJS)
$(OUTDIR)\xemacs.res $(TEMACS_LIBS) $(OUTDIR)\dump-id.obj
+ $(XEMACS_LFLAGS) -manifest:no -section:.rsrc,rw -out:$(BLDSRC)\xemacs.exe
$(TEMACS_OBJS) $(OUTDIR)\xemacs.res $(TEMACS_LIBS) $(OUTDIR)\dump-id.obj
<<
-$(DEL) $(BLDSRC)\xemacs.dmp
!endif
＠＠ -1431,7 +1434,10 ＠＠
###################### Building the info files
!if !defined(MAKEINFO)
-MAKEINFO=$(XEMACS_BATCH_PACKAGES) -l texinfmt -f batch-texinfo-format
+MAKEINFO=$(XEMACS_BATCH_PACKAGES)
+MAKEINFOFLAGS=-l texinfmt -f batch-texinfo-format
+!else
+MAKEINFOFLAGS=--no-validate --force
!endif
MANDIR = $(SRCROOT)\man
＠＠ -1455,7 +1461,7 ＠＠
{$(MANDIR)}.texi{$(INFODIR)}.info:
cd $(MANDIR)
- $(MAKEINFO) $(**F)
+ $(MAKEINFO) $(MAKEINFOFLAGS) $(**F)
XEMACS_SRCS = \
$(MANDIR)\xemacs\abbrevs.texi \
＠＠ -1586,19 +1592,19 ＠＠
$(INFODIR)\xemacs.info: $(XEMACS_SRCS)
cd $(MANDIR)\xemacs
- $(MAKEINFO) xemacs.texi
+ $(MAKEINFO) $(MAKEINFOFLAGS) xemacs.texi
$(INFODIR)\lispref.info: $(LISPREF_SRCS)
cd $(MANDIR)\lispref
- $(MAKEINFO) lispref.texi
+ $(MAKEINFO) $(MAKEINFOFLAGS) lispref.texi
$(INFODIR)\internals.info: $(INTERNALS_SRCS)
cd $(MANDIR)\internals
- $(MAKEINFO) internals.texi
+ $(MAKEINFO) $(MAKEINFOFLAGS) internals.texi
$(INFODIR)\new-users-guide.info: $(NEW_USERS_GUIDE_SRCS)
cd $(MANDIR)\new-users-guide
- $(MAKEINFO) new-users-guide.texi
+ $(MAKEINFO) $(MAKEINFOFLAGS) new-users-guide.texi
info: makeinfo-test $(INFO_FILES)
＠＠ -1681,15 +1687,19 ＠＠
mostlyclean:
-$(DEL) $(BLDROOT)\Installation
+ -$(DEL) $(NT)\*.obj
-$(DEL) $(OUTDIR)\*.lib
-$(DEL) $(OUTDIR)\*.obj
-$(DEL) $(OUTDIR)\*.pdb
-$(DEL) $(OUTDIR)\*.idb
-$(DEL) $(OUTDIR)\*.ilk
+ -$(DEL) $(OUTDIR)\*.manifest
-$(DEL) $(OUTDIR)\*.res
-$(DEL) $(OUTDIR)\*.sbr
+ -$(DEL) $(OUTDIR)\*.tmp
-$(DEL) $(BLDSRC)\*.exe
-$(DEL) $(BLDSRC)\*.dmp
+ -$(DEL) $(BLDSRC)\*.manifest
-$(DEL) $(BLDSRC)\*.map
-$(DEL) $(BLDSRC)\*.pdb
-$(DEL) $(BLDSRC)\*.idb
Index: nt/xemacs.rc
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/nt/xemacs.rc,v
retrieving revision 1.3
diff -u -r1.3 xemacs.rc
--- nt/xemacs.rc 2001/04/12 18:23:01 1.3
+++ nt/xemacs.rc 2005/11/13 21:08:20
＠＠ -1,7 +1,40 ＠＠
+#include <winuser.rh>
+#include <winver.h>
+
#ifdef INCLUDE_DUMP
-101 DUMP "xemacs.dmp"
+101 DUMP "xemacs.dmp"
#endif
XEmacs ICON PRELOAD "xemacs.ico"
XEmacsFile ICON "File.ico"
-XEmacsLisp ICON "Lisp.ico"
+
+CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "obj\\xemacs.exe.manifest"
+
+VS_VERSION_INFO VERSIONINFO
+ FILEVERSION XEMACS_RC_FILEVERSION
+ PRODUCTVERSION XEMACS_RC_FILEVERSION
+ FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
+#ifdef _DEBUG
+ FILEFLAGS VS_FF_DEBUG
+#else
+ FILEFLAGS 0x0L
+#endif
+ FILEOS VOS__WINDOWS32
+ FILETYPE VFT_APP
+ FILESUBTYPE 0x0L
+BEGIN
+ BLOCK "StringFileInfo"
+ BEGIN
+ BLOCK "040904b0"
+ BEGIN
+ VALUE "CompanyName", "xemacs.org"
+ VALUE "FileDescription", "XEmacs"
+ VALUE "FileVersion", XEMACS_RC_VERSION
+ VALUE "InternalName", "XEmacs"
+ VALUE "LegalCopyright", "GNU General Public License"
+ VALUE "OriginalFilename", "xemacs.exe"
+ VALUE "ProductName", "XEmacs"
+ VALUE "ProductVersion", XEMACS_RC_VERSION
+ END
+ END
+END
Index: src/dumper.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/dumper.c,v
retrieving revision 1.31
diff -u -r1.31 dumper.c
--- src/dumper.c 2005/10/14 01:22:00 1.31
+++ src/dumper.c 2005/11/13 21:08:21
＠＠ -2103,8 +2103,7 ＠＠
#endif /* not MC_ALLOC */
pdump_dump_root_lisp_objects ();
- retry_fclose (pdump_out);
- retry_close (pdump_fd);
+ retry_fclose (pdump_out); /* closes pdump_fd too */
free (pdump_buf);
Index: src/s/windowsnt.h
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/s/windowsnt.h,v
retrieving revision 1.33
diff -u -r1.33 windowsnt.h
--- src/s/windowsnt.h 2005/01/24 23:34:34 1.33
+++ src/s/windowsnt.h 2005/11/13 21:08:26
＠＠ -165,6 +165,12 ＠＠
3. Think again. Undo still works. */
#if (_MSC_VER >= 800)
+/* The POSIX name for this item is deprecated...
+ Unfortunately also turns off other deprecation warnings.
+ _CRT_NONSTDC_NO_DEPRECATE is preferable, but doesn't appear to work. */
+#define _CRT_NONSTDC_NO_DEPRECATE
+#pragma warning ( disable : 4996 )
+
/* unnamed type definition in parentheses
(Martin added a pedantically correct definition of ALIGNOF, which
generates temporary anonymous structures, and MSVC complains) */
</assembly>
<?xml version="1.0" encoding="UTF-8"
standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
version=
processorArchitecture="X86"
name="xemacs"
type="win32"
/>
<description>xemacs.XEmacs.exe</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
1:23 a.m.
>>>> "Jonathan" == Jonathan Harris
<jonathan(a)xemacs.org> writes:
Jonathan> Small fixes for building under MS Visual Studio 20050
What is the party line on tracking MS's SDKs?
I have no personal opinion (I can't do the work), but I am concerned
because Python's Windows maintainer (whom I respect) is saying
"patches welcome, but the VS 2005 will not be supported" because it's
a pain in the butt for him. We already have a lot of Windows variants
to support (including Cygwin and I suspect some people would like
Mingwin/MSYS), but the only really active Windows developer over the
last two years has been Ben, and he's sporadic.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:24 a.m.
--- "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
>>>>> "Jonathan" == Jonathan Harris
<jonathan(a)xemacs.org> writes:
Jonathan> Small fixes for building under MS Visual Studio 20050
What is the party line on tracking MS's SDKs?
I have no personal opinion (I can't do the work), but I am concerned
because Python's Windows maintainer (whom I respect) is saying
"patches welcome, but the VS 2005 will not be supported" because it's
a pain in the butt for him. We already have a lot of Windows variants
to support (including Cygwin and I suspect some people would like
Mingwin/MSYS), but the only really active Windows developer over the
last two years has been Ben, and he's sporadic.
Which SDK are you referring to, specifically? I only have one of the betas of
VS 2005 and haven't spent much time with it, but from what I read, the C++
compiler and standard library are supposed to be more compliant with the
standard than VS 2003. If you're not worried about building "managed" code,
I'm
not sure what it is about VS 2005 that would be a pain to support. Is there
some benefit, other than security, to building XEmacs with managed code?
--Rick
12:52 a.m.
>>>> "Rick" == Rick Rankin
<rrankin1424-xemacs(a)yahoo.com> writes:
Rick> Which SDK are you referring to, specifically?
The free series (beta and otherwise) from Microsoft labelled VS 2005.
They all got tarred with the same brush.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:39 a.m.
Stephen J. Turnbull wrote:
>>>>>"Jonathan" == Jonathan Harris
<jonathan(a)xemacs.org> writes:
>>>>>
>>>>>
Jonathan> Small fixes for building under MS Visual Studio 20050
What is the party line on tracking MS's SDKs?
I have no personal opinion (I can't do the work), but I am concerned
because Python's Windows maintainer (whom I respect) is saying
"patches welcome, but the VS 2005 will not be supported" because it's
a pain in the butt for him. We already have a lot of Windows variants
to support (including Cygwin and I suspect some people would like
Mingwin/MSYS), but the only really active Windows developer over the
last two years has been Ben, and he's sporadic.
theoretically we support mingw. in practice i don't test with it, so it
probably is slightly bit-rotted (but not much, since i always test with
cygwin); but every so often someone (Craig Lanning?) submits patches.
i don't see anything wrong with patches for VS 2005; after all, we'll
have to "support" it eventually. it's all "no warranty" of course
:)
i.e. it's likely to work with whatever my build system is, but not
guaranteed for anything else.
ben
9:20 a.m.
* Ben Wing <ben(a)xemacs.org> writes:
i don't see anything wrong with patches for VS 2005; after all,
we'll have to "support" it eventually. it's all "no
warranty" of
course :) i.e. it's likely to work with whatever my build system
is, but not guaranteed for anything else.
I have tested VS2005 beta six months ago and I have been hit by some new
politics from MS regarding MSVCRT : they decided not to support anymore
most of the string functions from the C library, at least not in their
old form. They wanted to chase bugs due to misuse of strcpy, strmove,
etc. so they introduce new functions with new prototypes. In hteir new
form, all these string/buffer functions share prototype regularity. All
buffers are passed together wiht their size. The return value indicates
success/failure of the function. Well, in principle that's ok, except
the compiler may by default report errors when not using these new
functions. This breaks lots of existing code. IIRC there is a
compatibility mode reporting only warnings. However, clearly MS wants to
rule out the old C library from the stuff they support. This is what I
have infered from my tests.
Fabrice
8:26 p.m.
Fabrice wrote:
I have tested VS2005 beta six months ago and I have been hit by some
new politics from MS regarding MSVCRT : they decided not to support
anymore most of the string functions from the C library, at least
not in their old form.
...
Perhaps this is the "pain in the butt" issue that Stephen reports from
the Python maintainer.
...
IIRC there is a compatibility mode reporting only warnings. However,
clearly MS wants to rule out the old C library from the stuff they
support. This is what I have infered from my tests.
I found that basically everything worked fine apart from lots of
warnings along the lines of "The POSIX name for this item is
deprecated...", which this patch suppresses. The only other issue is
packaging up the std C library for redistribution, which I'll address in
another patch.
VS2005 is available in a free (as in beer) version[*] and so is likely
to be popular. I think that in the past we've supported the last two
versions of MS tools, which would suggest dropping support for VS 6.
Jonathan.
* http://msdn.microsoft.com/vstudio/express/visualc/download/
8:40 p.m.
* Jonathan Harris <jonathan(a)xemacs.org> writes:
I found that basically everything worked fine apart from lots of
warnings along the lines of "The POSIX name for this item is
deprecated...", which this patch suppresses. The only other issue
is packaging up the std C library for redistribution, which I'll
address in another patch.
Ok, I didn't check with the final version. What I reported was about
beta1 and maybe they stepped back because it was really annoying.
It is good to know that xemacs compiles with the free version of
VS2005. Well it is good to know that it compiles iwth VS2005 and that
ther is a free version of VS2005 ;-)
Best regards,
--
Fabrice Popineau
------------------------
e-mail: Fabrice.Popineau(a)supelec.fr | The difference between theory
voice-mail: +33 (0) 387764715 | and practice, is that
surface-mail: Supelec, 2 rue E. Belin, | theoretically,
F-57070 Metz | there is no difference !
1:04 a.m.
>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
Ben> i don't see anything wrong with patches for VS 2005; after
Ben> all, we'll have to "support" it eventually. it's all
"no
Ben> warranty" of course :) i.e. it's likely to work with whatever
Ben> my build system is, but not guaranteed for anything else.
OK, that is about what I'd expected, and seems consistent with what
Andy and Jonathan say.
Fabrice and Rick: Thanks for your comments and your interest. That
doesn't mean things can't change, only that you'll either have to do
it yourself, or specifically ask (probably Ben or Jonathan) for more
robust support.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7001
days inactive
7003
days old
9 comments
6 participants
participants (6)
-
Andy Piper -
Ben Wing -
Fabrice Popineau -
Jonathan Harris -
Rick Rankin -
Stephen J. Turnbull