How to open a URL in the default web browser?

This is easily done by calling ShellExecute() HTTP and FTP URLs should be processed by both Netscape and IE: the "default" browser will handle them. Other protocols such as mailto and news may also handled by the browser. IE4 adds handlers for things like "Callto:" for Net Meeting contacts.

#include "windows.h"

 #include "shellapi.h"

 //link in the library

#pragma comment(lib,"shell32.lib")

int main(int argc, char *const argv[])

{

    ShellExecute(NULL,"open", "http://coderdreambook.blogspot.in/", "", "c:\\", SW_SHOWNORMAL);

    return 0;

}

MD vs MT options to use Run-Time Library

 -> /MD, /MT these options, you can select either single-threaded or multi threaded run-time routines, indicate that a multi threaded module is a dynamic-link library (DLL), and select the retail or debug version of the library.

Note:

Having more than one copy of the run-time libraries in a process can cause problems, because static data in one copy is not shared with the other copy. To ensure that your process contains only one copy, avoid mixing static and dynamic versions of the run-time libraries. The linker will prevent you from linking with both static and dynamic versions within one .EXE file, but you can still end up with two (or more) copies of the run-time libraries. For example, a dynamic-link library linked with the static (non-DLL) versions of the run-time libraries can cause problems when used with an .EXE file that was linked with the dynamic (DLL) version of the run-time libraries. (You should also avoid mixing the debug and non-debug versions of the libraries in one process.)

Command Line	Project Settings	Description
/MD	Multithreaded DLL	Defines _MT and _DLL so that both multithread- and DLL-specific versions of the run-time routines are selected from the standard .H files. This option also causes the compiler to place the library name MSVCRT.LIB into the .OBJ file. Applications compiled with this option are statically linked to MSVCRT.LIB. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCRT.DLL, which must be available at run time to applications linked with MSVCRT.LIB.
/MDd	Debug Multithreaded DLL	Defines _DEBUG, _MT, and _DLL so that debug multithread- and DLL-specific versions of the run-time routines are selected from the standard .H files. It also causes the compiler to place the library name MSVCRTD.LIB into the .OBJ file.
/ML	Single-Threaded	Causes the compiler to place the library name LIBC.LIB into the .OBJ file so that the linker will use LIBC.LIB to resolve external symbols. This is the compiler’s default action. LIBC.LIB does not provide multithread support.
/MLd	Debug Single-Threaded	Defines _DEBUG and causes the compiler to place the library name LIBCD.LIB into the .OBJ file so that the linker will use LIBCD.LIB to resolve external symbols. LIBCD.LIB does not provide multithread support.
/MT	Multithreaded	Defines _MT so that multithread-specific versions of the run-time routines are selected from the standard header (.H) files. This option also causes the compiler to place the library name LIBCMT.LIB into the .OBJ file so that the linker will use LIBCMT.LIB to resolve external symbols. Either /MT or /MD (or their debug equivalents /MTd or /MDd) is required to create multithreaded programs.
/MTd	Debug Multithreaded	Defines _DEBUG and _MT. Defining _MT causes multithread-specific versions of the run-time routines to be selected from the standard .H files. This option also causes the compiler to place the library name LIBCMTD.LIB into the .OBJ file so that the linker will use LIBCMTD.LIB to resolve external symbols. Either /MTd or /MDd (or their non-debug equivalents /MT or MD) is required to create multithreaded programs.
/LD	Not applicable	Creates a DLL. Passes the /DLL option to the linker. The linker looks for, but does not require, aDllMain function. If you do not write a DllMain function, the linker inserts a DllMainfunction that returns TRUE. Links the DLL startup code. Creates an import library (.LIB), if an export (.EXP) file is not specified on the command line; you link the import library to applications that call your DLL. Interprets /Fe as naming a DLL rather than an .EXE file; the default program name becomes basename.DLL instead of basename.EXE. Changes default run-time library support to /MT if you have not explicitly specified one of the /M options
/LDd	Not applicable	Creates a debug DLL. Defines _DEBUG.

To find these options in the development environment, click Settings on the Project menu. Then click the C/C++ tab, and click Code Generation in theCategory box. See the Use Run-Time Library drop-down box.

The debug options select the debug versions of the library or DLL and define _DEBUG. For more information on using the debug versions, see C Run-Time Debug Libraries.

Run-Time Library Behavior:

The C/C++ run-time library code performs the DLL startup sequence, eliminating the need to link with a separate module as was necessary in Windows 3.x. Included in the C/C++ run-time library code is the DLL entry-point function called _DllMainCRTStartup. The _DllMainCRTStartup function does several things, including calling CRT_INIT, which initializes the C/C++ run-time library and invokes C++ constructors on static, non-local variables. Without this function, the run-time library would be left in an uninitialized state.

While it is possible to specify another entry-point function using the /ENTRY: linker switch, it is not recommended because your entry-point function would have to duplicate everything that _DllMainCRTStartup does. 

When building DLLs in Visual C++, _DllMainCRTStartup is linked in automatically and you do not need to specify an entry-point function using the /ENTRY: linker switch .

In addition to initializing the C run-time library, _DllMainCRTStartup calls a function called DllMain. Depending on the kind of DLL you are building, Visual C++ provides DllMain for you and it gets linked in so that _DllMainCRTStartup always has something to call. In this way, if you do not need to initialize your DLL, there's nothing special you have to do when building your DLL. If you need to initialize your DLL, where you add your code depends on the kind of DLL you are writing. See Initialize a DLL for more information.

The C/C++ run-time library code calls constructors and destructors on static, non-local variables. For example, in the following DLL source code, Equus andSugar are two static, non-local objects of class CHorse, defined in HORSES.H. There is no function in source code that contains calls to a constructor function for CHorse or to the destructor function because these objects are defined outside of any function. Therefore, calls to these constructors and destructors must be performed by the run-time code. (The run-time library code for applications also performs this function.)

#include "horses.h"

CHorse  Equus( ARABIAN, MALE );
CHorse  Sugar( THOROUGHBRED, FEMALE );

BOOL    WINAPI   DllMain (HANDLE hInst,
                            ULONG ul_reason_for_call,
                            LPVOID lpReserved)
.
.
.

Each time a new process attempts to use the DLL, the operating system creates a separate copy of the DLL's data: this is called "process attach". The run-time library code for the DLL calls the constructors for all the global objects, if any, and then calls the DllMain function with process attach selected. The opposite situation is process detach: the run-time library code calls DllMain with process detach selected and then calls a list of termination functions including atexit functions, destructors for the global objects, and destructors for the static objects. Note that the order of events in process attach is the reverse of that in process detach.

The run-time library code is also called during thread attach and thread detach, but the run-time code does no initialization or termination on its own.

Linking with MD has advantages:

1 - Different modules (i.e. DLLs or EXEs) can exchange "memory ownership". For example, a memory allocated through new/malloc in one module can be reallocated/deleted/freed by another. This is very helpful if you use STL in the interface between your modules.
2 - The runtime has some "global data". Linking with MT means that this "global data" will not be shared, while with MD, it will be shared. This means that with MD, you can pass some data from one module to another without risk.
3 - your executable can be smaller (since it doesn't have the library embedded in it), and I believe that at very least the code segment of a DLL is shared amongst all processes that are actively using it (reducing the total amount of RAM consumed).

Linking with MD has disadvantages:

1. while a module compiled with MD will link with a DLL at the moment of execution. if DLL will not found in the machine then your application will be crashed.

Linking with MT has advantages:

1. If you use /MT, your executable won't depend on a DLL being present on the target system. If you're wrapping this in an installer, it probably won't be an issue and you can go either way.

I use /MT myself, so that I can ignore the whole DLL mess.   Module you compiled with MT will have the runtime "inside it", while a module compiled with MD will link with a DLL at the moment of execution.

Note:

->Anyway, a release and debug versions of the same module should link with the same category of runtime. If your release links with MT, then your debug should link with MTd. In the same way, if your release links with MD, your debug should link with MDd.

-> Now, you should avoid mixing in the same process different modules linked with different run times (Note that the release and debug run times are different run times). violating this rule could lead to mysterious crashes.

For example, say you have MyExe.exe which links with MyDll.dll : You should avoid mixing a release version of MyExe.exe and an debug version of MyDllD.dll. In the same way, you should avoid mixing a MT compiled MyExe.exe and a MD compiled MyDll.dll.

-> I've also found that in practice, when working with statically-linked 3rd-party binary-only libraries that have been built with different runtime options, /MT in the main application tends to cause conflicts much more often than /MD (because you'll run into trouble if the C runtime is statically-linked multiple times, especially if they are different versions).

-> Typical solutions to this are to have the user install the appropriate MSVC redistributable package, or use an installer that does all the work

-> I believe the default for projects built through Visual Studio is /MD.

-> If you are using DLLs then you should go for the dynamically linked CRT (/MD).

-> If you use the dynamic CRT for your .exe and all .dlls then they will all share a single implementation of the CRT - which means they will all share a single CRT heap and memory allocated in one .exe/.dll can be freed in another.

-> If you use the static CRT for your .exe and all .dlls then they'll all get a seperate copy of the CRT - which means they'll all use their own CRT heap so memory must be freed in the same module in which it was allocated. You'll also suffer from code bloat (multiple copies of the CRT) and excess runtime overhead (each heap allocates memory from the OS to keep track of its state, and the overhead can be noticeable).

__stdcall vs __cdecl.

During the long, hard, but yet beautiful process of learning C++ programming for Windows, you have probably been curious about the strange specifiers that sometime appear in front of function declarations, like __cdecl, __stdcall,__fastcall, WINAPI, etc. After looking through MSDN, or some other reference, you probably found out that these specifiers specify the calling conventions for functions. In this article, I will try to explain different calling conventions used by Visual C++ (and probably other Windows C/C++ compilers). 

Traditionally, C function calls are made with the caller pushing some parameters onto the stack, calling the function, and then popping the stack to clean up those pushed arguments.

/* example of __cdecl */
push arg1
push arg2
push arg3
call function
add sp,12 // effectively "pop; pop; pop"

Note: The default convention — shown above — is known as __cdecl.

The other most popular convention is __stdcall. In it the parameters are again pushed by the caller, but the stack is cleaned up by the callee. It is the standard convention for Win32 API functions (as defined by the WINAPI macro in <windows.h>), and it's also sometimes called the "Pascal" calling convention.
/* example of __stdcall */
push arg1 
push arg2 
push arg3 
call function // no stack cleanup - callee does this

This looks like a minor technical detail, but if there is a disagreement on how the stack is managed between the caller and the callee, the stack will be destroyed in a way that is unlikely to be recovered.
Since __stdcall does stack cleanup, the (very tiny) code to perform this task is found in only one place, rather than being duplicated in every caller as it is in__cdecl. This makes the code very slightly smaller, though the size impact is only visible in large programs.

Variadic functions like printf() are almost impossible to get right with__stdcall, because only the caller really knows how many arguments were passed in order to clean them up. The callee can make some good guesses (say, by looking at a format string), but the stack cleanup would have to be determined by the actual logic of the function, not the calling-convention mechanism itself. Hence only __cdecl supports variadic functions so that the caller can do the cleanup.       

Linker symbol name decorations:
As mentioned in a bullet point above, calling a function with the "wrong" convention can be disastrous, so Microsoft has a mechanism to avoid this from happening. It works well, though it can be maddening if one does not know what the reasons are.
They have chosen to resolve this by encoding the calling convention into the low-level function names with extra characters (which are often called "decorations"), and these are treated as unrelated names by the linker. The default calling convention is__cdecl, but each one can be requested explicitly with the /G? parameter to the compiler.

__cdecl   (cl /Gd ...)

All function names of this type are prefixed with an underscore, and the number of parameters does not really matter because the caller is responsible for stack setup and stack cleanup. It is possible for a caller and callee to be confused over the number of parameters actually passed, but at least the stack discipline is maintained properly.

__stdcall   (cl /Gz ...)
These function names are prefixed with an underscore and appended with the number of bytes of parameters passed. By this mechanism, it's not possible to call a function with the "wrong" type, or even with the wrong number of parameters.

__fastcall   (cl /Gr ...)
These function names start with an @ sign and are suffixed with the @parameter count, much like 

__stdcall.
Examples:
Declaration                            decorated name
----------------------------------------------------
void __cdecl    foo(void);               _foo
void __cdecl    foo(int a);               _foo
void __cdecl    foo(int a, int b);      _foo
void __stdcall  foo(void);             _foo@0
void __stdcall  foo(int a);             _foo@4
void __stdcall   foo(int a, int b);       _foo@8
void __fastcall   foo(void);              @foo@0
void __fastcall   foo(int a);             @foo@4
void __fastcall   foo(int a, int b);     @foo@8

We'll note that the decorated names are never visible to a C program: they are strictly a linker facility, and the linker will never resolve one kind of reference with the "wrong" one.

C calling convention (__cdecl)
This convention is the default for C/C++ programs (compiler option /Gd). If a project is set to use some other calling convention, we can still declare a function to use __cdecl:

int __cdecl sumExample (int a, int b);

The main characteristics of __cdecl calling convention are:
1. Arguments are passed from right to left, and placed on the stack.
2. Stack cleanup is performed by the caller.
3. Function name is decorated by prefixing it with an underscore character '_' .

Standard calling convention (__stdcall)
This convention is usually used to call Win32 API functions. In fact, WINAPI is nothing but another name for__stdcall:

#define WINAPI __stdcall
We can explicitly declare a function to use the __stdcall convention:

int __stdcall sumExample (int a, int b);

Also, we can use the compiler option /Gz to specify __stdcall for all functions not explicitly declared with some other calling convention.
The main characteristics of __stdcall calling convention are:
1. Arguments are passed from right to left, and placed on the stack.
2. Stack cleanup is performed by the called function.
3. Function name is decorated by prepending an underscore character and appending a '@' character and the number of bytes of stack space required.
Because the stack is cleaned by the called function, the __stdcall calling convention creates smaller executables than __cdecl, in which the code for stack cleanup must be generated for each function call. On the other hand, functions with the variable number of arguments (like printf()) must use __cdecl, because only the caller knows the number of arguments in each function call; therefore only the caller can perform the stack cleanup.

Note:
__cdecl is the default calling convention for C and C++ programs. The advantage of this calling convetion is that it allows functions with a variable number of arguments to be used. The disadvantage is that it creates larger executables.
__stdcall is used to call Win32 API functions. It does not allow functions to have a variable number of arguments.
__fastcall attempts to put arguments in registers, rather than on the stack, thus making function calls faster.
Thiscall calling convention is the default calling convention used by C++ member functions that do not use variable arguments.