Quake 2 MS-VC 6 does not transfer to VS2010 Express
#1 Members - Reputation: 79
Posted 30 September 2011 - 09:31 AM
C:\Users\Columbus\Documents\Visual Studio 2010\Projects\quake2-3.21\game\game.dsp : error : Project upgrade failed.
C:\Users\Columbus\Documents\Visual Studio 2010\Projects\quake2-3.21\quake2.dsp : error : Project upgrade failed.
C:\Users\Columbus\Documents\Visual Studio 2010\Projects\quake2-3.21\ref_gl\ref_gl.dsp : error : Project upgrade failed.
C:\Users\Columbus\Documents\Visual Studio 2010\Projects\quake2-3.21\ref_soft\ref_soft.dsp : error : Project upgrade failed.
#2 Moderators - Reputation: 2309
Posted 30 September 2011 - 04:23 PM
Josh Petrie | Lead Tools Engineer, ArenaNet | Microsoft C++ MVP
#4 Members - Reputation: 2908
Posted 30 September 2011 - 05:03 PM
There are easier paths between where you are and where you're trying to get to, unless the journey is especially appealing to you. (even then, this particular journey is going to be like trekking for months through dense woods, only to reach a clearing at the end and realize you've been paralleling a major freeway the entire time).
#5 Members - Reputation: 79
Posted 30 September 2011 - 05:47 PM
Good luck friend, I tried something similar to that with VS2008 after a few hours of fixing syntax bugs and things the compiler was not happy with I gave up =p
In 2002 i tried to compile quake 2 or 3 on vs2003 and it showed 500 error messages. weird.
#6 Members - Reputation: 2908
Posted 30 September 2011 - 05:55 PM
#7 Members - Reputation: 79
Posted 30 September 2011 - 06:05 PM
Yes. Because VC6 came with both a compiler and a standard library that were completely broken with respect to the burgeoning standard at the time -- sure, VC6 "worked" left to its own devices, and in some ways it was even "good" for the time, but code written against VC6 is necessarily broken and won't work without modifications on *any* other compiler, even the very next iteration of VC, and rightfully so. VS2010's compiler still maintains switches to enable *some* of the broken behavior of VC6 in order to ease porting, IIRC.
"Yes. Because VC6 came with both a compiler and a standard library that were completely broken with respect to the burgeoning standard at the time -- sure, VC6 "worked" left to its own devices, and in some ways it was even "good" for the time, . . . "
What the heck ?
Try to give a little referential documentation and evidence.
#8 Members - Reputation: 2908
Posted 30 September 2011 - 06:09 PM
Everyone and their grandmother knows that VC6 was broken as all shit. They didn't even get the scoping on 'for' loop counters correct (which is one of those switches they maintain, BTW). Perhaps its you who needs to gather the referential documentation.
* -- seriously, it wasn't I who down-voted your post, for what its worth. I find it counter-productive to down-vote people for being mistaken, and assume their misinformation isn't willful or malicious until they've made it clear that it is.
#9 Moderators - Reputation: 2309
Posted 30 September 2011 - 06:19 PM
This is a relatively well-known fact. Visual Studio 6 shipped in June of 1998. C++ itself was not accepted as an ISO standard until September of 1998. VS6 was a decent toolchain for its time, but it was released (and thus, most of its major development) was done well in advance of any kind of final ratification of the C++ standard. The VS team had to pick what was popular and looked good from the available collection of C++ variants and ideas being tossed about and implement that.
Yes. Because VC6 came with both a compiler and a standard library that were completely broken with respect to the burgeoning standard at the time -- sure, VC6 "worked" left to its own devices, and in some ways it was even "good" for the time, but code written against VC6 is necessarily broken and won't work without modifications on *any* other compiler, even the very next iteration of VC, and rightfully so. VS2010's compiler still maintains switches to enable *some* of the broken behavior of VC6 in order to ease porting, IIRC.
"Yes. Because VC6 came with both a compiler and a standard library that were completely broken with respect to the burgeoning standard at the time -- sure, VC6 "worked" left to its own devices, and in some ways it was even "good" for the time, . . . "
What the heck ?
Try to give a little referential documentation and evidence.
Josh Petrie | Lead Tools Engineer, ArenaNet | Microsoft C++ MVP
#10 Members - Reputation: 79
Posted 30 September 2011 - 06:22 PM
Yes. Because VC6 came with both a compiler and a standard library that were completely broken with respect to the burgeoning standard at the time -- sure, VC6 "worked" left to its own devices, and in some ways it was even "good" for the time, but code written against VC6 is necessarily broken and won't work without modifications on *any* other compiler, even the very next iteration of VC, and rightfully so. VS2010's compiler still maintains switches to enable *some* of the broken behavior of VC6 in order to ease porting, IIRC.
"Yes. Because VC6 came with both a compiler and a standard library that were completely broken with respect to the burgeoning standard at the time -- sure, VC6 "worked" left to its own devices, and in some ways it was even "good" for the time, . . . "
What the heck ?
Try to give a little referential documentation and evidence.
Try to have concern with your mouth and language regarding **** and older woman.
And quit annoying users with irrelevant point(s).
#12 Members - Reputation: 139
Posted 30 September 2011 - 06:25 PM
I have inline assembly in my VC++ 2010 projects (legacy from when I bought the non-optimizing VC++ 6 and 2003 editions, so I had to use assembly back then for certain parts). So I am quite sure it works. I think it only doesn't work if you compile it as managed code or as 64 bit. If you compile as 64 bit exec you can however put the assembly code in an external module, compile with nasm and link the resulting object file with the rest.(hint: VS2010 doesn't support inline assembly anymore, in favor of intrinsic instructions (or external assembly files).
#13 Members - Reputation: 4032
Posted 30 September 2011 - 06:40 PM
From 2005 onwards you'll be switched to the multithreaded CRT and won't have an option to go back to single threaded, but I'm not certain if this may or may not be a problem.
I'm pretty certain that starting with 2005 MSVC defaults projects to unicode and this default will come through when you upgrade the project, so you'll need to switch it back to multi-byte.
The warning level will likely also go to 3 instead of 1, so you'll get a whole pile of noise in the compiler output. Flip it back to 1 for your initial build, then ease it back up, fixing things as you go.
If memory serves, the last time I looked at this code one of the Alpha builds was the default project configuration so you need to just set the regular debug or release build instead.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#14 Members - Reputation: 2908
Posted 30 September 2011 - 06:53 PM
I have inline assembly in my VC++ 2010 projects (legacy from when I bought the non-optimizing VC++ 6 and 2003 editions, so I had to use assembly back then for certain parts). So I am quite sure it works. I think it only doesn't work if you compile it as managed code or as 64 bit. If you compile as 64 bit exec you can however put the assembly code in an external module, compile with nasm and link the resulting object file with the rest.
(hint: VS2010 doesn't support inline assembly anymore, in favor of intrinsic instructions (or external assembly files).
Yes, you're right -- it was only the 64-bit compiler that disallows inline ASM (and managed C++ for obvious reasons).






