This is a heads up for any one that is used to auto link static libraries using project dependencies.

VS 2010 changed the game by adding a new step that is necessary in order to auto link static libraries.

It is not enough to specify project dependencies as we used to do in older versions of Visual Studio.

To setup auto linking go to Project/Properties/Common Properties/Framework and References/Add new reference.

By default when developing native C/C++ apps using VS 2010 beware that your executables will not run on Win 2K and older targets.

That is true even if you remove any external dependencies and adhere to Win32 API compatible with older Windows versions.

One possible solution to the problem is Native Multi Targeting - using the VS 2008 compiler while working with the VS 2010 IDE. Assuming you can afford to have VS 2008 installed on the same machine.

mkdir is a C runtime library function that creates directories.

In contrary to what could be understood from the MSDN documentation:

“…On an error, the function returns –1 and sets errno as follows.EEXIST Directory was not created because dirname is the name of an existing file, directory, or device.ENOENT Path was not found.For more information about these and other return codes, see _doserrno, errno, _sys_errlist, and _sys_nerr.”

mkdir might return other error values. For example when calling mkdir on an existing directory the function might return EEXIST but can also return EACCES (permission denied). The function error results seem to differ according to user access permissions on the system. This has been tested on Windows 2003/Vista/7. For more information and portability issues check out this discussion about mkdir portability in Kernel trap.

·         Note that this discussion applies to Microsoft’s implementation of the C run time library.

People working with cross platform low level code are usually aware of the issues related to the little and big endian data presentation methods which dictate how bytes are ordered in memory. This helps them avoid pitfalls related to cross platform data transfer such as when transferring data over the network or when moving files from a little endian platform to a big endian platform and vice versa.

But what about bit field ordering, is there any standard ordering of C/C++ bit-fields and what effect can this have on your code?

As it turns out there is no ANSI bit ordering standard and bit ordering is compiler dependant.

To demonstrate the problems that might arise from this lack of standardization, consider the following C++ code that describes an IP packet header:

unsigned char tos; // type of service

The IP header length and version fields are both 4 bit, bit-fields.

Logic might lead you to assume that the header length will be placed after the version in memory like the other IPHeader data members but in fact this is compiler dependant.

For example Visual C++ documentation says the following about Microsoft's implementation of C++ bit fields:

"The ordering of data declared as bit fields is from low to high bit..."

The result of this would be that length will be placed before the version field and this will produce an invalid IP header.

This means that for the IP header to be generated correctly on Visual C++ you will need to reverse the order of the IP header length and version fields:

To avoid those types of pit falls when working with bit fields, make sure you know and control the type of bit ordering your compiler and data structures employ.

Some compilers might let you change the default bit ordering but be sure to consider all the possible interactions with other parts of the code.