update from VC6.0 to vs2003 or vs2005?

My system is developed using VC6.0 with openGL. Do you think whether I have to convert my code to VS2003 or VS2005?
Does VS2003/VS2005 support opengl?

thanks

Huh ? Why would they not support it ? Try dev-cpp, I guess it’s one of the best non commercial IDE and respect fully ISO C/C++ standards.

Download and install the free VS2005 express version, and see if your stuff complies.
I can see OpenGL’s .h and .lib files under …\VC\PlatformSDK…
If it satisfies your definition of “support”, then yeah, it is supported.

Hi!

Um… actually I’m having a problem with that. See, \VC\PlatformSDK\ is not present in my hard drive. Of course, this means that I will need to download the “Microsoft Platform SDK for Windows Server 2003 R2” thing from their site, but at almost 900MB frankly I’m thinking this might not be a good idea. All the “gl*.h” files are full of Windows-specific #defines and DATA_TYPEs, so the “normal” header files are basically useless without the PSDK. Do you know if I can install something else that lets me develop Windows OpenGL apps with VC2005 Express without the Platform SDK?

I have to convert my code from VC6.0 to VS2003 or VS2005?

Everybody has to convert the code from VC6.0 to VS2003 or VS2005?
We have to update from this to that …?

It is too tired for us programmer to update codes from a system to anothers.

works without any problems here. Nothing had to be downloaded.
Be prepared though, helen my sweet pickaxe, you’ll have to install the dreaded Windows XP Service Pack 2.

Hello,
there is no problem with OpenGL in any Visual Studio, so don’t worry to update your VS.
There are some problems with VS 2005, like tons of unresolved externals from single-threaded and/or multi-threaded functions, and things like deprecated functions (MS deprecated almost all stdio functions like printf, and advise to use printf_s (from “secure”… what a stupid idea… couldn’t they just secure printf instead of making the new one? This “_s” makes code look more complex) that requires some time to solve, but it can be solved and it’s not related to OpenGL.
Since all extensions functions are taken from driver, you just need to download new glext.h and put it into “Microsoft Visual Studio 8\VC\PlatformSDK\Include” directory, the same place to put glut.h and other GL or (for example) CG files.

Of course make a backup before converting, because there is a little possibility that you’ll get stuck… All conversions to newer versions of VS requires some time, even days.
Good luck.

Do you know if I can install something else that lets me develop Windows OpenGL apps with VC2005 Express without the Platform SDK?
Can you develop for the Mac without the Mac SDK (assuming it doesn’t come on your machine)? Can you develop for X-Windows without an SDK for that (once again, assuming it doesn’t come with X)?

If you want to write a Windows app, you need the Windows Platform SDK. I don’t recall it being 9000MB though; more like 90 or so.

Korval wrote:
If you want to write a Windows app, you need the Windows Platform SDK. I don’t recall it being 9000MB though; more like 90 or so.
MS PSDK isn’t really needed. w32api works.

The MS PSDK was 6-8 months ago something like 400-450MB IIRC (the freely downloadable CD image), but it’s constantly growing. Once installed, its on-disk directory was around 260-270MB. 40MB of that was include files.

Wtf :S, what sort of discussion is this? What sort of problems can a person encounter while shifting compiler(s)? You just need to use the headers/libs/dlls (whatever) you were already using with vc6 with vc7 and vc8. I can’t see anyone doing much wrong with that. Knackered, i feel like i am doing your job :stuck_out_tongue: , lol.

Originally posted by Bobo.Bobo:
There are some problems with VS 2005, like tons of unresolved externals from single-threaded and/or multi-threaded functions, and things like deprecated functions (MS deprecated almost all stdio functions like printf, and advise to use printf_s (from “secure”… what a stupid idea… couldn’t they just secure printf instead of making the new one? This “_s” makes code look more complex) that requires some time to solve, but it can be solved and it’s not related to OpenGL.
Here’s some info how to work around issues with the CRT security update:
http://msdn2.microsoft.com/en-us/library/8ef0s5kh.aspx

The easiest way if you don’t care about the security stuff in VC2005 is to just add this to a top-level header:

// To get rid of MSVC 2005 warnings
#if _MSC_VER >= 1400
#pragma warning (disable: 4996)
#endif

It’s funny how it takes decades before a proper version of something is created.
strcpy_s checks to make sure the destination is large enough so that overflow can be avoided!!! LOL

Originally posted by V-man:
It’s funny how it takes decades before a proper version of something is created.
strcpy_s checks to make sure the destination is large enough so that overflow can be avoided!!! LOL

but i assume its gonna be slower than strcpy with the bounds check overhead, thus if u had the between choice of strcpy + strcpy_s, having only strcpy would be the correct choice (lowest common denominator), u could always wrap it with something like strcpy_s

strcpy is not a particularly lightweight function as it stands (being a strlen followed by a memcpy), so it would have to be a particularly small string for an additional compare instruction to start being significant.
In my experience (with thick junior programmers who can’t get their head around null terminators versus string length), manipulating strings using the string.h functions causes the most memory bounds problems, so any additional limit checking is a good thing, in release mode as well as debug.
People should really be using std::string by now anyway.

std:string is nice when you concatenate but for doing some manipulation like putting a ‘\0’ somewhere, or looking for a certain char and overwriting with another, it somehow looks overcomplicated.

Originally posted by knackered:
strcpy is not a particularly lightweight function as it stands (being a strlen followed by a memcpy
Not that I know how it’s actually implemented, but why would you do that way? It would seem to me that doing it like this would be faster:

while (*src){
  *dst++ = *src++;
}

That way the string isn’t read twice.

The biggest problem (among others smaller ones) with std::string is the absence of an sprintf(…) style formatting function. Its the biggest nuisance and it has forced me to write my own string class.

humus,

in your code the src string is read twice, too- character by character. for the first time when the while-condition is checked, and for the second time when it is copied to dst.