MS Visual C++ 6.0 project dependency problem

If your game project produces an exe, I don't think adding it as a dependency will link the code like a library. Your best bet is to separate all shared code into another static library project, and then have both the game and tool projects use that. Make sure the game's WinMain function is not part of that shared code.

You realize VC6 is a decade old, obsolete, and a terrible C++ compiler, right?

I hope you didn't pay too much for it. I didn't even think anyone sold it anymore.

VC2008 is available, and is light years better. And it's free.

And nobody uses MFC anymore either. You sure like abysmal tech ;)

Quote:

Original post by RDragon1 You sure like abysmal tech ;)

Awww. I was going to say that after he made his changes :)

I fully expected to get grilled on this thread :)

I don't suppose I have the luck that a grizzled veteran would come along and read it. As a postmortem, I found an include path option independent of specific projects that worked for what I wanted.

On a lighter note, I've had my copy that long and it serves me fine for as infrequently as I have had to use it. And be fair now, there are still installed code bases in the wild running on MFC.. those bases are probably also running on a PII with Windows 98. Poor users :) As it happens I may have to work in one such base at my next job. Legacy coders can make serious bank slogging mud all day! I knew a guy that easily made middle six figures for a few months maintaining a COBOL base, knowing full well after he was done they were going to kick him. But hell, why not tuck away the extra trimmings after paying your monthlies into some nice investments? :)

Yes, VC++ 6.0 might be used for legacy purposes as you say. However, be aware that VC++ 6.0 was released before the C++ standard, and as such it does not follow the C++ standard (which is why using it is discouraged here). So if you want to write modern C++ code, make sure to upgrade to something more recent, or you will run into problems.

I think youre all making too much mess about VC6. I still use it at home for all of my home game projects and it works just fine. Yeah, its not exactly standard-compliant but does the end user care ? Hardly.

However, youre wrong about VS2008 being free. Its not if you need to maintain your MFC dialogs, which you need to pay for in Standard version.

How is it free if I am to completely redesign/rewrite all UI stuff for my editor ? That time can be hardly declared as free, since its going to cost me lots of other features I might have developed in that time.

Check this article containing info on historical debugging feature:
http://channel9.msdn.com/posts/VisualStudio/Historical-Debugger-and-Test-Impact-Analysis-in-Visual-Studio-Team-System-2010/#Page=1

I jumped in joy when reading about this killer feature (which I prayed for 10 yrs ago) until I discovered that regular C++ isnt suported.

So, I guess Ill stay with VC6 for another decade, as a family man therere lots of other things I have to shell out for, instead of just a shiny new interface ...

My gut reaction to the thread title is "yes, having to depend on MS Visual C++ 6.0 is a problem".

Quote:

Original post by joe1024 I think youre all making too much mess about VC6. I still use it at home for all of my home game projects and it works just fine.

For programming in the language you've learned, sure. For programming in C++, it most assuredly does not.

Quote:

Yeah, its not exactly standard-compliant but does the end user care ? Hardly.

If he wants things to behave the way the language standard guarantees, and have access to the modern standard library, and compile recently written code that assumes everything is as it ought to be, he damn well cares.

Quote:

However, youre wrong about VS2008 being free. Its not if you need to maintain your MFC dialogs, which you need to pay for in Standard version.

MFC? You're kidding me?

Quote:

How is it free if I am to completely redesign/rewrite all UI stuff for my editor? That time can be hardly declared as free, since its going to cost me lots of other features I might have developed in that time.

OMG, code doesn't last forever. Imagine that! You might instead take the opportunity to fix issues with the existing code while bringing it in line with modern standards. You might find that the result is much shorter and more expressive, and you might improve your skills.

Quote:

Check this article containing info on historical debugging feature: http://channel9.msdn.com/posts/VisualStudio/Historical-Debugger-and-Test-Impact-Analysis-in-Visual-Studio-Team-System-2010/#Page=1 I jumped in joy when reading about this killer feature (which I prayed for 10 yrs ago) until I discovered that regular C++ isnt suported.

So because a feature in the planned next release of the software isn't going to work as perfectly as you'd hope, you're going to stick with a several-versions-older release? Seriously, this is analogous to deciding to stick with Windows 98 because you heard bad things about an upcoming service pack for Vista. Just thought I'd throw Windows 98 in there to remind you of what kind of time scales we're talking about here. Ten years is an eternity in computing.

Quote:

So, I guess Ill stay with VC6 for another decade, as a family man therere lots of other things I have to shell out for, instead of just a shiny new interface ...

Let me ask, with this attitude, why did you bother migrating from C to C++ in the first place? Or from assembly for that matter?

Quote:

Original post by Zahlman For programming in the language you've learned, sure. For programming in C++, it most assuredly does not.

Yeah, the standard was acknowledged after VC6 came out, so there are few glitches here and there (e.g. templates and other smaller issues).

Quote:

Original post by Zahlman If he wants things to behave the way the language standard guarantees, and have access to the modern standard library, and compile recently written code that assumes everything is as it ought to be, he damn well cares.

Oh, sorry - I meant users of the end application. Im the only user of the engine.

Quote:

Original post by Zahlman MFC? You're kidding me?

No, I still have my interface for my editor coded in MFC/WinAPI. How long would it take to completely exchange all UI-realted stuff from MFC into something more current ? Would there be some advantage, except maybe less maintanance for the new API/method ?

Quote:

Original post by Zahlman OMG, code doesn't last forever. Imagine that! You might instead take the opportunity to fix issues with the existing code while bringing it in line with modern standards. You might find that the result is much shorter and more expressive, and you might improve your skills.

I understand your point. Youre right. Except that it would waste all my previous years of effort. Id have to rewrite whole engine from scratch if I were to port it to C#. Thats a lot of work and it would cost you maybe a year of your life, plus lots of features that would be done, if you didnt start the rewrite.

Quote:

Original post by Zahlman So because a feature in the planned next release of the software isn't going to work as perfectly as you'd hope, you're going to stick with a several-versions-older release? Seriously, this is analogous to deciding to stick with Windows 98 because you heard bad things about an upcoming service pack for Vista. Just thought I'd throw Windows 98 in there to remind you of what kind of time scales we're talking about here. Ten years is an eternity in computing.

Well, Im still waiting for the feature which is worth paying for. And this "Undo debugging" feature looked extremely promising ! However, regular C++ is an ancient language for MS (just like Cobol), so I dont see a point of buying a SW because of the feature which I cant use unless Im programming in a specific langauge. But I cant port all of my work to C# now. How long will that take and what would be the benefit ? Still, with the current rate of advances, it might well happen that by the time Im done with porting (actually rewriting), C# will be declared as obsolete, effectively loosing maybe 1 year of my life. MS is known for burning bridges whenever they see it appropriate.
I know that it now seems extremely improbable, but would you guess 10 yrs ago how wil C# spread ? Exactly, you couldnt at that time, and thats my point.
So, I might just as well stay with C++/DirectX and loose nothing.

Quote:

Original post by Zahlman Let me ask, with this attitude, why did you bother migrating from C to C++ in the first place? Or from assembly for that matter?

I jumped straight from assembler to Pascal/Delphi, then directly to C++. I had to make the switch, because that was the only viable choice at that time. Plus, it doesnt hurt to learn new language.


I almost made the switch to C#/XNA, in which case I would have to use the VS2k8. But since MS is so picky as to whose EXE file doesn`t smell rotten, I have to stay back. The longer and more you code in one language/API, the tougher it will be in future to just scrap all your work and start anew.