What Every Computer Programmer Should Know
2008-02-29 21:20:29
What Every Computer Programmer Should Know About Windows API, CRT and Standard C++ Library
- 1. The Purpose
- 2. Basics
- 3. Code Reuse
- 3.1 Linking Statically
- 3.1.1 CRT as a Black Box
- 3.2 Linking Dynamically
- 3.1 Linking Statically
- 4. Summary
1. The Purpose
The purpose of this article is to clear the essential points about Windows API, C Runtime Library (CRT) and Standard C++ Library (STL). It is not uncommon that even experienced developers have confusion and hold onto misconceptions about the relationship between these parts. If you ever wondered what is implemented on top of what and never had a time to figure it out, then keep reading.
2. Basics
The following diagram represents the relationship between WinAPI, CRT and STL.
| Application | User Mode | |||
| Standard C++ Library | ||||
| C Runtime Library | ||||
| Operating System | Kernel Mode | |||
| Hardware | ||||
Adjacent blocks can communicate with each other. What does it mean? Let's go from the bottom to the top.
2.2. Hardware
Each hardware part exposes its own set of commands that enables operating system to control and communicate with it. An amount and complexity of commands varies from part to part. Often different vendors of the same part may provide additional commands beyond requirements of a common standard. Communication with countless hardware devices with endless variety of commands would be enormous toil for software writers if they had to access it directly. Here operating system comes to the rescue.
2.3 Operating System
The purpose of the OS is to encapsulate all intricacies of underlying hardware and provide unified access interface to computer's parts. No application can access hardware directly. Only OS can access hardware. The part of the OS that accesses hardware is said to run in kernel mode.
Older OS'es like MS-DOS, for example, allowed programs to access hardware resources directly. Though it enabled software writers to make certain performance gains, in the long run this technique often made the software very brittle and incompatible with newer hardware parts.
2.4 Application Programming Interface
OS exposes underlying machine resources by means of Application Programming Interface (API). API is a uniform set of functions that enables software developers to abstract from hardware peculiarities and focus on their own goals. Application cannot bypass an OS and access hardware resources directly. It is commonly said that applications run in user mode. MS Windows provides API as a set of C functions. C language is chosen as the lowest common denominator for software development under Windows platform.
2.4.1 Platform Software Development Kit
MS distributes for free Platform Software Development Kit (Platform SDK or PSDK), which enables software developers to write Windows programs. PSDK contains:
- Header files with API functions declarations
- Import Lib files to link with (where calls to API functions are redirected to relevant DLL's)
- Documentation
- Various binary helper tools
For example, to open or create a file one calls CreateFile function, which is declared in "WinBase.h" header file and requires "Kernel32.lib" library to link with.
Names of Windows API functions follow Camel case naming convention and usually are easily distinguished by this. Names of macros and constants are conventionally in uppercase. Each function always has "Requirements" section on its documentation page where necessary headers, import libraries and supported OS versions are specified.
A Windows application can call any API function, provided application follows function's signature and links with appropriate import library (or gets function's address directly from implementing DLL with GetProcAddress call.
2.5 C Runtime Library
On top of OS API functions software vendors implement C Runtime Library (CRT). CRT is a standardized set of header files and C functions, which implement common tasks, such as string operations, some math functions, basic input/output etc. Usually the same vendor that makes C compiler also provides CRT implementation. International Organization for Standardization [^] is responsible for C language standard and its runtime library.
2.5.1 Standards and Extensions
Theoretically, by using only standard C functions developer can ensure that the same code may be used to build and run a program under any platform where decent C compiler and CRT implementation exists. However, in practice software vendors include many useful extensions to standard library functions, which make developers' life easier but at a price of portability.
Names of CRT functions are in lower case. Names of macros and constants are in uppercase. Names of extensions begin from underscore character, for example _mkdir function. Each function always has "Requirements" section on its documentation page where its header is specified.
2.6 C++ Standard Library
C++ programming language defines its own standard library. C++ Standard Library specifies a set of classes and functions that facilitate common programming tasks.
Often C++ Standard Library is referred as STL. This abbreviation belongs to pre-standard times and stands for Standard Template Library. Since latest revision of C++ standard STL became a subset of C++ Standard Library. However, the term STL is still ubiquitous and used as a synonym for C++ Standard Library.
International Organization for Standardization [^] is responsible for C++ language standard and its library.
2.6.1 Contents of C++ Standard Library
C++ Standard Library may be divided into following major parts:
- Containers, where common data structures are defined, such as
vector,set,list,mapetc. - Iterators, which provide uniform way to operate over standard containers.
- Algorithms, which implement common useful algorithms. Algorithms use iterators instead of working directly with containers. That's why the same implementation of an algorithm can be used with different standard containers.
- Allocators, which handle memory storage allocation/deallocation for elements in containers.
- Function Objects and Utilities, which are helpers to algorithms and containers.
- Streams, which provide uniform object oriented way of input/output.
- C Runtime Library. Due to backward compatibility of C++ with C language, CRT is incorporated into Standard C++ Library.
2.7 Cross-platform Development
Sometimes there is requirement that software program will run on several computer platforms. Developer may choose to develop as many separate code bases of software as there are target platforms. However, this approach is tedious and error prone. It is also wasteful and ineffective considering development resources since the same functionality must be implemented and maintained over and over again.
The common approach is to develop single code base for all platforms and restrict the usage of platform-dependent API functions and vendor-specific standard libraries extensions. It makes development harder, however, in the long run all platforms benefit from new features and bug fixes.
3. Code Reuse
There are two ways to incorporate CRT and/or C++ Library code into a program: 1) static linking and 2) dynamic linking. In the following discussion I will use solely CRT term to save typing, however these concepts are relevant both to CRT and C++ Standard Library.
3.1 Linking Statically
When CRT/C++ Library linked statically, then all its code is embedded into resulting executable image. This technique has both advantages and disadvantages.
Advantages:
- Simple deployment. It is enough to copy a program to destination computer to make it run. No need to worry about complicated scenarios of CRT/C++ Library deployment.
- No additional files. It can be very convenient for small utility application to comprise just of one executable file. Such self-contained application can be easily downloaded and redistributed without the risk to break its integrity.
Disadvantages:
- Not serviceable. New versions of a library and fixes of an old verions are invisible for statically linked programs.
- Domino Effect of static linking. In the modern world rarely a program can pull it out all by itself. Nowadays software programs are complex and heavily rely on 3rd party components and libraries. Also, a software program itself is often divided into several loosely coupled modules. Using static linking to CRT in one of them greatly reduces interoperability between modules and forces developer to fall back on lowest common denominator, i.e. C interface with explicit methods for acquisition and release of resources. Following section discusses the issue in more details.
3.1.1 CRT as a Black Box
The problem is that internal CRT objects cannot be shared with other CRT instances. The memory allocated in one instance of CRT must be freed in the same instance, the file opened on one instance of CRT must be operated and closed by functions from the same instance, etc. It happens because CRT tracks acquired resources internally. Any attempt to free memory chunk or read from file via FILE* that came from other CRT instance will lead to corruption of internal CRT state and most likely to crash.
That's why linking CRT statically obligates a developer of a module to provide additional functions to release allocated resources and a user of a module to remember to call these functions in order to prevent resource leaks. No STL containers or C++ objects that use allocations internally can be shared across modules that link to CRT statically. Following diagram illustrates the usage of a memory buffer allocated via call to malloc.
malloc from different modules
In the above diagram Module 1 is linked to CRT statically, while Modules 2 and 3 are linked to CRT dynamically. Modules 2 and 3 can pass CRT owned objects between them freely. For example, a memory chunk allocated with malloc in Module 3 can be freed in Module 2 with free. It is because both malloc and free calls will end up in the same instance of CRT.
On the other hand, Module 1 cannot let other modules to free its resources. Everything allocated in Modukle 1 must be freed by Module 1. It is because only Module 1 has an access to statically linked instance of CRT. In the above sample Module 2 must remember to call a function from Module 1 in order to properly release acquired memory.
3.2 Linking Dynamically
When CRT/C++ Library linked dynamically, then only small import libraries are linked with resulting executable image. Import libraries conatin instructions where to find actual implementation of CRT/C++ Library functions. On program's start system loader reads these instructions and loads appropriate DLL's into process' address space.
Advantages:
- Improved Modularity. As described in previous sections overall modularity of a program can benefit from dynamic linking. Program can be divided into several modules while being able to pass relatively high-level objects between them.
- Faster start. CRT DLL's are preloaded by the the system on start. Then when a program needs to load CRT module, no actual load occurs. It enables the system to save physical memory and reduce page swapping.
Disadvantages:
- Complicated deployment. CRT libraries must be redistributed and properly installed in order program to work. It requires a writing of additional setup program and thinking out deployment strategy.
4. Summary
The article described relationships and dependencies between Windows API, C Runtime Library and Standard C++ Library. Windows API is a lowest operational level for user mode programs. On top of Windows API there is C Runtime Library, which encapsulates and hides operating system differences. Standard C++ Library provides much more functionality and also includes CRT as an integral part. Using only standardized functions and classes allows to write cross-platform applications. Such applications require rebuild only in order to run on new platform. No code change is required.
Both C Runtime Library and Standard C++ Library can be linked to statically or dynamically, depending on application's needs. Each method has its own advantages and drawbacks.
License
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)
About the Author
| Alex Blekhman ^0u$f/I(r*yf0 ` n#o-\-B0 |
LUPA开源社区D*U%u KBpCA9^
|
推荐 收藏 导入论坛 等级(1) 编辑 管理 查看(10) 评论(0) 评分(0/0)
TAG: