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.

I was recently porting an MFC C++ application that compiled on Visual studio 2005 32-bit to VS 2008 64-bit.

It turns out there is a bug in the code generated by older versions of MFC that makes it not compile on 64 bit.

The problem is with the OnTimer function signature:

      afx_msg void OnTimer(UINT nIDEvent); 

It should be changed to ->

      afx_msg void OnTimer(UINT_PTR nIDEvent);

 

You can find Microsoft’s reaction to a similar connect bug report for VS 2005 at:

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101372

Hope this helps!

 

If you are in the business of writing components/plugins that work inside browsers and even if your target audience is Windows users, you can't ignore Firefox anymore.

IE is still the most popular browser by far but Firefox is a force to reckon with when it comes to writing browser plugins.

If you use Visual studio as a development environment and want to develop plugins for Firefox here are a few points to get you started.

First checkout the article OpenGL sample as Firefox plugin on code project. It is a great and simple example on how to write a Firefox plugin.

Second, because some things have changed since the above article was written, follow the steps below to get the Firefox plugin project to work on Visual Studio:

1. Download the Firefox source code version you want

    Example: the Firefox 3.0.1 version is found here

2. Extract to yourroot\mozilla

   Example C:\Projects\XProj\mozila

3. Download the Gecko SDK/ XULRunner SDK source code version you want

    Example: the Gecko 1.9 (Firefox 3.0) version is found here

4. Extract to yourroot\xulrunner-sdk(for Firefox version 3.0) or yourroot\gecko-sdk(for Firefox version 1.5-2.0)

   Example C:\Projects\XProj\xulrunner-sdk

5. Run unix2dos on npbasic.dsp and npbasic.dsw (you can find them at yourroot\mozilla\modules\plugin\tools\sdk\samples\basic\windows)

6. Open the npbasic Visual Studio project (you can find it at yourroot\mozilla\modules\plugin\tools\sdk\samples\basic\windows)

7. Inside Visual Studio go to project properties and set the additional include directories:

For Firefox 1.5-2 (gecko-sdk) change to->

yourroot\gecko-sdk\include; yourroot\mozilla\modules\plugin\tools\sdk\samples\include

For Firefox 3 (xulrunner-sdk) change to ->

yourroot\xulrunner-sdk\sdk\include; yourroot\mozilla\modules\plugin\tools\sdk\samples\include

8. Fix a compilation bug in npplat.h:

When building the project you might receive the following error:

error C2146: syntax error : missing ';' before
identifier 'ContextRecord'

The error can be fixed by changing the order of some of the include files inside npplat.h.

The following 2 include lines are found in npplat.h:

#include "npapi.h"

#include "npupp.h"

You will need to move them from the beginning of the npplat.h to a place beyond where the Windows include files are included.

For Example if the original file looks like this:

...

#ifndef _NPPLAT_H_

#define _NPPLAT_H_

#include "npapi.h"

#include "npupp.h"

/**************************************************/

/* Windows */

/**************************************************/

#ifdef XP_WIN

#include "windows.h"

#endif //XP_WIN

...

The modified file should look like this:

...

#ifndef _NPPLAT_H_

#define _NPPLAT_H_

/**************************************************/

/* Windows */

/**************************************************/

#ifdef XP_WIN

#include "windows.h"

#endif //XP_WIN

#include "npapi.h"

#include "npupp.h"

.....

 9. Rebuild the project.

10. You should be good to go now. Good luck!

 

This is a heads up for people developing ActiveX  controls for IE. The problem was demonstrated on IE 7 but might be true on other browser versions.

If you embed an ATL based ActiveX control inside a web page and try to send/fire events to the script and find out that the events are not generated then you might have the following problem.

As a simple debug trace can demonstrate initiation of ActiveX controls and script on a web page is done synchronically by one thread.

At first, objects are created, then any global script code gets executed and only after that IConnectionPointContainerImpl Advise gets called to establish a connection between the connection point and a sink.

Now the problem is that if you call a member function of the ActiveX object in the global script and this function tries to generate events those events will never be generated since the advise function was not called yet.

A simple solution to the problem, although a little bit of a hack, is to make sure you never call ActiveX functions when the page initializes.

Instead you can use a timer event handler function and call the ActiveX functions from inside the timer event handler this will insure that advise gets called to register the event handlers before you call any ActiveX member functions.

Example:

Lets assume we have a init function in the JavaScript script that does some ActiveX initialization.

function InitActiveX()

{

MyActiveXObj.Myfunction(parameters);

}

//InitActiveX(); //-> PRB: un remarking this line will cause the advise function not to get called on time!!

var timerId = setTimeout('InitActiveX',1000); // this works because the advise function will get called before the timer event handler function gets executed!!

Note that even a time delay of 0 works because it still makes sure the function is not called directly from the global script.

 

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:

struct IPHeader

{

unsigned int version:4; // version of IP

unsigned int headerLen:4; // length of IP header

unsigned char tos; // type of service

unsigned short totalLen; // total length of the packet

unsigned short id; // unique identifier

unsigned short flags; // flags

unsigned char ttl; // time to live

unsigned char protocol; // protocol  type (TCP, UDP etc)

unsigned short checksum; // IP checksum

unsigned int sourceIP; // source IP address

unsigned int destIP; // destination  IP address

};

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:

struct IPHeader

{

unsigned int headerLen:4; // length of IP header

unsigned int version:4; // version of IP

unsigned char tos; // type of service

unsigned short totalLen; // total length of the packet

unsigned short id; // unique identifier

unsigned short flags; // flags

unsigned char ttl; // time to live

unsigned char protocol; // protocol  type (TCP, UDP etc)

unsigned short checksum; // IP checksum

unsigned int sourceIP; // source IP address

unsigned int destIP; // destination  IP address

};

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.