compiler versions?

I spent a few hours yesterday trying to compile MUSHClient 4.50 with MS Visual C++ 2008. After tracking down a few obscure compiler options that prevented it from linking with MFC, I finally got the project built but then it segfaulted immediately on execution with a corrupted stack so I couldn't even step into it to see what was going on.

Discouraged by this, I dug out a *very* old copy of Visual Studio 6.0 (dating from 1998!) and, despite Vista telling me that I really, really don't want to run this program, it compiled, linked and executed the project perfectly without needing a single modification.

So I was wondering, to Nick and whomever else is compiling the source, which versions of MSVC and MFC you are using? And any special build environment configuration you have? Oh, and Nick, mushclient_resources/res/nick.bmp -- is that really what you look like? :)

Nick uses VC6, which is, as you discovered, why MUSHclient compiles under it without a hitch. I use Visual Studio 2005, and I recently helped make some fixes to allow it to easily compile under it as well. I haven't tested with VS2008, largely because I don't have a non-express version of it, but you should be using the .sln/.vjproj files regardless.

I don't have any other special configuration. Just make sure you follow the instructions on Nick's GitHub wiki page, such as getting the DirectX SDK and perhaps the Platform SDK as well.

It would probably also help if you posted the errors and described the issues you had at the very beginning, so we can try to ease VS2008 compilation in the future.

I started with your .sln/.vcproj files and imported them into VS2008. It made a few seemingly minor modifications to the project file while importing, related to Vista user account control if I remember correctly.

The first change I had to make was the "Use MFC in shared DLL" because I don't have static MFC libs for VS2008. I suppose that could be the cause of the explosion later on, although ideally the app shouldn't care if MFC is statically linked or not. The next change I had to make was adding _CRT_SECURE_NO_WARNINGS to the preproc defs, otherwise you get about a billion deprecation warnings that obscure everything else. That allowed everything to compile, albeit with 490 warnings - mostly cast warnings and signed/unsigned comparisons. But then there were about a dozen unresolved externals in the link. Most of these were fixed by setting "treat wchar_t as builtin type" to false in the language settings - apparently VS2008 defaults to recognizing wchar_t as a distinct type from unsigned short. A few more link errors were fixed by adding _USE_32BIT_TIME_T to the preproc defs. That finally left two unresolved externals, xMonitorFromRect and xGetMonitorInfo, that are declared in multimon.h but are not defined anywhere in my VS2008 environment. (maybe they are defined in the static MFC libs?) Anyway, I added a #define COMPILE_MULTIMON_STUBS to winplace.cpp right before it includes multimon.h and that got the functions defined and then everything linked up fine.

I guess it's no surprise with all that monkeying that the app crashes on launch. The stack trace is completely fubar'd so you can't tell what's going on. I tried to compile a debug version to step through it, but that started a whole new raft of compile and link errors so I finally gave up and went to VS6. Now that I know that VS6 is what Nick uses, I guess I will just stick to that and endure Vista asking me "are you _sure_ you want to run this program?" every time.

Possibly, though I'm curious why you "had" to use MFC as a shared DLL.


Yeah, really. I cleaned up the level 1 warnings (at least under VS2005), but after that you get a kajillion typecast warnings.


That doesn't sound right. My project has that set to true.


You should be able to replace #include "multimon.h" with #include <windows.h>, I also dealt with this a while back.


It's probably the configuration changes and preprocessor definitions you added, did you add them to both configurations or just the active one?

I had a thought on using VS2008: the VS6 installation comes with the MFC4.2 source, maybe it would be possible to compile that with VS2008 to make static link libs to use with muschclient? Hmmm, sounds like a lot of work.

It could very well work. See if you can find the MFC paths in VC6, and add them to VS2008. You might not even have to compile MFC yourself if you can find where VC6 keeps its MFC lib.

because I don't have MFC static link libs with VS2008, just the import libs for the MFC dlls.



maybe the MFC libs you have with VS2005 are built using wchar_t as its own type?



i made all the changes to both the Debug and Release builds, but the debug build still had a bunch of errors.

Ah, right.

that would be easy enough, they are at VS98/MFC/Lib,Include. i might try that, although now that i have a working dev chain with VS6 my motivation is pretty low.

edit: unless Nick plans on upgrading from VS6 at some point in the future.

I doubt it. He said this, when I asked the same thing:

I suppose one day I will have to spend hundreds of dollars, and fill up my disk with gigabytes of "useful utilities" as defined by Microsoft, to produce the exact same end result I get today by spending nothing, but not this week, thanks.

BTW I tried to compile under g++ to see what would happen. Well what happened was thousands of errors and warnings due to:

• Non-standard data types (eg. __int64 instead of "long long").
  
• #pragma directives that are not standard
  
• Inline assembler which would have to be reworked for g++

And that was just their own include files! It hadn't even got to my code yet.

20 years ago, yes. ;)

Update on compiling with VS2008: I finally got it to work by first building a static lib from the MFC42 source tree in the VS6 distribution. This was a non-trivial task requiring significant modification to the MFC and ATL source, but the entire project will now compile, link and execute with no errors or warnings. By the way, this is the 'free' VS Express that I'm using, so Nick if you ever wanted to upgrade you wouldn't have to spend hundreds of dollars (just hundreds of megabytes of disk space).

I would think you'd make changes to the MUSHclient source, not overhaul the old MFC library...

The changes to the MFC and ATL source were necessary to compile MFC itself with VS2008. Compiling mushclient with VS2008 and then linking it against the MFC lib from VS6 results in an app that crashes immediately. The mushclient source itself compiles just fine with VS2008 (after setting a few options to stop a raft of warnings)... Nick must follow a better coding style than the MS engineers.

This "non-trivial" task probably involved fixing up a lot of the old #pragma and other directives I alluded to earlier.

I didn't know they distributed the old MFC source - is that part of the free download?

No, I had the MFC6 source from my old copy of Visual Studio 6. If you buy the full edition of VS2008 you will get MFC9, which would very likely require some amount of modification to mushclient in order to work correctly, in addition to costing a lot of money.

I didn't have to make any changes to the #pragma's, apparently they are all upwards-compatible. The majority of changes were related to MS's interpretation of the C++ standard, which hasn't been upwards-compatible. In particular, MSVC now requires the typename keyword when defining template types, and the scope of a variable declared inside of a for() statement is now limited to the statement's execution block. And also a few random compile errors that were never caught by MSVC6. If you ever need to get a hold of these changes I can send you the diffs.