What’s a PFN?

MSIX introduced Package identity in Windows 8. While the familiar package identity “5-tuple” was functional, it wasn’t especially convenient to pass through APIs or embed in resources such as files, registry keys, URLs, or XML documents.

To address this, Windows defined an opaque string representation known as a Package Moniker. Windows called a related identifier derived from a package’s Name and Publisher the Package Family Moniker. These were commonly abbreviated as PM and PFM.

As development progressed, Windows quite sensibly required new APIs to pass through API Design Review. The review team (then and now) consists of very senior developers from across Windows, pooling their collective experience to help ensure APIs are polished before they’re released into the wild.

Eventually, the Package API came before the review team.

The review team spent quite a bit of time questioning the terms Package Moniker and Package Family Moniker, ultimately leading to one reviewer’s memorable suggestion:

Moniker is too geeky. How about Name?

“Too geeky.”

In that room.

The irony wasn’t lost on any of us.

Someone suggested PackageName and PackageFamilyName. Unfortunately, PackageName conflicted with the existing Name field in a package identity. Someone then proposed PackageFullName, and the room happily agreed.

In hindsight, we probably should have noticed the problem immediately.

It wasn’t until later that we realized we’d created two terms with the same acronym: PFN.

Since different features, subsystems, and teams often deal with one or the other, discussions about “PFN” became increasingly common. Inevitably, someone would interpret “PFN” to mean the other thing, and confusion would promptly ensue.

This happened often enough that I began interrupting meetings to ask:

I’m sorry. What’s a PFN?

I’ve done this so many times that I’ve occasionally joked it should be tattooed across my forehead.

Don’t abbreviate.