Terrorism: It's a Dog's Life! And, It Just Works...

This morning I heard a piece on the K9 Enforcement Detection program. These dogs, many of which come from animal shelters because their feisty behavior (good for this program) was too much for their original owners, have detected over 40,000 concealed HUMANS in cargo, etc - not to mention tons of explosives and drugs.

The dogs are trained that if they smell a human they can't see, they should make an alert to their handler. All the training is basically positive reinforcement and play to the dogs.

This program costs a measly $3.5 million a year, a drop in the bucket compared to the multimillion dollar high-tech equipment we have that's designed to do to same work and may actually be more effective than the machines.

In addition, the dogs are highly portable and can be flown anywhere on a moment's notice.

Support our Troops - Woof!

It Just Works

I had to do another C++ conversion recently on a custom C++ program that takes a file and a password and performs a custom XOR MD5 encryption on the file. The original code supplied by the vendor had a front-end console application that just looked for the file names and password as command line arguments, so I was able to immediately throw that part out.

Previously I had done a number of managed to unmanaged C++ wrappers, but this time I decided to try "IJW". Turns out that it really does "Just Work" - with some provisos - in this case the inputs were of type unsigned char* (equivalent to a byte array).

The managed code signature looks like:

void Encryption.Encrypt (byte* plaintext, byte* cyphertext, sbyte* pwd);

You can see what's required to perform the marshaling of the parameters to the underlying native C++ types below:

// Modifications to the C++ class (Compile with /CLR switch)
#using <mscorlib.dll>
using namespace System;

public __gc class Encryption


void Encrypt(unsigned char * plainText, unsigned char *cypherText, char *pwd)

the above gets compiled with the /CLR switch, which tells C++ to generate a managed code assembly
// C# calling class:

string outputString = System.Text.Encoding.UTF8.GetString(cb);
byte[] pbData = new byte[cb.Length];
byte[] cbData = new byte[cb.Length];
byte[] pwdByt=System.Text.Encoding.UTF8.GetBytes(password);
byte[] pwdBytData = new byte[pwdByt.Length];
IntPtr ptrb = Marshal.AllocHGlobal(b.Length);
IntPtr ptrcb = Marshal.AllocHGlobal(cb.Length);
IntPtr ptrPwd = Marshal.AllocHGlobal(pwdByt.Length);

byte[] resByt=new byte[cb.Length];

string fileName2=fileName+".enc";
string resultPath = basePath +fileName2;
FileStream fs2 = new FileStream(resultPath,FileMode.Create );

catch(Exception ex)


Bottom line? I could have spent hours attempting to translate the complicated encryption algorithm to C#. Instead all i had to do was add some cool __gc stuff to the native C++ code, figure out the marshaling of the pointers, and I was good to go.

Buzzwords Department:

Microsoft announced the release of the first beta release of its Windows Vista client operating system, and with it the company also announced official names for the operating system's presentation and communication subsystems, formerly known by the code names "Avalon" and "Indigo," respectively.

According to sources, Microsoft will officially name Avalon the Windows Presentation Foundation (WPF) and Indigo the Windows Communication Foundation (WCF).
Microsoft officials said Windows Vista, formerly known as Longhorn, offers substantial benefits to developers, particularly around WinFX, the managed code programming model that builds on the .Net Framework.


ASP.NET 2.0: Strange 404 Errors and the "App_Offline.htm" file

If you get strange HTTP 404 errors in your ASP.NET 2.0 application, always check for a zero-length "magic file" called app_offline.htm and delete it. If this file is present in your web site, then the entire application will be considered offline by the ASP.NET runtime. There is actually a button that says "Take application offline" which creates this file, but unfortunately the "magic file" can also "magically appear", so you can spend quite some time chasing bugs that aren't there. Post-beta 2 builds are expected to provide a proper explanation.

The reason it can appear by itself is that it's used to "take the application offline" when copying a web site. If this operation crashes somewhere in the middle for some reason, the file doesn't get deleted. For ADO.NET and Databases, if ASP.NET has open connections, you can shut down the application domain by adding a file named "app_offline.htm" to the Web application root directory. This has the effect of shutting down the application domain (not the process) and redirecting all requests to the application to this file (returning a 404 response code).

To allow the application to restart, remove this file. Note that simply closing connections in your page code will not release the file lock, because by default the ADO.NET connection pool retains the active connections.


Don't have to Pee in the Boat!

This comes up so often (guilty of it meself) that I have to write about it.

Programmers often come up with a scheme of logic in how they are going to implement their particular business scenario. Sometimes it is elegant, sometimes it's complicated. But more often than not, it isn't always completely "thought through".


Two Irishmen are fishing on a lake. One pulls in a bottle, and as he unhooks it from the line, a genie pops out and offers him one wish.
"Turn the lake into beer", the fisherman says.
Genie waves his hand and -- "Poof" -- the whole lake turns into sparkling Harps!
Fisherman turns to his buddy and says, "Well, what do you think?"
His buddy says, "You jerk! Now we'll have to pee in the boat!"

Do you find yourself often having boxed yourself in, without a clear path to the Mens (or Ladies) room, and no key? And you have to "Pee in the Boat", e.g. you have to work around all the code you have already written, just to get something done that you perhaps didn't think about in advance.

I don't believe in anything that sounds like "Extreme Programming" or says you are supposed to "Smell the Code"-- for this very reason. I'd rather have everybody get together, map everything out, discuss all the logic beforehand (especially you want to do this when there is more than one programmer involved, because you can end up "Peeing in the Boat" just by yourself!). Now! --Once there's a plan, a contract, a schema, and some logic, the likelihood of getting your collective self "boxed in" and having to "Pee in the Boat" goes way down!

Nothing like a Harps after a heavy programming session -- along with a comfy place to pee! After all, we wouldn't want to spoil the lake, now, would we?


IISRESET Yields "Class not registered", ASP.NET 2.0 Solution Model, and Virtual Earth

Here's the fix:

Use the following command:
C:\Windows\system32\inetsrv\iisrstas.exe /RegServer

While I am on this, IISRESET comes with some handy command line switches that many people are not aware of:

IISRESET.EXE (c) Microsoft Corp. 1998-1999

iisreset [computername]

/RESTART Stop and then restart all Internet services.
/START Start all Internet services.
/STOP Stop all Internet services.
/REBOOT Reboot the computer.
/REBOOTONERROR Reboot the computer if an error occurs when starting,
stopping, or restarting Internet services.
/NOFORCE Do not forcefully terminate Internet services if
attempting to stop them gracefully fails.
/TIMEOUT:val Specify the timeout value ( in seconds ) to wait for
a successful stop of Internet services. On expiration
of this timeout the computer can be rebooted if
the /REBOOTONERROR parameter is specified.
The default value is 20s for restart, 60s for stop,
and 0s for reboot.
/STATUS Display the status of all Internet services.
/ENABLE Enable restarting of Internet Services
on the local system.
/DISABLE Disable restarting of Internet Services
on the local system.

Tip: I keep a link to this on the tray, and if I am working with a solution where IIS has a lock on a file, all I have to do is hit it, and I am good to go!

Now, the

ASP.NET 2.0 "FileSystem" based Solution model:
I've read lots of complaints about not being able to find or reload a WebSite solution using the File System Option. That's not accurate. If you want to be able to reload a complete Solution that has a File System - based web site in it (using the built-in "cassini-meanie" Web server), just SAVE the solution file in the same folder! Now you can zip it up and send it to somebody, and when they click on the Solution file, everything will be just fine! This includes any and all additional Class Library or Control projects in the solution, as long as you have placed them under the folder tree that represents the root of the FileSystem - based Web Site. Really, I find it difficult to understand why this seems to be such an obstacle to some developers. All this fiddling with IIS and worrying about permissions and everything else is just made incredibly easy with this method. And, you can always change it to a real IIS - based web solution anytime you want. In addition if you've got SQLExpress MDF etc. files for a database that is reference by and goes with the solution, you are good to go with no hassle at all! I just don't think it can get any easier. . .

These incessant kvetchers remind me of the joke about the Jewish grandmother at the beach whose 5 year old grandson is suddenly swept out to sea by a huge wave. She looks up to the heavens and says, "Dear God, please send him back! He's my only grandson!" Suddenly another huge wave rolls in and deposits the kid back on the beach, good as new. She looks up to the heavens and says, "He had a HAT!"....

Finally, MS is releasing an early version of Virtual Earth here. Let's see what the API looks like. Here is some API Stuff.. Its very easy to use!


An Interesting Story about Contract First (and other tidbits)

This morning I had the simplest class, marked Serializable, and ran it through an XmlSerializer test just to "be sure". Little booger started throwing those weirdo XmlSerializer exceptions. They are so hard to understand, even if you look at the InnerException, its enough to make you go stark, raving mad.

Finally, I thought, "How about doing it backwards?" In other words, Let's write the XSD Schema and be happy with it. Then, we just fire up XSDObjectGen and let the tool generate the class, right?

Well, it serialized perfectly right out of the box. I had gotten a property assignment wrong (mistakenly assigned to the public field instead of the private one in the ctor).

There's something to be said for Contract First!

On a somewhat related side note, Oleg Tkachenko, XML MVP, has announced that XPathReader 1.1 is available. Nice Stuff, lean and mean XPath rocks!

And another: this morning I spent some time letting FXCop have fun with the assemblies in my latest Solution. It came up with a lot of stuff that "doesn't necessarily fit" (which rules can be easily turned off). However, it also came up with some very useful best - practices items concerning naming conventions, and in a couple of cases, places where the classes own disposable objects and on which I had not implemented IDisposable (so I did, and not only that - I wired up the calling classes to actually make the call!). I'd recommend FXCop if you have never used it. Best practices coding is -- well, best practices coding!

Finally, Microsoft Update replaces Windows Update with all the Office stuff all combined into one. Try it!

And, on a humorous note, Tiberias OsBurn has a cool article about "Over OOPing". I really had to laught at this one, because I myself have seen this "First Hand".


Some observations on Script Callbacks, "AJAX", "ATLAS" "AHAB" and where it's all going.

I've taken a more than cursory interest in the whole Remote Scripting (.NET species) vs. AJAX and now ATLAS discussion, mostly because I started using Remote Scripting since Microsoft first released it, and because I continued to refine it after seeing Brent Ashley's excellent work with JSRS, which was one of the first "real" cross-browser solutions back in 2000 (that's the turn of the Century for you history buffs).

Now Bertrand Leroy, a Microsoft guy whose work I like, has authored some very interesting ASP.NET 2.0 script callback stuff that he points to on his blog, and he is obviously (at least, to me he is) involved quite heavily in the development of this new ATLAS infrastructure that they'll preview at PDC. Leroy's most recent post brings to the surface what I agree are the major differences between the "AJAX a - la .NET" approach as popularized by Michael Swartz with his AJAX.NET library, and Leroy's RefreshPanel, the ASP.NET 2.0 bullt-in Script Callbacks and interfaces and finally, to follow, the ATLAS offering that Microsoft is working out as I write:

Leroy states that their callbacks are an integral part of the page lifecycle and thus carry with them the weight of the state of the page. He goes on to explain that most "AJAX" users seem to expect to just query data out-of-band, not necessarily trigger server-side events in the stateful context of the page.

According to Leroy, "If you are a control developer, nothing outside of your control should be considered an asset simply because it's not responsible for it. Many Ajax control developers think like page developers and expose properties that will point the control to some service url that will feed them data. " (N.B.--this is what AJAX.NET does, preventing direct server-side access to the page from which the callback was initiated).

Leroy continues, "We avoid that kind of architecture because we want our page developers to be able to drag and drop the control to the page in the designer and have it working immediately. We don't want them to have to write a separate page, handler or web service for that. We want the control and the page to be self-contained components. To achieve that goal, we need the out-of-band calls to go back to the page itself and not to some external url.

We also want the callback event to be able to access all the richness and statefulness of the page and its control tree. In other words, we want a callback-enabled control to be able to interact fully with its context on the page (data sources are the main example). Finally, we want the callback model to be as close as possible to the existing postback model: we want simple events on simple controls."

He goes on to explain that the "AJAX" developer is composing existing controls, orchestrating their relationships with each other and the other layers of the application using event handlers, and that it is this last point that is relevant to Ajax: the orchestration with other layers of the application. Typically, the page will exchange data with other layers. This is very different from callbacks which are actually controls triggering events on themselves.

If you're just going to exchange data with another layer, you don't really want all the extra weight of page statefulness. What you want is the data and nothing else (The current "AJAX" view, for the most part).

Finally, Leroy finishes by saying that both approaches are complementary. They've understood this from the feedback and it is something they are going to address with the Atlas framework (among other things).

This is good, for two reason:

1) It shows that Microsoft is very interested in developer feedback both from the "AJAX" club and the "script callback server control infrastructure" club and intends to provide a framework that addresses both.

2) It shows that the Microsoft view is looking (I think) a bit farther over the horizon into the future than those who are looking to clone ASP.NET server objects (DataSet, for example) with Javascript as if it was a truly OOP programming environment (which it is not).

So, in my opinion, it will be worth the wait. In the meantime, if you are an ASP.NET developer (1.1 and even looking at 2.0) and want something that does most everything AJAX.NET does, without the obvious problem of separate "service urls" (e.g. phantom page extensions ) to make it work, and that does all this in only about 400 lines of code, look at Jason Diamond's library. I wrote a piece on it here (I changed the namespace to Remote Scripting cause this "AJAX" buzzword makes me want to puke, but otherwise it's all Jason's library).

On a side note, I think it's interesting, the kinds of comments you get when you take a position on something. Everybody's entitled to an opinion; everybody's entitled to respond and say they don't agree. I thought that was what blogging is all about, no? Usually, I'm pretty reserved, but when something (such as, for example, this "AJAX" misappropriation / buzzword phenomenon) rubs me the wrong way, well -- I'm gonna say exactly what I think about it! If people think its "over the top" or "pompous", or "snooty", so be it.

I have several issues with the use of the term "AJAX" (besides the obvious fact that it clouds the landscape with another unneccessary buzzword):

The examples that Jesse Garrett of Adaptive Path uses in his original piece "coining" the term AJAX simply do not qualify as "AJAX", according to his own definition. Google Suggest doesn't use XML or XSLT, it uses JavaScript arrays. And, none of their remote scripting stuff uses XHTML either. So when Garrett uses Google Suggest as the generally accepted example of their new acronymn, when it doesn't even match the criteria they've set out for it, it is not only a misstatement, it's a misrepresentation. Google's developers unassumingly refer to their remote scripting stuff as just plain "javascript". Obviously, they, who are arguably the best proponents of this technique on the planet, don't particularly see the need for a new buzzword either.

No question that Adaptive Path wants to sell services and seminars off this. To say to people "this is how we build web sites, which is kind of like how Google does it, but they actually use a different technique" is pretty complicated compared to saying "Google uses AJAX, and so do we." This is, at best, a real stretch of the facts.

Finally, the unfettered promulgation of new acronymns into the technical lingosphere when they do not particularly add value (e.g. they don't really represent any clearly defined "something new") serves to confuse the landscape and make it more difficult for developers. This is especially true for newer developers, who in many cases are now getting all hopped-up about "AJAX" and actually have NO IDEA that it is only a new name for a technology called Remote Scripting which was invented and released to the developer community by Microsoft last century (circa 1998), and that AJAX doesn't offer one single thing that makes it qualify as an actual "new" technology. All the "pieces" that Adaptive Path claims make up "AJAX" have all been used, in whole or in part, by many many developers, many times over the last seven years or so before some marketer coined the term "AJAX".

One commenter whose post I read even went so far as to intimate that Adaptive Path caused a real firestorm with AJAX and that I (Peter Bromberg) was just resentful because I didn't have a hand in its development! Actually, Adaptive Path capitalized on a confluence of factors; the main ones being that most browsers now have some sort of implementation of Microsoft's original XMLHTTPRequest object. Up until very recently, only Internet Explorer did.
So, there was a lot of pent-up demand for this sort of feature, and Adaptive Path capitalized on it. Even without XMLHTTP, Google Suggest degrades gracefully to the hidden IFRAME technology (JSRS) made popular by Brent Ashley in the year 2000.

You know what? I call it "AHAB" (ALotta Hype And Bullshit). You can call it whatever you want to, it's not going to bother me. The fact of the matter is, it's still just plain Remote Scripting.

N.B. Whoops! Somebody else did me one better!


Revealing our Sources, Protecting our Butts, or just plain Treason?

Special Counsel Patrick Fitzgerald, a Justice Department prosecutor, is trying to determine who in the Bush administration leaked the name of covert CIA operative Valerie Plame in 2003 to the media and whether any laws were violated.
Plame's name was leaked, her diplomat husband said, because of his criticism of the Bush administration's handling of the Iraq war. Right.

So Judge Hogan orders Judith Miller to jail, saying confinement at a jail in the Washington, D.C., area might convince her to change her mind and testify. Meanwhile buddy Time reporter Matt Cooper gets a convenient phone call from his "source" who suddenly tells him it's OK to squawk, and so he doesn't go to jail. Yup, its Cooper and Time who are the chicken-shits!

Kudos to Miller, she has enough guts to stand by her principles as a professional journalist, whether you agree with her or not. Meanwhile Bob Novack, not exactly Mr. Liberal, and the real potential villain in all this, is nowhere to be heard from...

It's interesting because first I hear about this on NPR (yes, I listen and I am a financial supporter too) and alta-cacca Daniel Schorr, who should have retired 45 years ago, is pontificating how this is a body blow to the press, etc. etc. and what terrible things would happen if the Executive Branch would have been able to pressure Woodward and Bernstein to clam up over Watergate, right?

OK so now I'm home and ABC, fearing their boat may already be listing to the right somewhat, attempts to stabilize by bringing on George Stephanopolis to provide his sage wisdom. Meanwhile, over at FOX, Brit Hume talks about how he himself once wrote a piece in the New York Times Magazine at the time of the Supreme Court decision 32 years ago and makes the point that "deep throats" never went away after that one, in fact they are bigger than ever.

But the thing has gone overboard, and the main point is this:

I don't think there should be any doubt that confidential sources should be off-limits to the courts. However - it depends on the story. If the leak, as in this case, harms our national security, the reporter has broken the law. Yup, that's what the law says. Watergate, they did a good thing by exposing corruption in Government. But - there was no effect on national security. That's the difference. So, you can't have your source and eat it, too.

N.B. There's more to this:

"The information age is over. The information is out there," said Jim Guerin, technology director for the city of Dunedin, which will soon be the first city in Florida to go completely Wi-Fi. "Now it's the connectivity age. It opens up a whole new area for ethics, legal boundaries and responsibilities. It's a whole new frontier."

There's a dark side to the convenience, though. The technology has made life easier for high-tech criminals because it provides near anonymity. A "Wireless moocher" was arrested recently in florida, sitting with his wireless laptop in his van outside somebody's house. Even though many people know how to turn on WEP encryption and keys, they don't do so because "Well, the neighbors are all old people..."


Contract First and XSDObjectGen

I have been a fan of the concept of "Contract First" development, particularly where XML - based messages can encapsulate the data. This works not only for webservices, but for most any type of business object. The general idea is that if you can "Schematize" the objects at the message level, your customers or partners can get a copy of the schema and begin their part of the work about consuming your stuff even before you write any code.

This concept has not been lost on the folks at Microsoft. Not only have they incorporated the Application Connection Designer in VS.NET 2005 Team System, there has been significant work along these lines by some of the XML and webServices luminaries such as Christian Weyer and others. The MS XML Team Blog is another good place to start for resources and links.

Aaron Skonnard has a series he is doing on this at MSDN.

Enter XSDObjectGen from Colin Cole and Dan Rogers at Microsoft. This is a big step in the right direction, because it really fills in a lot of the missing links between Contract First (schema) and Code When? (your classes). Developers who are building applications that use XML based messaging need tools to "Start with the Schema" as the modelling language, and be able to quickly and accurately generate the code implementations that allow them to stay in the Object Oriented Programming World they are comfortable in.

Feed it your schema(s) and get back XSD.EXE - style classes - but on steroids! Everything you need (well, almost everything). Since the generated code consists of ordinary classes, you can even choose to ignore the fact that XML is even involved and simply use them as, well -- classes!

XSDObjectGen produces a new Project Type in VIsual Studio.NET - "XSDObjectGenerator" which uses the new library as a Visual Studio.NET wizard, making the process almost a no-brainer. Or, you can choose to use it on the command line and generate your classes "by hand". Either way, you get a lot for your trouble, including support for XML schema constructs, Enumerator and Collection behavior, a programming model that actually matches the orginating Schema, automatic subclass construction, and much more including a "MakeSchemaCompliant" method that addresses one of the shortcomings with this technique so that any required fields you haven't populated will be filled with at least default (empty) values. You also get depth-wise traversal events that you can hook. In short, if you can write a schema, which you can do very easily in the Visual Studio .NET XSD Schema Designer, you are gonna get a whole bunch of very usable code for your effort!

For Webservices, this thing is a dream - the generated sample classes are attributed to work well in document literal WSDL contracts, and you can directly use the generated classes as method arguments and return types in webservice method bodies. It even supports XMLInclude if your schema is in multiple "pieces" (only one level deep, however).

I have only one regret at this point: This thing would have saved me some 10 to 15 hours of tedious coding against somebody's industry spec schemas, had I found it two weeks earlier! Highly recommended.

NOTE: for those seeking a robust JAXB - style Schema Compiler for .NET, look up "DINGO" on Sourceforge.net Snippet:

"Dingo is a pluggable Schema Compiler for .NET and will generate C# code. The goal is to provide a simple way to generate Domain Objects. .NET XSD currently only generates Data Objects. Dingo can delegate code generation with high granularity."

N.B. Fellow MVP Daniel Cazzulino, who never ceases to amaze me because his batteries never seem to run down, is also working with a similar idea for VS.NET as an add-in, here.