Moving to Visual Studio 8

[Indiepath]

I'm very happy with VS6 - it just works! I do feel it's time I migrate to VS8, what are the implications with regard to distributables? ie. Can I assume that the majority of users will be able to run the applications without having to download additional runtimes?

[Nikster]

Depends on the libraries you link against, but normally it's only an issue with things like mfc and the like, I always statically link things which I can to avoid issues like "user doesn't have mcvrt1000293-1.dll" :)

[Backov]

Your user has to have the msvc redistributables installed. It's a small installer, and they often have it - but even on new Vista laptops I have recently had to install it.

You also can't properly statically link against them or just include them in the local dir - doesn't work and bad idea respectively. I should say that yes, you can statically link the MSVCRT stuff, but that screws up a lot of other stuff - like game engines.

Anyway, VC8 adds a LOT over VC6, but that's the gotcha. It's an artifact of Windows new Side by Side DLL system, which is supposed to eliminate the DLL hell, and does a not bad job of it.

[Nikster]

You also can't properly statically link against them or just include them in the local dir - doesn't work and bad idea respectively. I should say that yes, you can statically link the MSVCRT stuff, but that screws up a lot of other stuff - like game engines.


You confused me with the can't and can link business :D but which game engines would it screw up on ? I've yet to hit any problem with any 3rd party libraries when I've statically linked msvcrt.

[svero]

I did this move pretty recently. Big disappointment for me. Can't say as I love the new IDE much. I'm hard pressed to think of any advantages from the switch. Macros are terrible. Compiler is slower. It's full of bugs. Keyboard customization is worse. You can't even add an icon to a c++ windows app and have it work properly. I'm really not terribly impressed overall. Unless you have some pressing need to switch or you're planning on writing managed code (c# etc...) I don't see the move as being that helpful. Like you I felt I was way behind and it was time to upgrade. One of the reasons I moved was to be able to use that xna stuff. I bought the standard package. XNA only works with the free package.

IMHO msdev is all downhill since version 4.2 -- If this is what it takes microsoft 12 yrs or so to come up with they should just stop working on it and save everyone a lot of trouble. It's particularly disgusting when you consider that this is a development tool. You'd think the programmers working on this thing would have to also use it... Donno. I'm at a loss for an explanation really.

[jessechounard]

The next version of XNA (which should be out by the end of the year) will support the full versions.

I also had some disappointment with VC++ 2005, but it's because C# 2005 is so incredible. The code completion is worthless by comparison, and the refactoring tools in C# are incredibly useful.

But still, there's no way I could go back to VC++ 6.0. The compiler was just far too broken. The IDE was really great, but I'd have to use mingw under the hood through makefiles or something.

[Backov]

You confused me with the can't and can link business :D but which game engines would it screw up on ? I've yet to hit any problem with any 3rd party libraries when I've statically linked msvcrt.

Ogre specifically in my case - but I assume any library where it's a "Multi-Threaded DLL" would screw up. Even though Ogre doesn't actually do any multi threading by default, it's built that way and if you statically link MSVCRT you break it.

[vjvj]

I like VC 2005 a lot. I statically link as well, and rebuild all the libraries I use in order to ensure that everything links up fine. However, I know one of these days I need to stop being a hack and look into that side-by-side stuff.

The funniest part about 2005 is MS's decision to deprecate standard C functions. There's a flag to disable the warning; you'll probably want to use it :)

[Sharpfish]

I went frome VC++6 to VC++2005, not had any major problems.

I did like the 'simplicity' of VC6 and resisted upgrading until VC++ 2005 and my old compiler started to show it's age (couldn't get updates for it etc).

The manifest/CLR thing appears more convoluted, but aside from that it's pretty much the same after tweaking, and it's not that slow on my system. The newer compiler was also supposed to produce faster .exe's if I recall but I never got around to A/Bing them so don't quote me.

[Jack Norton]

I never upgraded from VC6. With visual assist installed, has nothing missing. The IDE loads fast and doesn't require 1Gb of RAM of core duo just to open a window (ok I'm exaggerating but wtf, the new version are SO SLOOOOOW).
Also break/edit/continue was never working for me on the new version and I use that option more often than compile :rolleyes:

[Indiepath]

I never upgraded from VC6. With visual assist installed, has nothing missing. The IDE loads fast and doesn't require 1Gb of RAM of core duo just to open a window (ok I'm exaggerating but wtf, the new version are SO SLOOOOOW).
Also break/edit/continue was never working for me on the new version and I use that option more often than compile :rolleyes:Hmmn, so you regret the upgrade?

[Jack Norton]

I didn't try the VC8, but the VC Express - so maybe is different, but honestly don't think by much...

[vjvj]

VC8 and Express are pretty similar from my experience.

[Cygon]

I've been using VC++ 2005 Express for quite some time now and am very happy with it. Granted, the MSVC6 IDE was way more responsive, but its compiler was so hopelessly outdated that it became really troublesome getting libraries like Boost or LuaBind to work.

If you statically link the C runtime, you will only have problems if you're using DLLs. Specifically, each DLL will have its own copy of the C runtime and thus, have its own heap. So if you allocate memory in a .dll and try to free it in the .exe, it will fail (and display that ugly assertion message in debug mode).

On another note, there are two versions of the VC++ 2005 runtime actually:
8.0.50727.42 from VC++ 2005 and 8.0.50727.762 from VC++ 2005 SP1. The newer SP1 runtime seems to be missing on most systems.

-Markus-

[AlexN]

On another note, there are two versions of the VC++ 2005 runtime actually:
8.0.50727.42 from VC++ 2005 and 8.0.50727.762 from VC++ 2005 SP1. The newer SP1 runtime seems to be missing on most systems.




Oh yeah, I almost forgot this, the 8.0.50727.762 runtime is in the redist folder though, so if you put that next to the executable file, it should run.

[lennard]

I switched to 2005 last year because I needed a library that comes with the new compiler. I finished Real E$tate Empire and then switched back for my current project - very happy, far more productive. Can't believe how screwed up the new IDE is. Brief is unusable (huge for me), the help system is horrible and recompile on the fly is mostly broken. Unbelievable that this was released.

The library I needed was for finding the user data directory under Vista - I'm now using this code (cobbled together from stuff I found on the internet) - feel free to use it, let me know if you find problems:




#include <stdio.h>
#include <stdlib.h>

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <windowsx.h>
#include <winuser.h>
#include <commdlg.h>
#include <sys/types.h>
#include <sys/stat.h>

#include "userDir.h"

typedef HMODULE (__stdcall *SHGETFOLDERPATH)(HWND, int, HANDLE, DWORD, LPTSTR);
#define CSIDL_PROGRAM_FILES 38
#define CSIDL_PERSONAL 0x0005 // My Documents
#define CSIDL_FLAG_CREATE 0x8000 // new for Win2K, or this in to force creation of folder

char szPath[MAX_PATH];

char *getUserDir()
{
if( !szPath[0] )
{
HMODULE hModule = LoadLibrary("SHFOLDER.DLL");
if (hModule != NULL)
{
SHGETFOLDERPATH fnShGetFolderPath = (SHGETFOLDERPATH)GetProcAddress(hModule, "SHGetFolderPathA");

if (fnShGetFolderPath != NULL)
{
fnShGetFolderPath( NULL,
CSIDL_PERSONAL|CSIDL_FLAG_CREATE,
NULL,
0,
szPath
);
}
FreeLibrary(hModule);
}
}

if( szPath[0] )
return szPath;
else return "c:\\";
}

[Indiepath]

Hmmn, Vista is another kettle of fish VS6 or whatever. On another note does anyone know how I can run my shell extension (context menu item) with elevated privaliges (vista).

[GolfHacker]

Flashy and new isn't always better. I'm a firm believer in the old adage, "If it ain't broke, don't fix it". I've been using VS 2003 for four years, and it works fine for me. My games use C/C++ with Win32/DirectX or SDL/OpenGL. The IDE still works, the debugger still debugs, the compiler still compiles, and my executables still run fine, even on Vista. I see no reason to upgrade.

Indiepath, if you're happy with VS6, I say don't waste your money. Stick with something you're comfortable with that's already paid for.

[Jack Norton]

For me VC6 + Visual Assist X beats any other compiler I've tried... ultra fast and with all the tooltip / code completion / browse info that you can find on the new version (but still very fast compared to them).

[vjvj]

Funny how opinions vary so greatly on this subject.

I loved VC 6.0 but had to ditch it to support DX8 for Meridian. I hated 2003, but (as stated above) upgraded to 2005 and like it quite a bit.

[tolik]

Using latest version of VS makes your game run faster, sometimes increase was 5-15%, we had a lot of benchmarking done on PC casual side and confirmed it. Newer compilers might compile slower, but that's the price for optimization.

[StormcloudCreations]

I'm considering shifting to VB 2005 (express edition) thinking it may offer me some speed gains over VB6, especially with graphics, automation and such.

I finished this project:
http://matrixgames.com/games/game.asp?gid=347

and have had complaints about the slowness of interface responsiveness, especially on the main Combat screen, etc, and the fact that supporting multiple screen resolutions is a real pain. Demo is available for those that want to offer advice.

Will VB 2005 address a lot of this kinda thing (interface speed, multiple resolution/form support), or would it be a waste of time?

[Cygon]

If you used the standard drawing routines of VB6 (versus Win32 api calls), you will probably have a drastical speed up with VB.NET 2005.

On the other hand, you might conclude the Microsoft literally threw VB6 away and reinvented VB.NET which shares not much more than the language's keywords. Might as well switch von VB6 to C# -- it's the same learning curve I'd say.

-Markus-

[Thorbrian]

You also can't properly statically link against them or just include them in the local dir - doesn't work and bad idea respectively. I should say that yes, you can statically link the MSVCRT stuff, but that screws up a lot of other stuff - like game engines.I assume the comment above is about the c run time (MSCVR80.dll) - If so, I haven't found that to be true at all.

We ship games that statically link to the runtime, and it's perfectly fine because we build all of our dependencies/libraries to do the same (which I think is the only sane way to do things - problems of c-runtime mismatches can and do happen with an all Visual C++ 6.0 system with the whole single vs. multithreaded and the whole static vs. dynamic linking things)

For home projects, I ship a C-runtime dll with my game all the time, there are no ill effects at all - but that's only true for the same reason as above - I make sure all components I ship link to the same c-runtime.

Basically, I think my advice for someone switching from VC 6.0 to anything newer is build all your libraries/dependencies with the same runtime linkage as your app, and either statically link the runtime or ship the runtime. If you do that, you avoid the risks of crash bugs and memory trouble or people not being able to run your game.

[vjvj]

I assume the comment above is about the c run time (MSCVR80.dll) - If so, I haven't found that to be true at all.

We ship games that statically link to the runtime, and it's perfectly fine because we build all of our dependencies/libraries to do the same (which I think is the only sane way to do things - problems of c-runtime mismatches can and do happen with an all Visual C++ 6.0 system with the whole single vs. multithreaded and the whole static vs. dynamic linking things)

For home projects, I ship a C-runtime dll with my game all the time, there are no ill effects at all - but that's only true for the same reason as above - I make sure all components I ship link to the same c-runtime.

Basically, I think my advice for someone switching from VC 6.0 to anything newer is build all your libraries/dependencies with the same runtime linkage as your app, and either statically link the runtime or ship the runtime. If you do that, you avoid the risks of crash bugs and memory trouble or people not being able to run your game.

As mentioned above, this is exactly what I do as well and I'm not sure why anyone would do anything differently. That's not meant to be offensive, either; I'm really curious what benefits there are to dynamic linking the C runtime other than shaving a MB or two from your exe size (which really only affects patch downloads anyway, since initial install still needs to include the dll).

The only argument I've seen is that it allows you to incorporate fixes from any updated runtimes... But if your app is tested against a specific runtime, why would you not want to freeze against that version?

[Cygon]

[...]

The only argument I've seen is that it allows you to incorporate fixes from any updated runtimes... But if your app is tested against a specific runtime, why would you not want to freeze against that version?

This has changed since VC++ 6.0. VC++ 8.0 will always loads the same version of the runtime, even when a newer runtime has been installed. That's possible because Windows XP and later allow side-by-side installation of different versions of the runtime. These are stored in C:\Windows\WinSxS (SxS: "side-by-side").

So the only reason to use the dynamically linked runtime remains the case where your project has at least one DLL and you want to allocate memory in one place and free it in the other.

-Markus-