Microsoft Visual C++ 2005

Moderator: GZDoom Developers

User avatar
MartinHowe
Posts: 2056
Joined: Mon Aug 11, 2003 1:50 pm
Preferred Pronouns: He/Him
Location: East Suffolk (UK)

Microsoft Visual C++ 2005

Post by MartinHowe »

This applies to all editions of Microsoft Visual C++ 2005.

Randy please would you consider upgrading the ZDoom source code to be compliant with MSVC 2005 as soon as possible? This is now the "official" current C compiler from Microsoft, the one that replaces the old 2003 and V6 compilers.

Those "people" (must use a polite word there) at Microsoft have decided to deprecate half the standard C library due to buffer overruns and POSIX names. This makes compiling ZDoom and GZDoom very difficult due to the blizzard of warnings. In an ideal world, the code would be rewritten to overcome the problems properly, but of course that would take a lot of time.

Therefore at the very least, could a set of macros be loaded by EVERY source file in ZDoom and its dependencies that needs them in order to remove the warnings? In particular we do not want to permanently change the source to use the new ISO names as it would then screw up compilation with MinGW and Linux.

Below please find below the list of macros that are potentially needed as if they were in some globally included file. Of course some files (such as zlib) already redefine, for example, fdopen to be _fdopen so it isn't quite as simple as that, but the following should be a useful starting point.

Code: Select all

#if defined(_MSC_VER) && (_MSC_VER >= 1400)
#define _CRT_SECURE_NO_DEPRECATE
#define _CRT_NONSTDC_NO_DEPRECATE
// The following aren't needed if the above line
// is used, so this is just a list for reference.
#define access      _access
#define cabs        _cabs
#define cgets       _cgets
#define chdir       _chdir
#define chmod       _chmod
#define chsize      _chsize
#define close       _close
#define cprintf     _cprintf
#define cputs       _cputs
#define creat       _creat
#define cscanf      _cscanf
#define cwait       _cwait
#define dup         _dup
#define dup2        _dup2
#define ecvt        _ecvt
#define eof         _eof
#define execl       _execl
#define execle      _execle
#define execlp      _execlp
#define execlpe     _execlpe
#define execv       _execv
#define execve      _execve
#define execvp      _execvp
#define execvpe     _execvpe
#define fcloseall   _fcloseall
#define fcvt        _fcvt
#define fdopen      _fdopen
#define fgetchar    _fgetchar
#define filelength  _filelength
#define fileno      _fileno
#define flushall    _flushall
#define fputchar    _fputchar
#define gcvt        _gcvt
#define getch       _getch
#define getche      _getche
#define getcwd      _getcwd
#define getpid      _getpid
#define getw        _getw
#define hypot       _hypot
#define inp         _inp
#define inpw        _inpw
#define isascii     __isascii
#define isatty      _isatty
#define iscsym      __iscsym
#define iscsymf     __iscsymf
#define itoa        _itoa
#define j0          _j0
#define j1          _j1
#define jn          _jn
#define kbhit       _kbhit
#define lfind       _lfind
#define locking     _locking
#define lsearch     _lsearch
#define lseek       _lseek
#define ltoa        _ltoa
#define memccpy     _memccpy
#define memicmp     _memicmp
#define mkdir       _mkdir
#define mktemp      _mktemp
#define open        _open
#define outp        _outp
#define outpw       _outpw
#define putch       _putch
#define putenv      _putenv
#define putw        _putw
#define read        _read
#define rmdir       _rmdir
#define rmtmp       _rmtmp
#define setmode     _setmode
#define sopen       _sopen
#define spawnl      _spawnl
#define spawnle     _spawnle
#define spawnlp     _spawnlp
#define spawnlpe    _spawnlpe
#define spawnv      _spawnv
#define spawnve     _spawnve
#define spawnvp     _spawnvp
#define spawnvpe    _spawnvpe
#define strcmpi     _stricmp
#define strdup      _strdup
#define stricmp     _stricmp
#define strlwr      _strlwr
#define strnicmp    _strnicmp
#define strnset     _strnset
#define strrev      _strrev
#define strset      _strset
#define strupr      _strupr
#define swab        _swab
#define tell        _tell
#define tempnam     _tempnam
#define toascii     __toascii
#define tzset       _tzset
#define ultoa       _ultoa
#define umask       _umask
#define ungetch     _ungetch
#define unlink      _unlink
#define wcsdup      _wcsdup
#define wcsicmp     _wcsicmp
#define wcsicoll    _wcsicoll
#define wcslwr      _wcslwr
#define wcsnicmp    _wcsnicmp
#define wcsnset     _wcsnset
#define wcsrev      _wcsrev
#define wcsset      _wcsset
#define wcsupr      _wcsupr
#define write       _write
#define y0          _y0
#define y1          _y1
#define yn          _yn
#endif
Comments please?
Last edited by MartinHowe on Fri Mar 24, 2006 5:31 pm, edited 2 times in total.
User avatar
MartinHowe
Posts: 2056
Joined: Mon Aug 11, 2003 1:50 pm
Preferred Pronouns: He/Him
Location: East Suffolk (UK)

Post by MartinHowe »

OK, for those poor saps who are stuck with MSVC 2005, here's what I did to get ZDoom to compile and run with it. (This assumes that you already know how set up the necessary libraries, unix-command-line-tools and so forth, just as you would have had to for MSVC7).

1. Open the zdoom.sln file. It shows as a sort-of text-file-like icon with the number "7.1" on it. The IDE will force you to convert the files to the new formats and by default offers to create backup copies. Do so. The warnings in the log file can be ignored for now.

2. For each of the projects open the project property pages and navigate to Configuration Properties, C/C++, Advanced.

3. Under Configuration: select all configurations.

4. In the Disable Specific Warnings setting, enter 4995;4996.

5. In the entire source archive, delete all .pch and .idb files. Also delete any existing Release and Debug directories in zdoom and all of its subdirectories.

6. For 2098, use Replace in Files to perform the following replacements:

a) "LONG(" -> "ZDOOM_LONG("
b) "LONG (" -> "ZDOOM_LONG ("
c) "SHORT(" -> "ZDOOM_SHORT("
d) "SHORT (" -> "ZDOOM_SHORT ("

You do not need to this for the SVN repo stuff; however, I haven't tried that yet, so that probably doesn't matter. THIS ADVICE IS FOR 2098 ONLY!!!! For n00b programmers: do not type the quotes in a-d above, they're only used here for clarity.

7. At line 1385 (in 2098 anyway) of s_sound.cpp in routine S_ChangeMusic.cpp change the "char *more" to be "const char *more". Hmm... it always could have been, so wonder why it wasn't?

8. For the DEBUG version, copy the thingdef_specials.gperf file from the src directory into the main zdoom directory. It works, though I'm not sure why. You don't need to do this for the RELEASE version.

9. Select the zdoom project property pages and navigate to the Manifest Tool, Input and Output page. Modify the "Embed Manifest" setting to "No".

10. Build it and go destroy something with it :) I just killed five ettins and smashed four stained-glass windows. Aren't I the vandal :)

Thanks to Bio, Grubber and Graf for various hints and advice.
Last edited by MartinHowe on Thu Mar 23, 2006 6:04 pm, edited 2 times in total.
dennisj1
Posts: 399
Joined: Sun Jan 11, 2004 1:46 pm
Location: Superior, WI

Post by dennisj1 »

@MartinHowe: Will GZDoom actually compile with Microsoft Visual C++ 2005? (I got MSVC2005 Express). If so, interesting... I should check it out.
User avatar
MartinHowe
Posts: 2056
Joined: Mon Aug 11, 2003 1:50 pm
Preferred Pronouns: He/Him
Location: East Suffolk (UK)

Post by MartinHowe »

dennisj1 wrote:@MartinHowe: Will GZDoom actually compile with Microsoft Visual C++ 2005? (I got MSVC2005 Express). If so, interesting... I should check it out.
Yes, I recently regenned my system and have downloaded the entire Express suite. I have successfully compiled and run GZDoom (Release) via MSVC 2005 Express as described above. I did experience some manifest-related problems with compiling a debug release, so I'll have to look into that.
User avatar
sirjuddington
Posts: 1030
Joined: Wed Jul 16, 2003 4:47 am
Location: Australia
Contact:

Post by sirjuddington »

#define _CRT_SECURE_NO_DEPRECATE
#define _CRT_NONSTDC_NO_DEPRECATE

That will get rid of most warnings.
User avatar
MartinHowe
Posts: 2056
Joined: Mon Aug 11, 2003 1:50 pm
Preferred Pronouns: He/Him
Location: East Suffolk (UK)

Post by MartinHowe »

SlayeR wrote:#define _CRT_SECURE_NO_DEPRECATE
#define _CRT_NONSTDC_NO_DEPRECATE

That will get rid of most warnings.
Quite, but if not built into the source (being conditional upon the value of _MSC_VER) it means fiddling with the project files or manually adding them to the source every time a new version appears. It'd be really nice if Randy built those into the source himself.
DaniJ
Posts: 116
Joined: Sun Jan 30, 2005 12:52 am

Post by DaniJ »

You could add those as a directive from the command line rather than editing the source, when compiling.

/D "_CRT_SECURE_NO_DEPRECATE" /D "_CRT_NONSTDC_NO_DEPRECATE"
User avatar
MartinHowe
Posts: 2056
Joined: Mon Aug 11, 2003 1:50 pm
Preferred Pronouns: He/Him
Location: East Suffolk (UK)

Post by MartinHowe »

DaniJ wrote:You could add those as a directive from the command line rather than editing the source, when compiling.

/D "_CRT_SECURE_NO_DEPRECATE" /D "_CRT_NONSTDC_NO_DEPRECATE"
Sure, but that still involves the project files. Mind you, since they don't get updated back into ZDoom, that's probably OK. It would be nice if Randy could support MSVC8, it's free and (supposedly) can be installed alongside VC7; especially as it is now the "official" MS compiler.

By the way, I have tried to compile ZDoom 2098 from source using the same methods as detailed above (excepting DevIL and OpenGL specific stuff).

The problem here is that m_swap.h defines LONG and SHORT as byte-swapping macros and these conflict with the Platform SDK.

As a matter of urgency, if Randy could at least replace these macro names with something that doesn't conflict with the SDK it would be nice. For the moment, I replaced them with ZDOOM_LONG and ZDOOM_SHORT and it now works OK for release version.

Compiling for debug version gives an error about not being able to find thingdef_special.gperf, but the compiler can't say why it is an error, since the file clearly exists. It seems to be looking for it in the wrong directory, but I don't want to risk moving it in case Randy has a reason for it being in the "src" subdirectory - I have no experience with GPerf at all. (EDIT: I copied the file into the main zdoom directory and it compiles :? ). I also get the same "duplicate resource" error concering manifests. If anybody can explain this, it would be a great help (see this thread).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

MartinHowe wrote: The problem here is that m_swap.h defines LONG and SHORT as byte-swapping macros and these conflict with the Platform SDK.

As a matter of urgency, if Randy could at least replace these macro names with something that doesn't conflict with the SDK it would be nice. For the moment, I replaced them with ZDOOM_LONG and ZDOOM_SHORT and it now works OK for release version.

He has done that already. Guess why GZDoom (which is based on much more recent code) doesn't use them anymore?
User avatar
Grubber
Posts: 1031
Joined: Wed Oct 15, 2003 12:19 am
Location: Czech Republic
Contact:

Post by Grubber »

@MartinHowe: In project properties, set "Manifest Tool->Input and Output->Embed Manifest" to "no". MSVC 2005 generates manifest file, but zdoom has its own.
User avatar
MartinHowe
Posts: 2056
Joined: Mon Aug 11, 2003 1:50 pm
Preferred Pronouns: He/Him
Location: East Suffolk (UK)

Post by MartinHowe »

The HOW-TO guide in the second message in this thread has been updated. As far as I can see, this is now the definitive guide to building ZDoom 2098 with MSVC 2005. If anybody has any suggested improvements, please reply to this thread.
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Post by randi »

Done, although not really because it was a feature suggestion. ;)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Was this really necessary? :(
User avatar
Grubber
Posts: 1031
Joined: Wed Oct 15, 2003 12:19 am
Location: Czech Republic
Contact:

Post by Grubber »

I'm all for it. MSVC 2005 > MSVC 2003
User avatar
MartinHowe
Posts: 2056
Joined: Mon Aug 11, 2003 1:50 pm
Preferred Pronouns: He/Him
Location: East Suffolk (UK)

Post by MartinHowe »

Graf Zahl wrote:Was this really necessary? :(
Since 2005 is the shipping current standard MSVC compiler that all the world and his wife (or "her husband" or "their cat" :) ) will soon be using, I'm afraid yes. You can still get the Express version of 2005 for free and the standard edition isn't that expensive. Express is well-capable of compiling large C++ and C programs -- it copes with (G)ZDoom after all :P
Post Reply

Return to “Closed Feature Suggestions [GZDoom]”