Include Headers and Libraries Manually

In this exercise, you will practice how to explicitly include headers and libraries into your project. This is also called loading DOM «raw». This example is functionally identical to the Load an XML DOM Object from an XML File (C/C++) example that follows it. The only difference is the way these headers and libraries are included.

This project uses or creates the following files.

Component	Description
Source: loadDOMRaw.cpp	Creates an XML DOM object and loads the resource file into the project’s main directory.
Resource: stocks.xml	An XML data file.
Output	This is the output you should get when you build and run the loadDOMRaw project.

To create the loadDOMRaw Visual C++ Project

1. Create a C++ Win32 console application in Visual Studio 2008. For detailed instructions on how to do this, see Set Up My Visual C++ Project. Name the project LoadDOMRawProj.

To include headers and libraries manually

Locate the SDK directory installed by the appropriate MSXML package. By default for MSXML 6.0, your directory will be C:\Program Files\MSXML 6.0, with subdirectories named inc and lib.

Set up the include directory for Visual Studio. From the Tools menu, select Options. In the Options dialog box, expand Projects and Solutions. Select VC++ Directories. Select Include files in the Show directories for drop down box. Click the New Line button, and add a new line to the list of directories. Browse to the directory that contains the MSXML header file. For MSXML 6.0, by default, the directory is C:\Program Files\MSXML 6.0\inc. Click OK.

Set up the lib directory for Visual Studio. From the Tools menu, select Options. In the Options dialog box, expand Projects and Solutions. Select VC++ Directories. Select Library files in the Show directories for drop down box. Click the New Line button, and add a new line to the list of directories. Browse to the directory that contains the MSXML libraries. For MSXML 6.0, by default, the directory is C:\Program Files\MSXML 6.0\lib. Click OK.

Modify the project to link with the MSXML 6.0 library. In the Solution Explorer, right click on the project and select Properties. In the tree, expand Configuration Properties, and then expand Linker. Under Linker, click on Command Line. Enter msxml6.lib in the Additional options text box.

Include the required MSXML header file by adding the following preprocessor directives to the source code:

You need to include the appropriate header file for the version of MSXML that you want to use. For an explanation about which header files to include, and which libraries to link to, see Building MSXML Applications.

Next, we’ll add the source code for this project.

Libraries and Headers

Kernel-mode drivers use the native system services routines by calling the Nt and Zw entry points in the Ntoskrnl.exe dynamic link library (DLL). This DLL contains the actual implementations of these routines. To access these entry points, a driver statically links to the Ntoskrnl.lib library, which is available in the Windows Driver Kit (WDK). The routines that are implemented in Ntoskrnl.lib are stubs that dynamically link to the entry points in Ntoskrnl.exe at run time.

The WDK documentation describes some, but not all, of the Zw entry points in Ntoskrnl.exe. For descriptions of the Zw routines that can be called by drivers, see ZwXxx Routines.

Most of the documented Zw routines are defined in the Wdm.h header file in the WDK, but a few are defined in other header files, such as Ntddk.h and Ntifs.h.

Typically, user-mode applications do not call the Nt and Zw routines. Instead, an application might call a Win32 routine, such as CreateFile, which then calls a native system services routine, such as NtCreateFile or ZwCreateFile, to perform the requested operation. However, a user-mode application might directly call an Nt or Zw routine to perform an operation that is not supported by the Win32 routines.

User-mode applications use the native system services routines by calling the entry points in the Ntdll.dll dynamic link library. These entry points convert calls to Nt and Zw routines into system calls that are trapped to kernel mode. To access these entry points, a user-mode application statically links to the Ntdll.lib library, which is available in the WDK. The routines that are implemented in Ntdll.lib are stubs that dynamically link to the entry points in Ntdll.dll at run time.

The Windows SDK documentation describes some, but not all, of the Nt entry points in Ntdll.lib. Most of the documented Nt routines are defined in the Winternl.h header file in the Windows SDK. This documentation makes little mention of the Zw entry points, and no header files in the Windows SDK contain definitions of Zw routines.

With a couple of minor exceptions, each entry point in Ntdll.dll for an Nt routine has a matching entry point for a Zw routine. The documentation for the WDK and Windows SDK recommends that application developers avoid calling undocumented Nt entry points, and warns that the Zw entry points might disappear from Ntdll.dll in a future version of Windows. Application developers who call the Zw routines from user mode should be prepared for this occurrence.

For descriptions of the Nt routines that can be called by applications, see Winternl, Files, and Miscellaneous Low-Level Client Support. Some reference pages for Nt routines in the Windows SDK documentation label the routines as «deprecated» and advise readers to use the equivalent Win32 routines instead of the deprecated Nt routines.

Media Foundation Headers and Libraries

This topic lists the headers and libraries that define all of the Media Foundation APIs.

To find the header and library for a specific API element, consult the reference pages in the Media Foundation Programming Reference.

Headers

• codecapi.h
• d3d11.h
• d3d9.h
• d3d9caps.h
• d3d9types.h
• dxva.h
• dxva2api.h
• dxvahd.h
• evr.h
• evr9.h
• mfapi.h
• mfcaptureengine.h
• mferrors.h
• mfidl.h
• mfmediacapture.h
• mfmediaengine.h
• mfmp2dlna.h
• mfobjects.h
• mfplat.lib
• mfplay.h
• mfreadwrite.h
• mftransform.h
• opmapi.h
• wmcodecdsp.h
• wmcontainer.h

Libraries

• dxva2.lib
• evr.lib
• mf.lib
• mfplat.lib
• mfplay.lib
• mfreadwrite.lib
• mfuuid.lib

Library Changes in Windows 7

Starting in WindowsВ 7, certain Media Foundation functions are exported from different DLL files than previous versions.

These changes affect the following .lib files:

An application that uses any of these functions must link to a different set of .lib files, depending on the SDK version and the target platform.

SDK Version	Libraries
Windows SDK for WindowsВ Vista Windows SDK for Windows ServerВ 2008	evr.lib mf.lib mfplat.lib
Windows SDK for WindowsВ 7	If the target platform is WindowsВ Vista or Windows ServerВ 2008, link the following libraries: evr_vista.lib mf_vista.lib mfplat_vista.lib If the target platform is WindowsВ 7 or later, link the following libraries: evr.lib mf.lib mfplat.lib

Additional Info on Helper Functions

The WindowsВ 8 MFPlat.dll is a component of the MicrosoftВ Windows operating system. It has several functions included in the module.

MFPlat implements helper functionality for low level memory allocation, operation scheduling FIFOs, and win32 file access abstractions. To be more specific, it provides support for the following:

• allocating and initializing memory buffers (known as ‘samples’) and helpers to simplify managing their lifetimes
• efficient Data copying functions for memory buffers
• allocating and initializing operation FIFOs (known as ‘events’)
• implementing a simple clock object
• implementing a win32 file wrapper
• allocating and initializing arrays of memory buffers for CPUs and GPUs

If the MFStartup method succeeds, MFPlat provides the following work queue functionality:

• internally supporting I/O items (as used by the win32 file wrapper and socket libraries)
• providing an array of multithreaded work queues with thread priority support
• supporting work items, timer items, and wait items through the work queues

MFPlat provides helper functionality for finding and creating media transforms and media sources registered on the system, and creating and manipulating media types, though MFPlat itself cannot create the actual media nor play it back.

Header Files and Libraries

Do I really need header files for using libraries?My code works without header files and the libraries are linked perfectly except that I get a «warning: implicit declaration of function» message.Still its just a warning my program runs.

4 Answers 4

Header file:- is a file that allows programmers to separate certain elements of a program’s source code into reusable files.

A library file is the executable code that works according to what is specified in the header file.

I get a «warning: implicit declaration of function» message.

There may be many reasons for this warning like maybe your header guard is not working right. Another possibility is that you have declared the function Func but called it with func .

Including a header file is equal to copying the content of the header file but we do not do it because it will be very much error-prone and it is not a good idea to copy the content of header file in the source files, specially if we have multiple source file comprising our program.

For most of the starters this warning is seen when they start using

So I am using this example. For the warning in this case You need to add:

This file includes the declaration for the built-in function malloc . If you don’t do that, the compiler thinks you want to define your own function named malloc and it warns you because:

1. You don’t explicitly declare it and
2. There already is a built-in function by that name which has a different signature than the one that was implicitly declared (when a function is declared implicitly, its return and argument types are assumed to be int , which isn’t compatible with the built-in malloc , which takes a size_t and returns a void* ).

My code works without header files and the libraries are linked perfectly except that I get a «warning: implicit declaration of function» message.Still its just a warning my program runs.

It is a bad practice to ignore a warning from the compiler. Programs that are not compiled properly could have bugs that might cause you bigger problems and errors in the future.

So for example, if you get a warning:

It is expected that you must include the header file wherein that function is defined.

Do I really need header files for using libraries?

My code works without header files

No, it doesn’t. It only appears to be working.

and the libraries are linked perfectly except that I get a «warning: implicit declaration of function» message

In this case, I wouldn’t call it «perfect».

Still its just a warning my program runs.

And you can never know what it does since it now invokes undefined behavior. «Just a warning»? Sure. There’s a reason the compiler warns you. Respect warnings and fix them.

Here’s the quote from C99 (6.5.2.2.6) which explains why the program has UB without headers (more precisely, without proper function prototypes which you don’t seem to have either):

1. If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions. If the number of arguments does not equal the number of parameters, the behavior is undefined.

If the function is defined with a type that includes a prototype, and either the prototype ends with an ellipsis (, . ) or the types of the arguments after promotion are not compatible with the types of the parameters, the behavior is undefined.

If the function is defined with a type that does not include a prototype, and the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined, except for the following cases:

— one promoted type is a signed integer type, the other promoted type is the corresponding unsigned integer type, and the value is representable in both types;

— both types are pointers to qualified or unqualified versions of a character type or void.

There’s a very good reason header files are used. People who invented and designed the language knew what they were doing, and they made this decision because it’s a necessary thing and a good solution to the problem that types need to be visible across compilation units.