Does crt0 load msvcrt.dll?

Question

I'm trying to figure out how are Standard C Functions like printf() loaded into memory on Windows environment. I know that crt0.obj prepares the stack, calls int main(int argc, char **argv) and then exits the process with the exit code that main returned.

I also heard that C standard functions are located in a shared library called msvcrt.dll. I'm wondering if crt0 also loads msvcrt.dll or there is a msvcrt.lib which is also linked automatically by the compiler.

Thank you and sorry for my English :)

Wargo

Please read this carefully: blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx – Mckoy

Also I would recommend that you get a copy of (1) Process Monitor and (2) Depends, and learn how to use them both. They are both very handy for answering questions like yours. They're free. – Mckoy

I haven't double-checked this, but I believe that crt0.obj is part of msvcrtnn.dll. – Balmacaan

Answer 1

There will always be a run-time environment, such as msvcr80.dll (for Windows variants), loaded when you install your environment, what ever it is, i.e. MSVCxx, Code::Blocks with MinGW, etc. The environment installer places .dlls containing the standard C libraries (for C environments) into your system directory, and provides all necessary static libs to link to during your builds, and header files for prototypes and defines necessary to use that environment. You just need to set your path, (to see the.libs) and #include the right headers in your source code.

Note, for Operating systems such as Linux varieties the run-time environment is built into the OS, and incudes all shared libraries (synonymous with .dll) static libraries and .h for standard C.

Regarding your question on msvcrt.dll, read @Eric's comment above. Current RTEs from Microsoft use a nameing convention in the form msvcrnnn.dll (eg. msvcr80.dll, msvcr100.dll,... and so on depending on addressing (32 or 64 bit), OS version, etc.)

Regarding your statement: also linked automatically by the compiler. That is completely environment dependent. If you are using Microsoft's development environment, then yes, it is likely already set up with defaults to allow your linking to work right out of the box. If using Microsoft libraries, but from a non-Microsoft environment, paths and other environment variables need to be set in order to pick up the .lib and .h locations.

(Regarding your English: it is better than that spoken by most of the engineers I work with.)

Gully

Thank you! I've found an interesting site with a lot of information: codeproject.com/Articles/22642/… – Wargo

Answer 2

Here are some good pages for what gets linked with regards to the C runtime and the standard library (1,2,3):

crt0.obj is part of libcmt.lib, which is the CRT static library (COFF archive). You can instead choose to dynamically link the CRT by statically linking with a COFF import library, msvcrt.lib, which will cause dynamic linking with msvcr<version>.dll at runtime.

The standard library is implemented in libpcmt.lib and the dynamic version is msvcprt.lib, which will cause dynamic linking with msvcp<version>.dll at runtime.

My libcmt.lib on VS2017 does not have a crt0.obj object-file archive member and instead appears to implement mainCRTStartup in exe_main.obj and WinMainCRTStartup in exe_winmain.obj

Aniconic