http://genius.it/robrhinehart.com?p=1331 has a discussion of it.

That said, all the comments saying "guy's an idiot" have pretty much nailed it.

Windows Phone is pretty nice. It's main drawback is the lack of apps (which is hard to fix, as no one wants to develop for a platform with few users and no one wants to buy a phone with no software). It's main problem selling is that people associate it with Windows on the desktop, which is a usability disaster that somehow manages to get worse each version, in spite of having passed the point where people thought it couldn't get any worse some time ago.

Don't forget:
7. DOS (vs CP/M)
8. Doublespace (vs Stacker)
9. Windows (vs GEM)
10. XBox (vs Nintendo / Sega / Sony)
It's actually hard to think of a successful Microsoft product that hasn't followed this pattern.

Around 2005, Nokia had a shiny new kernel (Symbian EKA2), designed from scratch to scale to future mobile systems with a good security model, clean abstractions, and power management built in at all layers. It was still hampered, however, by userspace APIs that were designed for a far more memory-constrained environment. Their solution to this involved multiple phases. Their first part was to try to replace the kernel with Linux. This did not go well. They then had no idea how to design a new set of userland APIs, so they set up multiple teams internally competing. These teams were very good at sabotaging each other, but not so good at bringing a usable product to market.

Elop came in when Nokia had failed to produce anything to compete with the iPhone or even with a moderately decent Android handset. He managed to persuade Microsoft to buy Nokia for what now turns out to be a significant multiple of their real value. Of all the companies that benefitted from this, Microsoft was pretty low down the list.

Half true. If you want to ship Android, it's free: go to AOSP, download, tweak to your device, ship. If, on the other hand, you want the Google Play store, then you have to pay Google, agree to ship other Google apps in the default firmware install, and agree not to ship competing apps in a few categories in the default install.

A lot of that is marketing. It's far more a brand problem than a design culture. In terms of usability, I'd place Windows Phone a little bit ahead of iOS at the moment (which surprised me a lot, because Windows is a UI clusterfuck on the desktop, OS X is worse than it was but still in a completely different league to Windows 8.1 - I've not tried Windows 10 yet). Possibly MS moved all of their competent HCI people to the mobile team, or possibly management doesn't care as much about mobile so doesn't insist on multiple layers of design by committee. No one who's used Windows on the desktop would go out of their way to buy a Microsoft product though.

Symbian EKA2 was a great kernel design for mobile (and still does security and power management better than Linux), but a lot of the Symbian userspace APIs were designed at a time where 1MB of RAM was a lot, 4MB was huge. When 64MB was entry level, they were really showing their age: saving 1MB at the cost of a big increase in developer effort wasn't worth it. Nokia needed to provide a modern API and a clean migration path. They provided neither and they set up groups within the company competing to provide both and actively sabotaging each other. Maemo/Meego is an example of this: Switching from GTK to Qt shortly after launching the product doesn't instil developer confidence.

Windows Phone actually made sense for Nokia: they needed a software stack that let them differentiate themselves (and no one else seemed to be using WP) and they had managed to set up their corporate structure in such a way that it was impossible for them to develop it themselves. Some of their apps were really nice (their maps app, which was just bought by a consortium of German car makers was a lot better than the Apple or Google offerings, for example).

longjmp from a signal handler to normal code is undefined behaviour anyway - there are lots of things that can break it (signal stacks are one). God created ucontext (unfortunately, while drunk) for a reason.

Please don't. The advice in that book (or, that chapter, at least) is great, if you're targeting a 486 with VGA graphics and a compiler from around 1995. Some of the advice is still good, but it's interleaved with advice that will result in much slower code (though the advice to always profile first may save you there!) and so it would be very hard to read that book without already understanding optimisation and come away more informed.

The worst bug I had to fix recently was in some hand-written assembly where the immediate in a store and a load overflowed and the assembler silently truncated it. I read the code multiple times and it was only when I traced the execution and looked at the disassembly that it became clear that the assembly and disassembly didn't show the same thing. This caused crashes, but it was in context switch code, so it only happened in processes that happened to use those particular registers and often quite a long way after returning to the process.

That's not debugging a compiler bug, that's step one in producing a reduced test case, which is step one in debugging a compiler bug. It's also starting from the easiest kind of compiler bug to fix (ones where it causes a crash at all, and within that category, ones where the crash and the miscompilation are in the same place).

The order of parameter evaluation is one that bites a lot of people because most compilers do it the expected way. When you're walking an AST to emit some intermediate representation, you're going to traverse the parameter nodes either left-to-right or right-to-left and most compiler IRs don't make it easy to express the idea that these can happen in any order depending on what later optimisations want. If they have side effects that generate dependencies between them (as these do) then they're likely to remain in the order of the AST walker. Most compilers will walk left-to-right (because a surprising amount of code breaks if they don't), but a few will do it the other way.

To understand why this is in the spec, you have to understand the calling conventions. Pascal used a stack-based IR (p-code) and had a left-to-right order for parameter evaluation, which meant that the first parameter was evaluated and then pushed onto the stack, so the last parameter would be at the top of the stack. The natural thing when compiling Pascal (as opposed to interpreting the p-code) was to use the same calling convention, with parameters pushed onto the call stack left to right. Unfortunately, C can't do this and support variadic functions (not: some implementations wanted to do this, which is why the C spec says that variadic and non-variadic functions are allowed to use completely different calling conventions), because if the last variadic argument is the top of the stack then there's no way to find the non-variadic arguments unless you also do something like push the number / size of variadic arguments onto the stack.

This meant that C implementations tended to push parameters onto the stack right to left. This is less of an issue now that modern architectures have enough registers for most function arguments, but is still an issue on i386. Because of the order of the calling convention, it's more efficient on some architectures to evaluate arguments right to left. Some compilers that are heavily performance-focussed (GPU and DSP ones in particular, where they don't have a large body of legacy code that they need to support) will do this, because it reduces register pressure (evaluate the rightmost argument using some temporaries, push it to the stack, move onto the next, reusing all of those temporary registers).

It's called copy elision and it is part of the C++ spec. The spec specifically says that compilers may (but are not required to) implement it, meaning that the compiler is completely free to do different things within the abstract machine at different optimisation levels. It's definitely a bug, but unfortunately it's a bug in the C++ standard. Any sane spec would either require the compiler to implement it or prohibit it - either would be fine (with C++11, prohibiting it would make sense as returning an r-value reference and doing move construction ought to give the same benefit).

Another compiler guy here: Some compiler bugs are not that difficult to debug if you have a reduced test case that triggers the issue. Most are caused by subtle interactions of assumptions in different optimisations and so go away with very small changes to the code and are horrible to debug (and involve starring at the before and after parts for each step in the pipeline to find out exactly where the incorrect code was introduced, which is often not where the bug is, so then backtracking to find what produced the code that contained the invalid assumption that was then exploited later).

My day job involves a research OS, a research compiler, and research hardware. When something breaks and we can narrow it down to just two possibilities out of an OS bug, a compiler bug or a hardware bug, it's a good day...

The name thing was a huge deal-breaker for a fair number of people, and the pathologically horrible way they handled it made it a lot worse. I know dozens of people who would have used G+ but walked away from it because at least one person they knew had bad experiences with it. I spent months with my G+ account in various kinds of limbo because the "appeals" process for name decisions was completely dysfunctional. I eventually ran into someone on slashdot who knew a person who knew a person who could unstick my account and get my name approved, but by that time everyone had lost interest.

And one of my friends used to have a Picassa account, and then somehow it got marked as a G+ profile thing (even though she never intentionally activated G+), and then suspended because their algorithm thought the name was unrealistic, and then she lost access to the Picassa stuff. I don't know whether that actually got resolved.

Very badly run at every level. The most frustrating thing is, they had a guy writing about this who was apparently in some kind of leadership role, and he talked about how the appeals process should work and how the name stuff should work... And nothing he said actually had any influence on the behavior of the product. The actual appeals process consisted of a thing that did not include any mechanism at all for stating your case or explaining why you felt a given name was the right name to use for you, which was then ignored by a machine or possibly a person, who knows. That's it. No mechanism for response or interaction.

Google's hatred of actually dealing with things personally interacted very badly with a policy which was inherently personal.