PDA

View Full Version : update from VC6.0 to vs2003 or vs2005?



helenw
05-24-2006, 07:45 AM
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

jide
05-24-2006, 08:06 AM
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.

Coconut
05-24-2006, 08:37 AM
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.

Izhido
05-24-2006, 09:07 AM
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?

helenw
05-24-2006, 09:52 AM
I have to convert my code from VC6.0 to VS2003 or VS2005?

helenw
05-24-2006, 09:57 AM
Everybody has to convert the code from VC6.0 to VS2003 or VS2005?
We have to update from this to that ......?

helenw
05-24-2006, 10:00 AM
It is too tired for us programmer to update codes from a system to anothers.

knackered
05-24-2006, 10:20 AM
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.

Bobo.Bobo
05-24-2006, 01:53 PM
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.

Korval
05-24-2006, 06:23 PM
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.

tamlin
05-25-2006, 08:59 AM
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 (http://www.mingw.org/) 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.

Zulfiqar Malik
05-25-2006, 11:22 AM
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 :p , lol.

Humus
05-25-2006, 03:46 PM
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

V-man
05-25-2006, 08:42 PM
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

zed
05-25-2006, 11:02 PM
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

knackered
05-26-2006, 08:41 AM
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.

V-man
05-26-2006, 07:36 PM
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.

Humus
05-26-2006, 08:57 PM
Originally posted by knackered:
strcpy is not a particularly lightweight function as it stands (being a strlen followed by a memcpyNot 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.

Zulfiqar Malik
05-26-2006, 11:40 PM
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.

RigidBody
05-27-2006, 03:46 AM
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.

knackered
05-27-2006, 07:04 AM
std::string is meant to be a common exchange structure for strings, as a direct replacement for char*. Extra functionality like printf should be added by deriving from it or using the algorithms, I've always assumed.
Humus, why would there be a compare for every character in the string when there's block copy operations in CPU's to be used for things like this. I remember looking at the assembly of VC6's strlen function and it uses some fancy tricks to speed it up, like comparing a dword at a time.

Roderic (Ingenu)
05-27-2006, 08:38 AM
Originally posted by Zulfiqar Malik:
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. std::string with std::ostream (or specifically std::ostringstream) should do the trick, as it's meant to replace the C sprintf function.
The difference is that you need to setup the std::ostream instead of formating through the function call.

ebray99
05-28-2006, 02:12 AM
Well, it looks like this thread is going way off topic from OpenGL, but I'll add to it anyways since I feel this is pretty useful information. std::ostringstream is horrendously slow. By "horrendously slow", I mean 100 times per frame will severely impact your framerate. I encountered a performance bug a few projects ago that had to do with using std::ostringstream in UI code. Not fun. This was the case in VC6, but may no longer be the case since implementation Microsoft ships has changed since then. However, you will definately want to do some performance tests to see for yourself.

Kevin B

Humus
05-28-2006, 11:16 PM
Originally posted by RigidBody:
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. In source code yes, but obviously the compiler will optimize that and use the value already in the register.

Humus
05-28-2006, 11:34 PM
Originally posted by knackered:
Humus, why would there be a compare for every character in the string when there's block copy operations in CPU's to be used for things like this. I remember looking at the assembly of VC6's strlen function and it uses some fancy tricks to speed it up, like comparing a dword at a time. Of course you can do DWORD compares and writes at the same time too. But what I'm thinking here is that reading the entire string first, and then copying it means that you'll read the memory again. For short strings it will pretty much always be in the cache, so the practical difference may be small, but for longer strings it could affect performance quite a bit.

The block copy operations (assuming you mean REP MOVSD and the like) is AFAIK no longer recommended for use on modern CPUs as a normal loop with basic instructions doing the same work is faster.

RigidBody
05-29-2006, 01:27 AM
Originally posted by Humus:

Originally posted by RigidBody:
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. In source code yes, but obviously the compiler will optimize that and use the value already in the register. i didn't doubt that ;)

but if strlen + memcpy is used, the src string will be read from the cache. that's not as fast as a register, but closer to the cpu than main memory.

anyway, we're offtopic, and furthermore- i don't think that anyone will ever have a performance problem caused by strcpy.

Madoc
05-29-2006, 02:15 AM
Originally posted by Humus:
The block copy operations (assuming you mean REP MOVSD and the like) is AFAIK no longer recommended for use on modern CPUs as a normal loop with basic instructions doing the same work is faster. Gutted. How can that be? I always use that stuff with the assumption that it is a fair bit quicker.

knackered
05-29-2006, 07:23 AM
Humus, you've out-geeked me - I'm not that familiar with the comings and goings of modern CPU's (other than that they've got big caches and can perform the same instruction on multiple data), the last assembly I did was on the Z80. I take your word for it, and will regurgitate it as well-known fact to anyone else in the future, as I do with most of Korvals stuff.

Komat
05-29-2006, 06:15 PM
Gutted. How can that be? I always use that stuff with the assumption that it is a fair bit quicker. Entirely naive implementation would be linkely not faster however there are several tricks that can be done when the rep movsd is not used. Example of such things is prefetching, use of the SSE registers to copy 16 bytes at once and with special instructions that do not polute the caches. As example of such optimalizations can serve this memcpy optimized for the AMD Athlon procesors made by the AMD (http://www.cs.virginia.edu/stream/FTP/Contrib/AMD/memcpy_amd.asm) (I have once seen some paper about similiar optimalization with some performance numbers however I do not know where it was) or this page (http://now.cs.berkeley.edu/Td/bcopy.html) about optimalization done on old Pentium 1 based cpus.

V-man
05-29-2006, 07:28 PM
On .NET 2003, strcpy works by copying DWORD. It is written in assembly.
I think the optimized memcpy using MMX (that AMD code) needs to be tested. I once borrowed someones code for memcpy_mmx and the website said it is actually slower than than rep movsd and to my surprise, they were right.

"rep movsd" use to be a ultra special instruction. If it is no longer so ...

tamlin
05-30-2006, 02:54 AM
The runtime version of memcpy has been copying DWORD's since at least VC6, but probably earlier. If you view the assembler source code (crt\src\intel\memcpy.asm) you'll find it also takes into account the U and V pipes (for instruction pairing).

One thing that can seriously bite, is that the intrinsics of mem* functions (memcpy, strlen, strcpy and so on) at least up til VC7.0 (I haven't tested this with 7.1 or 8) produced code as if "optimizing" for a 386SX. I have particular fond memories of how a string operation (probably strcpy) ran 3.5 times (!) faster using the runtime library version over the intrinsic version. What's especially bad with this, is that turning on /O2 optimization brought with it /Oi (generate intrinsics).

If you ever see one of those memory-array functions becoming a bottleneck, knowing this can save a lot of frustration.