Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Development ➜ compiler versions?

compiler versions?

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1 2  

Posted by Hokken   USA  (18 posts)  Bio
Date Sun 28 Feb 2010 06:21 PM (UTC)
Message
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? :)
Top

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #1 on Sun 28 Feb 2010 06:33 PM (UTC)
Message
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.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top

Posted by Hokken   USA  (18 posts)  Bio
Date Reply #2 on Sun 28 Feb 2010 07:59 PM (UTC)
Message
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.
Top

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #3 on Sun 28 Feb 2010 08:07 PM (UTC)

Amended on Sun 28 Feb 2010 08:08 PM (UTC) by Twisol

Message
Hokken said:
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.


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

Hokken said:
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.

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

Hokken said:
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.

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

Hokken said:
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.

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

Hokken said:
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.

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

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top

Posted by Hokken   USA  (18 posts)  Bio
Date Reply #4 on Sun 28 Feb 2010 08:10 PM (UTC)
Message
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.
Top

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #5 on Sun 28 Feb 2010 08:13 PM (UTC)
Message
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.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top

Posted by Hokken   USA  (18 posts)  Bio
Date Reply #6 on Sun 28 Feb 2010 08:17 PM (UTC)
Message
Twisol said:

Hokken said:
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.


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


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

Twisol said:

Hokken said:
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.

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


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

Twisol said:

Hokken said:
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.

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


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

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #7 on Sun 28 Feb 2010 08:19 PM (UTC)
Message
Hokken said:
because I don't have MFC static link libs with VS2008, just the import libs for the MFC dlls.


Ah, right.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top

Posted by Hokken   USA  (18 posts)  Bio
Date Reply #8 on Sun 28 Feb 2010 08:21 PM (UTC)

Amended on Sun 28 Feb 2010 08:23 PM (UTC) by Hokken

Message
Twisol said:

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.


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.
Top

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #9 on Sun 28 Feb 2010 08:29 PM (UTC)
Message
I doubt it. He said this, when I asked the same thing:

Nick Gammon said:
As for why, I have tried to get off the Microsoft treadmill of buying the latest, greatest product, and then in 5 years having to buy a completely new one that I have to learn, and discard most of what I learnt in the previous 5 years (for example, XP and Vista).

This one works, it is cheap to not upgrade, what is the problem?

I think a while ago someone reported minor issues with compiling under .net, so I changed a few spots to make it compile under that, but still also compile for me. I don't mind doing that again, if you have some minor syntax issues, that I can change and be compatible for both me, and future versions.

After all, C++ is a standard, it shouldn't be too hard to keep it compatible.

The issue of the dll is interesting. It is possible that if I upgraded my own compiler, this might make MUSHclient incompatible with people who are using older systems. This is one reason to not change. I can see for myself that the current releases work under 98/2000/XP/Vista, so that is a pretty good compatibility.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top

Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #10 on Sun 28 Feb 2010 09:30 PM (UTC)
Message
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #11 on Tue 02 Mar 2010 06:11 AM (UTC)
Message
Hokken said:

Oh, and Nick, mushclient_resources/res/nick.bmp -- is that really what you look like? :)


20 years ago, yes. ;)

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Hokken   USA  (18 posts)  Bio
Date Reply #12 on Tue 02 Mar 2010 11:19 PM (UTC)
Message
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).
Top

Posted by Larkin   (278 posts)  Bio
Date Reply #13 on Wed 03 Mar 2010 12:37 PM (UTC)
Message
I would think you'd make changes to the MUSHclient source, not overhaul the old MFC library...
Top

Posted by Hokken   USA  (18 posts)  Bio
Date Reply #14 on Wed 03 Mar 2010 05:18 PM (UTC)
Message
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.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


47,699 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.