If I use the VC++ compiler that comes with the Windows 7 SDK (VC++ 2008) and I want to install an exe I wrote on a different computer... Do I have to include a bunch of DLLs with it?
How about with MinGW....
If I use the VC++ compiler that comes with the Windows 7 SDK (VC++ 2008) and I want to install an exe I wrote on a different computer... Do I have to include a bunch of DLLs with it?
How about with MinGW....
I think the answer is "it depends" on what compiler options you chose. IIRC, VC++ Express and the pay-for compilers might address this in different default ways.
Mainframe assembler programmer by trade. C coder when I can.
If you compile with MinGW, then you're good to go anywhere.
At least as of the 05 version (the most recent version that I ran often), if you compile with VS, then the machine you run it on has to have installed either its own copy of
VS, or the C Redistributable Runtime Library (I'm pretty sure that's not the real name, but similar), or you have to link statically (instead of linking via .dll) to the runtime.
Thanks for that...Originally Posted by tabstop
They kept talking about MFC and MSVCRT and I'm wondering... why???
I thought I was being so clever using the compiler that is supplied with the SDK. At least now I know why they're giving it away.
So... scrap VC++ and try MinGW on for size.
If you've gotten the impression that it can't be done or isn't easy, then you've gotten the wrong impression. I hope you didn't glance too quickly over that "or you have to statically link to the runtime" that was mentioned right at the end there.
To put it another way, you change a couple of project settings and hey presto a fully self-contained app!
And another option that hasn't been mentioned is to actually install the VS runtimes yourself as part of your own installer. And no I don't mean calling out to another installer, I mean you can actually install the required DLLs into the same dir along with the necessary manifests. Only go this way if your project contains a lot of DLLs which makes tis option take up less space.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Actually no, I didn't miss the bit at the end.
Over the years I've been messing about with this stuff, I've discovered that when you have to start distributing core functionality with programs, you either A) end up with a huge program that does very little or B) end up distributing bloatware. I really don't fancy writing a 200K program that needs 12megs of DLLs to run and I'm certainly not going to be the one that installs multiple copies of them on a user's system. I'll pick a different compiler first.
Actually this is one of the reasons I stuck with PellesC for so long. It does link in a number of CRT functions to produce fully autonomous code but still manages to produce a minimum program size under 20k. While VC does produce minimum program sizes in single digits, it needs to be accompanied by a 1.2meg Dll to do it.
Static linking also causes issues for bug fixes in the statically linked code. Your program will/would miss out on any bug fixes to the library.
I support several packages I've written over the years and when bugs rear their ugly heads, I always end up recompiling at least once to fix them so as long as my machine is up to date --which you can never count on from a user's machine-- I don't see how this is much of an issue.
Last edited by CommonTater; 01-10-2011 at 02:12 AM.
You're only thinking of what happens when the libraries are updated by you. I assumed you were linking to some third party libraries, and distributing to users.
Nope... I'm talking about the the C or C++ run time libraries.
Lets say, just for example, there's a bug in strlen() that can cause it to return incorrect values. Now if I find out about this and update my machine with the new libraries then write code that relies upon the CRTL in DLL form... the minute my program lands on a user's machine where that CRT is out of date, I've got bugs in my code (or so it appears). However; if I statically link the strlen() function from the new CRTL into my code, when it gets to a user's machine there will be no manifestation of error -- even if their version of the CRTL is horridly out of date.
Moreover; I don't have to distribute a bunch of DLLs that contain unused code with my program to make it work. Think what happesn if I have 6 programs all reliant upon those DLLs and a user installs all 6 of them... now he's got 6 copies of the CRTL on his machine, in various versions.
Worse still, if I put the CRTL into his system directories, I run the risk of actually introducing errors into other software that might also rely upon them.
It's far better that I should keep my stuff separate and build copies that run without external support... That way if there are problems, they're MY problems and I can fix them.
So lets get this straight, you're going to combat the VC bloatware redist (1.7 MB for the version relevant to the sdk compiler) by using mingw's static linking that adds ~444KB per C++ binary (that's with my manky old circa Dev-cpp version, and software rarely gets smaller). Using the program on your website as a barometer, mingw would end make your download larger by over 700K.
As for the post above, it seems you're unaware that the MS CRT dll is located in a single directory and updated in band via patch tuesday when required, apps linking against them automatically get redirected to the fixed versions when they're installed. There won't be an out of date CRT to link to, if there is it's not my "my app has a bug" it's "every app has a bug". Unless your statically linked software includes update notifications, people who downloaded it before you updated the binaries will have a larger, if not indefinite period of vulnerability.
This isn't 1991 where installing equals haphazardly copying stuff to system32 and hoping for the best. This is 2011 where installing equals haphazardly including component installers that know if the current stuff is sufficient for our needs and upgrades it if not.
Well, no, it won't... because I don't plan rewriting that in c++ anytime soon.
Ok. we disagree. No worries.As for the post above, it seems you're unaware that the MS CRT dll is located in a single directory and updated in band via patch tuesday when required, apps linking against them automatically get redirected to the fixed versions when they're installed. There won't be an out of date CRT to link to, if there is it's not my "my app has a bug" it's "every app has a bug". Unless your statically linked software includes update notifications, people who downloaded it before you updated the binaries will have a larger, if not indefinite period of vulnerability.
This isn't 1991 where installing equals haphazardly copying stuff to system32 and hoping for the best. This is 2011 where installing equals haphazardly including component installers that know if the current stuff is sufficient for our needs and upgrades it if not.
It somehow seems like your ignoring how I said that with the change of a few project settings, you don't need to distribute anything else at all.
With a bit more work you can also link with other runtimes such as tinycrt which makes your app not only self-contained, but also very small.
You've only having an issue with what it doesn't do by default.
There's far more to it than that, it's actually quite complicated. You can have your app insist on a specific crt version, or just use whatever is the latest on the machine. With a change of project settings the generated manifest can control what it uses. In most cases you can't get a program that expect a certain version of the CRT to run with an older version.
There never has been (and probably never will be) any such nasty bug in something anywhere near as commonly used as strlen in the VCRT. In fact for the massive project I work on at ork, we've never run into any bug that could be attributed to the CRT. They mainly only update it for obscure minor security holes.
It seems to me that you're making up reasons that don't exist to convice yourself because you've already made your mind up.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Not ignoring... just trying to understand.
While I do get the compile/link scenario. I've been somewhat spoiled by PellesC which produces autonomous programs with about 12k EXE size for "hello world". Windows proggys start at about 18k. (x86)
Don't mistake my opinions for closed mindedness. If you knew me you'd know the exact opposite... But what I need, and don't seem to be finding, are concise answers. Everyone is saying "It depends" and "Well, sometimes"... which is not entirely helpful at this point. I just really really don't want to invest myself into this and have some massive foulup in 3 years that I could have avoided today...
If I use the MS compiler... what are the odds that someone trying to install the resulting code will not have the required DLLs?
It appears to me that MinGW links in the *entire* MSVCRT which seems a tad excessive.
Is there some compelling reason --any reason-- I should choose one over the other?
Interesting note here... I just fired up a brand new system with Win7 ... MSVCRT.DLL is in there in about 4 different versions.
Both my XP systems have it as well...
So what's this bit from Microsoft about no guarantee it will be there?
