Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

C9 Lectures: Mahmoud Saleh - Advanced CRT, 2 of 2

Download

Right click “Save as…”

You first met Mahmoud Saleh in an episode of C9::GoingNative covering CRT (C Run-time Library). Mahmoud is the keeper of the CRT(C Run-time Library) at Microsoft, working on the VC++ team as a software engineer. The information presented in that GoingNative episode was introductory in nature and as we expected you asked for more advanced treatment of this important subject matter. Well, being the kind person that he is, Mahmoud agreed to do full lecture covering advanced topics related to CRT. Thank you, Mahmoud!

This will be a 2-part series with an option for more depending on how many questions you ask.

In part 2, you'll learn about File IO, Controlling the stream buffer, GS handler, C++ exceptions, CRT and Windows APIs, CRT floating point support.

->Slides for this presentation

->Source code for the demos in this presentation

Tune in. Enjoy. Learn.

See part 1

Tags:

Follow the Discussion

  • Thanks Mahmoud, very interesting stuff  Smiley

    I find the exception (C++/SEH) implementation details particularly interesting. There is a great article on CodeProject specifically for the VC++ implementation:

    http://www.codeproject.com/KB/cpp/exceptionhandler.aspx

    If other folks would agree as well, I'd love to watch a lecture on that topic.

    Charles, great work as always Smiley

  • MattMatt

    Glad to see some of my questions answered, thank you Mahmoud!

    "Some device drivers can link to it [msvcrt.dll] but only a very few and for specific needs" which are? :)

  • C64C64

    Thanks for this lecture!

     

  • MattMatt

    I have a lot of small (~50KB) system tools that depend on the CRT, what is the best way to distribute them to my users knowing that:

    - These tools should be compatible with Windows XP, Vista, 7
    - The CRT version targeted may or may not be installed on their system.
    - These tools are standalone apps and should not install or require any extra component on their system
    - I want to keep the CRT footprint as low as possible in term of application size (at most a few hundreds of KB)

    Linking with msvcrt.dll would be the best solution as I rely on the CRT for basic tasks only (mostly initialization and memory related)

    Assuming we should not use this CRT version, is static linking when I build my apps the second best option?

  • C64C64

    , Matt wrote:

    I have a lot of small (~50KB) system tools that depend on the CRT, what is the best way to distribute them to my users knowing that:

    - These tools should be compatible with Windows XP, Vista, 7
    - The CRT version targeted may or may not be installed on their system.
    - These tools are standalone apps and should not install or require any extra component on their system
    - I want to keep the CRT footprint as low as possible in term of application size (at most a few hundreds of KB)

    Linking with msvcrt.dll would be the best solution as I rely on the CRT for basic tasks only (mostly initialization and memory related)

    Assuming we should not use this CRT version, is static linking when I build my apps the second best option?

    IMHO, considering your requirements #2 and #3, you should consider static linking of CRT; in this way your tools don't rely on external components (CRT DLL), and you don't force your clients to download and install VC++ redistributables.

     

  • -Thanks Mahmoud,great video !

    -I would like to see a more in depth talk about the floating-point operations especially about the differences between code compiled for IA-32 and AMD64 on Windows.

    -Why is the x87's "fsincos" directive not exposed in Visual C++ ?

    -What happens if I invoke fxxx(x87 directives) trough assembler on AMD64 architectures under Windows ?

    -Hey Charles, get more people like this dude on camera Smiley also great job.

  • @C64: Right, you should not link to msvcrt. Static linking to the Visual Studio CRT will be your best bet. And with these O/S versions you're targeting, Visual C++ 10 fits your needs.
    I don't know how much your app size will increase - it all depends on how much of the CRT you're linking in. But my guess, it should be within the range you're looking for. The easiest way to verify is build once with /MD and another with /MT and see how much the size increases. To reduce app size, there are some tweaks you can make, e.g. /O2 instead of /O1, use intrinsics, even use Win32 APIs instead of CRT functions when possible.

     

  • ChrisChris

    msaleh, few questions.

    1. The CRT exposes some Microsoft specific non-standard functions(starting with underscore) that are easier to use than equivalent Win32 API functions. Which ones do you recommend to use?

    2. The whole thing about the new CRT not running on Windows XP. Even though users are really mad and Microsoft might reconsider this decision, let's assume it won't run on XP by default. Are there any workarounds (linking to it differently etc)?

  • @Matt: Thanks Matt,

    Good catch. That was bad of me! The latest Windows Driver Kit (WDK), 7.1.0, build environment allows building using various library options. Please see here. According to that page, msvcrt is the preferred option.

  • @Chris:Hi Chris,

    Re (1), The CRT non-standard functions serve many areas, many of which are not available for the Win32 APIs; e.g. the debug heap, but the important thing is consistency. This will reduce bugs and maintenance of course. Sometimes, you have to use CRT functions; for example if you're creating new threads and expecting to call CRT functions within the thread methods, then use _beingthread() or _beginthreadex() instead of Win32's CreateThread(). If you don't use _beginthread*(), then there could some memory leaks.
    Another example, is the environment variables functions. To make sure your environment variables are correctly read/updated, then either use the CRT functions exclusively or the Win32 API ones. Finally, the CRT functions have been designed to abstract away many of the complexities of the Win32 APIs, so you may find them easier to use. _exec* functions are much easier to use than CreateProcess for example.

    Re (2), like you've mentioned yourself, as with the whole product, O/S version support for the new CRT is not yet finalized, but I will try to get more details for you here.

    Re (2), this Connect bug talks about the same issue:
    "This [No XP support] behavior is by design in MFC and CRT for Visual Studio vNext.  The minimum supported operating systems are Windows Server 2008 SP2 and Windows Vista.  Windows XP is not a supported operating system for the release (design-time or run-time)."
    The release mentioned is "Developer Preview".

    There's a workaround already described there as well, which is use the multi-targeting feature. If you have Visual Studio v10 and vNext installed on the same box, you can target v10 compiler toolset and libs inside Visual Studio vNext. The limitation of course, you'll not benefit from improvements to the CRT or compiler or other libs improvements/bug fixes.

  • MattMatt

    #define RtlZeroMemory(Destination,Length) memset((Destination),0,(Length))

    is Win32 related (defined in WinNT.h), why does it rely on the CRT to do its job?

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.