Thread: Microsoft compilers question....

  1. #16
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    MSVCRT.dll is a "known dll". It will always be there, and you never need to provide it yourself.

    MinGW uses MS CRT's. It does not support "static linking" of any of those CRT's - it only dynamically links to MS CRT dll's.

    By default, it links with MSVCRT.dll. This is the CRT that shipped with VC++ 6.0 and has since become part of the operating system (a "known dll").

    MinGW also supports dynamically linking to the CRT's from VC++ .NET, 2005, and 2008.

    By default, MinGW uses GNU's libStdC++ as it's C++ library and links to it statically. Starting with MinGW 4.5, it can be linked to dynamically by using "-shared-libstdc++" on the command line.

    In the end, your installation/setup process is responsible for whatever is needed. If that process is "copy this EXE to your hard-drive", then you can't have any external dependencies to anything other than "known dll's".

    EXE size is a non-issue in my mind. Link statically if you want to hand out (non-setup) EXE's only.

    gg

  2. #17
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Not to be argumentative, just seeking clarity...

    Quote Originally Posted by Codeplug View Post
    MSVCRT.dll is a "known dll". It will always be there, and you never need to provide it yourself.
    Microsoft's advice to the contrary? That's what I don't get... It seems to be everywhere, but MS provides this 2meg redistributable archive that we're supposed to include...

    MinGW uses MS CRT's. It does not support "static linking" of any of those CRT's - it only dynamically links to MS CRT dll's.
    Then how does one explain the 400K+ minimum EXE size?

    By default, MinGW uses GNU's libStdC++ as it's C++ library and links to it statically. Starting with MinGW 4.5, it can be linked to dynamically by using "-shared-libstdc++" on the command line.
    Ahhh... so that explains it.

    In the end, your installation/setup process is responsible for whatever is needed. If that process is "copy this EXE to your hard-drive", then you can't have any external dependencies to anything other than "known dll's".
    Well, I'm not going to be distributing any thing in C++ for quite a while so the installer is a bridge to cross when I get there...

    As I said in another thread... I just really don't want to have some stupid problem 3 years down the road that I could have avoided today...

  3. #18
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    >> That's what I don't get...
    MSVCRT.dll - originally from VC++ 6.0 - now a known/system/OS dll (in the same league as user32.dll)
    MSVCR7[0|1].dll - from VC++ .NET - install locally in application directory
    MSVCR80.dll - from VC++ 2005 - uses WinSxS (redist package), or install locally as private SxS
    MSVCR90.dll - from VC++ 2008 - uses WinSxS (redist package), or install locally as private SxS
    MSVCR100.dll - from VC++ 2010 - redist package, or install locally (no longer uses WinSxS)

    http://support.microsoft.com/kb/326922

    gg

  4. #19
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    200K program that needs 12megs of DLLs
    You don't like that? That is an excellent position to be in. That mean you quite likely have 12 megs of code that can be re-factored, altered, and used by the 200k program without recompiling all 12 DLLs and the 200K program.

    The MSVCRT dll situation is completely different in 2005, and 2008 as Codeplug has pointed out. These now reside in WinSXS in your Windows installation folder. Each one is in a nice folder and the name of the folder is reference in the manifest file for your executable. And now, as Codeplug has pointed out, Microsoft decided to change this for some strange reason. However MSVCRT.DLL remains a system DLL. This switch in 2005 and 2008, IMO, caused an unecessary amount of porting headaches for existing code bases.

    Also as has been pointed out Windows still first looks in the local folder where the binary is for the DLLs the binary needs and then moves on to other locations like the WinSxS folder to find the others. If it cannot find the correct CRT DLLs it will give the oh so cryptic error that the application configuration is incorrect. If you look at your Event viewer under applications you will see a side by side linking error and it will tell you it cannot find the CRT DLLs.
    Last edited by VirtualAce; 01-11-2011 at 10:34 PM.

  5. #20
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    It's at moments like this when I yearn for the simplicity of Pascal... Smart linking, no DLLs to mess with, no manifests or SXS crap to make sense of ... Write, compile, run... Yippie!. PellesC is a similar experience... For windows just write, include a simple manifest, compile and run... Now, when after years of struggle, I finally get my head around the objects concept... bam... my life is suddenly all about manifests, DLLs, SXS, lack of documentation --is there such a thing as a C++ help file?-- and unanswered questions... It's becomming horrendously complex and beyond discouraging.

    I worked many years in electronics and had the boss from hell... but he had one thing right. He would look at my schematics and say: "Simplify - Simplify - Simplify!" a lesson Microsoft would do well to learn. It's no wonder they need 3,000 programmers to produce a working product...this is flat out ridiculous.

    I do appreciate you guys clearing up the CRT question for me.
    Now it's on to the 344 other problems I seem to have caused myself...

  6. #21
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    What's so difficult to understand?
    Either you link statically -- all requirements of your applications are embedded into the executable. Just give it away and it will work.
    Or you link dynamically -- the applications will need the requirements to be installed before running. You don't need to bother with where they're installed. The installer will do that job for you. Run the installer to install runtimes (once), run your app. Done.

    All compilers have to make this decision, including Pelle's, so don't use that as an argument.

    How is it not easy? Make sure the target machine has installed the VC redist, compile and run. Yipee! Done.
    Or make a setup project. Easy. Takes just a few steps. Run installer. Run app. Easy.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #22
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Elysia View Post
    What's so difficult to understand?
    I do understand...
    I have two choices...

    1) Static with bigger EXEs

    or

    2) Dynamic with possible runtime errors on some machine half way round the world.

    I get all that... I'm just not really fond of the alternatives I have...

    The big problem, as usual with this stuff, is the lack of specificity I get in response to questions... People here are better than most but after 50 websites all saying "It depends" and "Sometimes"... the old intra-cranial tissue tends to turn to mush.

    Your answer was specific, as were the ones immediately before... that's what I needed.

    Apparently the most common answer is to go with #2 and include the runtimes either in the download or on the download page. Using an installer package such as Inno, I can script it to install the runtimes along with my code, only if needed, so it turns out OK....

    I'm sorry if my frustration was showing... But in my own defense I'm dealing with a near vertical learning curve here and I think you already know how blocked I was on OOP stuff....

  8. #23
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Such is the way of the modern world, I'm afraid.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #24
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Elysia View Post
    Such is the way of the modern world, I'm afraid.
    I hear that!

    A few hundred tons of information floating around out there and no simple answers to anything I need... LOL.

    What I finally came up with was "learn the language first, worry about the rest later"...

  10. #25
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    The SDK comes with a vcredist package that you should include in your installer. It takes care of making sure all the SDK dependencies are installed correctly. Pretty simple, really.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #26
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by brewbuck View Post
    The SDK comes with a vcredist package that you should include in your installer. It takes care of making sure all the SDK dependencies are installed correctly. Pretty simple, really.
    I saw that... but only after greatly increasing the greyness of my hair!

    It can also be downloaded from the Microsoft website in self-installing form...

    32bit ... http://www.microsoft.com/downloads/e...displaylang=en
    64bit ... http://www.microsoft.com/downloads/e...9-9A8D7548C1B6
    Last edited by CommonTater; 01-14-2011 at 01:26 PM.

  12. #27
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    639
    You can also have the best of both worlds. Dynamic linking with no extra installer size if the redist isn't required: The Application Configuration is Never Correct « Just Let It Flow, not that I'm shamelessly plugging or anything.

  13. #28
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by adeyblue View Post
    You can also have the best of both worlds. Dynamic linking with no extra installer size if the redist isn't required: The Application Configuration is Never Correct « Just Let It Flow, not that I'm shamelessly plugging or anything.
    Now I might consider wrapping the instal.exe in that...

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Microsoft Math question
    By Akkernight in forum General Discussions
    Replies: 77
    Last Post: 08-31-2009, 02:04 PM
  2. another do while question
    By kbpsu in forum C++ Programming
    Replies: 3
    Last Post: 03-23-2009, 12:14 PM
  3. Academic Question About Compilers
    By keira in forum C Programming
    Replies: 4
    Last Post: 02-21-2008, 12:03 AM
  4. Microsoft Product Activiation loopholes
    By Liger86 in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 07-08-2005, 05:20 PM