If you move your mouse continually the query may not fail. Do not stop moving

I actually like windows as a user, but I'm amazed that it won as much developer mindshare as it did considering how much the win32 api sucks. It's brutal.

I have never been able to remember how Excel and Word for Windows handle multiple windows, as it changed in subtle ways (can you alt-tab between Excel documents. Between Word ones? Do documents appear in the taskbar, or windows, or just Excel?) between versions, as Word and Excel within an Office version do not appear to behave 100% the same, and I as I tended to encounter different versions, for example when helping a friend, or when using RDP to a different server (yes, we had servers with Office installed, and we didn't even use them for COM controls) at work.

IIRC opening up Excel again from the start menu didn't create a new instance, it just gave focus to the document/instance I had open. My jaw kinda dropped cause it wasn't like I had an extremely uncommon use case. There was no File > Open new window. I tried dragging the document to outside, like you can do in Firefox with a tab, nope. Opening a new document simply opened it in the current instance I had running. I needed to do a compare side by side of the documents. Switching between them didn't cut it.

Btw this is a different problem with Excel and Office all together - I was using Excel 2007 because the files I was using were created in 2007 and used a customer (who had only 2007) and would mess up if you saved them in a later version. The files had some complicated macros in them. Compatibility Mode (I think that's what they called it) WAS NOT actually compatible!! 2010 was out, and I had that installed as well, but 2007 had to be the one I used for this task.

I was just doing some simple maintenance operations on them. I had nothing to do with their evil creation.

There was some way to eventually get Excel 2007 to run two instances of itself, but like I said, it was a hack that I found online after a bunch of searching.

P.S. I'm also slightly(?) OCDish in preferring selections that are integer fractions of the paragrah length. E.g. in a paragraph of 6.3 lines I'll tend to select 2.1 lines at a time (not _that_ precisely of course).

My "first love" in OS's is AmigaOS, and while the OS is very dated in many ways (no memory protection, no SMP support), one of the things it really got right was to encourage extremely extensive multithreading. On Amiga's it was a necessity if you wanted to have full multitasking, as the machines were slow enough and memory constrained enough that not doing it would severely limit usability (frankly, it would have done PC's a world of good too, but the PC world took the simpler approach of not even trying for proper multi-tasking).

My favourite example is how cut and paste from the console worked.

It includes the device handlers handling keyboard and mouse input, the intuition input handler, which processes the raw input events and turns them into input events for specific windows, the console.device device handler which takes intuition events for console windows and "cooks" the events into higher level events that gets passed to the console-handler, which then will find the area you are selecting, and call a function that passes the buffer to the clipboard.device, which will then create a clipboard entry that gets written to a disk volume, which involves the filesystem handler for that filesystem, which again likely will involve a device suck as ram.device or trackdisk.device to write it to the actual device.

Every single one of these steps is handled by a separate thread/process (the distinction doesn't mean much on AmigaOS due to the lack of memory protection, and are usually referred to as "task" instead).

The reason for this is all down to responsiveness: The input devices and things like trackdisk.device musc deal with hardware, and so must have priority. But if the rest of the flow was given high priority, the system would be sluggish, so the minimum amount of work is done, put into a message, tacked onto a queue, and things are off to a start.

At the opposite end, things like clipboard.device must not lock up when clipboard entries are added, as while the clipboards are usually in RAM:, they are files on a filesystem, and a user with only 512KB RAM and possibly no harddrive might in fact be using a floppy drive for the clipboard - forcing the user to wait for a floppy write would have been intolerable (and why Amiga users loved to mock Windows 3.x users back in the day).

This permeated through many applications as well. It was a matter of pride for many developers, and the first chapters in many Amiga developer books tended to involve Exec (Amiga's "kernel", or parts of it) which provided a set of library functions for managing messages, lists of messages and message ports, as they were essential for talking to the OS, but also readily available for application developers. For many, before you'd written your first "hello world" app you had gotten a crash course in making things asynchronous by default.

Today a day go by for me without either my browser freezing, or Thunderbird freezing or some other application, both on Linux at home and OS X at work. And on the few occasions I've had to work on Windows machines, there too. Every time it happens, I dream wistfully about a world where people understood how to write software that way.

It is, in fact, not all that hard: "All it takes" is to subdivide your application into smaller components that only communicate using async message queues. Incidentally it makes the apps easier to test too, and easier to make robust (unlike under AmigaOS, on a modern OS you can separate components on process boundaries where it makes sense too, and automatically restart failed components), and it makes it easy to make them scriptable etc.

Historically, it was even worse: all desk accessories on Mac OS where running as load able drivers (http://www.folklore.org/StoryView.py?story=Desk_Ornaments.tx.... Aside: that article shows that Jobs did actually design a GUI, that for the calculator. More info at http://www.folklore.org/StoryView.py?project=Macintosh&story...)

I think windows wasn't much different. There is/was an article about the mess that Microsoft's build system for Windows was that explains how they spent lots of effort fixing layer violations in order to improve build times (they used to have full builds only novice every few months. That meant that incompatibilities between, say, an improved menu system and the latest version of the Explorer would take months to surface). Anybody remember that?

Anytime they start indexing or re-indexing a huge code base in a "background" thread, they end up locking the machine to varying extents. Linux is not as bad, as it only tends to lock up instances of the offending application... But that maybe because the Linux PC is a beefy workstation. OS X is on a much less powerful MacBook Pro, and freezes tend to lock up the whole system, or at least most of the other apps, especially Chrome.

I've also had problems with Chrome, and especially Flash, on OS X. Spinning beachballs on every page load. Click-to-flash was such a lifesaver, but I can now sorta see why Steve Jobs wanted Flash dead.

The spinning beachball has grown to be a frequent source of rage for me over the last 5 years. I'm surprised nobody else complains about it more. Maybe it only happens for heavy Java GUI-based apps?

X11 is supposed to be multithreaded enough to allow this and it worked fine on older versions of Xlib, before the libxcb transition.

Fixed by using select() in the event loop for the curious: https://github.com/lcrs/6ilk/commit/d5c39abde09e0467a8a4d17d...

This isn't too uncommon, actually, but what usually happens is that the company with the upper hand prevails and the other one has to fix the bugs, lest they piss off their customers who have to leave. However, when both companies keep their users in tight vendor lockdowns, they just wave their cocks around for a few months blaming each other and settle for the users working around, since it's the cheapest alternative.

You're right that this discussion is light on details, but there is one relevant detail from which reasonable conclusions can be drawn: there is a workaround that involves moving the mouse around continuously. I can't think of any plausible scenario that could produce that behavior that does not involve some blatantly horrible design decision by Microsoft (hence "their fault"). It's possible that such a scenario exists, but I can't think of one, and I have not seen any such plausible scenario proposed by anyone else. I also know that Microsoft products are chock-full of blatantly horrible design decisions. In particular, Windows tightly couples the graphical UI with the OS kernel in a way that other OSes do not. It seems to me exceedingly likely that whatever is causing this problem has something to do with that.

We make Objective-C run on Android at Apportable :-) The entire stack. Everything from clang, GCD, CoreFoundation, Foundation, UIKit, and dozens of comm frameworks. It's fairly popular with game developers.

We recently re-developed all of Foundation from scratch on top of the parts of CFLite that Apple open sources and no longer use GNUStep.

http://docs.apportable.com/release-notes.html#1100

We have even open sourced all our tests around Foundation as well and this is one of them. Check it out:

https://github.com/apportable/FoundationTests

It's usually a programmer error when you write code that does something other than what you intend, regardless of whether or not what you intend to do is the default behaviour.

I think this is perfectly understandable behaviour for a framework of such a general purpose. The whole convention over configuration thing works for tools like Ruby on Rails and web2py. 90% of the applications written using them are pretty much identical and the non-technical constraints favour quick delivery over well-adapted architecture, so you can afford making it obnoxiously hard for the rest of 10%.