InsideQC Forums

BTW I've been reading some interesting stuff about converting code from 32 to 64 bit in Gamasutra:

http://www.gamasutra.com/blogs/AndreyKa ... ograms.php

MS does not follow standards again? Oh my ...
So what is the reason for using MSVC? Is it because of nice IDE and because lots of projects are already in it (including Quake, which compiled IIRC without warnings ... maybe id soft toggled them off )? Open Source or GNU crowd (not sure what to call them) might look into UI first; it is a way how Macs or Windows won over Unix for majority of users.


Spike :
I dont know, but this might help http://doc.cat-v.org/henry_spencer/ifde ... ed_harmful or the guys who made it.

mh wrote: That's why I'd prefer the C-like subset of C++ over C any day. C is rubbish for productivity on this count alone. The big things are a nuisance but it's the little things that grate the most.

Me too.

Guess what? gcc doesn't fully implement c99 either.

c99 is A standard, not THE standard. That means that it's optional. It means that a compiler vendor doesn't HAVE to implement it.

Reasons for using MSVC? The IDE is very nice to use, yes. Microsoft have the best debugger in the business, bar none. gdb is amateurish and tacky by comparison. If you're even remotely serious about software development, a really good debugger is a must.

Being Open Source/Free/GNU/whatever is not enough, a tool must be good. Good software is good software, irrespective of the philosophy behind it. And bad software is bad software. And I'm sorry, but gdb is bad software.

list of c99 in support in compilers currently.

http://en.wikipedia.org/wiki/C99

mh wrote:Guess what? gcc doesn't fully implement c99 either.

c99 is A standard, not THE standard. That means that it's optional. It means that a compiler vendor doesn't HAVE to implement it.

Reasons for using MSVC? The IDE is very nice to use, yes. Microsoft have the best debugger in the business, bar none. gdb is amateurish and tacky by comparison. If you're even remotely serious about software development, a really good debugger is a must.

Being Open Source/Free/GNU/whatever is not enough, a tool must be good. Good software is good software, irrespective of the philosophy behind it. And bad software is bad software. And I'm sorry, but gdb is bad software.

MSVC 2008 is a great tool for C/C++, no doubt. That said, MSVC 2010 is a huge pile of steaming poo, mostly because .NET 4.0. Among other minor bugs autocomplete support is fubar'd without SP1, and even after this is slooooooow. Also, it forces me to run an instance of SQL Server Express because apparently it saves the project/solution metadata in a database (stupid idea). I have to use it in my job (and now I need 4Gb of RAM to do the same I used to do with 2Gb ), but reverted to 2008 at home.
Looks like being a Microsoft expensive tool isn't enough to ensure quality, either.

pff, msvc6 > all

The gems in this thread have been quite useful.

Spike wrote:noone knows what sort of windows they have. they don't understand 32bit or 64bit systems, they just know they're running windows! If you're lucky, they might know that its called 'XP'...

A late reply for sure --- that's a great point. No one does know what kind of Windows they are running.

Need to do some more checks for "offset" kind of stuff in model loaders and stuff, but I appear to have a 32/64 bit build going. Although the 64-bit version isn't running on Windows, but my Mac.

Just to be fair, and to further confuse the issue, it's entirely possible to have mixed 32/64 in a consumer product! This laptop - a Toshiba - came with a 64-bit Athlon chip but 32-bit Windows Vista.

64bit windows cannot run 16bit code (the 64bit instruction set does not support the 'vm86' extension for running 16bit paged code). It can be supported with software emulation or vmx/smx extensions (depending on cpu vendor), but not all intel cpus even support vmx, so its hardly universal. And yes, there was a disturbing amount of 16bit software still around (not just dos games, but windows software too), such that 32bit windows was a muuuch safer bet.
win7 is more commonly 64bit, but that's still by no means guarenteed.
win8 is much more commonly 64bit, except for winrt versions which are strictly 32bit... yay.

the only 64bit issues in vanilla quake that I can presently recall were sprites and qc strings (which can be a fairly significant issue in certain situations, and not noticable in others).

Spike wrote:except for winrt versions which are strictly 32bit... yay.

not to mention a totally different architecture (arm vs x86)