What requirements does mushclient to compile from source. I have visual studio 6, does it require anything other than that?
Compiling mushclient from source.
Posted by Robert Powell on Tue 21 Jul 2009 10:45 AM — 53 posts, 215,574 views.
I use Visual Studio 6 with their service pack supplied, from memory.
You may possible need to grab lua.h and a couple of files from the Lua distribution.
How about trying, and if you have any problems, report what they are?
You may possible need to grab lua.h and a couple of files from the Lua distribution.
How about trying, and if you have any problems, report what they are?
What was the workspace made with, because i cannot open it with visual studio 6 sp6?
Are you talking about the file MUSHclient.dsw? I open that with Visual Studio 6. It's not exactly lengthy:
Do you get an error message, and if so what is it?
Microsoft Developer Studio Workspace File, Format Version 6.00
# WARNING: DO NOT EDIT OR DELETE THIS WORKSPACE FILE!
###############################################################################
Project: "MUSHclient"=.\MUSHclient.dsp - Package Owner=<4>
Package=<5>
{{{
}}}
Package=<4>
{{{
}}}
###############################################################################
Global:
Package=<5>
{{{
}}}
Package=<3>
{{{
}}}
###############################################################################
Do you get an error message, and if so what is it?
Sorry for not being clear, i cannot seem to open the project file within developer studio, it complains about it not being made with it, specifically when i open the project file it says: This makefile was not created in developer studio, and then it tries to make a new project, opening the workspace does not seem to do anything either, im not sure if this is a vista problem or end user error or i have something missing that's needed.
Thanks Nick
Thanks Nick
Are you using Visual Studio to open the file MUSHclient.dsw using the File menu -> Open Workspace? And if you open that file with another editor (eg. Crimson Editor) does it look like what I pasted below?
I am specifically using Microsoft Visual C++ 6.0
Yeah, using File -> Open Workspace and nothing happens, opening the .dsw in another editor, it looks identical to the one you have posted above.
Well to test this all out I installed Visual Studio 6 from my 1999 CDROM, onto a PC running Vista Home edition. This PC has never had Visual Studio on it, nor been used to compile MUSHclient.
The first thing to say is, that even without patching Visual Studio from what was on the CD, once installed, and once I unzipped mushclient_4.40_src.tgz with WinZip and opened the mushclient.dsw file, it opened up OK in Visual Studio, showing all the files etc. that are in the project.
However I am hitting a number of issues that stop a successful compile - these tend to happen as new files are added to the project but are not added into the CVS repository. Thus they are not extracted when I make a source distribution.
I am documenting these right now, and will post again soon. However my point is you should be able to get the project open.
The first thing to say is, that even without patching Visual Studio from what was on the CD, once installed, and once I unzipped mushclient_4.40_src.tgz with WinZip and opened the mushclient.dsw file, it opened up OK in Visual Studio, showing all the files etc. that are in the project.
However I am hitting a number of issues that stop a successful compile - these tend to happen as new files are added to the project but are not added into the CVS repository. Thus they are not extracted when I make a source distribution.
I am documenting these right now, and will post again soon. However my point is you should be able to get the project open.
OK, what I needed to do to compile and run was the following:
- Install Visual Studio 6.0 from CD
- Download http://www.gammon.com.au/files/mushclient/src/mushclient_4.40_src.tgz
- Unzip that file with WinZip - I placed it into a directory I made called "source" in my "Documents" folder under Vista (in other words, the source should end up in a directory "mushclient" under the "source" directory. The archive mushclient_4.40_src.tgz already has that directory in it, so you don't need to create another one.
- Download http://www.gammon.com.au/files/mushclient/src/zlib.zip
- Make another directory inside the "source" directory mentioned above, called "zlib"
- Unzip the file zlib.zip into the zlib directory (the archive zlib.zip does *not* have a zlib directory in it, you must create that yourself)
- Download http://www.gammon.com.au/files/mushclient/src/mushclient4.40_src_extras.zip and open it with WinZip. Then drag files out of it as per below:
- The file mushclient4.40_src_extras.zip has some files missing from the mushclient_4.40_src.tgz archive - namely:
- cursor1.cur file
- sqlite3.h file
- sqlite3.c file
- lua5.1.lib file
The file cursor1.cur should be placed in the "res" subdirectory of the mushclient source directory. The others should be placed directly into the mushclient source directory.
- You should now be able to compile it successfully.
- In order to *run* it you need a couple of other files which are part of the normal MUSHclient distribution.
- First, grab a copy of lua5.1.dll from your normal MUSHclient installation. Put that into the same directory as where mushclient.exe ended up (that will be WinRel or WinDebug under the mushclient source).
- Second, grab a copy of the "locale" directory (and everything in it), and put that in the same place, otherwise it won't find its resources.
- Now you should be able to test.
I still cannot get the workspace in 4.40 to open, nor in 4.37 and 4.20, however, 4.19 i can get to open no problems, it would seem that the pkzip versions of the source are all working fine but the gnuzip ones are doing something funky that VS does not like?
It is probably line-endings. Try grabbing WinZip - after all, that worked for me.
Failing that, I had some utilities that fix up line endings. Try running unix2dos on the .dsw file at least, and possibly also the .cpp and .h files.
http://www.gammon.com.au/downloads/dlutilities.htm
Failing that, I had some utilities that fix up line endings. Try running unix2dos on the .dsw file at least, and possibly also the .cpp and .h files.
http://www.gammon.com.au/downloads/dlutilities.htm
Yeah, that's exactly what the problem was, for some reason the files all had unix line ends, i dont think i have ever had that trouble before, i was using winrar, which has never given be a problem with these things.
Thanks for all the help Nick, i now have something to amuse myself with on the train to the city each morning.
Thanks for all the help Nick, i now have something to amuse myself with on the train to the city each morning.
This is somewhat related to the main topic, so I don't really want to make a new thread, and it's a pretty simple question.... Can I ask why you use Visual Studio 6? From what I hear, it's very outdated and not standards-conforming. I use VS 2005 at the least, and I'd love to start messing with and compiling the source, but (a) VS2005 can't convert the workspace file to the newer version, and (b) I'm not fond of moving backwards, especially when it apparently doesn't conform to the standard.
If I could get past that initial hurdle, I wouldn't mind trying to help move the codebase forward, either.
EDIT: Well, I realize why you use VS6 - when MUSH was begun that's probably what was in use, right? Then I'd ask why you still use it, but then I realize it probably looks like an incredible time sink to move all of your code forward (considering the lack of standards compatability too). But the rest of the post stands. =/
If I could get past that initial hurdle, I wouldn't mind trying to help move the codebase forward, either.
EDIT: Well, I realize why you use VS6 - when MUSH was begun that's probably what was in use, right? Then I'd ask why you still use it, but then I realize it probably looks like an incredible time sink to move all of your code forward (considering the lack of standards compatability too). But the rest of the post stands. =/
I'm not really much of a C programmer, but I'm pretty sure I can answer that question since I came across that dilemma on a forum somewhere at some point.
MSVC 6 has a bigger amount of backwards compatibility. The specific file would be msvcrt.dll I believe. It's come standard with every version of Windows, even as far back as 95 I think, and it simply works. VC2005 and higher have new versions which need to be installed seperately on systems, and I think they might not even work on older systems. In the end, the newer development environments and compilers have different requirements which clash with the backwards compatability issue - many people still use those older OSes.
(Also, why take a new version if the old one still works fine? :D)
Edit: come to think of it, it is probably another file used in linking. I just realized CRT is in that filename, which doesn't apply to MUSHclient since it isn't a CRT application.
Edit 2: This link has the story I was thinking of, and reading it explains the C++ exception handling stuff that applies to non-CRT apps as well. I guess I was right-ish after all. http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/
MSVC 6 has a bigger amount of backwards compatibility. The specific file would be msvcrt.dll I believe. It's come standard with every version of Windows, even as far back as 95 I think, and it simply works. VC2005 and higher have new versions which need to be installed seperately on systems, and I think they might not even work on older systems. In the end, the newer development environments and compilers have different requirements which clash with the backwards compatability issue - many people still use those older OSes.
(Also, why take a new version if the old one still works fine? :D)
Edit: come to think of it, it is probably another file used in linking. I just realized CRT is in that filename, which doesn't apply to MUSHclient since it isn't a CRT application.
Edit 2: This link has the story I was thinking of, and reading it explains the C++ exception handling stuff that applies to non-CRT apps as well. I guess I was right-ish after all. http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/
Quote:
VS2005 can't convert the workspace file to the newer version ...
VS2005 can't convert the workspace file to the newer version ...
I wouldn't worry about that too much. Basically you could make a new project and just import into it all the .cpp files (and .c files) you can find. If you want to be a bit more controlled about it, edit the mushclient.dsp file, and look through that. It basically just gives you a list, like this:
SOURCE=.\accelerators.cpp
# End Source File
# Begin Source File
SOURCE=.\ActivityDoc.cpp
# End Source File
# Begin Source File
SOURCE=.\ansi.cpp
Then try to compile. ;)
You will probably get a few errors, you just have to sort those out.
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.
The recent issue I raised about Vista problems is more an installer or design issue, not a compiler one.
Hmm, alright, I will try that. Thanks Nick.
I recently read this article though, which is why I'm not such a fan of VS6: http://www.jasonbadams.net/20090119/why-you-shouldnt-use-vc6/
Also, I looked this up, and it seems like less than 0.5% people still use Windows 95: http://www.w3schools.com/browsers/browsers_os.asp
As for "buying the latest thing", there's Express versions of Visual Studio, which while lacking in-built resource editing and perhaps other things I haven't noticed, are perfectly valid for writing programs with. I completely understand the compiler difference though, barring the OS link I posted above.
I recently read this article though, which is why I'm not such a fan of VS6: http://www.jasonbadams.net/20090119/why-you-shouldnt-use-vc6/
Also, I looked this up, and it seems like less than 0.5% people still use Windows 95: http://www.w3schools.com/browsers/browsers_os.asp
As for "buying the latest thing", there's Express versions of Visual Studio, which while lacking in-built resource editing and perhaps other things I haven't noticed, are perfectly valid for writing programs with. I completely understand the compiler difference though, barring the OS link I posted above.
Quote:
I recently read this article though, which is why I'm not such a fan of VS6 ...
I recently read this article though, which is why I'm not such a fan of VS6 ...
They make very valid points, however that doesn't, in this case, impact on the result. Various things about STL don't work correctly, however I avoid those.
Quote:
there's Express versions of Visual Studio
there's Express versions of Visual Studio
I downloaded that, however it doesn't come with MFC, so I can't compile MUSHclient under that. It is an example of Microsoft locking you in with a proprietary product.
Ah, that really stinks. I did some research to see if MFC could be gotten separately, but... nope. =/
I've begun my attempt to compile MUSHclient under VS2005. If nobody minds I'd like to chronicle any obstacles I come across here, or in another thread if Nick doesn't mind.
So far I've got the source downloaded, and I'm working through the heap of warnings/errors. I managed to convert the VS6 project file (I had tried the workspace file unsuccessfully), which gave me a nice start. Unfortunately, I get a lot of errors about files that don't include stdafx.h, so I'm going through and changing the settings for those files (to Do Not Use Precompiled Header).
At first it also complained about not finding the precompiled header, so I had to change it in the project settings to Create it instead of Use it (/Yu to /Yc).
I also had to define LUA51 as a command line option (/D "LUA51") for the correct #include directives to fire.
The zlib headers were missing in the source package, so they had to be downloaded and placed one directory up (in the solution directory rather than the project directory). The DLL is already provided however, so I just needed the includes.
I'll update as I make progress, either here or in another thread as appropriate.
I've begun my attempt to compile MUSHclient under VS2005. If nobody minds I'd like to chronicle any obstacles I come across here, or in another thread if Nick doesn't mind.
So far I've got the source downloaded, and I'm working through the heap of warnings/errors. I managed to convert the VS6 project file (I had tried the workspace file unsuccessfully), which gave me a nice start. Unfortunately, I get a lot of errors about files that don't include stdafx.h, so I'm going through and changing the settings for those files (to Do Not Use Precompiled Header).
At first it also complained about not finding the precompiled header, so I had to change it in the project settings to Create it instead of Use it (/Yu to /Yc).
I also had to define LUA51 as a command line option (/D "LUA51") for the correct #include directives to fire.
The zlib headers were missing in the source package, so they had to be downloaded and placed one directory up (in the solution directory rather than the project directory). The DLL is already provided however, so I just needed the includes.
I'll update as I make progress, either here or in another thread as appropriate.
I've cleared out all the initial errors, including a problem with ucptable.c. It complained both about the 'cnode' type and 'too many initializers'; to solve the latter, I set it to compile that file as C++ instead of C. It seems like ucptable.c is meant to be more of a header, because another file includes it (and I assume that previous headers in that file define 'cnode'), so I set ucptable.c to simply not be built.
Now I have two main errors that have cropped up. One is an error from MUSHclient.h, saying it can't find <codecs.h>. I assume I either don't have the file, or I do and it's just not in my path.
The other error is about a cast a macro seems to make, and I'm not sure how to go about fixing it:
EDIT: Oh, and I just read something earlier, and I wanted to respond to you here:
Apparently, VS6 predates the standard. *shrug*
Now I have two main errors that have cropped up. One is an error from MUSHclient.h, saying it can't find <codecs.h>. I assume I either don't have the file, or I do and it's just not in my path.
The other error is about a cast a macro seems to make, and I'm not sure how to go about fixing it:
statlink.cpp(28) : error C2440: 'static_cast' : cannot convert from 'UINT (__thiscall CStaticLink::* )(CPoint)' to 'LRESULT (__thiscall CWnd::* )(CPoint)'
Cast from base to derived requires dynamic_cast or static_cast
EDIT: Oh, and I just read something earlier, and I wanted to respond to you here:
Quote:
After all, C++ is a standard, it shouldn't be too hard to keep it compatible
After all, C++ is a standard, it shouldn't be too hard to keep it compatible
Apparently, VS6 predates the standard. *shrug*
ucptable.c doesn't seem to be in the project.
The files mentioned in the mushclient.dsp file with a /Yu flag will not be using precompiled headers. Generally speaking these will be the .c files. Also generally speaking these will be "external" stuff (eg. PCRE, SQLite, zLib and so on) because they won't be using the precompiled headers (which themselves are in stdafx.h) with MUSHclient-specific stuff in them.
That looks similar to something on this page:
http://www.gammon.com.au/forum/?id=7755
Not too sure what to suggest as it compiles for me. Maybe change it to:
... and change the function prototype in StatLink.h to:
Let me know if that works.
The files mentioned in the mushclient.dsp file with a /Yu flag will not be using precompiled headers. Generally speaking these will be the .c files. Also generally speaking these will be "external" stuff (eg. PCRE, SQLite, zLib and so on) because they won't be using the precompiled headers (which themselves are in stdafx.h) with MUSHclient-specific stuff in them.
Quote:
The other error is about a cast a macro seems to make, and I'm not sure how to go about fixing it:
The other error is about a cast a macro seems to make, and I'm not sure how to go about fixing it:
That looks similar to something on this page:
http://www.gammon.com.au/forum/?id=7755
Not too sure what to suggest as it compiles for me. Maybe change it to:
LRESULT CStaticLink::CtlColor(CDC* pDC, UINT nCtlColor)
{
ASSERT(nCtlColor == CTLCOLOR_STATIC);
DWORD dwStyle = GetStyle();
HBRUSH hbr = NULL;
if ((dwStyle & 0xFF) <= SS_RIGHT) {
// this is a text control: set up font and colors
if (!(HFONT)m_font) {
// first time init: create font
LOGFONT lf;
GetFont()->GetObject(sizeof(lf), &lf);
lf.lfUnderline = TRUE;
m_font.CreateFontIndirect(&lf);
}
// use underline font and visited/unvisited colors
pDC->SelectObject(&m_font);
pDC->SetTextColor(m_color);
pDC->SetBkMode(TRANSPARENT);
// return hollow brush to preserve parent background color
hbr = (HBRUSH)::GetStockObject(HOLLOW_BRUSH);
}
return (LRESULT) hbr;
}
... and change the function prototype in StatLink.h to:
afx_msg LRESULT CtlColor(CDC* pDC, UINT nCtlColor);
Let me know if that works.
Quote:
Apparently, VS6 predates the standard. *shrug*
Apparently, VS6 predates the standard. *shrug*
I should have known better than to mentally link "Microsoft" and "standard".
Quote:
One is an error from MUSHclient.h, saying it can't find <codecs.h>.
One is an error from MUSHclient.h, saying it can't find <codecs.h>.
I can't find any references to codecs.h in MUSHclient.h.
I have such a file in the \Program Files\Microsoft Visual Studio\VC98\Include directory. Not sure why it is being included. Can you work out which file is requiring it?
On MS standards: *lol*
On codecs.h: Odd, the #include shows up for me on line 18. If I comment it out, I get the same error for dsound.h. If I comment that out, I get lots of errors about dsound-related nonexistent identifiers. Where can I get that codex.h and dsound.h that you have?
On the cast errors: I fixed it by changing OnNcHitTest (NOT CtlColor) to return LRESULT, and casted its return value for the same. Thanks for the pointer though, it set me on the right track.
On codecs.h: Odd, the #include shows up for me on line 18. If I comment it out, I get the same error for dsound.h. If I comment that out, I get lots of errors about dsound-related nonexistent identifiers. Where can I get that codex.h and dsound.h that you have?
On the cast errors: I fixed it by changing OnNcHitTest (NOT CtlColor) to return LRESULT, and casted its return value for the same. Thanks for the pointer though, it set me on the right track.
Looks like I removed #include <codecs.h> from recent versions. Must have been not needed.
As for dsound.h that is also in the \Program Files\Microsoft Visual Studio\VC98\Include directory.
Maybe do some sort of optional install for Direct Sound (or DirectX) headers?
As for dsound.h that is also in the \Program Files\Microsoft Visual Studio\VC98\Include directory.
Maybe do some sort of optional install for Direct Sound (or DirectX) headers?
Hmm, looks like I may need to download the DirectX SDK. I'll grab it and see how that goes.
I installed the DirectX SDK (March 2009) and updated Visual Studio's paths, clearing up that particular issue. I've made lots of progress so far clearing up many errors and warnings (and cataloging all of them).
There's three undeclared identifiers I can't seem to clear up though: IDD_GOATS_BLOOD, IDD_SELECT_GLOBAL_CONFIGURATION, and IDC_NEW. By their names I assume they're resource identifiers, but I can't figure out where they're supposed to be included from. Any pointers?
EDIT: I found some *.hm files in the initial download (id.hm, idd.hm, idc.hm, idf.hm), but Visual Studio has no idea what to do with them. I'll try messing with them and see what I can do with them, though, they seem to contain the resource IDs and their numeric codes.
EDIT 2: As my luck would have it, none of those files have the identifiers I'm missing...
There's three undeclared identifiers I can't seem to clear up though: IDD_GOATS_BLOOD, IDD_SELECT_GLOBAL_CONFIGURATION, and IDC_NEW. By their names I assume they're resource identifiers, but I can't figure out where they're supposed to be included from. Any pointers?
EDIT: I found some *.hm files in the initial download (id.hm, idd.hm, idc.hm, idf.hm), but Visual Studio has no idea what to do with them. I'll try messing with them and see what I can do with them, though, they seem to contain the resource IDs and their numeric codes.
EDIT 2: As my luck would have it, none of those files have the identifiers I'm missing...
The .hm files are for the Help Studio thing. That is a separate process to generate a help file, and isn't relevant to getting a MUSHclient.exe.
The Goats Blood is a reference to how to deal with people trying to sell you cleaning products. You ask them: "but, does it get goat's blood out?".
I gather from your second edit that these missing identifiers are not stopping you compile?
The Goats Blood is a reference to how to deal with people trying to sell you cleaning products. You ask them: "but, does it get goat's blood out?".
I gather from your second edit that these missing identifiers are not stopping you compile?
No, they are stopping the compile, and my "By their names I assume" comment I meant the IDD_* and IDC_* prefixes, which usually stand for resource identifiers. They're undefined though - something's not being included/compiled, but I've searched through everything with no luck.
My second edit referred to my terrible luck. ;) The goats blood thing is funny though :D
My second edit referred to my terrible luck. ;) The goats blood thing is funny though :D
enum { IDD = IDD_GOATS_BLOOD };
That is in EasterEggDlg.h, which is included from EasterEggDlg.cpp.
However EasterEggDlg.cpp isn't in the project. Just remove it (there is a reference to it which is commented out).
I can't find IDD_SELECT_GLOBAL_CONFIGURATION anywhere in my source directory. Where did you find it? Ditto for IDC_NEW.
GlobalConfigurationDlg.h for IDD_SELECT_GLOBAL_CONFIGURATION, and its .cpp for IDD_NEW.
Remove GlobalConfigurationDlg.cpp from the project.
That worked. I just dumped all the source files in the .zip into the project, heh.
Down to 8 errors and 118 warnings so far!
Down to 8 errors and 118 warnings so far!
I'm getting some unresolved external errors from the linker, now . The unresolved identifiers are:
inflateInit
inflate
inflateEnd
inflateReset
deflateInit
deflateInit2_
deflate
deflateEnd
deflateReset
DirectSoundCreate
crc32
xGetMonitorInfo
xMonitorFromRect
CGlobalChangeDlg::CGlobalChangeDlg(class CWnd *)
The first set seem to be macros defined in zconf.h. The second set I can't find anywhere. And the last one I'm not sure about either.
inflateInit
inflate
inflateEnd
inflateReset
deflateInit
deflateInit2_
deflate
deflateEnd
deflateReset
DirectSoundCreate
crc32
xGetMonitorInfo
xMonitorFromRect
CGlobalChangeDlg::CGlobalChangeDlg(class CWnd *)
The first set seem to be macros defined in zconf.h. The second set I can't find anywhere. And the last one I'm not sure about either.
I mentioned zlib.zip on the first page of this thread. From that directory, you need to add the following files into the project (without using precompiled headers):
Add dsound.lib into the libraries used by the project.
Can't find any references to those - what is the module that calls them?
That constructor should be in GlobalChangeDlg.cpp - is that in the project?
- adler32.c
- compress.c
- crc32.c
- deflate.c
- gzio.c
- infblock.c
- infcodes.c
- inffast.c
- inflate.c
- inftrees.c
- infutil.c
- minigzip.c
- trees.c
- uncompr.c
- zutil.c
Quote:
DirectSoundCreate
DirectSoundCreate
Add dsound.lib into the libraries used by the project.
Quote:
xGetMonitorInfo
xMonitorFromRect
xGetMonitorInfo
xMonitorFromRect
Can't find any references to those - what is the module that calls them?
Quote:
CGlobalChangeDlg::CGlobalChangeDlg(class CWnd *)
CGlobalChangeDlg::CGlobalChangeDlg(class CWnd *)
That constructor should be in GlobalChangeDlg.cpp - is that in the project?
Quote:
xGetMonitorInfo
xMonitorFromRect
xGetMonitorInfo
xMonitorFromRect
Try a Google on those two. They seem to be in multimon.h.
The code I saw on the Google search seemed to match what I have here (they are in the MFC files).
GlobalChangeDlg.cpp was somehow left out; including that fixed it.
I added the zlib files and that cleared up the zlib linker errors.
The multimon functions were fixed by replacing #include <MULTIMON.H> in winplace.cpp with #include <windows.h>, the standard (~_^) Windows inclusion header.
Now it compiles and links! When it runs, though, it crashes because it can't find mushclient\debug\locale\EN.dll. :P
I added the zlib files and that cleared up the zlib linker errors.
The multimon functions were fixed by replacing #include <MULTIMON.H> in winplace.cpp with #include <windows.h>, the standard (~_^) Windows inclusion header.
Now it compiles and links! When it runs, though, it crashes because it can't find mushclient\debug\locale\EN.dll. :P
See my steps on page 1 of this thread. I talk about fixing that.
Wow - it works! :D Here's what I did, apart from errors and things you already mentioned, to get it to work:
* Install DirectX SDK (used March 2009 version)
** Add DirectX paths to Visual Studio's directories lists
* Add build options: /D "LUA51" /D "_CRT_SECURE_NO_WARNINGS"
* Add custom build option: /D "_USING_MFC8" -- see error in forcelib.h.
Here's the list of errors I had to change if you want to merge them with the current code.
There's also a whole load of warnings that I'm clearing up, mostly type conversions, but they don't really affect the build.
* Install DirectX SDK (used March 2009 version)
** Add DirectX paths to Visual Studio's directories lists
* Add build options: /D "LUA51" /D "_CRT_SECURE_NO_WARNINGS"
* Add custom build option: /D "_USING_MFC8" -- see error in forcelib.h.
Here's the list of errors I had to change if you want to merge them with the current code.
==configuration.cpp==
-Line 80, missing return value.
Add 'void' to function header.
==Utilities.cpp==
-Line 1202, redefinition of default second parameter (bSigned) in IsStringNumber.
Remove '=false' from the function header
==methods.cpp==
-Line 12054, undeclared identifier DSBCAPS_CTRLDEFAULT.
This flag is no longer supported directly.
Replace with (DSBCAPS_CTRLPAN | DSBCAPS_CTRLVOLUME | DSBCAPS_CTRLFREQUENCY).
==MUSHclient.cpp==
-Linker error with lua5.1.dll
Comment out the #pragma comment(linker, *) directive.
==forcelib.h==
-Linker error with mfc42d.lib
VS2005 uses a newer version of MFC.
Add an #ifdef branch controlled by _USING_MFC8 (custom identifier):
#ifndef _AFXDLL // this was already here
// stuff you already have goes here
#else // this was already here
#ifdef _USING_MFC8
#ifndef _UNICODE
#ifdef _DEBUG
#pragma comment(lib, "mfc80d.lib")
#pragma comment(lib, "mfcs80d.lib")
#else
#pragma comment(lib, "mfc80.lib")
#pragma comment(lib, "mfcs80.lib")
#endif
#else
#ifdef _DEBUG
#pragma comment(lib, "mfc80ud.lib")
#pragma comment(lib, "mfcs80ud.lib")
#else
#pragma comment(lib, "mfc80u.lib")
#pragma comment(lib, "mfcs80u.lib")
#endif
#endif
#else
// stuff you already have goes here
#endif
#endif // this was already here
There's also a whole load of warnings that I'm clearing up, mostly type conversions, but they don't really affect the build.
Hello.
I've gotten MUSHclient to compile and link successfully, but I can't run it. I've read this thread and I need the locale directory. The problem is I don't seem to have that directory.
I've gotten MUSHclient to compile and link successfully, but I can't run it. I've read this thread and I need the locale directory. The problem is I don't seem to have that directory.
The locale directory is part of the standard MUSHclient distribution. It changes infrequently, so a copy from any recent download would do. Basically it has the resource file in it (which has dialog boxes, menus, etc.).
See my post on page 1 of this thread, where I say "In order to *run* it you need a couple of other files ...".
I see. It is running now. Thanks. :)
For anyone compiling it under VS 2008 or anything that likes to add UAC manifests to the resultant binaries, be sure to take off that option in the Project Configuration. Manifest resource == No compatibility VirtualStore created for MUSHClient == Epic MUSHClient fail (when placed in Program Files).
Under the latest version of the source released (v4.45), I am getting this error 16 times, stating that LINK_SIZE must be 2, 3, or 4. I can't find any references to LINK_SIZE at all in the project source, nor in the project file.
I also get this error from the make process:
I'm not sure what to make of either error.
EDIT: It seems that the second error only comes up in debug mode, and apparently .sbr files contain debug info... All of the non-MUSHclient sources (png, sqlite, md5, etc) create them properly, but the build aborts once it tries to build ActivityDoc's .sbr file.
EDIT 2: If I toggle the switch from /Fr to /FR (noting, by the way, that the former is deprecated in VS2005), it gets much further... then has the same error, but on shs.sbr instead.
mushclient\pcre_internal.h(368) : fatal error C1189: #error : LINK_SIZE must be either 2, 3, or 4I also get this error from the make process:
BSCMAKE: error BK1506 : cannot open file '.\WinDebug\ActivityDoc.sbr': No such file or directoryI'm not sure what to make of either error.
EDIT: It seems that the second error only comes up in debug mode, and apparently .sbr files contain debug info... All of the non-MUSHclient sources (png, sqlite, md5, etc) create them properly, but the build aborts once it tries to build ActivityDoc's .sbr file.
EDIT 2: If I toggle the switch from /Fr to /FR (noting, by the way, that the former is deprecated in VS2005), it gets much further... then has the same error, but on shs.sbr instead.
Removing the /Fr flag cleared up the second error, but I am boggled by the first. If I go to where it says the error occured, and artificially #define LINK_SIZE 2 right before it's checked, a whole bunch of other undeclared identifiers crop up in the pcre files.
Some more sleuthing reveals that the pcre files don't seem to be #include'ing config.h, which predefines LINK_SIZE and the other identifiers mentioned. Apparently it's only included if HAVE_CONFIG_H is defined... clearly, you have this define set in stdafx.h, but testing shows that it's not defined when the pcre files need it.
Adding a compiler flag /D "HAVE_CONFIG_H" seems to expose the symbol properly to the pcre files. The only remaining issue is that pcre_ucp_searchfuncs.c doesn't include config.h, but it does include pcre_internal.h (which is where the LINK_SIZE error originates). I patched in an #include to config.h in it, but it leaves a bad taste to be editing an external library when it's supposed to compile fine...
... and of course, that's not the end of the errors.
What in the world changed to cause this much damage to the compilation process? I don't remember dealing with this the first time I compiled MUSHclient; these are totally new problems.
EDIT: Hang on, feel free to disregard this post for the moment... I realized I was using my outdated project file instead of the new one that came with the source. Trying to get past the zlib undefined externals again at the moment.
Some more sleuthing reveals that the pcre files don't seem to be #include'ing config.h, which predefines LINK_SIZE and the other identifiers mentioned. Apparently it's only included if HAVE_CONFIG_H is defined... clearly, you have this define set in stdafx.h, but testing shows that it's not defined when the pcre files need it.
Adding a compiler flag /D "HAVE_CONFIG_H" seems to expose the symbol properly to the pcre files. The only remaining issue is that pcre_ucp_searchfuncs.c doesn't include config.h, but it does include pcre_internal.h (which is where the LINK_SIZE error originates). I patched in an #include to config.h in it, but it leaves a bad taste to be editing an external library when it's supposed to compile fine...
... and of course, that's not the end of the errors.
Error 308 error LNK2019: unresolved external symbol __pcre_ucd_stage2 referenced in function _match pcre_exec.obj
Error 311 error LNK2019: unresolved external symbol __pcre_ucd_stage1 referenced in function _match pcre_exec.obj
Error 305 error LNK2019: unresolved external symbol __pcre_ucd_records referenced in function _match pcre_exec.obj
Error 307 error LNK2001: unresolved external symbol __pcre_ucd_stage2 pcre_compile.obj
Error 309 error LNK2001: unresolved external symbol __pcre_ucd_stage2 pcre_xclass.obj
Error 310 error LNK2001: unresolved external symbol __pcre_ucd_stage1 pcre_compile.obj
Error 312 error LNK2001: unresolved external symbol __pcre_ucd_stage1 pcre_xclass.obj
Error 304 error LNK2001: unresolved external symbol __pcre_ucd_records pcre_compile.obj
Error 306 error LNK2001: unresolved external symbol __pcre_ucd_records pcre_xclass.objWhat in the world changed to cause this much damage to the compilation process? I don't remember dealing with this the first time I compiled MUSHclient; these are totally new problems.
EDIT: Hang on, feel free to disregard this post for the moment... I realized I was using my outdated project file instead of the new one that came with the source. Trying to get past the zlib undefined externals again at the moment.
Okay, all fixed by using the new project file, and downloading zlib 1.2.3. Since MUSHclient uses a different version of zlib now, Nick, would you be able to update your zlib.zip download?
This is really odd. First, please note that I commented out all of my changes to make sure they weren't causing this (and double-checked with WinMerge diffs). Every time the mouse moves, clicks, whatever, while within the output area, MUSHclient.exe's memory usage goes up about 4K in the Task Manager and doesn't come back down. Even stranger is that I left the .exe with my changes running overnight, and when I woke up, MUSHclient had almost 50% of my RAM. When I closed MUSHclient (not end task, just normally), it didn't leave the Task Manager; it sat there eating up more and more memory, on its own.
I can't reproduce this with the official 4.45 executable, and since I did disable my changes while testing, I was basically compiling it as it was. I suppose it must be the compilation process and/or the newer version of MFC, rather than any changes I introduced to the source...
I can't reproduce this with the official 4.45 executable, and since I did disable my changes while testing, I was basically compiling it as it was. I suppose it must be the compilation process and/or the newer version of MFC, rather than any changes I introduced to the source...
Did you make a Debug executable? They tend to be memory hogs.
Ah... yes, I did. Recompiling in Release mode fixes the memory issues. I sure feel stupid now.
Twisol said:
Since MUSHclient uses a different version of zlib now, Nick, would you be able to update your zlib.zip download?
Since MUSHclient uses a different version of zlib now, Nick, would you be able to update your zlib.zip download?
The zlib files are the same as downloaded from:
http://www.zlib.net/
(version 1.2.3)
Except that at the start of zconf.h change:
#ifndef ZCONF_H
#define ZCONF_H
to:
#ifndef ZCONF_H
#define ZCONF_H
#undef ZLIB_DLL // NJG
Twisol said:
Ah... yes, I did. Recompiling in Release mode fixes the memory issues. I sure feel stupid now.
Ah... yes, I did. Recompiling in Release mode fixes the memory issues. I sure feel stupid now.
It's not your fault their debug version works so badly. :)
It looks like it is actually possible to build MFC with express editions with a few steps. See here:
http://www.codeproject.com/KB/MFC/MFCinVisualStudioExpress.aspx
And if you already have MFC includes and libraries, like from VC6, you can use those instead of dealing with the DDK section and it works better.
http://www.codeproject.com/KB/MFC/MFCinVisualStudioExpress.aspx
And if you already have MFC includes and libraries, like from VC6, you can use those instead of dealing with the DDK section and it works better.
Quote:
If you have a VC++ 6 installed, you can use that instead of the DDK.
Follow the instructions in the article, but where it tells you to add the "$(DDK_directory)\inc\mfc42" directory, use the "C:\Program Files\Microsoft Visual Studio\VC98\MFC\Include" folder instead. Same goes for the other include and lib directories (e.g., "C:\Program Files\Microsoft Visual Studio\VC98\MFC\Lib" for the lib).
You do not need to install the DDK. Also you can build and run in debug mode, when you have the original VC++ 6 installed.
If you have a VC++ 6 installed, you can use that instead of the DDK.
Follow the instructions in the article, but where it tells you to add the "$(DDK_directory)\inc\mfc42" directory, use the "C:\Program Files\Microsoft Visual Studio\VC98\MFC\Include" folder instead. Same goes for the other include and lib directories (e.g., "C:\Program Files\Microsoft Visual Studio\VC98\MFC\Lib" for the lib).
You do not need to install the DDK. Also you can build and run in debug mode, when you have the original VC++ 6 installed.