Mismanaged code

Managed code is all the rage. Once long ago we had either slow code that was interpreted during runtime or fast compiled code that was built into a binary which the processor could execute natively. Microsoft said fuck this shit and introduced a middle ground. Probably to combat their mess of an operating system. To be fair, Microsoft wasn't first, they were just the ones to come up with the name.

Managed code does compile, not into something that is understood by the hardware CPU, but by a virtual processor. This way the program can be made more secure and portable between different architectures among other things. Java and dotNet are the most common platforms for managed code.

One of the many many problems with Windows is the convoluted way it runs and separates the 32 and 64 bit environment. Adding a third architecture, code that compiles into something that is neither 32 nor 64 bit Intel instructions adds to the confusion.

I wrote earlier about how a 64 bit Windows is really two Windows in one, Windows On Windows. As you might remember in the unlikely case you read that post, 32 bit processes access the 32 bit operating system, and 64 bit processes access the 64 bit one.

So, which OS is accessed by a program written in managed code?

It depends.

Lets say you need to deploy a program that requires some third party database client for an ODBC connection. The supplier tells you it needs the 64 bit version, "or it wont work". You have the 32 bit one installed sitewide already and you know they don't play well together. You know this, because you are an ORACLE.

Luckily, the program you need to deploy is written in C#. If a dotNet program utilize the 32 or 64 bit environment is decided by the programmer at compile time by setting the target platform. If he does not, it compiles to AnyCPU which chooses the 64 bit platform if available.

With the Microsoft tool corflags this can be changed after the fact! Flags in the file header tells the runtime environment if 32 bit is preferred or required and voila the program works well with the already installed 32-bit ODBC, saving me a lot of future work and headaches.

Java programs can be launched with either a 32 or 64 bit javaw.exe. Most Java programs can be launched with a specific client, bundled with the program itself. This is useful since most Java versions are incompatible with anything. But that's a different blog post.

Right now I'm working on something that is going to bring a different kind of headache. Cheers!

Globally Unique Identifier

Globally Unique Identifier is a genious thing when you need a globally unique identifier! They are not as brilliant when they are used everywhere you would need a human-readable name, because of laziness.

If you've ever been troubleshooting a Windows program, and you have if you are reading this blog, you are fully aware of the frustration you feel trying to find the associated file from a class identifier in the registry or when figuring out which program C:\Windows\Installer\{136688F1-EF42-414E-92D6-BFF4D25EE688}\ARPPRODUCTICON.exe belongs to.

Usually you just copy the GUID into the clipboard and paste it into an appropriate search box. Isn't obvious that {25336920-03F9-11cf-8FD0-00AA00686F13} is the CLSID for "Browse in place"?

It doesn't help then, at all, that there are two ways of storing the GUID, either normally or compressed. And by "compressed" I mean "not really compressed, just a little different to annoy people and make their life harder".

How to convert between a standard and a compressed GUID:

Have you seen anything dumber than this, lately?

Also note that the "Browse in place" GUID, usually found under keys such as HKCR\htmlfile or HKCR\jpegfile, have two lowercase letters for no reason. It's likely true on your Windows too. To be truly globally unique, GUIDs should be generated by an algorithm standardized by ISO, IEC or someone with power to standardize. I am not sure, but I doubt the algorithm is inconsistent with upper and lower case.

Sometimes it is obvious the GUID is not random, as in the case with Microsoft Office;

The product code for Office consists of it's version and language and such, ending in "0FF1CE" as Microsoft describes here. My Office 2016 Pro has a GUID of  {90160000-0011-0000-0000-0000000FF1CE}.

Older Java clients had class IDs starting with "CAFE"; {CAFEEFAC-0013-0000-0003-ABCDEFFEDCBA}, or maybe it should read "Café fuck", because that is how I read it.

Finding the product code for an msi install is trivial when the program is already installed, but often you would like to avoid littering your computer, even your virtual one, with garbage unless you really have to.

I wrote a tool to list the product codes of all msi files in a folder, and also put them in the clipboard for easy pasting into your uninstall-script. Download it here.

If you don't dare to download unknown programs and run them on your computer you are not an application deployer.