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
Introduces a section of one or more export definitions that specify the exported names or ordinals of functions or data. Each definition must be on a separate line.
17
18
18
-
```
19
+
```DEF
19
20
EXPORTS
20
-
definition
21
+
definition
21
22
```
22
23
23
24
## Remarks
24
-
The first `definition` can be on the same line as the `EXPORTS` keyword or on a subsequent line. The .DEF file can contain one or more `EXPORTS` statements.
`entryname` is the function or variable name that you want to export. This is required. If the name that you export differs from the name in the DLL, specify the export's name in the DLL by using `internalname`. For example, if your DLL exports a function `func1` and you want callers to use it as `func2`, you would specify:
34
-
35
-
```
36
-
EXPORTS
37
-
func2=func1
38
-
```
39
-
40
-
Because the Visual C++ compiler uses name decoration for C++ functions, you must either use the decorated name as the `entryname` or `internalname`, or define the exported functions by using `extern "C"` in the source code. The compiler also decorates C functions that use the [__stdcall](../../cpp/stdcall.md) calling convention with an underscore (_) prefix and a suffix composed of the at sign (@) followed by the number of bytes (in decimal) in the argument list.
41
-
42
-
To find the decorated names produced by the compiler, use the [DUMPBIN](../../build/reference/dumpbin-reference.md) tool or the linker [/MAP](../../build/reference/map-generate-mapfile.md) option. The decorated names are compiler-specific. If you export the decorated names in the .DEF file, executables that link to the DLL must also be built by using the same version of the compiler. This ensures that the decorated names in the caller match the exported names in the .DEF file.
43
-
44
-
You can use @`ordinal` to specify that a number, and not the function name, will go into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don’t recommend exporting functions by ordinal unless your DLL’s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL.
45
-
46
-
By using the optional `NONAME` keyword, you can export by ordinal only and reduce the size of the export table in the resulting DLL. However, if you want to use [GetProcAddress](http://msdn.microsoft.com/library/windows/desktop/ms683212.aspx) on the DLL, you must know the ordinal because the name will not be valid.
47
-
48
-
The optional keyword `PRIVATE` prevents `entryname` from being included in the import library generated by LINK. It does not affect the export in the image also generated by LINK.
49
-
50
-
The optional keyword `DATA` specifies that an export is data, not code. This example shows how you could export a data variable named `exported_global`:
51
-
52
-
```
25
+
26
+
The first *definition* can be on the same line as the `EXPORTS` keyword or on a subsequent line. The .DEF file can contain one or more `EXPORTS` statements.
*entryname* is the function or variable name that you want to export. This is required. If the name that you export differs from the name in the DLL, specify the export's name in the DLL by using *internal_name*. For example, if your DLL exports a function `func1` and you want callers to use it as `func2`, you would specify:
35
+
36
+
```DEF
37
+
EXPORTS
38
+
func2=func1
39
+
```
40
+
41
+
If the name that you export is from other module, specify the export's name in the DLL by using *other_module.exported_name*. For example, if your DLL exports a function `other_module.func1` and you want callers to use it as `func2`, you would specify:
42
+
43
+
```DEF
44
+
EXPORTS
45
+
func2=other_module.func1
46
+
```
47
+
48
+
Because the Visual C++ compiler uses name decoration for C++ functions, you must either use the decorated name internal_name or define the exported functions by using extern "C" in the source code. The compiler also decorates C functions that use the [__stdcall](../../cpp/stdcall.md) calling convention with an underscore (_) prefix and a suffix composed of the at sign (@) followed by the number of bytes (in decimal) in the argument list.
49
+
50
+
To find the decorated names produced by the compiler, use the [DUMPBIN](../../build/reference/dumpbin-reference.md) tool or the linker [/MAP](../../build/reference/map-generate-mapfile.md) option. The decorated names are compiler-specific. If you export the decorated names in the .DEF file, executables that link to the DLL must also be built by using the same version of the compiler. This ensures that the decorated names in the caller match the exported names in the .DEF file.
51
+
52
+
You can use @*ordinal* to specify that a number, and not the function name, will go into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don’t recommend exporting functions by ordinal unless your DLL’s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL.
53
+
54
+
By using the optional `NONAME` keyword, you can export by ordinal only and reduce the size of the export table in the resulting DLL. However, if you want to use [GetProcAddress](http://msdn.microsoft.com/library/windows/desktop/ms683212.aspx) on the DLL, you must know the ordinal because the name will not be valid.
55
+
56
+
The optional keyword `PRIVATE` prevents *entryname* from being included in the import library generated by LINK. It does not affect the export in the image also generated by LINK.
57
+
58
+
The optional keyword `DATA` specifies that an export is data, not code. This example shows how you could export a data variable named `exported_global`:
59
+
60
+
```DEF
53
61
EXPORTS
54
-
exported_global DATA
62
+
exported_global DATA
55
63
```
56
64
57
-
There are four ways to export a definition, listed in recommended order:
65
+
There are four ways to export a definition, listed in recommended order:
58
66
59
67
1. The [__declspec(dllexport)](../../cpp/dllexport-dllimport.md) keyword in the source code
60
68
@@ -64,11 +72,11 @@ EXPORTS
64
72
65
73
4. A [comment](../../preprocessor/comment-c-cpp.md) directive in the source code, of the form `#pragma comment(linker, "/export: definition ")`
66
74
67
-
All four methods can be used in the same program. When LINK builds a program that contains exports, it also creates an import library, unless an .EXP file is used in the build.
75
+
All four methods can be used in the same program. When LINK builds a program that contains exports, it also creates an import library, unless an .EXP file is used in the build.
68
76
69
-
Here's an example of an EXPORTS section:
77
+
Here's an example of an EXPORTS section:
70
78
71
-
```
79
+
```DEF
72
80
EXPORTS
73
81
DllCanUnloadNow @1 PRIVATE
74
82
DllWindowName = WindowName DATA
@@ -77,7 +85,8 @@ EXPORTS
77
85
DllUnregisterServer
78
86
```
79
87
80
-
When you export a variable from a DLL by using a .DEF file, you do not have to specify `__declspec(dllexport)` on the variable. However, in any file that uses the DLL, you must still use `__declspec(dllimport)` on the declaration of data.
88
+
When you export a variable from a DLL by using a .DEF file, you do not have to specify `__declspec(dllexport)` on the variable. However, in any file that uses the DLL, you must still use `__declspec(dllimport)` on the declaration of data.
81
89
82
-
## See Also
83
-
[Rules for Module-Definition Statements](../../build/reference/rules-for-module-definition-statements.md)
90
+
## See also
91
+
92
+
[Rules for Module-Definition Statements](../../build/reference/rules-for-module-definition-statements.md)
Copy file name to clipboardExpand all lines: docs/data/oledb/accessing-xml-data.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,21 +25,21 @@ There are two separate methods of retrieving XML data from a data source: one us
25
25
## Retrieving XML Data Using CStreamRowset
26
26
You specify [CStreamRowset](../../data/oledb/cstreamrowset-class.md) as the rowset type in your `CCommand` or `CTable` declaration. You can use it with your own accessor or no accessor, for example:
Normally when you call `CCommand::Open` (specifying, for example, `CRowset` as the `TRowset` class), it obtains an `IRowset` pointer. `ICommand::Execute` returns an `IRowset` pointer, which is stored in the `m_spRowset` member of the `CRowset` object. Methods such as `MoveFirst`, `MoveNext`, and `GetData` use that pointer to retrieve the data.
39
39
40
40
By contrast, when you call `CCommand::Open` (but specify `CStreamRowset` as the `TRowset` class), `ICommand::Execute` returns an `ISequentialStream` pointer, which is stored in the `m_spStream` data member of [CStreamRowset](../../data/oledb/cstreamrowset-class.md). You then use the `Read` method to retrieve the (Unicode string) data in XML format. For example:
41
41
42
-
```
42
+
```cpp
43
43
myCmd.m_spStream->Read()
44
44
```
45
45
@@ -55,13 +55,13 @@ myCmd.m_spStream->Read()
55
55
56
56
Use `CXMLAccessor` as you would any other accessor class, passing it as a template parameter to `CCommand` or `CTable`:
57
57
58
-
```
58
+
```cpp
59
59
CTable<CXMLAccessor, CRowset> rs;
60
60
```
61
61
62
62
Use [GetXMLRowData](../../data/oledb/cxmlaccessor-getxmlrowdata.md) to retrieve data from the table one row at a time, and navigate rows using methods such as `MoveNext`, for example:
@@ -104,24 +96,24 @@ Gets column information from the opened rowset.
104
96
### Syntax
105
97
106
98
```cpp
107
-
HRESULT GetColumnInfo(DBORDINAL* pulColumns,
108
-
DBCOLUMNINFO** ppColumnInfo,
109
-
LPOLESTR* ppStrings) const;
110
-
111
-
HRESULT GetColumnInfo(DBORDINAL* pColumns,
99
+
HRESULT GetColumnInfo(DBORDINAL* pulColumns,
100
+
DBCOLUMNINFO** ppColumnInfo,
101
+
LPOLESTR* ppStrings) const;
102
+
103
+
HRESULT GetColumnInfo(DBORDINAL* pColumns,
112
104
DBCOLUMNINFO** ppColumnInfo);
113
105
```
114
106
115
107
#### Parameters
116
-
See [IColumnsInfo::GetColumnInfo](https://msdn.microsoft.com/en-us/library/ms722704.aspx) in the *OLE DB Programmer's Reference*.
108
+
See [IColumnsInfo::GetColumnInfo](https://msdn.microsoft.com/library/ms722704.aspx) in the *OLE DB Programmer's Reference*.
117
109
118
110
### Return Value
119
111
A standard HRESULT.
120
112
121
113
### Remarks
122
114
The user must free the returned column information and string buffer. Use the second version of this method when you use [CDynamicAccessor](../../data/oledb/cdynamicaccessor-class.md) and need to override the bindings.
123
115
124
-
For more information, see [IColumnsInfo::GetColumnInfo](https://msdn.microsoft.com/en-us/library/ms722704.aspx) in the *OLE DB Programmer's Reference*.
116
+
For more information, see [IColumnsInfo::GetColumnInfo](https://msdn.microsoft.com/library/ms722704.aspx) in the *OLE DB Programmer's Reference*.
125
117
126
118
## See Also
127
119
[OLE DB Consumer Templates](../../data/oledb/ole-db-consumer-templates-cpp.md)
0 commit comments