Something that makes following Microsoft tech <i>different</i> for engineers, in my opinion, is that naming has historically been driven by marketing/sales, not engineering. There is not a 1-1 mapping between the branded/advertised functionality and the technical components responsible for it. This makes sense when your audience is purchasers at a company. They care about what features/scenarios are supported, not how they are implemented (sorting through that is, at most, the job of someone lower on the totem pole).<p>Engineers, on the other hand, want to know how the system works. Even when it <i>shouldn’t</i> matter to us, we can’t help but think in terms of the actual mechanisms driving the system’s behavior. We don’t like black boxes, because we experience daily the leakiness of all abstractions. And for an engineer targeting Windows as a platform, the technical details obviously <i>do</i> matter.<p>I think this difference is especially jarring to developers used to the <i></i>nix world, where everything is much more developer-oriented. I would bet that the early success of Microsoft products against Unix is partially due to this difference in focus. Ideally, you communicate differently with both groups, but in reality you have to make trade offs. It would just create more confusion if there was one set of names/brands for end-consumers and another totally different set for developers.<p>(Another difference is that Windows has historically been one big project, so features <i>do</i> in fact span technical components, which due to being under single management, are less regimented to begin with.)<p>The web has definitely changed things by making operating systems less important. At least the perceived importance of marketing to developers has increased. I think Microsoft has done a good job adapting to this change lately.