Visual C++ 2010 Express support

[dtugend]

fixes #1338

Changes:

• added project files for Visual C++ 2010 Express
• resolved function calls that would otherwise be ambiguous now
• solved ARRAYSIZE macro and HSPRITE type collisions with Windows.h and
  winsock.h includes by guarding the includes
• "solved" _MSC_VER issues in public/interface.h / inclusion of non-existent file instead of the other content

TODO:
We should think about if we actually should instead link to a .h that
defines / redirects the required macros, so that platform differences
would be limited to a few .cpp files (meaning not including windows.h in a
huge number of files as it is now), see the issue above for details.

TODO2:
Converting the many other .dsp files (the tools) too.

[dtugend]

See this as just a suggestion, I won't be sad if it gets rejected or s.th..

[dtugend]

Attention:
The following line in the .gitattributes file needs review:
*.dsp text eol=crlf

This will cause git to normalize line endings to LF, as soon as the files a touched (use touch command i.e.).
However upon checkout the files will be CRLF, including the .zip download (since that one goes through checkout too), meaning only the internal representation in the repro will change.

If this is not wanted, then remove the line for the .dsp files please.

[dtugend]

The idea I listed under "TODO" in the first post is sadly an complicated option:

You would want to get the MAX_PATH macro value out of the .cpp without including windows.h in the .h.
Sadly extern const is not an option, because the compiler doesn't consider that an constant expression.

The only way to get it out would require a custom preprocessing step, so that the .h file is generated with the correct value before the actual build of the DLLs.
I have never done such a custom preprocessing step yet and don't know if it will work with MSVC++ (I have heard such things are done in Linux autobuilds).

But if you think the idea is worth trying, I would try to do such a thing?

[alfred-valve]

Looks good to me, I've not loaded the vproj's locally though. I don't know enough about GIT to understand the line ending issue, isn't your change good in that it forces CRLF on the vproj and dsp files when you sync them, which is what you want (because windows/msdev expects it)?

[dtugend]

Regarding the GIT issue (my understanding of GIT is very limited too):

*.dsp text eol=crlf
Seems to work as follows (as far as I understand):
It forces CRLF upon checkout (which also applies correctly to the .zip download).
However the internal representation in the repro will be normalized to LF (currently you have the internal representation of the .dsp as CRLF; The internal representation of .sln and .vcxproj should be LF already.).
So as soon as someone touches the .dsp files (i.e. touch command), it will detect them as changed and will want to normalize to LF for internal representation (this should happen one time only, since after that the internal representation with LF will match the one on check-in then).

You can see what I mean (as long as the .dsps are not normalized yet) as follows:

• touch cl_cdll/cl_dll.dsp
• git diff cl_cdll/cl_dll.dsp > foo.txt
• Examine foo.txt in i.e. Notepad++ (View -> Show Symbol -> Show all Characters) and see that it converts CRLF to LF endings (as said this will happen one time only, and it will be CRLF upon checkout and in the .zip download).

(I haven't found a better solution to prevent Windows users that usually have core.autocrlf=true from converting the dsp files to LF (would affect the .zip download, since that one is checked out on a Linux system).)

[jeandrek]

Wow, I applaud you for porting this ancient piece of software to compile with Visual C++ 2010 while still maintaining compatibilty with Visual C++ 6.0, and Valve too for actually accepting it (even though I'm somewhat dissapointed with the Steam version of the Half-Life SDK missing a lot of what is necessary to make a mod even though the ReadMe.txt file says it should be there.)