We’ve got openings for customer support engineers! We pride ourselves with excellent customer support located right here in New York City near Grand Central. Work closely with developers in a true software company taking phone calls and helping fortune 100 customers resolve complicated enterprise software issues. Send me a resume to dblock at dblock org if you’re awesome. No recruiters, I mean it.

I am pleased to announce the open-sourcing of WAFFLE.

http://waffle.codeplex.com

WAFFLE stands for Windows Authentication Functional Framework (Light Edition). WAFFLE is a .NET library with a COM interface and a Java bridge that provides a working implementation of server-side Windows authentication, including Forms, Negotiate, NTLM and other SPNEGOs.

The long story:

We had a pickle. Our enterprise application, written in Java, needed Windows Forms authentication. We had no idea how to do this. After logon we wanted to get the logged on user's SID, a fully qualified name and domain groups, including nested ones to match an account in our database. Then we wanted to allow users to switch the application from Forms authentication to Windows authentication with single sign-on. Hard to believe, but we couldn't find anything that did what we wanted! So we wrote WAFFLE. Today we use JAAS and Tomcat and WAFFLE as a back-end, allowing our users to do all of forms logon, Windows NTLM, Negotiate and Kerberos (SPNEGO) authentication. WAFFLE is written in .NET and we use a Jacob Java bridge for interop. In some near future we’ll add the Java code that does Negotiate and NTLM in a Tomcat valve, it’s pretty straightforward.

If nothing else, this code serves as a clean and working example for everything related to LogonUser, InitializeSecurityContext and AcceptSecurityContext APIs.

One of the main reasons I never liked JAVA is because of it's cross-platform philosophy. The idea is that everything needs to be so generic and portable, that you can’t get anything actually done. Running applications in the real world means integrating with the operating system. In my own experience I needed to get the username of the user logged into Windows, so I’ve generated everything from JNI monstrosities, C# libraries with COM wrappers invoked via Jacob to making remote service calls from CXF to WCF. Can someone please provide a solution that doesn’t make me feel retarded debugging SOAP messages for a local call to GetUserNameW?!

Thank you. The answer is called JNA.

Wrapping a Win32 function is a trivial exercise for any C/C++ developer who dealt with Win32. GetUserNameW takes a wchar_t buffer and a pointer to a length. In JNA this looks like this.

In order not to feel too much like a Win32 developer, we ought to wrap this thing with a usable method. GetUserName returns a boolean for success or failure and can give us an additional error when the buffer isn’t sufficiently large.

Note how JNA implements those nice methods that convert char[] buffers to String. That’s service!

I’ve been tracking a bug in CabLib, used in dotNetInstaller recently. CabLib is a complete C# and C++ wrapper for Cabinet.dll and its goal is to make it easier to CAB files. Anyone who used Cabinet.dll’s interface directly will quickly discover that it follows the usual Microsoft Win32 mantra: if a developer can do something himself with the existing API, don’t include that functionality in the platform SDK. This produces a well thought-through Cabinet SDK, provided that your user has a major in computer science and a PhD in cognitive psychology.

One of the more interesting aspects of CABs is so-called split CABs. This is just a chain of CAB files, useful if you need to put CABs on a set of floppy drives or embed as a Win32 resource, as dotNetInstaller does (resource size is limited). The Cabinet.dll interface is based on callbacks: you call FDICopy and it calls you back (fdintCABINET_INFO) whenever it encounters a file that is split over several CABs, telling you which next CAB to process. Logically, you would want to process that next CAB, except that here you need to wait for FDICopy to return to do it. This means you need to remember what the next CAB name is, so that you can call FDICopy on it. The algorithm around FDICopy looks like this.

… and the callback …

There’s a bug here, one that was not obvious to track. The symptom is that you’re not getting all the files extracted, some CAB files are missed. The problem is that while you’re processing CAB1, for FILE1 you can get a callback that says to continue in CAB2. Then you can get a callback for FILE2 that says to continue in CAB3. You should be ignoring that second callback because you haven’t processed CAB2 yet.

I initially fixed it with a list, but CabLib author pointed out that this is an overkill. The final code looks like this.

This was a huge time suck from my development time. If there’s one conclusion you want to take away from this, is that you should never design an interface like the one in Cabinet.dll.

I was very happy upgrading to Windows 7. Virtually everything worked. All kinds of source code that I am writing compiles and runs without issues. It’s only a week later that I had to touch the AppSecInc. Community MSI extensions and discovered that most unit tests are failing. I talked about unit testing custom actions earlier. I finally got to the bottom of it.

On Windows 7 the behavior of MSIOpenPackage has changed. We use it to run unit tests by creating a database (MSICreateDatabase) and calling MSIOpenPackage to get a working handle. On Windows 7 code that worked earlier always returns 0x80070645: This action is only valid for products that are currently installed. This is one obscure error code! Why do I need an installed product to open an MSI package?

Microsoft.public.platformsdk.msi was helpful [thread]. For MsiOpenPackage to succeed you now have to have a Property table with a populated ProductCode value in the MSI file itself. MsiExt shim code now looks like this. The two Execute statements are new. This incidentally demonstrates what fields you need in the MSI summary to get a valid MSI.

Hope this saves you hours of fruitless debugging.

Maybe Raymond can answer why this change in behavior in Windows 7?