There were a few things (GDI handles and suchlike) that had very small limits. Once you exhausted them, the system was basically unusable. There was a little program you could run that would show the number allocated vs allowed. By the time you'd launched one program, they were normally 60-90% gone.

These two are related. OS/2 needed 16MB of RAM to be useable back when I had a 386 that couldn't take more than 5MB (1MB soldered onto the board, 4x1MB matched SIMMs). Windows NT had the same problem - NT4 needed 32MB as an absolute minimum when Windows 95 could happily run in 16 and unhappily run in 8 (and allegedly run in 4MB, but I tried that once and it really wasn't a good idea). The advantage that Windows NT had was that it used pretty much the same APIs as Windows 95 (except DirectX, until later), so the kinds of users who were willing to pay the extra costs could still run the same programs as the ones that weren't.

I never ran 3.0 on a 386 to try that. On Windows 3.1 it wouldn't work, because the OS required either (286) protected mode or (386) enhanced mode. Running 3.0 on a 386, the DOS prompt would use VM86 mode (yes, x86 has had virtualisation support for a long time, but only for 16-bit programs). Windows 3.0 could run in real mode, so would work inside VM86 mode. In real mode, it didn't have access to VM86 mode (no nested virtualisation), so probably couldn't start again.

I'm not sure if it ever became a real product, but the Novell guys did have Netware running as a paravirtualised Xen guest. Apparently it was quite an interesting challenge, as Netware was one of the few operating systems to use rings 1 and 2 on i386.

And Windows 3.1 lost real mode support. You could run Windows 3.0 on an 8086 with an EGA screen and 640KB of RAM (I did - the machine originally shipped with GEM). I think 3.1 still have 286 protected mode support, but didn't work very well unless you ran it in 386 enhanced mode. It was a bit sad that the version of Windows that required an MMU didn't use it to implement memory protection...

Sort of. The desire not to cannibalise sales was a key factor in the design of the PC, but these were also features that IBM didn't think would be missed.

IBM knew what multitasking was for: it was to allow multiple users to use the same computer with administrator-controled priorities. Protected memory was for the same things. Why would you need these on a computer that was intended for a single user to use? A single user can obviously only run one program at a time (they only have one set of eyes and hands) and you can save a lot in hardware (and software) if you remove the ability to do more. And, of course, then no one will start buying the cheap PCs and hooking them up to a load of terminals rather than buying a minicomputer or mainframe.

My father's company got their first Windows 3.0 install because they bought a diagram tool (Meta Design, I think), that came with a free copy. The company that made it had decided that bundling a copy of Windows 3.0 was cheaper than writing (or licensing) a graphical toolkit for DOS and an associated set of printer drivers. I don't know if they were the only company to do this, but after a year or so they stopped bundling Windows and just expected their customers to either have a copy already or go and buy one.

It's not the state getting into your "business", it's your business getting into the state. Marriage predates nation-states by millennia. And as a practical matter, I'm glad I didn't have to get a lawyer and sign a 500-page contract in order to get married, and I'm glad that other people don't need their own lawyer to go over such a contract in order to recognize my marriage.

Java anon classes aren't quite the same because of the lack of "var" or similar - so you can implement interface members or override base class members, but you cannot introduce new members that can then be referenced outside of that object.

OTOH, C# anon classes don't support base types...

Not necessarily. Greenland ice core records show that in the past the planet has seen temperature shifts of up to 7 C in as little as 30 years. 7 C is huge. It's like transporting Moscow to Rome. Of course, we have no idea what caused such rapid changes in the past. It wasn't CO2 levels, or particulates.

I would. If one or more isolated populations managed to survive more than a couple of generations after the event, I think it's highly likely that they'd continue to survive indefinitely. The worst of the changes would be past, and they'd clearly have learned how to survive in the new environment, else they'd have died sooner.

Human intelligence makes us highly adaptable, as evidenced by the extraordinary diversity of environments in which we live, and lived even before the advent of modern technology. Humans who lack the necessary knowledge of how to survive in a particular environment are at severe risk of death any place on the planet, but if they manage to survive for even a year or two, odds are that they'll have learned enough to be able to extend that time almost indefinitely.

I'm not necessarily saying that begin..end is better, just that it's an obvious alternative. Personally, I don't mind {}, though I think that it's really redundant, and the proper way is to treat everything as an expression, in which case semicolon becomes a sequence operator (i.e. "a;b" means "evaluate a, then throw the result away and evaluate b" - like comma in C), and you just use parens to group things where needed.

If you read my post, you'll see that it specifically calls out "import static", and why it's not really good enough.

Scala's problem, I think, is not that it has operator overloading, but that the conventions around the language encourage its use for DSLs. C++ also has this problem, but to a significantly smaller degree, and C# doesn't have it at all.

And how is this different from setX?