Random header image... Refresh for more!

dynamic Has a Use! Partial Verification of Complex Classes in Test Automation

I don’t like dynamic in C#.  It’s one of those features that seems to serve only to confuse the language.  And yeah, I get that Ruby and Python are doing it, but if Ruby and Python jumped off a bridge, would you?

When I first picked up C#1, I liked it for three reasons: 

  1. Garbage collection.
  2. It had a built-in string class.
  3. It actively prevented you from doing stupid things that C++ was fine with.

When they added “var” to the language, reason #3 died a little.  People started using “var” to declare ordinary variables where the type is known.  Sure, the compiler can figure out what the type is, but a human can’t, at least not by just reading the code without a knowledge of the return type of the function you just called. 

And then along came “dynamic” and walloped reason #3 over the head with a large stick.  Now, not even the compiler knows what you’re doing.  You have to wait until runtime to tell if your code is going to work.  It’s a bit like programming in Basic on a Commodore 64, except you’ll get a RuntimeBinderException instead of “?SYNTAX ERROR IN 150”2.  The end result is the same, a stupid typo broke your code when someone else tried to run it. 

It doesn't make any sense here, either.

 The idea behind dynamic is that it lets you write code against certain types of COM objects and dynamic objects from languages like Python and Ruby.  Of course, COM should be dead by now and that maybe MS Office’s Automation should look at this new-fangled .Net thing that everyone else in Redmond has been using FOR TEN YEARS, and that maybe if you want to use features from Python or Ruby that maybe you should actually be using Python or Ruby, but whatever…  The way dynamic works is that you can declare a variable as type “dynamic”, just like you’d declare it a “string” or an “int”, and this tells the compiler that you have no idea what the object is.  Since you don’t know what it is and since the compiler doesn’t know what it is, you can go ahead and call any method you’d like on it or use and property on it and theoretically, it’ll work.  It’s called “Duck Typing”, as in “quacks-like-a”.  In other words, I don’t care what object X really is and I don’t want to force it to be a subclass of Y or implement interface Z.  All I care about is whether or not it can “Quack()”.  If it can “Quack()”, then it’s enough of a Duck for me to use in my function. 

In most cases, dynamic in C# doesn’t actually mean that you can dynamically change the structure of the underlying object.  Whatever that object is, it’s still that type, even though you’re hiding it behind the dynamic keyword.  Think of dynamic as if it’s “var” with amnesia.  “var” knows what type it is at compile time, so you can ask it “Do you know how to quack?” and it can tell you.  With dynamic, it won’t know whether or not it can quack until the code actually runs, at which point its memory comes back and it remembers how to quack.  Either way, whether it knows how to quack at run-time or compile-time, the thing quacking is still a duck. 

Now, I don’t know about you, but I don’t trust amnesiac ducks. 

You see, since you can call any method or property on the dynamic object, you have to simply hope that whatever the object turns out to be when you run it actually implements that method or property, or else you’re totally screwed.  Also, since there’s no Intellisense to guide you, you’d better hope that you spelled the property or method correctly, or else you’re totally screwed.  Oh, yeah, and since there’s no type checking, you’d better hope that the type of that property or the types of the parameters or return value of the method are what you think they are, or else you’re totally screwed. 

It’s this whole “…or else you’re totally screwed” bit that turns me off about dynamic.  There’s a lot of ways this can go wrong, and when it goes wrong, you don’t know it’s gone wrong until the program is running and it dies.  And, of course, it won’t do that until it’s out live in production and a customer comes across the bug, and the whole site goes down and the closest tester gets blamed for missing the bug.  You can see how that would be a problem for me, so you can understand why I don’t like dynamic

But then I found a way to actually make use of dynamic to solve a testing problem I’ve been having. 

Before I go into details, let me first say that I’m a bit reluctant to share this idea, for several reasons: 

  1. I don’t like dynamic, so it feels dirty to use it in this way.
  2. I haven’t really fully explored this idea, so it could be a complete load of nonsense.
  3. It’s voodoo magic code and I don’t like using voodoo magic code because no one can understand voodoo magic code.  I know that I’m going to spend more time explaining how it works to other people than they’re going to spend using it, because they’re going to look at it and be scared away.
  4. “…or else you’re totally screwed”.  It would not be good to have test cases that fail at runtime because of typos.
  5. It feels like this is half of a good idea, and that once I figure out what the missing half of the puzzle is, I’ll have something that’s useful and won’t scare people away and won’t feel dirty.  I don’t like writing about half an idea.
  6. I don’t like dynamic.

However, I’m sharing it because I want it to be a good idea and hope that writing about it will get me thinking about how to solve those remaining problems. 

Anyway, here’s the scenario: 

Where I work, we have services that return complex objects.  Sometimes, these objects can have upwards of 20 properties, and some of those properties are classes that have more properties on them.  In other words, there’s more properties floating around in these objects than in most Florida land scams.  Testing these objects is relatively straightforward, though.  Simply create a parallel object with the expected values, and walk through the expected and actual objects property by property, comparing the values.  If something doesn’t match, fail the test. 

The problem I have is that for most of my tests, I don’t really care about most of those properties.  Each test only focuses on a handful of values and the rest don’t matter.  The one-size-fits-all approach of walking the properties required an exact match.  If I only care about four or five properties, why should I have to specify values for the other 15?  I might not even know what they are.  One of the properties could be something like response time, which I have no way of knowing at the time I write the test.   But, I don’t want to have to write custom validation for each test to check only the values it cares about, because that’s inefficient and difficult to maintain. 

Let’s give a more concrete example class to work off of here. 

 
public class SearchResult
{
        public string Title { get; set; }
        public string Excerpt { get; set; }
        public string URL { get; set; }
        public double Score { get; set; }
        public int Size { get; set; }
        public int Position { get; set; }
        public DateTime IndexedTime { get; set; }
        public string CacheURL { get; set; }
} 

 

This class is a simplification of a result returned from a search engine.  Each result has a title, an excerpt of text from the page, a URL for the page and internal information, like the confidence score of the result, the size of the page, the date the page was last indexed, the position of the result, and, if available, a URL for a cached copy of the page. 

Here’s the property by property checker: 

 
public void CompareResults(SearchResult expected, SearchResult actual)
{
    Assert.AreEqual(expected.CacheURL, actual.CacheURL, "CacheURL mismatch");
    Assert.AreEqual(expected.Excerpt, actual.Excerpt, "Excerpt mismatch");
    Assert.AreEqual(expected.IndexedTime, actual.IndexedTime, "IndexedTime mismatch");
    Assert.AreEqual(expected.Position, actual.Position, "Position mismatch");
    Assert.AreEqual(expected.Score, actual.Score, "Score mismatch");
    Assert.AreEqual(expected.Size, actual.Size, "Size mismatch");
    Assert.AreEqual(expected.Title, actual.Title, "Title mismatch");
    Assert.AreEqual(expected.URL, actual.URL, "URL mismatch");
}

 

Now, let’s write a test:  If I search for “dogs”, then I expect to get the Wikipedia entry for “Dogs” as my top result. 

 
public static void CheckThatWikipediaIsInResultsForDogs()
{
    SearchResult expected = new SearchResult();
    expected.URL = "http://en.wikipedia.org/wiki/Dogs";
    expected.Title = "Dog - Wikipedia, the free encyclopedia"; 
    expected.Position = 0;

    SearchEngine engine = new SearchEngine();
    SearchResult actual = engine.Search("dogs"); 

    CompareResults(expected, actual);
} 

 

Now we run it and…  Aw crap.

Assert Failed! != http://www.mathpirate.net/cache?=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDogs : CacheURL mismatch

The test failed, not because the Wikipedia entry wasn’t the result, which is what I cared about, but because the CacheURL was wrong.  I don’t care about the CacheURL.  There are other tests somewhere else that will deal with CacheURL.  Now, I can specify it if I want to, but I also have to specify the excerpt and the page size and the last indexed time, etc.  But I’m not going to .  I don’t give a flying monkey dance about those values in this test, so it’s stupid to specify them.  The “CompareResults” method has to change.

One fairly simple way to take care of that problem is to check for non-null or non-default values and not check the values if the value is the default.  Here’s the new and improved CompareResults:

public static void CompareResults(SearchResult expected, SearchResult actual)
{
    if (expected.CacheURL != null) { Assert.AreEqual(expected.CacheURL, actual.CacheURL, "CacheURL mismatch"); }
    if (expected.Excerpt != null) { Assert.AreEqual(expected.Excerpt, actual.Excerpt, "Excerpt mismatch"); }
    if (expected.IndexedTime != default(DateTime)) { Assert.AreEqual(expected.IndexedTime, actual.IndexedTime, "IndexedTime mismatch"); }
    if (expected.Position != default(int)) { Assert.AreEqual(expected.Position, actual.Position, "Position mismatch"); }
    if (expected.Score != default(double)) { Assert.AreEqual(expected.Score, actual.Score, "Score mismatch"); }
    if (expected.Size != default(int)) { Assert.AreEqual(expected.Size, actual.Size, "Size mismatch"); }
    if (expected.Title != null) { Assert.AreEqual(expected.Title, actual.Title, "Title mismatch"); }
    if (expected.URL != null) { Assert.AreEqual(expected.URL, actual.URL, "URL mismatch"); }
}

Run it now and it passes.  It didn’t care about the missing CacheURL.  Hey, problem solved!

Except…   The new and improved CompareResults is new and improved and still broken.

Here’s what was returned from the Search method:

Notice that Position is set to 5.  In my test, I explicitly set that position should be 0.  CompareResults missed it because  of the check that I added: if(expected.Position != default(int)).  default(int) isn’t some magic value, like “undefined”.  It’s “0”.  Plain old zero.  So when that line executed, it became if(0 != 0)3.  And so, the check was skipped and it missed the fact that the test should have failed.  The same problem will occur if you’re explicitly checking for a null property value.

So…  What to do?

There are multiple options to handle this case, none of them very pleasant:

  • Live with it.  One-size-fits-all never actually fits you.  Deal.
  • Write custom validation for every test that needs to check a default or null value explicitly.  Hope that everyone remembers this needs to be done.
  • Write a parallel set of classes that mimic the actual class, but have boolean properties like “PositionSet” for every single property on the object. 
  • Go back to the original method that checks everything exactly, but write custom pre-treater methods that can go in and clear out values that you don’t care about before you do the comparison. 4

Or…

Use dynamic.

Here’s how it works:

Instead of creating an instance of the type of object that you want to create, you create a dynamic object, and only set the properties you care about.  Then, in the comparison method, it can check if you’ve set the value, and then do the comparison if you have.  If not, it gets ignored.  This solves the problem of forcing a check on values you don’t care about as well as the problem of default values.  If you didn’t set the value up front, it’s not there, so the verification method won’t look at it.

Let’s see it in action:

public static void CheckThatWikipediaIsInResultsForDogsDynamic()
{
    dynamic expected = new ExpandoObject();
    expected.URL = "http://en.wikipedia.org/wiki/Dogs";
    expected.Title = "Dog - Wikipedia, the free encyclopedia";
    expected.Position = 0;

    SearchEngine engine = new SearchEngine();
    SearchResult actual = engine.Search("dogs");

    CompareResultsDynamic(expected, actual);
}

The test method looks almost identical.  The only notable difference is the first line.  I changed “SearchResult expected = new SearchResult();” to “dynamic expected = new ExpandoObject();”5.  The properties are set on the object the same way, the function is called the same way.

public static void CompareResultsDynamic(dynamic expected, SearchResult actual)
{
    if (PropertyExists(expected, "CacheURL")) { Assert.AreEqual(expected.CacheURL, actual.CacheURL, "CacheURL mismatch"); }
    if (PropertyExists(expected, "Excerpt")) { Assert.AreEqual(expected.Excerpt, actual.Excerpt, "Excerpt mismatch"); }
    if (PropertyExists(expected, "IndexedTime")) { Assert.AreEqual(expected.IndexedTime, actual.IndexedTime, "IndexedTime mismatch"); }
    if (PropertyExists(expected, "Position")) { Assert.AreEqual(expected.Position, actual.Position, "Position mismatch"); }
    if (PropertyExists(expected, "Score")) { Assert.AreEqual(expected.Score, actual.Score, "Score mismatch"); }
    if (PropertyExists(expected, "Size")) { Assert.AreEqual(expected.Size, actual.Size, "Size mismatch"); }
    if (PropertyExists(expected, "Title")) { Assert.AreEqual(expected.Title, actual.Title, "Title mismatch"); }
    if (PropertyExists(expected, "URL")) { Assert.AreEqual(expected.URL, actual.URL, "URL mismatch"); }
}

This is the new CompareResults function.  First, the “expected” parameter has changed.  It’s now “dynamic” instead of “SearchResult”.  The Asserts themselves are identical, and they’re still wrapped inside of if statements, but the if conditions have changed.  Instead of looking for nulls or default values, they’re checking that the property exists on the dynamic object.

This is one part where the whole dynamic thing is sorely lacking.  There’s no built-in way to tell if an object can do what you want it to do without trying to do it.  It’s like you’re commanding the duck to “Quack, damn you!”, without first asking “Can you actually quack?”.  Ruby’s got “respond_to?(‘Quack’)”, while C# has “Do it yourself and don’t forget to account for all of the different possibilities of how the quacking can be done, otherwise just try to  ‘Quack’ and catch the exception”.  Here’s a very abbreviated and probably error-prone example of how to ask if an object supports the property you want to call:

public static bool PropertyExists(object dynamicObject, string propertyName)
{
    if (dynamicObject is ExpandoObject)
    {
        IDictionary<string, object> expando = (IDictionary<string, object>)dynamicObject;
        return expando.ContainsKey(propertyName);
    }
    else
    {
        return dynamicObject.GetType().GetProperty(propertyName) != null;
    }
}

First, it checks if the object is an ExpandoObject.  If it is, then it can use the explicit IDictionary implementation on IDictionary in order to find out if the property exists or not.  Otherwise, it uses basic Reflection to ask if the object has the property you’re looking for.  This PropertyExists method will probably need a bit of work for general consumption, but it’s a start and works well enough for this example.

But…  Does it work?

Assert Failed! 0 != 5 : Position mismatch

It didn’t complain about the CacheURL, like the first solution did, but it did catch the Position mismatch, which the second solution missed.  I’d call that a success!

There are, of course, problems with this solution…

  • There’s no Intellisense, so you have to know what the object looks like.  Of course, what you can do there is write the initialization with the actual class, then change it to dynamic once you have all of the properties in place.
  • There’s no compile-time checking, so if you make a typo or if a property disappears or changes names, you don’t know about it until everything breaks at runtime.  Or worse, nothing breaks at all, but you end up not checking the values you think you’re checking. 6
  • It’s voodoo magic code.  You’re going to be the only one who understands how it works, so you’re on the hook for making sure it actually does work and you’ll going to be the one that gets blamed or cursed every time something goes wrong.

Like I said, it’s half of a good idea and I haven’t really explored all of its benefits and consequences yet.  The core is here and I know this is a good place to start and build something awesome on top of.  I already have some ideas of where this could go.  Like toward a generic exapandable data-driven object comparison framework.

But that’s for another time…

Here’s the code from this post:  http://www.mathpirate.net/svn/Projects/AutomationUsingDynamic/

  1. I came through C++ and hadn’t been exposed to Java at that time. []
  2. Okay, it’s more like writing JavaScript, but whatever. []
  3. if(0!=0){ throw new UniverseDestroyingParadoxException(“Critical Mathematical Foundation Error.  Please Reboot.”); } []
  4. I admit that I’ve done this once.  It was not one of my better moments. []
  5. ExpandoObject is a type that does some magic with the C# dynamic runtime binder.  I’m not going to explain how it works, after all, there are search engines for that.  However, using ExpandoObject lets you dynamically add members to your dynamic object.  If you tried to do this with an ordinary object, you’d get a RuntimeBinderException because the property you’re setting isn’t there. []
  6. Why, oh why didn’t they do something like “dynamic<T>” for at least some compile-time checking? []

January 1, 2011   No Comments

Just throw;ing this out there.

In C#, what’s the difference between “throw;” and “throw e;”?

This is one of those “Interview Question” tidbits of language trivia.  It’s the sort of thing that you can probably remember the exact circumstances where you learned about it, because it was probably preceded by three hours of frustration and confusion.  It’s the sort of thing that I’d always assumed separated the serious C# programmers from the casual passerby.

Until today…

Today, this issue came up and I was honestly surprised by the number of people around me who didn’t know the difference, and even more surprised about how the difference seems to be missing from official sources, like the C# Language Specification1, so I felt compelled to write about it.

To clarify, I’m asking about the difference between “throw;” and “throw e;”, where you’re rethrowing an exception that was caught inside a catch statement.

In other words, this:

public static void DoSomething()
{
    throw new Exception("Thrown on line 12.");
}

public static void ExceptionRethrower()
{
    try
    {
        DoSomething();
    }
    catch (Exception e)
    {
        LogException(e);
        throw e;
    }
}

So, DoSomething(); does something and throws an exception2.  You want to catch it and log it or whatever, but you want the exception to bubble up to the callers of ExceptionRethrower() for some reason.  I’m sure you’ve written code like this somewhere.

And there it is, “throw e;” at the end of the catch.  Let’s write a bit of code to call this function and catch the exception, and see what turns up.

static void Main(string[] args)
{
    try
    {
        ExceptionRethrower();
    }
    catch (Exception e)
    {
        Console.WriteLine(e);
    }
}

Okay…  So, the function DoSomething is throwing an exception, which is caught and logged in ExceptionRethrower, then rethrown up to Main, where the exception and its stack trace are printed out.  That means the stack trace will have DoSomething on top, then ExceptionRethrower, followed by Main on the bottom, right?

System.Exception: Thrown on line 12.
   at ThrowExample.Program.ExceptionRethrower() in E:\svn\Projects\ThrowExample\ThrowExample\Program.cs:line 26
   at ThrowExample.Program.Main(String[] args) in E:\svn\Projects\ThrowExample\ThrowExample\Program.cs:line 34

Nope.

It’s got Main and ExceptionRethrower, but what happened to DoSomething?  And the exception message says that I threw it on line 12, but according to the stack trace, I was nowhere near line 12.

So…  WTF?

Let’s play with the debugger, instead.  I’m going to comment out the try/catch in Main and let the exception fall out and kill my app and see what VS has to say about it.

Line 26 is my “throw e;”.  It’s eating my stack trace!

Okay, so, let’s see what happens if I just “throw;”, instead.

System.Exception: Thrown on line 12.
   at ThrowExample.Program.DoSomething() in E:\svn\Projects\ThrowExample\ThrowExample\Program.cs:line 12
   at ThrowExample.Program.ExceptionRethrower() in E:\svn\Projects\ThrowExample\ThrowExample\Program.cs:line 26
   at ThrowExample.Program.Main(String[] args) in E:\svn\Projects\ThrowExample\ThrowExample\Program.cs:line 34

Hey, look!  DoSomething() is there in the trace now, with the exception originating on line 12 like it should.

So, there’s your answer to the original question:  Rethrowing the instance, as in “throw e;” will discard the existing stack trace and make it look like the exception originated on the “throw e;” line, while a parameterless “throw;” will retain the original stack trace.

Sort of…

Look at that second stack trace again.  Look closely at the line numbers.  It still has line 26, where the “throw;” is located, but the call to DoSomething() is on line 21.  It should, like the call stack below shows, have DoSomething() line 12 (Where the exception was thrown), then ExceptionRethrower() line 21 (Where DoSomething() was called), then Main() line 34 (Where ExceptionRethrower() was called).

How did line 21 get tossed aside for line 26?  Well, think about the stack for a moment.  When you’re generating a stack trace, either on the call stack side or on the exception side, each function has a single frame, pointing at the last line that was executed.  When you’re at line 12 in DoSomething(), the last line in ExceptionRethrower() was line 21.  However, once the exception is thrown, you hit the catch in ExeceptionRethrower() and get rerouted, so by the time you end up in Main(), the last line called in ExceptionRethrower() was line 26 at the throw;.  This also means that if you throw, catch, and rethrow, all in a single function, the stack trace will end up pointing at the rethrow, regardless of whether you’re using “throw;” or “throw e;”.

Of course, if that whole “call stack” explanation I just gave actually held any water, then adding in a finally block would cause the stack trace to point at the last line of the finally, because that was the last line of the function executed.  However, that’s not the case.  Even when you add in the finally, the stack trace still points at the throw line.   But hey, the explanation still sounds plausible, so I’m leaving it in this post.  I’m sure it’s something close to that, anyway.  It’s a good thing finallys don’t affect the trace, because if it did, I can’t imagine how wildly FUBARed some stack traces would end up. 3

In general, if you have to catch and rethrow an exception, you should use the plain throw;.  If you rethrow the instance using throw e;, you’ll have a hard time debugging and testing, because your stack traces will all dead end at a throw that’s nowhere near the source of the problem.  However, if you’re writing a library or service for third-party consumption, then throw e; provides a quick way to let exceptions get out to the callers while hiding some of the implementation details of your code by killing off the call stack. 4

Another thing to be aware of is that whichever rethrowing scheme you use, the original instance is used.  That means that if you save off the exception instance for later, the stack trace will have been wiped out or modified by the time you want to use it.  Even more subtle and insidious is that this means that if you’re using a threaded logger of some sort, there’s a chance that the stack trace will be mangled by the time the logger gets around to writing out the exception.  In other words, some times the log will say the exception’s on line 12, other times it’ll say the exception’s on line 26. 5

The sample code is here: http://www.mathpirate.net/svn/Projects/ThrowExample/

To reiterate, for those who skipped to the end:

  • “throw e;” wipes out the stack trace, restarting it at the point of the throw.
  • “throw;” maintains the existing stack trace, but still mangles the stack of the current frame.
  1. I couldn’t find it in there, anyway… []
  2. From line 12, obviously… []
  3. By the way, speaking of finally blocks, did you know that you can’t return from one?  There’s another bit of obscure language trivia for you. []
  4. Of course, if you actually think that’s a good idea, then you probably will want to rethink your exception handling strategy in general…  That’s just the only reason I could think of for deliberately using throw e; to rethrow a caught exception. []
  5. Have fun debugging that one… []

December 13, 2010   No Comments

Let’s Start a Dialog

.Net:

if(MessageBox.Show("Are You Sure?", MessageBoxButtons.YesNo) == DialogResult.Yes) { DoWork(); }

Android:

     AlertDialog.Builder dialogBuilder = new AlertDialog.Builder(this);
     dialogBuilder.setTitle("Save File");
     dialogBuilder.setMessage("Are you sure?");
     dialogBuilder.setPositiveButton("Yes",
       new DialogInterface.OnClickListener()
       {
        public void onClick(DialogInterface dialog, int which)
        {
         doWork();
        }
       });
     dialogBuilder.setNegativeButton("No",
       new DialogInterface.OnClickListener()
       {
        public void onClick(DialogInterface dialog, int which)
        {
         dontDoWork();
        }
       });
     dialogBuilder.setCancelable(true);
     dialogBuilder.setOnCancelListener(
       new DialogInterface.OnCancelListener() {
     
     public void onCancel(DialogInterface dialog)
     {
      dontDoWorkHereEither();
     }
    });
     dialogBuilder.show();

OMG.  WTF.  SERIOUSLY?

Why write just one line of code when TWENTY-NINE will do the same thing just as well?

December 12, 2010   No Comments

Best Line So Far

string twit = "SarahPalinUSA";

September 6, 2010   No Comments

The Extendables

And when your example code relies on extension methods, please make sure that you have the namespace which contains those extension methods references.

I am so ready to take the Baseball Bat of Great Justice and hand out a Beat Down Of Many Angers on these people.

Listen, it’s simple:

  • .Net 3.0 was largely a mistake.  var and extension methods were part of that mistake.  Don’t use var and extension methods all over the place.  If you don’t know the right place to use them, don’t use them at all.
  • THE DOCUMENTATION MUST NOT SUCK.  No documentation is often better than bad documentation.
  • CODE SAMPLES MUST COMPILE.  You have to realize that people are going to copy and paste whatever is on your page and try to compile it.
  • The easiest way to meet the requirements of THE DOCUMENTATION MUST NOT SUCK and CODE SAMPLES MUST COMPILE is to write a sample class, test it, then paste the entire class into your page.

GRRRRRRRRRRRRRRrrrrrrrrrrrrrrrr

September 5, 2010   No Comments

var-y annoying

I want to smack people who use “var” all over the place in their code.  Particularly in their example code.

I AM NOT A COMPILER.  I DON’T DO TYPE INFERENCE.

September 5, 2010   No Comments

Source Code Repository

By the way, for those of you playing the home game, I’m checking in the code as I go:  http://www.mathpirate.net/svn/Projects/EchoChamber/

September 4, 2010   No Comments

Um. No.

for (int i = 0; i < PrefixLength; PrefixLength++)
{
     prefixQueue.Enqueue(EchoToken.TerminatorWord);
}

Oops.

September 3, 2010   No Comments

Windows Workflow Quick Tip

Given that I spent all day looking for this and had trouble finding it (Okay, I’ll be honest, I skipped a page in the book because it didn’t look relevant, but whatever), if you ever need to get the name of the currently executing state on a Windows Workflow (WF) State Machine Workflow, there’s a class you can use called StateMachineWorkflowInstance.  StateMachineWorkflowInstance has a property called CurrentStateName to give you the name as a string and another called CurrentState, which gives you an instance of the StateActivity object that’s currently running.

For some reason unknown to me, StateMachineWorkflowInstance isn’t derived from WorkflowInstance1, so the WorkflowInstance you get back from WorkflowRuntime.CreateWorkflow can’t be cast to a StateMachineWorkflowInstance instance.  Instead, you have to new up the object yourself.  The constructor takes the WorkflowRuntime where the workflow is executing, and the Guid returned by the InstanceId property on the WorkflowInstance that was returned by CreateWorkflow for the workflow you want to know the state for.

  1. Cause, you know, .Net is all object orienty and such, so that’s what I would’ve done… []

June 15, 2010   No Comments

Temporal Mechanics: Changing the Speed of Time, Part II

So, you want to change the speed of time, eh?  Now, I trust that you’re only going to change this on your own computer and not do anything to your coworker’s computer when they go for coffee and leave their machine unlocked and unattended for a few minutes, correct?  Okay, let’s begin.

First, before you go changing the speed of time, let’s see how fast time is going.  In order to do that, there’s a Win32 function called “GetSystemTimeAdjustment”.  Here’s the signature:

BOOL WINAPI GetSystemTimeAdjustment(
    __out PDWORD lpTimeAdjustment,
    __out PDWORD lpTimeIncrement,
    __out PBOOL lpTimeAdjustmentDisabled
);

Of course, Win32 C is terribly ugly and nasty to work with, so I’m going to do this in C#.  That means a P/Invoke, but at least I won’t have to deal with __out PDWORDs and the like.  Here’s that bit:

[DllImport("kernel32.dll")]
public static extern bool GetSystemTimeAdjustment(out uint timeAdjustment, out uint timeIncrement, out bool timeAdjustmentDisabled);

It’s still sort of ugly, but not nearly as totally ugly, so it’s all right.  If you’re not completely familiar with all of this DllImport stuff and static externs and out parameters, that’s okay.  I’m going to mock your ignorance of the language, but aside from that, it’s no big deal.  Now let’s give it a call and see who answers.

uint timeAdjustment;
uint timeIncrement;
bool timeAdjustmentDisabled;

GetSystemTimeAdjustment(out timeAdjustment, out timeIncrement, out timeAdjustmentDisabled);

Console.WriteLine("Adjustment: {0} Increment: {1} Adjustment Disabled: {2}", timeAdjustment, timeIncrement, timeAdjustmentDisabled);

On my current home machine (XP, not on a domain), I get this as the output:

Adjustment: 156250  Increment: 156250  Adjustment Disabled: True

If you recall my previous entry on this topic, you’ll remember that the Windows Time Service would add a certain number of 100ns units to the system clock every 15.6 ms or so.  The Adjustment number is the number of 100ns ticks it will add, and the Increment number is the number of 100ns ticks of supposedly “real” time that will elapse between time adjustments.  Obviously, Increment is not completely accurate, it doesn’t mean precisely 15.625 ms of real world time, because if it did, then Adjustment would always equal Increment, and your clock would be completely accurate with no drift whatsoever, so there would be no need for automatic adjustments.  In this case, Adjustment does equal Increment.  However, if you look at the final value, Adjustment Disabled is true.  That means the automatic time adjustments are disabled.  When that’s disabled, the Windows Time Service isn’t doing any of the gradual corrections that I talked about in the last post, instead, it considers your physical clock ticks to be good enough.  Your computer clock will likely drift over time.  On my machine, I’m not joined to a domain or anything like that.  Instead, I’m configured to talk to time.windows.com once a week and resync my clock.

Of course, printing that information out just once is somewhat boring.  I strongly recommend putting it in a loop and printing it out every couple of seconds.

while (true)
{
    GetSystemTimeAdjustment(out timeAdjustment, out timeIncrement, out timeAdjustmentDisabled);
    Console.WriteLine("Adjustment: {0} Increment: {1} Adjustment Disabled: {2}", timeAdjustment, timeIncrement, timeAdjustmentDisabled);
    Thread.Sleep(5000);
}

If you’re on a domain or otherwise have your system clock actively and frequently being kept in line by something, I would strongly urge you to do the following fun experiment at this point.

  1. Compile this program.
  2. Run this program.
  3. If Adjustment Disabled == false, put your computer’s clock ahead or back a minute or so.
  4. Watch the program for a while.

You’ll see something like this over the course of the next 20 minutes or so (Your numbers will vary).

Adjustment: 156250  Increment: 156250  Adjustment Disabled: False
Adjustment: 145125  Increment: 156250  Adjustment Disabled: False
Adjustment: 154412  Increment: 156250  Adjustment Disabled: False
Adjustment: 156159  Increment: 156250  Adjustment Disabled: False
Adjustment: 156225  Increment: 156250  Adjustment Disabled: False
Adjustment: 156247  Increment: 156250  Adjustment Disabled: False
Adjustment: 156249  Increment: 156250  Adjustment Disabled: False
Adjustment: 156250  Increment: 156250  Adjustment Disabled: False

Remember that adjustment is how much time is being added to your system’s clock at each tick.  The Windows Time Service synced with your domain controller and realized that your system time was off by about a minute.  Because of that, it decided that it needed to run slow for a bit to allow reality to catch up.  When Adjustment went to 145125, it meant that every 15.6 ms, the computer only added 14.5 ms to its timer.  A difference of only 1.1 ms per tick, but when you consider that there are about 64 ticks in a second and 60 seconds in a minute, you’re talking a difference of over 4 seconds per minute of real time.  Which means that at a rate like that, every minute of real time will only be 56 seconds in warped computer time.  That will very quickly add up and within 15 minutes, that minute you set your clock off will be made up.

However, the Time Service is cautious and doesn’t wish to over correct, so it will shoot for lower than the full time offset.  That means basically that instead of trying to close the full minute in one shot, it’ll pull back only 50 seconds.  Then it will go seven seconds, then two seconds, then a fraction of a second.  My experience with the time service is that the adjust will try to softly land on Increment, getting closer and closer until the two are even.

Under normal circumstances, if Adjustment is higher than Increment, it means that your clock is running slow and the Time Service is speeding up your system’s time to catch up with reality.  If Adjustment is lower than Increment, your clock is ahead and the Windows Time Service will put on the brakes and decelerate time to allow reality to catch up.

Normal circumstances aren’t much fun, though.  Let’s go for a few abnormal circumstances, shall we?

I did promise that you would be able to change the speed of time on your own.  That means no Time Service involvement.  If you want your clock to take off like a Prius with a stuck accelerator and janky brakes, I can help you make that happen.

There’s a GetSystemTimeAdjustment, so naturally, there’s gotta be a SetSystemTimeAdjustment.

BOOL WINAPI SetSystemTimeAdjustment(
    __in DWORD dwTimeAdjustment,
    __in BOOL bTimeAdjustmentDisabled
);

Let’s sharpen that up a bit…

[DllImport("kernel32.dll")]
public static extern bool SetSystemTimeAdjustment(uint timeAdjustment, bool timeAdjustmentDisabled);

It should be noted that the DWORD parameter of the C turns into a uint argument.  Initially, I had written the P/Invoke signature using a signed integer.  I thought it would be fun to set the time adjustment to -156250, to watch the clock go backwards.  Unfortunately, when -156250 gets treated as an unsigned integer, it becomes, well, 4294811045.  So, instead of watching my computer’s clock run backwards, I saw it zoom to the future at a rate of a day every 3.14 seconds.  Which, I have to admit, was totally awesome.

Anyway, I strongly suggest that you first call GetSystemTimeAdjustment and see what the adjustment value is first, so that you’ll have a good idea of where you want to set the value to get the effect you want.  Rememember, double the base and the clock goes twice as fast, cut the base in half and your clock moves at half speed.  I haven’t found a way to go back in time yet, but that sort of thing only causes universe destroying paradoxes, so perhaps that’s for the best.

So, now, if you run it, giving some reasonable (or unreasonable) number as the value of Adjustment, what you’ll probably find is that ABSOLTELY NOTHING happens.  This is, of course, the unseen impact of the Temporal Security Agency preventing you from tampering with time. 1  They don’t like it when you mess with that sort of thing.  To get around that, you have to ask for the “SE_SYSTEMTIME_NAME” privilege beforehand.  I have no idea at all what that means, I just know that the documentation says you need it and offers you no practical guidance whatsoever as to how you’re supposed to acquire it.

What to do when you’re faced with obtuse documentation on an obscure subject like Win32 Privilege Tokens?  Steal the code from the Internet, of course.

        //The code in this block is not mine and I make no claims to it.
        //I don't really even know what it's doing...
        #region Code stolen from the Internet.
        private const int ANYSIZE_ARRAY = 1;
        private const string SE_SYSTEMTIME_NAME = "SeSystemtimePrivilege";
        private const int SE_PRIVILEGE_ENABLED = 0x00000002;
        private const int TOKEN_QUERY = 0x0008;
        private const int TOKEN_ADJUST_PRIVILEGES = 0x0020;

        [StructLayout(LayoutKind.Sequential)]
        public struct LUID
        {
            public int LowPart;
            public int HighPart;
        }

        [StructLayout(LayoutKind.Sequential)]
        public struct LUID_AND_ATTRIBUTES
        {
            public LUID Luid;
            public int Attributes;
        }

        [StructLayout(LayoutKind.Sequential)]
        public struct TOKEN_PRIVILEGES
        {
            public int PrivilegeCount;
            [MarshalAs(UnmanagedType.ByValArray, SizeConst = ANYSIZE_ARRAY)]
            public LUID_AND_ATTRIBUTES[] Privileges;
        }

        [DllImport("advapi32.dll", CharSet = CharSet.Auto)]
        public static extern bool OpenProcessToken(int ProcessHandle, int DesiredAccess, ref int TokenHandle);

        [DllImport("kernel32.dll", CharSet = CharSet.Auto)]
        public static extern int GetCurrentProcess();

        [DllImport("advapi32.dll", CharSet = CharSet.Auto)]
        public static extern bool LookupPrivilegeValue(string lpSystemName, string lpName, [MarshalAs(UnmanagedType.Struct)] ref LUID lpLuid);

        [DllImport("advapi32.dll", CharSet = CharSet.Auto)]
        public static extern bool AdjustTokenPrivileges(int TokenHandle, int DisableAllPrivileges, [MarshalAs(UnmanagedType.Struct)] ref TOKEN_PRIVILEGES NewState, int BufferLength, [MarshalAs(UnmanagedType.Struct)] ref TOKEN_PRIVILEGES PreviousState, ref int ReturnLength);

        public static bool AdjustPrivileges()
        {
            TOKEN_PRIVILEGES tkNew = new TOKEN_PRIVILEGES();
            tkNew.Privileges = new LUID_AND_ATTRIBUTES[ANYSIZE_ARRAY];
            TOKEN_PRIVILEGES tkOld = new TOKEN_PRIVILEGES();
            tkOld.Privileges = new LUID_AND_ATTRIBUTES[ANYSIZE_ARRAY];

            LUID luid = new LUID();
            int token = -1;
            int oldluidSize = 0;

            if (LookupPrivilegeValue(null, SE_SYSTEMTIME_NAME, ref luid))
            {
                if (OpenProcessToken(GetCurrentProcess(),
                TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, ref token))
                {
                    tkNew.PrivilegeCount = 1;
                    tkNew.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
                    tkNew.Privileges[0].Luid = luid;
                    int luidSize = Marshal.SizeOf(typeof(TOKEN_PRIVILEGES));
                    if (AdjustTokenPrivileges(token, 0, ref tkNew, luidSize, ref tkOld, ref oldluidSize))
                    {
                        return true;
                    }
                }
            }
            return false;
        }
        #endregion Code stolen from the Internet.

That code isn’t mine.  I don’t know whose it is and I don’t know what it does exactly.  All I know is it magically makes all the time stuff work, and for that I am grateful.  Anyway, now all you should have to do is add a call to AdjustPrivileges() at some point before you try to call SetSystemTimeAdjustment.  Like so:

    if (!AdjustPrivileges())
    {
        throw new Exception("AdjustPrivileges failed.");
    }

    if (!SetSystemTimeAdjustment(312500, false))
    {
        throw new Exception("SetSystemTimeAdjustment failed.");
    }

 

Before you run this, let me just warn you not to run this.  I don’t know what it’s going to do to your computer.  You’re changing time randomly.  That can never be a good thing.  So don’t do it.

Since you’re going to do it anyway, here’s two ways to try to get yourself out of an uncontrolled time slide.  Kill the program first, then try to resynchronize your clock by going into your taskbar clock and telling it to update the time.  If that doesn’t work, stop and restart the Windows Time Service.  And if that doesn’t work, well, I told you not to do it and you didn’t listen to me, so don’t go blaming me.

The source code is located here, in case you don’t feel like typing in everything by hand: http://www.mathpirate.net/svn/Projects/SpeedOfTime/

Now, make sure you have a watch or a clock or something that will display seconds and that’s not tied to your computer in any way.  Make sure it’s roughly synchronized (within a second or two) of your computer.  Then press play and do the time warp.

What’s checked in will cause your computer to travel through time twice as fast as reality.  You can, of course, tweak the number and modify how fast or slow you want to go.  Pay attention to the read-out, though.  If the Windows Time Service is actively adjusting your time, it will likely override your temporal anomaly and either fix the clock outright, or at least modify the adjustment so you start to return to normality.  To prevent unwanted chronometric realignment, you may want to stop the Windows Time Service while you’re messing around.

For those of you smart enough not to play the home game, here’s a video which will demonstrate the effects of time compression and dilation.

And now, here’s the effects of a non-linear temporal anomaly.

  1. I know you’re there, Agent Blackwood! []

March 20, 2010   No Comments