Certainly not... they are the standard runtime libraries. They come with your compiler and do not change.
You can download the dlls that are missing here
avoiding the .NET framework?
quote:Original post by DeetsHeader files know nothing about DLLs. DLLs are specified in project settings or makefiles. Certain environments (eg MSVS) allow the specification of static link libraries via non-portable extensions such as #pragma comment <library file>.
That, as far as I know, is done in the proper *.h files, that call the proper *.dll file.
quote:Original post by twix
Hopefully, at some point everyone will have a copy of the .NET framework installed already. Probably when Longhorn is released.
what a weird name for an OS. Isn''t it the codename?
Excuse me, but out of the Help File of my VS.Net, if I may:
An executable file links to (or loads) a DLL in one of two ways:
„h Implicit linking
„h Explicit linking
Note Implicit linking is sometimes referred to as static load or load-time dynamic linking. Explicit linking is sometimes referred to as dynamic load or run-time dynamic linking.
With implicit linking, the executable using the DLL links to an import library (.LIB file) provided by the maker of the DLL. The operating system loads the DLL when the executable using it is loaded. The client executable calls the DLL''s exported functions just as if the functions were contained within the executable.
With explicit linking, the executable using the DLL must make function calls to explicitly load and unload the DLL, and to access the DLL''s exported functions. The client executable must call the exported functions through a function pointer.
An executable can use the same DLL with either linking method. Furthermore, these mechanisms are not mutually exclusive, as one executable can implicitly link to a DLL and another can attach to it explicitly.
What do you want to know more about?
„h Determining which linking method to use
„h The search path used by Windows to locate a DLL
See Also
DLLs
With both implicit and explicit linking, Windows first searches the set of pre-installed DLLs such as the performance library (KERNEL32.DLL) and the security library (USER32.DLL). Windows then searches for the DLLs in the following sequence:
1. The directory where the executable module for the current process is located.
2. The current directory.
3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
5. The directories listed in the PATH environment variable.
Note The LIBPATH environment variable is not used.
What do you want to do?
„h Link implicitly
„h Link explicitly
„h Determine which linking method to use
See Also
DLLs
To implicitly link to a DLL, executables must obtain the following from the provider of the DLL:
„h A header file (.H file) containing the declarations of the exported functions and/or C++ classes.
„h An import library (.LIB files) to link with. (The linker creates the import library when the DLL is built.)
„h The actual DLL (.DLL file).
Executables using the DLL must include the header file containing the exported functions (or C++ classes) in each source file that contains calls to the exported functions. From a coding perspective, the function calls to the exported functions are just like any other function call.
To build the calling executable file, you must link with the import library. If you are using an external makefile, specify the file name of the import library where you list other object (.OBJ) files or libraries that you are linking with.
The operating system must be able to locate the .DLL file when it loads the calling executable.
With explicit linking, applications must make a function call to explicitly load the DLL at run time. To explicitly link to a DLL, an application must:
„h Call LoadLibrary (or a similar function) to load the DLL and obtain a module handle.
„h Call GetProcAddress to obtain a function pointer to each exported function that the application wants to call. Because applications are calling the DLL''s functions through a pointer, the compiler does not generate external references, so there is no need to link with an import library.
„h Call FreeLibrary when done with the DLL.
Out of Microsoft, but back to something else, I got work to do.
An executable file links to (or loads) a DLL in one of two ways:
„h Implicit linking
„h Explicit linking
Note Implicit linking is sometimes referred to as static load or load-time dynamic linking. Explicit linking is sometimes referred to as dynamic load or run-time dynamic linking.
With implicit linking, the executable using the DLL links to an import library (.LIB file) provided by the maker of the DLL. The operating system loads the DLL when the executable using it is loaded. The client executable calls the DLL''s exported functions just as if the functions were contained within the executable.
With explicit linking, the executable using the DLL must make function calls to explicitly load and unload the DLL, and to access the DLL''s exported functions. The client executable must call the exported functions through a function pointer.
An executable can use the same DLL with either linking method. Furthermore, these mechanisms are not mutually exclusive, as one executable can implicitly link to a DLL and another can attach to it explicitly.
What do you want to know more about?
„h Determining which linking method to use
„h The search path used by Windows to locate a DLL
See Also
DLLs
With both implicit and explicit linking, Windows first searches the set of pre-installed DLLs such as the performance library (KERNEL32.DLL) and the security library (USER32.DLL). Windows then searches for the DLLs in the following sequence:
1. The directory where the executable module for the current process is located.
2. The current directory.
3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
5. The directories listed in the PATH environment variable.
Note The LIBPATH environment variable is not used.
What do you want to do?
„h Link implicitly
„h Link explicitly
„h Determine which linking method to use
See Also
DLLs
To implicitly link to a DLL, executables must obtain the following from the provider of the DLL:
„h A header file (.H file) containing the declarations of the exported functions and/or C++ classes.
„h An import library (.LIB files) to link with. (The linker creates the import library when the DLL is built.)
„h The actual DLL (.DLL file).
Executables using the DLL must include the header file containing the exported functions (or C++ classes) in each source file that contains calls to the exported functions. From a coding perspective, the function calls to the exported functions are just like any other function call.
To build the calling executable file, you must link with the import library. If you are using an external makefile, specify the file name of the import library where you list other object (.OBJ) files or libraries that you are linking with.
The operating system must be able to locate the .DLL file when it loads the calling executable.
With explicit linking, applications must make a function call to explicitly load the DLL at run time. To explicitly link to a DLL, an application must:
„h Call LoadLibrary (or a similar function) to load the DLL and obtain a module handle.
„h Call GetProcAddress to obtain a function pointer to each exported function that the application wants to call. Because applications are calling the DLL''s functions through a pointer, the compiler does not generate external references, so there is no need to link with an import library.
„h Call FreeLibrary when done with the DLL.
Out of Microsoft, but back to something else, I got work to do.
And if you ever want to use the Managed Extensions to include the Net Framework, that can also be done.
But:
C/C++ Preprocessor Reference
managed, unmanagedSee Also
Pragma Directives
#pragma managed
#pragma unmanaged
The /clr compiler option provides module-level control for compiling functions either as managed or unmanaged. The managed and unmanaged pragmas enable function-level control for compiling functions as managed or unmanaged.
An unmanaged function will be compiled for the native platform, and execution of that portion of the program will be passed to the native platform by the common language runtime.
Functions are managed by default when /clr is used. The compiler ignores the managed and unmanaged pragmas if /clr is not used in the compilation.
Example
// pragma_directives_managed_unmanaged.cpp
// compile with: /clr
#using
#include <stdio.h>
// func1 is managed
void func1(void)
{
System::Console::WriteLine("In managed function.\n");
}
#pragma unmanaged
// func2 is unmanaged
void func2(void)
{
printf("In unmanaged function.\n");
}
#pragma managed
// main is managed
void main()
{
func1();
func2();
}
Output
In managed function.
In unmanaged function.
See Also
Pragma Directives
--------------------------------------------------------------------------------
Send feedback to Microsoft
© 2001 Microsoft Corporation. All rights reserved.
But most games, will use unmanaged code, since that is like old programming with Visual Studio, I guess, before Microsoft had this bright idea.
But:
C/C++ Preprocessor Reference
managed, unmanagedSee Also
Pragma Directives
#pragma managed
#pragma unmanaged
The /clr compiler option provides module-level control for compiling functions either as managed or unmanaged. The managed and unmanaged pragmas enable function-level control for compiling functions as managed or unmanaged.
An unmanaged function will be compiled for the native platform, and execution of that portion of the program will be passed to the native platform by the common language runtime.
Functions are managed by default when /clr is used. The compiler ignores the managed and unmanaged pragmas if /clr is not used in the compilation.
Example
// pragma_directives_managed_unmanaged.cpp
// compile with: /clr
#using
#include <stdio.h>
// func1 is managed
void func1(void)
{
System::Console::WriteLine("In managed function.\n");
}
#pragma unmanaged
// func2 is unmanaged
void func2(void)
{
printf("In unmanaged function.\n");
}
#pragma managed
// main is managed
void main()
{
func1();
func2();
}
Output
In managed function.
In unmanaged function.
See Also
Pragma Directives
--------------------------------------------------------------------------------
Send feedback to Microsoft
© 2001 Microsoft Corporation. All rights reserved.
But most games, will use unmanaged code, since that is like old programming with Visual Studio, I guess, before Microsoft had this bright idea.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement