Your application or dynamic-link library does not explicitly call any C run-time functions.Usually, when you link a Windows application or dynamic-link library, the linker adds C run-time startup code to the _TEXT code segment. For Windows applications (but not dynamic-link libraries), this startup code in turn allocates memory for C run-time variables from the application's automatic data segment.
With Windows, you can eliminate this code and data overhead required by the C run-time libraries if all of the following conditions are true:
Your application or dynamic-link library does not explicitly call any C run-time functions.
Your application uses neither the __argc nor __argv command-line arguments nor the environ variable. For more information about how to retrieve the command line and the MS-DOS environment, see Section 14.3, “Using Command-Line Arguments and the MS-DOS Environment.” Dynamic-link libraries cannot use __argc, __argv, and environ in any case.
Your application or dynamic-link library does not implicitly call any C run-time functions, such as to perform stack checking or long division. Stack checking is enabled by default, but you can disable it by using the CL option /Gs.
To eliminate the C run-time startup code from a Windows application, link
the library named xNOCRT.LIB instead of the usual C run-time library
xLIBCEW.LIB (the x placeholder stands for the memory-model specifier
S, M, L, or C).
The following example shows the link command line for an application named SAMPLE that does not make explicit or implicit calls to C run-time functions:
link /nod sample, , , snocrt libw, sample.defThe xNOCRT.LIB library includes the Windows startup code that ultimately calls your application's WinMain function.
If you link your application by using xNOCRT.LIB instead of xLIBCEW.LIB and the linker reports unresolved external symbols that do not belong to your application, your application is probably calling C run-time functions implicitly. In this case, you can still eliminate C run-time startup code and data required for explicit C run-time calls and for the use of the __argc, __argv, and environ variables. To do this, include xNOCRT.LIB on your linker command line before (rather than instead of) xLIBCEW.LIB. You must also specify the linker option /noe.
The following example shows the linker command line for an application named Sample if it makes implicit C run-time calls, but not explicit C run-time calls:
link /nod /noe sample, , , snocrt slibcew libw, sample.defTo eliminate the C run-time startup code from a Windows dynamic-link library, link the static library xNOCRTD.LIB in place of the usual C run-time library xDLLCEW.LIB.
The following example shows the linker command line for a dynamic-link library named SAMPDLL that does not make explicit or implicit calls to C run-time functions:
link /nod sampdll libentry,sampdll.dll,,snocrtd libw,sampdll.defThe xNOCRTD.LIB library includes the Windows startup code that ultimately calls your dynamic-link library's LibMain function.
As with an application, if the linker reports unresolved external references that do not belong to your dynamic-link library, the library is probably making implicit C run-time calls. In this case, you can eliminate the startup code required for explicit C run-time calls by linking xNOCRTD.LIB along with xDLLCEW.LIB, as follows:
link /nod /noe sampdll libentry,sampdll.dll,,snocrtd sdllcew,sampdll.defBe sure to include the required /noe option.