{"id":109823,"date":"2024-05-30T07:00:00","date_gmt":"2024-05-30T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109823"},"modified":"2024-06-02T07:45:39","modified_gmt":"2024-06-02T14:45:39","slug":"20240530-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240530-00\/?p=109823","title":{"rendered":"A graphical depiction of the steps in building a C++ executable, enhanced for classic Win32"},"content":{"rendered":"

Last time, we generated a diagram showing the basics of how a C++ executable is built<\/a>. The diagram applies to Windows programs too, but it is often the case that some of the parts that go into the C++ build are themselves build outputs of other tools. And there are usually other parts of a Windows program that aren’t covered by the C++ build workflow because they produce things beyond just a C++ program.<\/p>\n

Let’s add some of them into our diagram, at least the ones most often seen in classic Win32 apps.<\/p>\n

 <\/p>\n

\u00a0<\/div>\n
\u00a0<\/div>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
.idl<\/td>\n <\/td>\n <\/td>\n<\/tr>\n
\u2193<\/td>\n <\/td>\n <\/td>\n<\/tr>\n
MIDL compiler<\/td>\n <\/td>\n <\/td>\n<\/tr>\n
\u2193<\/td>\n <\/td>\n <\/td>\n<\/tr>\n
\n
\u00a0<\/div>\n
.h, .cpp<\/div>\n<\/td>\n
 <\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\n\n
\u00a0<\/div>\n
\u2193<\/div>\n<\/td>\n
 <\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\n\n
\u00a0<\/div>\n
C++ compiler<\/div>\n<\/td>\n
 <\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\n\n
\u00a0<\/div>\n
\u2193<\/div>\n<\/td>\n
 <\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\n\n
\u00a0<\/div>\n
.obj<\/div>\n<\/td>\n
 <\/td>\n.rc, .ico, .bmp<\/td>\n<\/tr>\n
\u00a0<\/td>\n\n
\u00a0<\/div>\n
\u2199<\/div>\n<\/td>\n
\n
\u00a0<\/div>\n
\u2193
\n\u2193
\n\u2193
\n\u2193
\n\u2193
\n\u2193
\n\u2193<\/div>\n<\/td>\n
 <\/td>\n\u2193<\/td>\n<\/tr>\n
\n
\u00a0<\/div>\n
librarian<\/div>\n<\/td>\n
<\/td>\n <\/td>\nrc compiler<\/td>\n<\/tr>\n
\n
\u00a0<\/div>\n
\u2193<\/div>\n<\/td>\n
<\/td>\n <\/td>\n\u2193<\/td>\n<\/tr>\n
\n
\u00a0<\/div>\n
.lib<\/div>\n<\/td>\n
<\/td>\n <\/td>\n.res<\/td>\n<\/tr>\n
\u00a0<\/td>\n\n
\u00a0<\/div>\n
\u2198<\/div>\n

<\/td>\n

\u2199<\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\n\n
\u00a0<\/div>\n
linker<\/div>\n<\/td>\n
 <\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\n\n
\u00a0<\/div>\n
\u2193<\/div>\n<\/td>\n
 <\/td>\n <\/td>\n<\/tr>\n
\u00a0<\/td>\n\u00a0<\/td>\n\n
\u00a0<\/div>\n
.dll, .exe<\/div>\n<\/td>\n
 <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The original diagram is still there in the bottom left corner, where it consumes C++ source files (.h, .cpp) and eventually produces a module (.dll, .exe). The added steps are things that either produce C++ source files from other sources or add additional content to the resulting module.<\/p>\n

If there is an .idl file, it is processed by the MIDL compiler, which produces .h and .c files, which you consume in your project code.<\/p>\n

You may have other code generators as part of your project. If you have a yacc grammar or a Lottie animation, you’ll also have a compiler compiler or an animation generator as a code generation step, to take the raw materials and turn them into code and resources that are consumed as inputs by other boxes.<\/p>\n

Once we have generated all the C++ source files, we can go through the process we saw last time: Compile the C++ source files to object files, and possibly generate a .lib.<\/p>\n

Meanwhile, for classic Win32 resources, the resource compiler takes the .rc file and any supporting files (like .ico and .bmp) and produces a .res file.<\/p>\n

After all the .obj, .lib, and .res files have been produced, we feed them all to the linker, which produces the resulting module, a .dll or .exe.<\/p>\n

The essence of the process hasn’t changed. There’s just more rigmarole before the compilation (to produce header files and code), alongside the compilation (to produce a resource file), and after the compilation (to incorporate the resources into the final binary).<\/p>\n

Next time, we’ll add more rigamarole around the central diagram by adding packaging and XAML.<\/p>\n

\n