Calvin Hsia's WebLog : C++

Comment/Uncomment code to switch versions quickly without using macros

Calvin_Hsia — Sat, 28 Mar 2009 09:39:00 GMT

In a typical day, I write or debug programs in several languages: typically Foxpro, C#, VB, C++ and 32 bit assembly, with an occasional MSIL, IDL and 64 bit ASM thrown in.

Sometimes, I like to switch between one version of code and another. This is useful if I want to do side by side comparisons of behavior.

One way to do this is with preprocessor macros, like this:

#If SomeValue

#else

#endif

However, that’s a fair amount of typing.

There’s a shortcut that works with C# and C++ style comments.

In these languages, a line that starts with “//” is a comment.

Also, a block comment (which can span multiple lines) starts with “/*” and ends with “*/”

//*

int sub foo1() {

int x = 2;

Console.WriteLine((new System.Diagnostics.StackTrace().GetFrames()[0].GetMethod().Name)); // shows Foo1

return x;

}

/*/

int sub foo2() {

int x = 3;

Console.WriteLine((new System.Diagnostics.StackTrace().GetFrames()[0].GetMethod().Name)); // shows Foo2

return x;

}

// */

With a single character change I can switch between foo1 and foo2: just delete the very first “/”. That changes the single line comment into a block comment. The “*/” of the “/*/” now acts like the end of the comment block.

Using an editor that colors the code (like Visual Studio) shows the switch properly

int sub foo1() {

int x = 2;

Console.WriteLine((new System.Diagnostics.StackTrace().GetFrames()[0].GetMethod().Name)); // shows Foo1

return x;

}

/*/

int sub foo2() {

int x = 3;

Console.WriteLine((new System.Diagnostics.StackTrace().GetFrames()[0].GetMethod().Name)); // shows Foo2

return x;

}

// */

This technique is useful when creating sample code for others to play with, such as in my next blog post.

Overload Operator new to detect memory leaks

Calvin_Hsia — Tue, 20 Jan 2009 05:47:00 GMT

There are various leak detection methods for memory allocators. A popular one is to tag each allocation with some information about the caller. When there’s a memory leak, you just need to look at that tag info to find the line of code that allocated the memory.

However, this requires that the caller pass in the parameters, such as file and line number, for each allocation. (Perhaps we want to do this only on debug builds.) Also, there could be thousands of callers: we want to avoid changing all the call sites.

The __FILE__ and __LINE__ predefined macros and default parameters can help eliminate the need to modify thousands of lines of source code. They are the file and line number of the currently compiled line. Then we can store the file/line with every allocation.

We can create an allocation method with 2 default parameters, and use these predefined macros as the defaults:

void * MyAlloc(size_t cbSize, char *szFile = __FILE__, UINT nLineNo = __LINE__)

Now a caller to MyAlloc will automatically pass in the file and line number parameters with no change to the original source.

void *ptemp = MyAlloc(100);// let's allocate 100 bytes (Default params are __FILE__ and __LINE__

Although this works with direct calls to MyAlloc, many allocations are via the “new” operator. We can override the default module implementation with our own:

// the single override of the module's new operator:

void * _cdecl operator new (size_t cbSize)

void *p = MyAlloc(cbSize, __FILE__, __LINE__); // this line will show for all New operator calls<sigh>

return p;

}

Using this technique, every “new” allocation will point to this same file/line of code. Not very useful: we want to know which line of code called “new”, not where the “new” operator override is.

But how do we pass in default parameters (so we don’t have to modify thousands of lines of source)?

If we try this:

void * _cdecl operator new (size_t cbSize, char *szFile = __FILE__, UINT nLineNo = __LINE__)

we get a linker error:

1>d:\dev\vc\overnew\overnew.cpp(99) : error C2668: 'operator new' : ambiguous call to overloaded function

1> d:\dev\vc\overnew\overnew.cpp(45): could be 'void *operator new(size_t,char *,UINT)'

1> d:\dev\vc\overnew\predefined c++ types (compiler internal)(23): or 'void *operator new(size_t)'

1> while trying to match the argument list '(unsigned int)'

That makes sense: the linker has no idea which operator new to call because there’s only 1 parameter: the size, and both implementations match operator new with 1 integer parameter.

We also have problems when trying to link in COM, ATL or STD Lib code which also call “new”

One way to avoid this is to use an overload (not an override). What’s the difference?

An override replaces existing functionality, whereas the overload adds functionality, and the called code is determined by it’s signature.

If we add a parameter to operator New (like a simple integer), then we have overloaded it. If we then modify every caller to pass in the parameter, then we can use the predefined macros and default parameter trick:

void * _cdecl operator new (size_t cbSize, int nAnyIntParam, char *szFile = __FILE__, UINT nLineNo = __LINE__)

The big drawback is we have to modify all the call sites.

If the call sites already have a parameter and are thus calling the overload, then no big deal: this is what the FoxPro code base does: each memory handle is marked with the kind of memory (Data Engine, Property Sheet, Form Designer, UserCode, etc). It was simple to add the File/LineNo default parameters to debug builds.

However, this still doesn’t work with COM, ATL, STD code. IMalloc, IMallocSpy can be used for mapping COM calls through our code.

A solution is to recall that the main task at hand is to find which line of code allocated a leaking block: instead of recording __LINE__, which could be the same for all new calls, let’s use the same recording mechanism to record the caller’s address (they’re both just 32 bit DWORDS.)

// the single override of the module's new operator:

void * _cdecl operator new (size_t cbSize)

{

UINT *EbpRegister ; // the Base Pointer: the stack frame base

_asm { mov EbpRegister, ebp};

UINT CallerAddr = *(((size_t *)EbpRegister)+1) ; // the return addr

void *p = MyAlloc(cbSize, __FILE__, CallerAddr);

return p;

}

Below is a sample that you can build and run using Visual Studio. (I suspect all versions will work.)

It demonstrates allocating and freeing memory from direct calls, from operator new, and from overloaded operator new.

Start VS, choose File->New->Project->C++->Win32->Console Application. Call it OverNew

In the wizard choose add common header files for ATL, click Finish.

Paste in the Sample1 code below:

Now hit F5 to run the code.

If you uncomment any of the Delete lines, the program will leak: the memory is never released.

There is no warning or error that the memory leaks. In this simple scenario, the leak doesn’t matter because the process just exits. However, in more complex scenarios, the leak can be crippling.

Now when you run the code, you get output like this:

MyAlloc 1056a8 Size = 100 d:\dev\vc\overnew\overnew.cpp(23)

MyAlloc 105850 Size = 4 d:\dev\vc\overnew\overnew.cpp(61)

Op new 105958

Constructor 105958

MyAlloc 105998 Size = 4 d:\dev\vc\overnew\overnew.cpp(61)

Op new 105aa0

Constructor 105aa0

MyAlloc 105ae0 Size = 4 d:\dev\vc\overnew\overnew.cpp(69)

Op new overload 105be8

Constructor 105be8

Destructor 105958

Op del 105958

MyDelete 105958 d:\dev\vc\overnew\overnew.cpp(61)

Destructor 105aa0

Op del 105aa0

MyDelete 105aa0 d:\dev\vc\overnew\overnew.cpp(61)

Op del 1057b0

MyDelete 1057b0 d:\dev\vc\overnew\overnew.cpp(23)

Destructor 105be8

Op del 105be8

MyDelete 105be8 d:\dev\vc\overnew\overnew.cpp(69)

Note: this sample doesn’t overload the operator new []() version which allocates arrays. That’s for you to do.

void* _cdecl operator new[](size_t cbSize)

Write simple Debug helpers to help you debug and maintain your code

Calvin_Hsia — Thu, 04 Dec 2008 01:55:00 GMT

Much of my time is spent using the Visual Studio debugger examining code to figure out how it works and how to fix it. When stepping through a function, the values the function uses are very useful for code understanding. The debugger shows these values in the Watch/Locals/Auto/Callstack windows. For example, the Locals window shows the Local variables used by the current code while at a breakpoint. Each variable might be a structure or class with many members. You can click to expand to examine sub-members of a value.

I also like to modify code while the debug session is live, so I can see real values while writing. Edit and Continue is a very useful feature, but it doesn’t work in every case, such as creating new methods or types. Also, native code doesn’t support EnC. So I like using an external editor (perhaps another instance of VS) to modify the code. This means that your debug session is still live, and the source code file still matches the binary, until you save the file in the external editor.

The string shown for a variable can be customized to help understand what the code is doing. As you step through the code, if you can understand at a glance what the function is doing, rather than drilling into sub-members, you’re more efficient. Some types have dozens of variables, and some might be more important than others.

For native code (C++, C) you can customize the display string with this: Customize the VS debugger display of your data

For managed code (VB, C#) you can override the ToString method to customize the string. In VS 2008, the debugger will display the results of calling the ToString method.

There are 2 options:

Tools->Options->Debugging->

Enable Property Evaluation and other implicit function calls

Call string conversion function on object in variables windows (C# and javascript only)

The next version of Visual Studio will add VB to this feature!

As a simple workaround, to have the debugger call ToString in VB programs, you need only prefix your types with

<DebuggerDisplay("{tostring}")> _

The line continuation character won’t be needed in the next version either!

If you don’t have the source code or can’t modify it, you can still modify the displayed string: Customize the display of types in the Debugger using Extension Methods and DebuggerDisplay Attribute

Below are a VB and C# program demonstrating how the string can be customized.

Start VS2008, choose File->New->Project->C# or VB->WPF Application, then paste in the code.

Put a Breakpoint on the indicated line and hit F5. You’ll see the string displayed is the result of the ToString function.

Make your code more maintainable: The evils of the Return statement

Calvin_Hsia — Tue, 29 Jul 2008 00:34:00 GMT

What does it mean to make code more maintainable? Certainly obfuscated code is hard to understand, by definition.

A big part of maintainability is making it easier for others to read and understand what the code is doing. Your code may have been working for years, but then somebody comes along and wants to add a feature, which might break your code.

Sometimes the behavior of code isn’t quite right, so you might need to investigate somebody else’s code.

(The repro scenario of the issue might be quite complicated, involving several tedious minutes of (perhaps ambiguous) keystrokes and clicks.

You might be single stepping some code, and suddenly you find yourself past the point where something seems to have gone wrong. <Sigh>. You have to restart the entire scenario, putting a breakpoint before the offending code is executed. Or do you? Set Next Statement is your friend. Often you can use Set Next Statement to go back a bit. You can perhaps modify some local variables and try to execute the code again, without having to repeat the tedious repro scenario.)

The Return statement exists in many languages, including C#, VB, FoxPro, C++. This discussion pertains to all of them.

Each of these languages allow you to create a very complex expression, perhaps with inline conditionals, precede it with the keyword “Return” and the value of the expression is the return value of the current method.

Suppose you had “simple” functions Foo and Bar:

int Foo(someparam)

{

return Bar(someparam)->SomeMethod(SomeOtherParam);

}

int Bar(someparam)

{

<...some code...>

return AnotherFoo(SomeFunc(SomeOtherValue));

}

Another return statement sample with 20 calls in it:

return (HasFlag(Flags, GetSomeVal(Flags)) &&

!HasFlag32(Result, SXF_LPE) &&

!(IsSomeValPointer(Result) &&

// Rule out Pointers to values of types.

!(Result->AsSomeValPointerExpression().Left->type == type_WRD &&

Result->AsSomeValPointerExpression().Left->AsWordPointerExpression().BasePointer &&

!HasFlag32(Result->AsSomeValPointerExpression().Left->AsWordPointerExpression().BasePointer, SXF_LWORD) &&

ValHelpers::IsValue(Result->AsSomeValPointerExpression().Left->AsWordPointerExpression().BasePointer->ResultType)&&

// make sure SomeSomeVal() still works for value types(bug 32804)

!(Result->AsSomeValPointerExpression().Left->AsWordPointerExpression().BasePointer->type == type_SYM &&

Result->AsSomeValPointerExpression().Left->AsWordPointerExpression().BasePointer->AsWordPointerExpression().Word->PVariable()->IsGood()))))

Suppose you’re debugging a program and single stepping and reach the end of Bar(). Even after stepping over this statement, you can’t easily see the value (or intermediate values) that’s being returned. You can’t even see the type of the return value unless you can see the method signature on the screen: “Function MyMethod() As SomeType”

The Autos window does show the return value/type for native code, (but not VB or C#), but I find that the other info it displays is useless. It tries to guess the nearby values that you might want to see: I much prefer the Locals window. It would be nice if the return value from the Autos window were displayed in the Locals window. So I’ve resorted to showing just the top couple of lines of the Auto window under my Locals window. However, the Autos window doesn’t allow you to change a returned value, whereas the Locals window does.

Also, seeing intermediate values by hovering your mouse works for local values, but not for method calls.

(If you’re debugging C++ code, then if you open the Debug->Windows->Registers window, you can see and change simple return values like Bools and Integers in the EAX register (32 bit) or RAX (64 bit), but watch out for implied destructor calls)

So you step out of the function Bar(), then you’re on another complex return statement in Foo(), where you still can’t see the returned value. So you step out again, and yet another Return statement. You might need to step out a few levels before you can see what the value is. If you want to reexamine this path, you can Set Next Statement back, but then you’re at a call stack level that’s far from the original code, so you have to go drill back down the callstack.

Now suppose you think the return value of Bar() isn’t quite right, or you want to reexamine what is happening.

Right click and choose “Step Into Specific” ,which might list 20 different functions into which you could step. However, depending on conditionals and prior values, not all of the 20 may be called. So you Step into the first, see that it’s uninteresting, Step into the Next, etc. until you see something interesting.

(look for a future blog post on Just My Code for native debugging that will remove a lot of the uninteresting Step Intos., like library or template functions or operator overloads)

So we’ve discussed two maintainability issues:

· make the return value of your function more visible while debugging, so the user can verify functionality more easily and can use Set Next Statement.

· Break up complex expressions, especially in Return statements.

The simple solution to both of these issues: Introduce new local variables to have intermediate results and break up nested conditional clauses to be separate If statements.

· Set Next Statement and Breakpoint granularity is finer.

· Intermediate results can be seen and modified in the Locals window

· Mouse hover shows the values

· The local variable names can be further indications of intent.

Simply changing the code from:

Return <ComplexExpr>

Int RetVal = <ComplexExpr>

Return RetVal

will make a huge difference in this debugging scenario. The user can Step Over and the RetVal can be seen in the debugger and, if it’s wrong, the user can Set Next Statement back and reexecute the code, Stepping In, rather than Stepping Over (watch out for side effects of reexecution). The user stays within the method without having to back up a few levels of the call stack. Also, it’s easier to see the type of the return value.

int Foo(someparam)

{

SomeType Barval = Bar(somparam);

Int RetVal = Barval->SomeMethod(SomeOtherParam);

return Retval;

}

int Bar(someparam)

{

<...some code...>

SomeFuncType SomeFuncVal = SomeFunc(SomeOtherValue));

Int Retval = AnotherFoo(SomeFuncVal);

return Retval;

}

Modern optimizing compilers can optimize out those variables and can generate identical code.

I once heard of a chess program written in one (very long) line of code, but imagine trying to maintain that puppy!

How fast is interop code?

Calvin_Hsia — Wed, 28 May 2008 22:24:00 GMT

How fast is interop code? If you’re in one kind of code and your calling another, what is the cost of the interop?

For example, .Net code can call native C++ code (like Windows APIs) and vice versa. Similarly with Foxpro and C++ code. .Net code is often referred to as Managed code because much is managed for the programmer, such as memory allocation. That leaves C++ code to be called “Unmanaged”. An easy way to interop with C++ code is to use COM (Component Object Model, or sometimes ActiveX) as glue. Whether it’s COM calling .Net or vice versa, the managed boundary is traversed twice: there and back. Similarly with Fox code calling COM code.

Fox code calling .Net code (e.g. A Visual Basic COM object is simple to create, call and debug from Excel) will have both Fox to COM and COM to .Net interop.

I want to measure raw interop performance, so I want to remove memory allocation and Unicode/String marshalling issues from the tests. I want to have a loop on one side call a very fast method on the other, so that most of the execution time is in the interop, not the loop or the method call. I want to use in-process, same thread calls, so remote procedure calls/marshalling are not being measured.

We’ll create a native C++ method that just returns consecutive integers. A simple loop in the .Net or Fox client that calls this method keeps a running total would be a good perf test.

Start with this sample ActiveX control code: Create an ActiveX control using ATL that you can use from Fox, Excel, VB6, VB.Net. You don’t need the events and methods from that sample, just the control itself.

(If you’re using VS2008, in the ATL Project wizard, select DLL and just choose “Finish”. When adding a method in Class View, make sure to choose the ITestCtrl Interface (defined in MyCtrl.IDL, not ITestCtrl VCCodeStruct defined in MyCtrl_i.h. Similarly, if you’re adding an event, make sure to choose the _ITestCtrlEvents interface under MyCtrlLib in Class View. Also, you need to run the “Implement ConnectionPoint Wizard” and change the call to “Fire_MyEvent”, see http://msdn.microsoft.com/en-us/library/9h7xedd1.aspx)

When COM code is called from VB.Net or FoxPro, the calls are not quite direct: COM is used for creating the object and initialization and there is some parameter/return value massaging required per call. Then it’s either a straight virtual function call (vTable) call to IDispatch (late bound) or IUnknown (early bound). IOW, the performance would be slower than the a direct PInvoke or DECLARE DLL call.

Let’s add a simple method RetInt with no parameters that just returns an int. Add a method to our COM Control by right clicking on the ITestCtrl interface in Class View and choosing Add->Method to start the “Add Method Wizard”

Since all COM interface method calls return HRESULTS, to return a value an additional parameter is added and marked with the RetVal attribute and is passed by ref. So make the Method Name “RetInt”, the Parameter type “LONG *”, and the Parameter Name “RetVal”. Choose the Retval checkbox. Then choose “Add” to add the param to the method.

Add another method DoSum similarly. This method will run with no interop, so we have a baseline for comparison. (It runs the loop multiple times because it goes so much faster, but the timing measurement divides out the multiple runs.)

The resulting code is added to TestCtrl.CPP. Add the implementation:

static LONG g_Int = 0;

STDMETHODIMP CTestCtrl::RetInt(LONG* RetVal)

{

*RetVal = ++g_Int; // just return consecutive integers

return S_OK;

}

// DoSum will calculate the value with no interop whatsoever

STDMETHODIMP CTestCtrl::DoSum(LONG nTimes,LONG nInternalLoopCount, DOUBLE* Retval)

{

LONGLONG nSum;

for (LONG j = 0 ; j < nInternalLoopCount ; j++) // this code runs so fast we have to do it multiple times

{

nSum = 0;

for (LONG i = 1 ; i <= nTimes ; i++)

{

nSum += i;

}

*Retval = (DOUBLE)nSum;

return S_OK;

}

// RetIntStatic can be called directly via PInvoke or Declare Dll

extern "C" HRESULT __declspec(dllexport) WINAPI RetIntStatic(LONG *RetVal)

{

*RetVal = ++g_Int;

return S_OK;

}

You can add more methods, like a way to reset g_Int to get more accurate results, but I don’t really care about the results, just how long it takes to get them.

Of course, you’ll want to run perf tests using optimized Release builds, so you’re not including debug asserts, etc. A really smart optimizing compiler would remove the loops in DoSum altogether!

If you have Foxpro, try running this Fox code. Notice that DoLoop can take either the Form or the Control as a parameter. There’s a RetInt method on each.

CLEAR ALL

CLEAR

MODIFY COMMAND PROGRAM() NOWAIT

_screen.FontName="Courier New" && Make font monospace, not proportional

SET DECIMALS TO 6

g_Int=0

ox=CREATEOBJECT("MyForm")

*ox.visible=1

nLoops=1000000

nInternalLoopCnt=1000

ns=SECONDS()

zObj=ox.oc && use temp var so we don't deref ox.oc in loop

r = zObj.DoSum(nLoops,nInternalLoopCnt)

?"Internal DoSum ",r,(SECONDS()-ns)/nInternalLoopCnt

?DoLoop(ox,nLoops, "With No Interop" )

?DoLoop(ox.oc,nLoops,"With COM Interop")

*Use early binding:

oy=CREATEOBJECTEx("MyCtrl.TestCtrl","","")

?DoLoop(oy,nLoops,"With COM Interop Early Bound")

*Try Declare DLL: like PInvoke

DECLARE integer _RetIntStatic@4 IN "d:\dev\vc\myctrl\release\myctrl.dll" as RetIntStatic integer @ Retval

?DoLoopStatic(nLoops,"With DeclareDLL interop")

FUNCTION DoLoop(zObj as object,nTimes as Integer, sDesc as String) as String

LOCAL nSum

nSum=0

ns=SECONDS()

FOR i = 1 TO nTimes

nSum = nSum + zObj.RetInt()

ENDFOR

RETURN sDesc+" Sum= "+TRANSFORM(nSum) + " "+ TRANSFORM(SECONDS()-ns)

RETURN

FUNCTION DoLoopStatic(nTimes as Integer, sDesc as String) as String

LOCAL nSum

nSum=0

nRetval=0

ns=SECONDS()

FOR i = 1 TO nTimes

RetIntStatic(@nRetval)

nSum = nSum + nRetval

ENDFOR

RETURN sDesc+" Sum= "+TRANSFORM(nSum) + " "+ TRANSFORM(SECONDS()-ns)

RETURN

DEFINE CLASS MyForm as Form

ADD OBJECT OC as olecontrol WITH ;

oleClass="MyCtrl.TestCtrl",;

height=200,width=300

left=200

AllowOutput=.f.

PROCEDURE RetInt as Integer

g_Int = g_Int+1

RETURN g_Int

ENDDEFINE

The DoSum call (Fox and VB) was consistent as expected: they both execute in about the same time because there is only one interop call.

I consistently saw the COM Interop loop taking about 50% longer than the non interop loop. This makes sense. The code that calls the COM object has to deal with all sorts of parameter types, marshalling, etc. The non interop did the entire calculation within Fox code.

The DoSum method has its own internal loop to do the calculation, which does NO interop of any kind in the loop, runs roughly 2000 times faster. That implies there are about 2000 times more instructions executed in the loop.

Now I want to run a similar test using VB.Net. Let’s add a new project to the ActiveX control project from above.

Choose the Solution Explorer, right click on the solution, choose Add New Project, VB->Windows Forms Application. I put my VB Project within the folder of the TestCtrl project.

Right click on the project, and choose “Set As Startup Project” so hitting F5 will start this project.

If you’re on a 64 bit OS, then make sure you target x86 (Project->Properties->Compile->Advanced Compile Options->Target CPU->x86

Add the ActiveX control to your toolbox: Right click on the toolbox, choose items\COM Components…TestCtrl class.

Now drag the control from the toolbox onto the form. Dbl Click on the form and paste in this code:

Public Class Form1

'Note the path: "..\..\..\Release\MyCtrl.dll"

<Runtime.InteropServices.DllImport( _

"..\..\..\Release\MyCtrl.dll", _

CallingConvention:=Runtime.InteropServices.CallingConvention.Winapi, _

entrypoint:="_RetIntStatic@4")> _

Friend Shared Function RetIntStatic(ByRef RetVal As Integer) As Integer

End Function

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

Dim nLoops = 1000000

Dim nInternalLoopCnt = 1000

Dim sStopWatch = Stopwatch.StartNew

Dim r = Me.AxTestCtrl1.DoSum(nLoops, nInternalLoopCnt)

Console.WriteLine("Internal DoSum Native=" + r.ToString + " " + (sStopWatch.ElapsedMilliseconds / 1000 / nInternalLoopCnt).ToString)

sStopWatch = Stopwatch.StartNew

r = Me.DoSum(nLoops, nInternalLoopCnt)

Console.WriteLine("Internal DoSum .Net =" + r.ToString + " " + (sStopWatch.ElapsedMilliseconds / 1000 / nInternalLoopCnt).ToString)

Console.WriteLine(DoLoop(Me, nLoops, "With Late bound No interop, calling local VB.Net method"))

Console.WriteLine(DoLoop(Me.AxTestCtrl1, nLoops, "With Late bound COM interop"))

Console.WriteLine(DoLoopEarlyForm(Me, nLoops, "With Early bound No interop, calling local VB.Net method"))

Console.WriteLine(DoLoopEarlyCtrl(Me.AxTestCtrl1, nLoops, "With Early bound COM interop"))

Console.WriteLine(DoLoopPInvoke(nLoops, "With PInvoke interop"))

End

End Sub

Function DoLoop(ByVal zObj As Object, ByVal nTimes As Integer, ByVal sDesc As String) As String

Dim nSum = 0L

Dim sStopWatch = Stopwatch.StartNew

For i = 1 To nTimes

nSum += zObj.RetInt

Return sDesc + " Sum = " + nSum.ToString + " " + (sStopWatch.ElapsedMilliseconds / 1000).ToString()

End Function

Function DoLoopEarlyForm(ByVal zObj As Form1, ByVal nTimes As Integer, ByVal sDesc As String) As String

Dim nSum = 0L

Dim sStopWatch = Stopwatch.StartNew

For i = 1 To nTimes

nSum += zObj.RetInt

Return sDesc + " Sum = " + nSum.ToString + " " + (sStopWatch.ElapsedMilliseconds / 1000).ToString()

End Function

Function DoLoopEarlyCtrl(ByVal zObj As AxMyCtrlLib.AxTestCtrl, ByVal nTimes As Integer, ByVal sDesc As String) As String

Dim nSum = 0L 'L for Long so doesn't overflow 32 bits

Dim sStopWatch = Stopwatch.StartNew

For i = 1 To nTimes

nSum += zObj.RetInt

Return sDesc + " Sum = " + nSum.ToString + " " + (sStopWatch.ElapsedMilliseconds / 1000).ToString()

End Function

Function DoLoopPInvoke(ByVal nTimes As Integer, ByVal sDesc As String) As String

Dim nSum = 0L 'L for Long so doesn't overflow 32 bits

Dim sStopWatch = Stopwatch.StartNew

For i = 1 To nTimes

Dim RetVal = 0

RetIntStatic(RetVal)

nSum += RetVal

Return sDesc + " Sum = " + nSum.ToString + " " + (sStopWatch.ElapsedMilliseconds / 1000).ToString()

End Function

Private Shared g_Int As Long

Public Function RetInt() As Long

g_Int += 1

Return g_Int

End Function

Function DoSum(ByVal nTimes As Long, ByVal nInternalLoopCount As Long) As Double

Dim nSum As Long

For j = 1 To nInternalLoopCount ' calculated multiple times because it's fast

nSum = 0

For i = 1 To nTimes

nSum += i

Return nSum

End Function

End Class

Run the code with the Output Window visible. Here, the VB code with interop ran maybe 40% slower, and several times slower than the Fox code. I realized that this was because of the late binding calls the VB code does. The VB DoLoop method takes zObj as an Object, and I invoke the RetInt method on it. That means, the VB runtime latebinder code is called to reflect on the object and see if it has a Retint method on it that can be called. Both the Form and the control have a method with this name. The latebinding was code that I didn’t want to measure, so I added some strongly typed calls that forced the calls to be early bound direct calls, which were much faster. For the Non-interop code doing the entire calculation within VB, the late bound was around 1000 times slower than the early bound, due to the late binder code. For the Interop case, the late bound was about 30 times slower than the early.

(Comparing .Net speed with native, the DoSum call (with no interop at all) in .Net was almost 3 times slower than Native, but that’s expected too: native code runs faster than managed.)

These early bound calls are several times faster than the Fox code too: they don’t have to do any parameter packing/checking.

However, even the Fox code doing early binding, Fox still has to do a lot of parameter translation between fox types and COM types.

The Fox and VB calls via PInvoke/Declare DLL were the fastest of all. They have to do the least parameter translation/packing/checking. This makes sense: the method call is declared to have N parameters of certain types, so less work needs to be done.

Using ILDasm to see the IL for the RetInt, you can see that there isn’t much code. The Fox code for RetInt, however, causes much more code to run.

.method public instance int64 RetInt() cil managed

{

// Code size 24 (0x18)

.maxstack 2

.locals init ([0] int64 RetInt)

IL_0000: nop

IL_0001: ldsfld int64 WindowsApplication1.Form1::g_Int

IL_0006: ldc.i4.1

IL_0007: conv.i8

IL_0008: add.ovf

IL_0009: stsfld int64 WindowsApplication1.Form1::g_Int

IL_000e: ldsfld int64 WindowsApplication1.Form1::g_Int

IL_0013: stloc.0

IL_0014: br.s IL_0016

IL_0016: ldloc.0

IL_0017: ret

} // end of method Form1::RetInt

Or use the debugger to see the native code in DoSum: (cdq is ConvertDoubleToQuadWord)

LONGLONG nSum=0;

for (LONG i = 1 ; i <= nTimes ; i++)

{

692B1DF1 8B C1 mov eax,ecx

692B1DF3 99 cdq

692B1DF4 03 D8 add ebx,eax

692B1DF6 13 EA adc ebp,edx

692B1DF8 8D 41 01 lea eax,[ecx+1]

692B1DFB 99 cdq

692B1DFC 03 F0 add esi,eax

692B1DFE 8B 44 24 20 mov eax,dword ptr [esp+20h]

692B1E02 13 FA adc edi,edx

692B1E04 83 C1 02 add ecx,2

692B1E07 48 dec eax

692B1E08 3B C8 cmp ecx,eax

692B1E0A 7E E5 jle CTestCtrl::DoSum+21h (692B1DF1h)

692B1E0C 3B 4C 24 20 cmp ecx,dword ptr [esp+20h]

692B1E10 7F 0B jg CTestCtrl::DoSum+4Dh (692B1E1Dh)

{

nSum += i;

692B1E12 8B C1 mov eax,ecx

692B1E14 99 cdq

692B1E15 89 44 24 10 mov dword ptr [esp+10h],eax

692B1E19 89 54 24 14 mov dword ptr [esp+14h],edx

}

This (optimized) code sums 32 bit values to a 64 bit running sum, so you can see instructions like “ADC”, which is AddWithCarry.

As an exercise, on 64 bit, create code like DoSum that natively handles 64 bit ints (or modify this code to use just 32 bits). You’ll see that the loop is trivial.

Hint: make sure you have the 64 bit tools installed.

Vista Aero DWM seems to optimize out GDI paint calls

Calvin_Hsia — Fri, 04 May 2007 02:50:00 GMT

In this post: Foxpro Menu items, combo boxes not refreshing selected item under Aero in Vista I describe a problem in Foxpro where menu and list items that are supposed to be non-selected aren’t painted correctly. I described a workaround: call the GdiSetBatchLimit API, which limits the GDI paint functions that are batched. Apparently some calls are being optimized out or not executed.

The problem occurs whether run as Administrator or not, but requires Desktop Composition enabled.

(Vista Aero can have DwmIsCompositionEnabled enabled or disabled. See Control Panel->System and Maintenance->System->Advanced System Settings->Advanced->Performance->Settings->Visual Effects->Enable desktop composition)

On Windows XP, the program runs as expected.

I’ve managed to create a standalone simple C++ program that demonstrates the behavior. The entire VS 2005 project is available here

The program displays a dozen items with the first item selected (inverted colors). The user can hit the down or up arrows to move the selection. If you hit the down arrow once, the first item is painted unselected, and the next item is painted selected. That’s fine. If you hit down arrow a few more times, the prior item doesn’t get repainted unselected.

I’ve put a call to GdiSetBatchLimit on Left or Right Arrow. Left will set it to 1, Right to 20 (the default). If you hit the left arrow, then the list selection behaves normally (you don’t even have to restart the app). Right arrow reproduces the problem behavior.

The problem seems related to calling SelectClipRgn

To create the sample project:

Start VS 2005: choose File->New Project-> Visual C++ Win32 Win32 Project. Call it VistaItems

In the Win32 Application Wizard, just choose all the defaults and Finish.

In the WndProc, add this case in the Switch to handle the WM_CREATE message:

case WM_CREATE:

{

RECT rect;

GetClientRect(hWnd,&rect);

rect.right/=2;

rect.left= 50;

CMenuWin *pCMenuWin = new (CMenuWin);

HWND hwndChild =

pCMenuWin->Create(hWnd, &rect,L"CMenuWin",

WS_VISIBLE | WS_CLIPCHILDREN | WS_POPUP

, WS_EX_NOPARENTNOTIFY);

if (hwndChild == 0)

{

int n = GetLastError();

DebugBreak();

}

SetParent(hwndChild, hWnd);

g_hwndChild = hwndChild;

}

break;

case WM_KEYDOWN:

return SendMessage(g_hwndChild, message, wParam, lParam);

break;

Add these lines after this line #include "VistaItems.h"

#include "atlbase.h"

#include "atlwin.h"

#define NUMITEMS 12

#define MAXITEMSIZE 10

struct DATA

{

TCHAR strText[MAXITEMSIZE];

int nState; // 0 or 1: selected or not

} Data[NUMITEMS] = {L"One",1,L"Two",0,L"Three",0,L"Four",0,

L"Five",0,L"Six",0,L"Seven",0,L"Eight",0,

L"Nine",0,L"Ten",0,L"Eleven",0,L"Twelve",0

};

int g_nCurItem = 0;

HDC g_hdc=0;

void GetRect(int nIndex, RECT * rect)

{

rect->left=10;

rect->right = 400;

rect->top = nIndex * 20;

rect->bottom = rect->top + 20;

}

void ShowItems(HWND hWnd, int nIndex, HDC hdc)

{

RECT rect;

GetRect(nIndex, &rect);

HFONT hFont = (HFONT)GetStockObject(ANSI_VAR_FONT);

COLORREF clr, clrold;

Data[nIndex].nState = 1 - Data[nIndex].nState ; // invert state

if (Data[nIndex].nState == 0)

{

clr = RGB(255,0,0);

SetBkColor(hdc, RGB(0,0,0));

} else

{

clr = RGB(0,0,255);

SetBkColor(hdc, RGB(255,255,255));

}

clrold = SetTextColor(hdc, clr);

ExtTextOut(hdc,

rect.left, rect.top, ETO_CLIPPED | ETO_OPAQUE ,

&rect, Data[nIndex].strText,(int)wcslen(Data[nIndex].strText), 0);

SetTextColor(hdc, clrold);

}

HRGN g_hRgn = 0;

HWND g_hwndChild = 0;

class CMenuWin : public CWindowImpl<CMenuWin>

{

public:

// DECLARE_WND_CLASS_EX(L"CMenuWin", 0 /*CS_OWNDC*/, COLOR_MENUHILIGHT) // backcolor

BEGIN_MSG_MAP(CMenuWin)

MESSAGE_HANDLER(WM_KEYDOWN,OnKeyDown)

MESSAGE_HANDLER(WM_PAINT,OnPaint)

END_MSG_MAP()

LRESULT OnKeyDown(UINT uMsg,WPARAM wParam, LPARAM lParam, BOOL & bHandled)

{

HDC hdc;

hdc = GetDC();

if (g_hRgn) {

DeleteObject(g_hRgn);

g_hRgn = 0;

}

RECT rect;

GetRect(g_nCurItem, &rect);

g_hRgn = CreateRectRgnIndirect(&rect);

SelectClipRgn(hdc,g_hRgn);

ShowItems(m_hWnd, g_nCurItem, hdc);

switch(wParam)

{

case VK_LEFT: // hit left arrow

GdiSetBatchLimit(1); // this will make it behave as expected

break;

case VK_RIGHT: // hit right arrow

GdiSetBatchLimit(20); // this will show the broken behavior

break;

case VK_DOWN: // down arrow

if (++g_nCurItem == NUMITEMS)

{

g_nCurItem=0;

}

break;

case VK_UP:

if (g_nCurItem-- == 0)

{

g_nCurItem=NUMITEMS-1;

}

break;

}

if (g_hRgn) {

DeleteObject(g_hRgn);

g_hRgn = 0;

}

GetRect(g_nCurItem, &rect);

g_hRgn = CreateRectRgnIndirect(&rect);

SelectClipRgn(hdc,g_hRgn);

ShowItems(m_hWnd, g_nCurItem, hdc);

ReleaseDC(hdc);

return 0;

}

LRESULT OnPaint(UINT uMsg,WPARAM wParam, LPARAM lParam, BOOL & bHandled)

{

PAINTSTRUCT ps;

HDC hdc = BeginPaint(&ps);

for (int i = 0 ; i < NUMITEMS ; i++)

{

ShowItems(m_hWnd, i, hdc);

}

EndPaint(&ps);

return 0;

}

};

End of code

Windows Vista Aero BorderStyle Paint problem as non Administrator

Calvin_Hsia — Wed, 02 May 2007 00:30:00 GMT

Above is an image of an inner form (from the C++ project below) before and after I dragged it a little bit up and left to obscure the title bar, then back to the original position. You can see the title, icon, close/minimize buttons were not painted correctly. The same thing happens in Foxpro and VS 2005.

In my prior post, Fix your forms to paint borders correctly under Vista Aero, I showed how Vista Aero doesn’t allow a window that already exists to change its border unless running as an Administrator.

If you run VS 2005 on Vista with Aero as a non-administrator, you can reproduce the same problem with the Windows Form Designer:

Start VS 2005, choose File->New->Visual Basic->Windows Application

Click on the form in the Form designer to select it, then change the FormBorderStyle property to FixedSingle

Now hover your mouse over the ToolBox to make it appear over the form in the designer. Then move your mouse away to let it disappear (or cause any other VS Window to cover the form).

You’ll see that the Titlebar of the form doesn’t get painted correctly: remnants of the toolbox still exist on the title bar. It works fine running VS as Administrator, Vista without Aero, or Windows XP.

I didn’t install C# on this recently borrowed Vista Aero machine, so I can’t test it, but I suspect it’s the same behavior because it’s the same form designer.

Here’re a few lines of sample C++ code that isolates the problem. (Zip file of VS2005 project with EXE available here)

The program simulates a form designer: it creates a child window with a caption initially, turns off the caption, then turns it back on.

Note that for Windows Styles, WS_CAPTION = WS_BORDER | WS_DLGFRAME

Start VS 2005: choose File->New Project-> Visual C++ Win32 Win32 Project. Call it VistaPaint

In the Win32 Application Wizard, just choose all the defaults and Finish.

Add these lines after this line #include "VistaPaint.h",

#include "atlbase.h"

#include "atlwin.h"

class CForm2 : public CWindowImpl<CForm2>

{

public:

DECLARE_WND_CLASS_EX(L"CForm2", 0, COLOR_MENUHILIGHT) // backcolor

BEGIN_MSG_MAP(CForm2)

END_MSG_MAP()

};

and in the WndProc, add this case in the Switch to handle the WM_CREATE message:

case WM_CREATE:

{

RECT rect;

GetClientRect(hWnd,&rect);

rect.bottom /=2;

rect.right/=2;

CForm2 *pCForm2 = new (CForm2);

pCForm2->Create(hWnd, &rect,L"CForm2",

, /*WS_EX_DLGMODALFRAME |*/ WS_EX_WINDOWEDGE | WS_EX_NOPARENTNOTIFY);

SetWindowLong(pCForm2->m_hWnd, GWL_STYLE, GetWindowLong(pCForm2->m_hWnd, GWL_STYLE) & ~( WS_CAPTION | WS_SYSMENU) ); // turn off caption (WS_CAPTION = WS_BORDER | WS_DLGFRAME )

SetWindowLong(pCForm2->m_hWnd, GWL_STYLE, GetWindowLong(pCForm2->m_hWnd, GWL_STYLE) | ( WS_CAPTION | WS_SYSMENU) ); // turn on caption (WS_CAPTION = WS_BORDER | WS_DLGFRAME )

}

break;

Last, change the InitInstance code to add the WS_CLIPCHILDREN flag: Change the CreateWindow line in InitInstance from

hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,

CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN ,

CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

Now hit F5 to run the code. Move the inner window inside the outer to cause the border to repaint. Observe the border doesn’t get repainted.

Now run the same app as an Administrator (start Windows Explorer, navigate to the Project Debug directory, right click on the EXE file and choose Run as Administrator). Observe that the border paints correctly.

For even more fun, comment out the DECLARE_WND_CLASS_EX line!

Fix your forms to paint borders correctly under Vista Aero

Calvin_Hsia — Sat, 28 Apr 2007 03:31:00 GMT

Apparently, the borders of some forms don’t get painted correctly on Windows Vista.

When executing a Fox Form, Fox asks Windows to create a window, then sets the BorderStyle of the window. Apparently, under Vista Aero (except as Administrator), the BorderStyle cannot be set after the Window has been created.

To reproduce the problem, start Visual FoxPro (I tried back to VFP7 (released summer 2001))

File->New->Form
In the property sheet, dbl-click BorderStyle to change it to 1 or 2

0 = No border ( no problem, because there are no borders to draw)
1 = Fixed Single
2 = Fixed Dialog
3 = Sizable (Default) (no problem, because it’s the default)

Hit Ctrl-E or click on the “!” in the toolbar to run the form. Give it a name
Move the form around so that the borders or title bar will need to be repainted
Result: The window behaves as if there is no border: it won’t get repainted.

Amazingly enough, run under Admin mode, and you’ll see the problem disappear. Perhaps a non-admin app changing the BorderStyle might be a security risk: An app might be able to grab a window handle from another process and impersonate a Credentials screen or something.

When Fox runs a form, it reads the Properties and sets them in the order encountered. For a Form, the “DoCreate” pseudo property means to create the window. The BorderStyle happens to be written after the DoCreate, so the BorderStyle setting is ignored

The properties look like this before the fix:

Top = 0

Left = 0

Height = 250

Width = 375

DoCreate = .T.

BorderStyle = 1

Caption = "Form1"

Name = "Form1"

So your choices are:

Open the Form as a table (It really is just a table) and manually put BorderStyle before DoCreate.
Run the program below that fixes your SCX files by putting the BorderStyle property before the DoCreate
Convert your SCX forms to VCX (Visual Classes), where the BorderStyle is set at window creation time. (Just choose File->Save As Class from the Form designer)
Wait for the next release of VFP SP
Run Vista without Aero
Run your app as Admin

Foxpro Menu items, combo boxes not refreshing selected item under Aero in Vista

Calvin_Hsia — Thu, 26 Apr 2007 21:28:00 GMT

If you’re running a Foxpro application under Vista when using Aero , you might encounter a problem when scrolling through lists, such as intellisense dropdowns, comboboxes, menus.

As you move from one item in the list to the next, each item in turn appears to be selected (colors inverted), which means the prior selected item should be unselected.

However, on Vista Aero, sometimes the prior items do not get painted unselected, thus showing multiple selected items.

There’s a simple workaround (that works back to VFP7): call the GdiSetBatchLimit API.

The GdiSetBatchLimit function sets the maximum number of function calls that can be accumulated in the calling thread's current batch. The system flushes the current batch whenever this limit is exceeded.

This will be fixed in the next SP release of VFP

The workaround is to run these 2 lines of code somewhere in your application only once.

DECLARE integer GdiSetBatchLimit IN WIN32API integer

GdiSetBatchLimit(1)

Create an ActiveX control using ATL that you can use from Fox, Excel, VB6, VB.Net

Calvin_Hsia — Tue, 29 Aug 2006 03:07:00 GMT

Creating an ActiveX control is a good exercise in understanding how one works. It also helps to have full control over its source code for learning and testing purposes. A customer asked about migrating legacy ActiveX controls over to .Net. Many controls can be used without any changes in .Net. (See Using ActiveX Controls with Windows Forms in Visual Studio .NET)

Here are some steps to create an ActiveX control using C++ ATL (Active Template Library) and a few wizards. We’ll add a method and an event, and if you’re really ambitious, we’ll add some GDIPlus calls to draw text and a picture.

Start Visual Studio 2005 (2003 works too, but the steps may be a little different). Now create a new project: choose File->New Project->C++->ATL->ATL Project. Call it “MyCtrl”

In the ATL Project Wizard’s Application Settings, choose “Attributed” and Server Type: DLL. Then choose Finish.

Now we’ll add a control to the project: Choose Project->Add Class->ATL->ATL Control to start the ATL Control Wizard.

Enter the short name "TestCtrl". Note that the ProgId is "MyCtrl.TestCtrl". In Options, choose Connection Points for event support, then Finish the wizard.

Now you can host the control in a client, even though it has no functionality yet. Hit F5 to go, allow it to build. When it asks for an Executable to run for debugging, point it to a host like “c:\program files\....\VFP9.EXE”, VB6.exe, or Excel.exe

Note that the output is MyCtrl.DLL. The extension doesn’t matter: if you want to use the traditional OCX extension, change Project->Properties->Configuration->Linker->General->Output file.

To use the control in VB6, right click on the toolbox and select Components->Controls. Add "MyCtrl 1.0 Type Library"

To use the control in Fox, create a new form, put on an ActiveX Control, then choose "CTestCtrl Object"

In VB.Net 2005, right click on the ToolBox Common Controls, choose "Add Toolbox Items", COM, "CTestCtrl Object"

Depending on which client you choose, you can have VS automatically start the client with F5 and load the control on a form by loading a prior project or executing some code. Choose Project->Properties, Configuration Properties->Debugging. Set the Command Arguments to point to some code to execute or a project.

For Fox, I have command arguments set to "-t t" which means to suppress the Log screen (run VFP9 /? to see other options) and run a program called "t" which contains these lines

CLEAR ALL

MODIFY FORM t nowait

RETURN

You can also view the control on a web page. Right click on TestCtrl.htm in Solution explorer and choose to view in a browser. Note all the security warnings!

Now that you see how easy it is to make a control that does nothing, let’s add some functionality.

Let’s add a method: In Class View (View->Class View), expand MyCtrl and right click on ITestCtrl, choose Add->New Method to start the "Add Method Wizard"

We'll add a method that takes a string parameter and returns an integer: a signature like this:

Function Foobar(bstrString as string) as Integer

In the wizard, set the Method Name to "Foobar"

Now we'll add the first parameter: it's an IN parameter, so check "In". Set the Parameter type to "BSTR" and the name to "bstrString", then choose "Add" to add that parameter.

All COM method calls return HRESULTs, with S_OK (zero) being success. Thus, to get a return value for a method call, we need to add another parameter that's passed by reference, and it's marked by "retval" in the dialog. IOW, if the method has N parameters, the COM method signature will have N+1, with the last parameter being the return value.

However, you'll see the "retval" checkbox disabled until you choose a parameter type that's by reference, such as "LONG *". The "*" indicates it's a pointer, so it's by reference. So Choose "LONG *" and then click on the newly enabled "retval" checkbox. Give it a name "nRetval", then choose "Add".

Now you have 2 parameters for the method.

Similarly, right click on ITestCtrl, choose Add->New Property called "MyString" (this actually adds 2 methods: a get and a set)

In TestCtrl.CPP, put some code in the Method Foobar. To open TestCtrl.CPP, click on CTestCtrl in Class View, and in the bottom pane of Class View, dbl-click on Foobar.

::MessageBox(0,bstrString,L"From Foobar",0);

*nRetval=10;

return S_OK;

Set a breakpoint on the MessageBox line and on the CTestCtrl::get_MyString and CTestCtrl::set_MyString methods.

Hit F5 to go, or test your control in a client. Call the Foobar method, play with the properties of the control. At breakpoints, examine the call stacks and expand the “this” pointer in the CTestCtrl object to see all the COM Interfaces CTestCtrl implements (I copied them from the debug window, pasted into a new VS C++ file, then used the VS Editor Column Select with Ctrl-Alt drag to select columns):

ATL::CStockPropImpl<CTestCtrl,ITestCtrl,&_GUID_4d088eed_554d_4df0_a5e9_

ATL::IPersistStreamInitImpl<CTestCtrl> {...} ATL::IPersistStreamInit

ATL::IOleControlImpl<CTestCtrl> {...} ATL::IOleControlImpl<CTestCtrl>

ATL::IOleObjectImpl<CTestCtrl> {...} ATL::IOleObjectImpl<CTestCtrl>

ATL::IOleInPlaceActiveObjectImpl<CTestCtrl> {...} ATL::IOleInPlaceAct

ATL::IViewObjectExImpl<CTestCtrl> {...} ATL::IViewObjectExImpl<CTes

ATL::IOleInPlaceObjectWindowlessImpl<CTestCtrl> {...} ATL::IOleInPlac

ATL::IPersistStorageImpl<CTestCtrl> {...} ATL::IPersistStorageImpl<CT

ATL::ISpecifyPropertyPagesImpl<CTestCtrl> {...} ATL::ISpecifyProper

ATL::IQuickActivateImpl<CTestCtrl> {...} ATL::IQuickActivateImpl<CTe

ATL::IDataObjectImpl<CTestCtrl> {...} ATL::IDataObjectImpl<CTestCtrl>

ATL::CComControl<CTestCtrl,ATL::CWindowImpl<CTestCtrl,ATL::CWindow,ATL:

ATL::IConnectionPointContainerImpl<CTestCtrl> {...} ATL::IConnectio

ATL::IPropertyNotifySinkCP<CTestCtrl,ATL::CComDynamicUnkArray> {...}

ATL::CComCoClass<CTestCtrl,&_GUID_b2ab8776_ec21_46a2_acf8_fcb9bd1e97bc>

ATL::CComObjectRootEx<ATL::CComSingleThreadModel> {...} ATL::CComOb

ISupportErrorInfo {...} ISupportErrorInfo

ATL::IConnectionPointImpl<CTestCtrl,&_GUID_6ea2a8a2_c809_4dbd_a938_c792

ATL::IProvideClassInfo2Impl<&_GUID_b2ab8776_ec21_46a2_acf8_fcb9bd1e97bc

Also, you'll see that without any implementation on the property get and set, setting and getting the property from the client does nothing.

Let's add some code to respond to mouse clicks on the control. First we need to write a click handler. From Class View, click on CTestCtrl. Near the top of the Properties window (not the Class View window), click on the Messages icon. Choose WM_LBUTTONDOWN, add code. This creates an OnLButtonDown method for you to fill out. I want the code to raise an event in the client. That means we need to modify the ITestCtrlEvents interface, add the definition of a method that the client will optionally implement.

From Class View, click on the ITestCtrlEvents interface (which was added because we chose Connection Point support above) and add a method as we did for the ITestCtrl interface.

Let's call it MyEvent with a single BSTR parameter bstrEventString and no return value. This will be implemented by the client (Fox or Excel) and will be called from our control.

Now add some code to fire the event in the client in your OnLButtonDown handler in TestCtrl.cpp:

LRESULT CTestCtrl::OnLButtonDown(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/)

{

CComBSTR bstr=L"it was clicked";

MyEvent(bstr); // Fire the event: call the client code, if it exists

return 0;

}

Now hit F5 and click on the control to see the event get fired. In the Fox client, add code to the Olecontrol1.MyEvent snippet.

*** ActiveX Control Event ***

MESSAGEBOX(bstreventstring+" From Fox event code")

?PROGRAM(),bstreventstring

For more fun, let’s override the OnDraw method and add some GDIPlus calls.

Add these 2 lines after the other #includes as the top of testctrl.h:

#include "gdiplus.h"

using namespace Gdiplus;

Then rename the OnDraw method (in the same file: TestCtrl.h) to be OnDrawOld, and add this code. Be sure to point to a jpg file on your machine and note that backslash is an escape character and needs to be doubled.

(For production code, we’d call GdiplusShutdown and cache the Image.)

Notice how the ActiveX control determines the difference between design time and run time.

HRESULT OnDraw(ATL_DRAWINFO& di)

{

BOOL fRunMode=0;

GetAmbientUserMode(fRunMode);

static Gdiplus::GdiplusStartupInput gdiplusStartupInput;

static ULONG_PTR gdiplusToken=0;

if (gdiplusToken == 0) {

Gdiplus::GdiplusStartup(&gdiplusToken, &gdiplusStartupInput,NULL);// note: call GdiplusShutdown!!!

}

Gdiplus::Graphics MyGraphics(di.hdcDraw);

Gdiplus::Image MyImage(L"d:\\kids.jpg",0);// some jpg: backslash needs to be doubled. Cache this!

RectF rect(

(REAL)di.prcBounds->left,

(REAL)di.prcBounds->top,

(REAL)(di.prcBounds->right - di.prcBounds->left),

(REAL)(di.prcBounds->bottom - di.prcBounds->top));

MyGraphics.DrawImage(&MyImage,rect);

if (!fRunMode) // if design mode, draw some text

{

Gdiplus::Font MyFont(L"Arial",16);

Gdiplus::StringFormat sf;

PointF pf(rect.X,rect.Y);

SolidBrush MyBrush(Color(128,0,128,255));

MyGraphics.DrawString(L"Design Time!",12,&MyFont,pf,&MyBrush);

}

return S_OK;

}

Now we’ll have to link with the GDIPlus library, so go to Project->Properties, Configuration Properties->Linker->input->Additional Dependencies and add Gdiplus.lib.

Hit F5 and have fun!

Below is sample Fox client code that doesn’t use the Fox form designer, so it will not be in design mode:

PUBLIC ox

ox=CREATEOBJECT("MyForm")

ox.visible=1

DEFINE CLASS MyForm as Form

ADD OBJECT OC as olecontrol WITH ;

oleClass="MyCtrl.TestCtrl",;

height=200,width=300

left=200

AllowOutput=.f.

PROCEDURE oc.MyEvent(bstreventstring as String)

MESSAGEBOX(bstreventstring+" From Fox event code")

?PROGRAM(),bstreventstring

?this.foobar("Call the Foobar method")

ENDDEFINE

When you try it in a VB.Net application, try this code:

Private Sub AxCTestCtrl1_MyEvent(ByVal sender As System.Object, ByVal e As AxMyCtrl._ITestCtrlEvents_MyEventEvent) Handles AxCTestCtrl1.MyEvent

MsgBox(e.bstrEventString)

End Sub

Host the CLR and Generate IL to call a MessageBox

Calvin_Hsia — Tue, 08 Aug 2006 01:07:00 GMT

Here’s some C++ code to host the CLR. It’s an alternative to using COM Interop (see A Visual Basic COM object is simple to create, call and debug from Excel), or using a User Control (see Create a .Net UserControl that calls a web service that acts as an ActiveX control to use in Excel, VB6, Foxpro)

I created a C++ native project in a Visual Studio Solution and added a method called “foobar” which uses COM to start the CLR using CorBindToRuntimeEx. It then loads an assembly and calls the “EntryPoint” method, with a single string parameter.

I added a VB.Net Class Library project into the VS Solution which created an assembly (d:\dev\vb\CLRHostTest\bin\debug\CLRHostTest.dll) that has a static method called “EntryPoint” that takes a single string parameter. The method dynamically generates (using System.Reflection.Emit) an assembly called “testasm” with a module called “MyModule”, which has a public class called “FoobarType” and a static method called “Main”. The code in “Main” shows a messagebox of the parameter passed to “EntryPoint”

Quite a bit of work just to show a MessageBox!

#include "assert.h"

#include <mscoree.h>

#import <mscorlib.tlb> raw_interfaces_only rename("ReportEvent","ReportEventManaged") //high_property_prefixes("_get","_put","_putref")

using namespace mscorlib;

void foobar() {

HRESULT hr;

CComPtr<ICLRRuntimeHost> pHost = NULL;

hr = CorBindToRuntimeEx(L"v2.0.50727",L"wks",0 //STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN | STARTUP_CONCURRENT_GC

,CLSID_CLRRuntimeHost, IID_ICLRRuntimeHost, (void **)&pHost);

_ASSERT(hr == S_OK);

hr = pHost->Start();

_ASSERT(hr == S_OK);

DWORD retVal;

hr = pHost->ExecuteInDefaultAppDomain(L"d:\\dev\\vb\\CLRHostTest\\bin\\debug\\CLRHostTest.dll",

L"CLRHostTest.CLRHostTestClass",L"EntryPoint",L"System.Windows.Forms.MessageBox.Show(\"test\")",&retVal);

_ASSERT(hr == S_OK);

pHost->Stop();

exit(0);

}

Here’s the VB code that gets called:

Imports System.Reflection

Imports System.Reflection.Emit

Public Class CLRHostTestClass

Shared Function EntryPoint(ByVal cArg As String) As Integer

' MsgBox("here in CLRHostTest " & cArg)

Dim asmName As AssemblyName = New AssemblyName("testasm")

Dim appDomain As AppDomain = System.Threading.Thread.GetDomain

Dim asmBldr As AssemblyBuilder = appDomain.DefineDynamicAssembly(asmName, AssemblyBuilderAccess.Run)

Dim moduleBldr As ModuleBuilder = asmBldr.DefineDynamicModule("MyModule")

Dim typeBldr As TypeBuilder = moduleBldr.DefineType("FoobarType", TypeAttributes.Class + TypeAttributes.Public)

Dim methodBldr As MethodBuilder = typeBldr.DefineMethod("Main", MethodAttributes.Public + MethodAttributes.Static, _

GetType(Integer), New System.Type() {GetType(String)})

Dim ilg As ILGenerator = methodBldr.GetILGenerator()

Dim msgboxMethodInfo As Reflection.MethodInfo = GetType(System.Windows.Forms.MessageBox).GetMethod( _

"Show", BindingFlags.Public + BindingFlags.Static, Nothing, _

CallingConventions.Standard, New System.Type() {GetType(String)}, Nothing)

ilg.Emit(OpCodes.Ldstr, cArg)

ilg.EmitCall(OpCodes.Call, msgboxMethodInfo, Nothing)

ilg.Emit(OpCodes.Ret)

Dim mytype As Type = typeBldr.CreateType()

mytype.InvokeMember("Main", BindingFlags.Public + BindingFlags.InvokeMethod + BindingFlags.Static _

, Nothing, Nothing, New String() {"aa"})

Return 10

End Function

End Class

Another way to call the method using mixed mode managed C++ (compiling with /clr)

#using "d:\dev\vb\CLRHostTest\bin\debug\CLRHostTest.dll"

void foobar()

{

System::String^ s = "Some text";

CLRHostTestClass::EntryPoint(s);

}

BTW, it was very hard to find documentation on the “^” (circumflex or caret) character. Try typing it into a search engine! Here’s a link: Handle to Object on Managed Heap

Customize the VS debugger display of your data

Calvin_Hsia — Tue, 07 Feb 2006 00:03:00 GMT

As a software developer, I spend much of my time looking at code, learning how it works, and figuring out how to modify or fix it. A very good tool to help examine code is the Visual Studio debugger.

(Even if you’re not a hard core programmer, the following tutorial shows some of the power of the Visual Studio components, such as the project system, build system, debugger, working together.)

At a breakpoint I can examine local variables in the Watch, Auto or Locals window to see their values and types. If it’s a class or structure, the debugger will show a “+” that indicates it can be expanded and the first couple members of that structure. Structures submembers or inherited values can be examined. These structures can get very deep. Sometimes I need to inspect a value that’s dozens of levels down in a hierarchy. That’s a lot of complicated tree navigation in the debugger. Other times I need to take a local variable name (or a member of that variable if it’s a structure/class), drag and drop it to a new line in the Watch Window, then type cast it to a value that’s more meaningful. As I step through code, the variable might go out of scope, or it might have a different name in a subroutine, so I’d have to repeat the typecasting steps in the watch window with the different variable name.

For example, suppose one of the variables is called VBLine and is an internal representation of a line of VB.NET code. It’s much more meaningful to see “Dim MyVar As String”, then a bunch of hex numbers in the debugger. I drag/drop it to the watch window, typecast it to a “DIM” statement, and expand/navigate the results to find “MyVar”. Then, I step into the next called function, with VBLine passed as an argument. The receiving function names the parameter VBStatement, so my watch window drilldown needs to be modified to use the different variable name.

This gets very cumbersome. Let’s improve it!

Here’s a simple demonstration of how you can control what the debugger displays.

Start Visual Studio (2003 or 2005. (It also works in VS7, although the steps might be slightly different.)
Choose File->New->Projects
Choose Visual C++->Win32 Console Application, call it Test
Click Finish on the wizard.

Now paste in some sample code to debug:

#include "windows.h"

int _tmain(int argc, _TCHAR* argv[])

{

OSVERSIONINFOEX osinfo; // Declare a structure

ZeroMemory(&osinfo, sizeof(osinfo)); // init it to 0

osinfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX); // set the size

GetVersionEx((LPOSVERSIONINFO) &osinfo); // call WinAPI to fill it in

WIN32_FIND_DATA FAR ffd; // Declare a structure

FindFirstFile("c:\\windows\\system32\\k*.exe",&ffd); // Find the first file starting with "k"

return 0; //set bpt here

}

This sample code just calls the Windows API functions GetVersionEx and FindFirstFile, which fill structures that we can examine in the debugger.

To make things simple, let’s use ANSI rather than Unicode chars (VS2005 defaults to Unicode). Choose Project->Properties->Configuration Properties->General->Character Set and change it to “Use Multi-Byte Character set” rather than “Use Unicode Character Set”

Let’s also remove the check for 64 bit portability issues:

Choose Project->Properties->Configuration Properties->C++->General and turn off “Detect 64 bit portability issues”

Hit F9 on the “return” line to set a breakpoint.

Then hit F5 to build and run the project.

When the breakpoint hits, the debug window shows:

+ osinfo {dwOSVersionInfoSize=284 dwMajorVersion=5 dwMinorVersion=1 ...} _OSVERSIONINFOEXA

+ ffd {dwFileAttributes=32 ftCreationTime={...} ftLastAccessTime={...} ...} _WIN32_FIND_DATAA

Now let’s control the string displayed for a given type.

Open the file called AutoExp.dat (installs with VS) in the VS editor:

File->Open->File. On my machine it’s c:\Program Files\Microsoft Visual Studio 8\Common7\Packages\Debugger\Autoexp.dat

This file describes how to customize the output of the Debug Watch, Locals, and Auto windows. It’s formatted like an INI file.

Add this line to the AutoExp.Dat file in the [AutoExpand] section.

_OSVERSIONINFOEXA = Hi there <szCSDVersion> Build number = <dwBuildNumber>

Now hit F5 to go to the breakpoint.

Now the watch window shows:

+ osinfo {Hi there 0x0013fe58 "Service Pack 2" Build number = 2600} _OSVERSIONINFOEXA

This is a big improvement: we’ve told the debugger which members of the structure to show and how to format them! We can still click on the “+” to drill down the member hierarchy.

When starting a debug session, the debugger reads the AutoExpand file and if the left of the equals matches the type in the Type column of the Locals/Watch/Auto window, then the right side will direct how to format the displayed string. The comments at the beginning of AutoExp.dat give more details, including more formatting options.

This is great, but it’s nothing compared to what we’ll do next!

You can write code that executes in the debugger process that can read the memory of the debugee! AutoExp.dat controls this feature too.

Replace the above line with these 3 lines

_OSVERSIONINFOEXA= $ADDIN(MyDbgEE.dll,?EE_OSVERSIONINFOEXA@@YGJKPAUtagDEBUGHELPER@@HHPADIK@Z)

_WIN32_FIND_DATAA =$ADDIN(MyDbgEE.dll,?EE_WIN32_FIND_DATAA@@YGJKPAUtagDEBUGHELPER@@HHPADIK@Z)

MyClass = $ADDIN(MyDbgEE.dll,?EE_MyClass@@YGJKPAUtagDEBUGHELPER@@HHPADIK@Z)

The $ADDIN(DllName,FunctionName) syntax means that the DLL named will be loaded, the FunctionName export in the DLL will be called. (Ignore the gobbledygook: it’s just C++ name decorating indicating the calling convention, the parameters, etc.) If any error occurs, like the DLL can’t be found, the export can’t be found, or the DLL caused an exception, the displayed string will be “{???}”

Now let’s create the project that will build MyDbg.DLL and add it to the current solution.

Choose File->New->Project->Visual C++ Win32 Project, call it MyDbgEE and choose to Add to solution (rather than to Create New Solution).

In the Win32 App Wizard that appears, change the Application Type to a DLL.

Change the project properties as above to non-Unicode and no 64 bit issues.

Add these lines:

#define ADDIN_API __declspec(dllexport)

typedef struct tagDEBUGHELPER

{

DWORD dwVersion;

BOOL (WINAPI *ReadDebuggeeMemory)( struct tagDEBUGHELPER *pThis, DWORD dwAddr, DWORD nWant, VOID* pWhere, DWORD *nGot );

// from here only when dwVersion >= 0x20000

DWORDLONG (WINAPI *GetRealAddress)( struct tagDEBUGHELPER *pThis );

BOOL (WINAPI *ReadDebuggeeMemoryEx)( struct tagDEBUGHELPER *pThis, DWORDLONG qwAddr, DWORD nWant, VOID* pWhere, DWORD *nGot );

int (WINAPI *GetProcessorType)( struct tagDEBUGHELPER *pThis );

} DEBUGHELPER;

ADDIN_API HRESULT WINAPI EE_OSVERSIONINFOEXA( DWORD dwAddress, DEBUGHELPER *pHelper, int nBase, BOOL bUniStrings, char *pResult, size_t max, DWORD reserved )

{

wsprintf(pResult,"Testing Addr = %x Uni = %d base = %d %x",dwAddress,bUniStrings, nBase, *(DWORD *)dwAddress);

return S_OK;

}

ADDIN_API HRESULT WINAPI EE_WIN32_FIND_DATAA( DWORD dwAddress, DEBUGHELPER *pHelper, int nBase, BOOL bUniStrings, char *pResult, size_t max, DWORD reserved )

{

WIN32_FIND_DATA FAR ffd;

DWORD nGot=0;

pHelper->ReadDebuggeeMemory(pHelper,dwAddress,sizeof(ffd),&ffd,&nGot);

wsprintf(pResult,"FindData found file '%s' DBG Process ID = %d",ffd.cFileName, GetCurrentProcessId());

return S_OK;

}

Now we need to tell VS where to put the built DLL so the debugger can find it. We can use the build events in the project.

For the DLL project, choose Project->Properties->Configuration Properties->Build Events->Post Build Event->Command Line. Put in copy $(TargetPath) "$(DevEnvDir)" Make sure you have the quotes and parentheses right. If you put in a description string, then that string will be echoed to the Output Window when building. Now when you rebuild, the debug dll will be copied to the same dir as Devenv.exe.

Now hit F5 and see the values in the debug window! Bring up Task Manager and notice that the Process ID shown is the same as that of the Devenv.exe debugger process.

To make things more interesting, let’s see how our debug code can read the debugger memory. We’ll add some code to obscure a desired value, but we’ll dig for it in the debug dll. Add this code after the “#include windows.h” line in the main Test code

struct MyClass {// normally this will go in #include file

int mymem1; // make the 1st few members irrelevant, so debugger won't show interesting info

int mymem2;

int mymem3;

int mymem4;

int mymem5;

short *str; // make this not a string, so debugger won't show it as a string

MyClass * m_pNextClass; // self referential, perhaps like a linklist

};

Now add this code to just before the “return” statement:

MyClass * pMyClass = new MyClass(); // declare a new instance of MyClass

pMyClass->str = new short(8); // create a heap allocated byte array

memcpy(pMyClass->str,"NotMe!",7); // desired value to see in debugger

pMyClass->m_pNextClass = new MyClass(); // make a submember instance

pMyClass->m_pNextClass->str = new short(8); // heap allocated submember string

memcpy(pMyClass->m_pNextClass ->str,"Bingo!",7); // desired value to see in pMyClass

This code creates a class MyClass with a pointer to another instance of MyClass which contains the desired debug display value.

Now we need to modify the debug dll to dig for the value. Copy the same structure definition above into the debug dll code. (Typically, these definitions will be in a shared #include file.)

Add this code:

ADDIN_API HRESULT WINAPI EE_MyClass( DWORD dwAddress, DEBUGHELPER *pHelper, int nBase, BOOL bUniStrings, char *pResult, size_t max, DWORD reserved )

{

DWORD nGot=0;

MyClass oMyClass;

pHelper->ReadDebuggeeMemory(pHelper,dwAddress,sizeof(oMyClass),&oMyClass,&nGot); // read the debuggee's structure

char szMainStr[100];

char szMemberStr[100];

*szMemberStr=0; // init to empty string

if (oMyClass.m_pNextClass) // if there's a sub member

{

MyClass oNextClass;

pHelper->ReadDebuggeeMemory(pHelper,(DWORD)oMyClass.m_pNextClass,sizeof(oNextClass),&oNextClass,&nGot); // read it

pHelper->ReadDebuggeeMemory(pHelper,(DWORD)oNextClass.str,sizeof(szMemberStr),&szMemberStr,&nGot); // read it's string

}

pHelper->ReadDebuggeeMemory(pHelper,(DWORD)oMyClass.str,sizeof(szMainStr),szMainStr,&nGot); // read the string of the main struct

wsprintf(pResult,"MyClass string is '%s'. Submem = '%s'",szMainStr,szMemberStr);

return S_OK;

}

Now hit the F5 button and Bingo! You can still drill down into the class manually as before, so you haven’t lost any functionality.

The debug DLL can be rebuilt even while debugging: it’s loaded/unloaded as needed by the debugger. That means persisting values might be cumbersome. I’ve used custom registry keys for persisting values, like global variables.

I’ve been using this debug expression evaluator architecture for years for huge projects, including Visual Foxpro and Visual Basic.Net, and I find it indispensable and a huge time saver.

See also: EEAddIn: Uses the Expression Evaluator Add-In API to extend the native debugger expression evaluator.

Very Advanced Debugging tips

Windows Security and how it affects running generated code

Calvin_Hsia — Thu, 10 Nov 2005 09:00:00 GMT

Here I described how VFP generates executable code and runs it for early and late binding COM clients and implementing COM interfaces. However, there is an important issue with generating and running executable code in the same process.

A computer has a processor (or a few) that fetches instructions from memory and executes them. Some of the instructions refer to other areas of memory. The Operating System loads the memory initially. Various areas of memory are used for different purposes:

Code (the program)
Stack (for local variables and return addresses)
Heap
Initialized Data (like constants)
Uninitialized Data (like an uninitialized static array)

It gets a little more complicated with multiple DLLs each of which may have its own code/data sections, and threads, each of which will have its own stack, but we’ll ignore this for now.

Certain areas of memory will remain constant for the process lifetime, such as the code. Other areas will change dynamically, such as the stack and the heap. The CPU will fetch instructions only through the Instruction Pointer.

The NX feature prevents code from running from non-code marked pages of memory, so if the IP points to an NX area of memory, an exception is thrown. Certain viruses and worms cause execution of code from the stack or heap, so this prevents certain kinds of malicious attacks.

The generated machine code for VFP COM servers and implemented interfaces lives in heap memory, so the IP will be fetching instructions from the heap.

(This feature is called NX (No Execute) on AMD machines, XD (Execute Disable) by Intel, and DEP (Data Execution Prevention) on Windows Server 2003 and I believe, WinXP SP2. Does anyone see this feature on WinXPSP2?)

To test this, I installed VFP8 and VFP9 (RTM) on an AMD64 machine running Windows Server 2003 SP1. Right click on My Computer, select Properties->Advanced->Performance Settings->Data Execution Prevention->Turn on DEP for all programs and services except those I select:

Then I built my universal COM server below (which is used to run my website, by the way) and tested it. On a WinXP machine, the code runs fine, with both early and late bound calls succeeding. If I use CREATEOBJECTEX to create an object which will be accessed via early binding, I can use GETINTERFACE to get the IDispatch interface to call it via late binding. Conversely, an object that is created via CREATEOBJECT will be accessed by late binding, but I can use GETINTERFACE to get its early bound interface

On the AMD machine with DEP enabled, VFP8 caused an Access Violation (see What is a C0000005 crash?) for the early bound calls, but VFP9 worked just fine. Why? Because generated executable code in VFP9 now gets put into a memory page marked with the PAGE_EXECUTE_READWRITE flag.

If your application invites any other 3^rd party code into the process space (such as ActiveX controls, COM servers, DECLARE DLL, Load/Call or a SET LIBRARY TO) and you are getting unexpected errors, it may be due to this NX feature.

These articles go into a lot more detail: http://en.wikipedia.org/wiki/NX_bit

A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003

* A universal COM server

TEXT TO tempvar NOSHOW

DEFINE CLASS c1 as session olepublic

proc MyDoCmd(cCmd as string,p2 as Variant,p3 as Variant,p4 as Variant,p5 as Variant) helpstring 'Execute a command'

&cCmd

proc MyEval(cExpr as string,p2 as Variant,p3 as Variant,p4 as Variant,p5 as Variant) helpstring 'Evaluate an expression'

RETURN &cExpr

ENDDEFINE

ENDTEXT

STRTOFILE(tempvar,"c1.prg")

IF FILE("t1.dll") && unregister prior one

DECLARE integer DllUnregisterServer IN t1.dll

?"Unregister",DllUnregisterServer()

CLEAR DLLS

ENDIF

IF !FILE("t1.pjx") && the GUIDS are stored in the project, so to keep the same GUID, use the same PJX

BUILD PROJECT t1 FROM c1

ENDIF

BUILD MTDLL t1 FROM t1

*Test it:

ox=CREATEOBJECT("t1.c1") && create late bound object (IDispatch interface)

?ox.MyEval("_vfp.servername")

?"Late bound object with late bound call ",ox.MyEval("'EarlyLate='+sys(2334)")

oEarly = GETINTERFACE(ox,"IC1")

?"Late bound object with early bound call ",oEarly.MyEval("'EarlyLate='+sys(2334)")

CLEAR ALL

oEarly=CREATEOBJECTEX("t1.c1","","") && create early bound object (IC1 interface)

?"Early bound object with early bound call",oEarly.MyEval("'EarlyLate='+sys(2334)")

oDisp=GETINTERFACE(oEarly,"IDispatch")

?"Early bound object with late bound call",oDisp.MyEval("'EarlyLate='+sys(2334)")

What is a C0000005 crash?

Calvin_Hsia — Wed, 30 Jun 2004 23:36:00 GMT

In my blog about Dr. Watson I talked about product crashes. What is an example of a crash? How destructive is it?

Here’s a simple example. MyFunction takes a string parameter and calculates its length

MyFunction (char * StringParam) {

int nlen; // declare an integer variable

nlen = strlen(StringParam);

}

Doesn’t look like there’s a bug does it?

But there’s a potential bug: the strlen function in the C Standard Library counts the bytes in the string before finding a zero (null) byte. If the string does not have a null byte, then the strlen function will be accessing memory beyond the string buffer looking for a null byte.

This is called a Buffer Overrun error. If the memory accessed beyond the string is not allocated to the process, then a C0000005 exception (Access Violation) will result. If this exception is unhandled by the process, then the ‘unhandled exception handler” of the OS will be invoked. This is typically Dr. Watson. (However, the memory may be legitimately accessed, but may be overwritten by a virus that takes advantage of a buffer overrun on a strcpy Standard Library function).

If you have Visual Studio installed, you can look at the file PlatformSDK\include\ntstatus.h to find some of the various kinds of exceptions:

// MessageId: STATUS_ACCESS_VIOLATION

// MessageText:

// The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

#define STATUS_ACCESS_VIOLATION ((NTSTATUS)0xC0000005L) // winnt

In the old days of Win3.11, there was no memory protection enforcement: Accessing any memory in the process address space was fair game. strlen would just cruise merrily through the process memory, even through non-owned memory, until it found a null byte. Thus, old code may run fine on old OS’s, but when run on a new OS, it might crash.

The C Standard Library (also known as the runtime library) is not part of the C language, but it is assumed by all C development environments (particularly the linker) to be available. Microsoft’s versions have “MSVCRT” in their names. When the string functions were defined, the strings were assumed to be character arrays with a terminating null byte. This implies possible buffer overruns, as well as that no strings can have embedded nulls (like binary data).

The C++ language has just as much accessibility to the C Standard library, although string classes and objects can be used. Thus buffer overruns are still around. Most processes that run on your computer today are primarily written in C or C++.

Using managed code in .NET, a string is an object that has a length property. No null terminating byte is assumed.

What are the consequences of a crash? If it occurs in a User mode application, then that process is no longer running, but all other running processes on the machine are still valid. If it occurs in a kernel mode application, such as a device driver, all bets are off because the erroneous code had much higher access rights to the machine than a user mode program.

Except for video driver crashes, I haven’t rebooted my machines in years due to a crash.

Most of the security bulletins and Windows Updates are due to buffer overruns. If the standard library had been defined to pass in a maximum length parameter along with every string buffer, many of these security patches would never exist.