You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A *code page* is a character set, which can include numbers, punctuation marks, and other glyphs. Different languages and locales may use different code pages. For example, ANSI code page 1252 is used for English and most European languages; OEM code page 932 is used for Japanese Kanji.
10
12
11
-
A code page can be represented in a table as a mapping of characters to single-byte values or multibyte values. Many code pages share the ASCII character set for characters in the range 0x00 - 0x7F.
13
+
A code page can be represented in a table as a mapping of characters to single-byte or multibyte values. Many code pages share the ASCII character set for characters in the range 0x00 - 0x7F.
12
14
13
-
The Microsoft run-time library uses the following types of code pages:
15
+
The Microsoft runtime library uses the following types of code pages:
14
16
15
-
- System-default ANSI code page. By default, at startup the run-time system automatically sets the multibyte code page to the system-default ANSI code page, which is obtained from the operating system. The call:
17
+
- System-default ANSI code page. By default, at startup the runtime system automatically sets the multibyte code page to the system-default ANSI code page, which is obtained from the operating system. The call:
16
18
17
19
```C
18
20
setlocale ( LC_ALL, "" );
19
21
```
20
22
21
23
also sets the locale to the system-default ANSI code page.
22
24
23
-
- Locale code page. The behavior of a number of run-time routines is dependent on the current locale setting, which includes the locale code page. (For more information, see [Locale-Dependent Routines](../c-runtime-library/locale.md).) By default, all locale-dependent routines in the Microsoft run-time library use the code page that corresponds to the "C" locale. At run-time you can change or query the locale code page in use with a call to [setlocale](../c-runtime-library/reference/setlocale-wsetlocale.md).
25
+
- Locale code page. The behavior of a number of run-time routines is dependent on the current locale setting, which includes the locale code page. (For more information, see [Locale-Dependent Routines](../c-runtime-library/locale.md).) By default, all locale-dependent routines in the Microsoft run-time library use the code page that corresponds to the "C" locale. At runtime, you can change or query the locale code page in use with a call to [setlocale](../c-runtime-library/reference/setlocale-wsetlocale.md).
24
26
25
27
- Multibyte code page. The behavior of most of the multibyte-character routines in the run-time library depends on the current multibyte code page setting. By default, these routines use the system-default ANSI code page. At run-time you can query and change the multibyte code page with [_getmbcp](../c-runtime-library/reference/getmbcp.md) and [_setmbcp](../c-runtime-library/reference/setmbcp.md), respectively.
26
28
27
-
- The "C" locale is defined by ANSI to correspond to the locale in which C programs have traditionally executed. The code page for the "C" locale ("C" code page) corresponds to the ASCII character set. For example, in the "C" locale, **islower** returns true for the values 0x61 - 0x7A only. In another locale, **islower** may return true for these as well as other values, as defined by that locale.
29
+
- The "C" locale is defined by ANSI to correspond to the locale in which C programs have traditionally executed. The code page for the "C" locale ("C" code page) corresponds to the ASCII character set. For example, in the "C" locale, **islower** returns true for the values 0x61 - 0x7A only. In another locale, **islower** may return `true` for these and other values, as defined by that locale.
Copy file name to clipboardExpand all lines: docs/c-runtime-library/compatibility.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,7 @@
2
2
title: "Compatibility"
3
3
description: "Describes the compatibility of the Microsoft Universal C runtime library (UCRT) with the Standard C library, POSIX, the Safe CRT, and Store apps."
4
4
ms.date: "9/11/2020"
5
+
ms.topic: "conceptual"
5
6
helpviewer_keywords: ["CRT, compatibility", "compatibility, C runtime libraries", "compatibility"]
Copy file name to clipboardExpand all lines: docs/c-runtime-library/crt-initialization.md
+12-10Lines changed: 12 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,14 @@
1
1
---
2
2
title: "CRT Initialization"
3
+
description: "Describes how the CRT initializes global state in native code."
4
+
ms.topic: "conceptual"
3
5
ms.date: "11/04/2016"
4
6
helpviewer_keywords: ["CRT initialization [C++]"]
5
7
ms.assetid: e7979813-1856-4848-9639-f29c86b74ad7
6
8
---
7
9
# CRT Initialization
8
10
9
-
This topic describes how the CRT initializes global states in native code.
11
+
This topic describes how the CRT initializes global state in native code.
10
12
11
13
By default, the linker includes the CRT library, which provides its own startup code. This startup code initializes the CRT library, calls global initializers, and then calls the user-provided `main` function for console applications.
12
14
@@ -30,11 +32,11 @@ int main()
30
32
31
33
According to the C/C++ standard, `func()` must be called before `main()` is executed. But who calls it?
32
34
33
-
One way to determine this is to set a breakpoint in `func()`, debug the application, and examine the stack. This is possible because the CRT source code is included with Visual Studio.
35
+
One way to determine the caller is to set a breakpoint in `func()`, debug the application, and examine the stack. This is possible because the CRT source code is included with Visual Studio.
34
36
35
-
When you browse the functions on the stack, you will find that the CRT is looping through a list of function pointers and calling each one as it encounters them. These functions are either similar to `func()` or constructors for class instances.
37
+
When you browse the functions on the stack, you'll see that the CRT is calling a list of function pointers. These functions are similar to `func()`, or constructors for class instances.
36
38
37
-
The CRT obtains the list of function pointers from the Microsoft C++ compiler. When the compiler sees a global initializer, it generates a dynamic initializer in the `.CRT$XCU` section (where `CRT` is the section name and `XCU` is the group name). To obtain a list of those dynamic initializers run the command **dumpbin /all main.obj**, and then search the `.CRT$XCU` section (when main.cpp is compiled as a C++ file, not a C file). It will be similar to the following:
39
+
The CRT gets the list of function pointers from the Microsoft C++ compiler. When the compiler sees a global initializer, it generates a dynamic initializer in the `.CRT$XCU` section where `CRT` is the section name and `XCU` is the group name. To get a list of dynamic initializers, run the command **dumpbin /all main.obj**, and then search the `.CRT$XCU` section. This applies when main.cpp is compiled as a C++ file, not a C file. It will be similar to the following example:
00000000 DIR32 00000000 C ??__Egi@@YAXXZ (void __cdecl `dynamic initializer for 'gi''(void))
63
65
```
64
66
65
67
The CRT defines two pointers:
@@ -68,11 +70,11 @@ The CRT defines two pointers:
68
70
69
71
-`__xc_z` in `.CRT$XCZ`
70
72
71
-
Both groups do not have any other symbols defined except `__xc_a` and `__xc_z`.
73
+
Neither group has any other symbols defined except `__xc_a` and `__xc_z`.
72
74
73
75
Now, when the linker reads various `.CRT` groups, it combines them in one section and orders them alphabetically. This means that the user-defined global initializers (which the Microsoft C++ compiler puts in `.CRT$XCU`) will always come after `.CRT$XCA` and before `.CRT$XCZ`.
74
76
75
-
The section will resemble the following:
77
+
The section will resemble the following example:
76
78
77
79
```
78
80
.CRT$XCA
@@ -84,7 +86,7 @@ The section will resemble the following:
84
86
__xc_z
85
87
```
86
88
87
-
So, the CRT library uses both `__xc_a` and `__xc_z` to determine the start and end of the global initializers list because of the way in which they are laid out in memory after the image is loaded.
89
+
So, the CRT library uses both `__xc_a` and `__xc_z` to determine the start and end of the global initializers list because of the way in which they're laid out in memory after the image is loaded.
0 commit comments