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
Targeting 64-bit
-
frag.machine
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
-
daemonicky
- Posts: 185
- Joined: Wed Apr 13, 2011 1:34 pm
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.
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.
Me too.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.
Think, touch, movetype, solid, traceline ...
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.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-
frag.machine
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
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 2Gbmh 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.
), but reverted to 2008 at home. Looks like being a Microsoft expensive tool isn't enough to ensure quality, either.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC 
(LordHavoc)
(LordHavoc)Re:
The gems in this thread have been quite useful.
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.
A late reply for sure --- that's a great point. No one does know what kind of Windows they are running.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'...
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.
The night is young. How else can I annoy the world before sunsrise? 
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..Re: Targeting 64-bit
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.
Re: Targeting 64-bit
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).
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).
Re: Targeting 64-bit
not to mention a totally different architecture (arm vs x86)Spike wrote:except for winrt versions which are strictly 32bit... yay.