Visual Studio issues

Quote:

I feel so upset that MS seems to be screwing everything over with the release of VS2005 and their "new" standard (which is not a standard, that word does not have any meaning since way back).

What "new" standard? New default project settings? That's hardly a particularly malicious decision.

Without knowing more about your application its difficult to offer any suggestions. Presumably your friend does not have developer tools installed and can't debug your application for you. Perhaps you should compile (with 2005) a version of your application that spews some information to a log file at key initialization / main loop points and have your friend run that build; try to isolate where the application is getting stuck.

The threading type switch in the DLL suggests, perhaps, that the incorrect DLL is being used on his machine or perhaps that something in your code is causing some kind of thread deadlock somehow; but that's purely a hunch.

Well, I dunno what to mention about the application. It is your average application, nothing ultra fancy. I have hardly made any changes to the VS settings.

Its just so funny that it works flawlessly for me but not for anyone else... (that does not have visual studio installed).

This basically means that we'll be seeing everyone offering Visual Studio with their games in the future... hahahahaha!

Try static linking with the runtime libs and see if it works for your friend. If it's set to multi-threaded dll then you have to give him msvcr80.dll and possibly another one. That's why I always do plain multi-threaded, to static link so you don't have to give dlls with the app. This issue has nothing to do with MS or MSVC, you can easily have the same problem on any platform, if for example a developer compiles with gcc with runtime libs that the users may not have. It would be nice if MS distributed the dlls in windows update or something but it's hardly that big of a deal to work around it. Everyone has the dependency dll for single threaded builds for 2003, which is likely why that build worked for him.

Typically windows complains about not being able to find the runtime dll though and wont even start the app, so this may not be the problem. I distribute the windows version of my bot(built with 2005) to hundreds of users and have yet to see this any problem, but I use multithreaded(not multithreaded dll). Have you sent it to more than 1 friend?

Two friends. One could run it and the other one got an error at startup (which I read was due to a missing msvc-yadda-yadda-8 DLL file.

Anyways.. I have now decided to give back Visual Studio 2005 to where it came from and stick to 2003, as all of the good stuff works there. It does not matter any longer what I do with the application, it still uses up quite a lot of resources when running. On my friend's computer and on my laptop, it runs at 100%, but on this computer I am using now, it runs at half that (around 48-50%), which so damn strange.

I tell ya... everytime I learn something new about programming, something fundamental fails, either due to it having been changed for some odd ass reason (hence why VS2005 can go kiss my ***), or due to that "random chance of a project becoming tainted by MS' random tainter.. then the project is doomed because it will fail, no matter what.. even if you move all the code files to another computer with another compiler, it will still fail.

Its a proven fact around my part of the world, and that is why I am reluctant before every new project I am going to start... I can do the same thing over and over, and once every 5th time it will simply not run for some damn odd reason, and still I use the same tools, the same code structure and everything.

So... how can I break this thing?

Quote:

Original post by Eldritch On my friend's computer and on my laptop, it runs at 100%, but on this computer I am using now, it runs at half that (around 48-50%), which so damn strange.

Is it possible that your current computer has HyperThreading and the others do not? That would account for the 100% vs 50% CPU utilization.

Quote:

So... how can I break this thing?

Learn what is actually going on, instead of what you think is going on, and use that knowledge to craft a proper solution instead of running away from the problem, blaming somebody else, and hoping it will magically work out for you next time.

This means that if something doesn't work properly or the way you expect, you figure out why through any number of means. You don't jump to conclusions, blame the tools, or blame Microsoft. These are not "cool" things to do, they don't help you solve the problem or learn anything. They simply make you look naive.

In this case, you said that one of your friends got a "missing DLL" error. This means the DLL your application requires isn't available. As others have said, electing to use the "Multi-Threaded" not "Multi-Threaded DLL" should fix this problem as it will perform a static link.

If, in general, you "fix" a problem by ignoring it (reverting to old tools at the first sign of weirdness) or starting over, you are not fixing anything because you didn't learn the true cause of failure -- which means you'll probably just make the same mistake again, later.

Quote:

I tell ya... everytime I learn something new about programming, something fundamental fails, either due to it having been changed for some odd ass reason (hence why VS2005 can go kiss my ***), or due to that "random chance of a project becoming tainted by MS' random tainter.. then the project is doomed because it will fail, no matter what.. even if you move all the code files to another computer with another compiler, it will still fail.

It is the nature of software upgrades to change things. If there was no change, there would be no upgrade. Some of the things that change may be things -- like default settings -- that you would prefer not to change. That's not always possible. Change is neccessary to advance the state of the art; if you leave sub-standard designs / options / APIs around just because you don't want to change things, your product will suffer in the long run. This is no doubt why the VS team elected to change aspects of the project file format and default options for VS2005; they probably overheard too many horror stories about backwards-compatibility hacks from the Win32 API folks at the MS cafeteria.