Did you ever need to run a piece of C# code on Windows 3.11?
twitter.com
twitter.com
This really blew my mind.
Unfortunately, AMD made a mistake in AMD64: the new 64-bit floating point context switching instructions couldn’t switch the FCS and FDS registers. This not only broke some very old software when run on a new kernel or hypervisor, but it also created a potential information leak.
Sadly, new CPUs “fix” this in an unfortunate way. Trying to read FCS or FDS gives zero. Now some very old software is broken.
Couldn’t disagree more; ctrl-alt-del gets a LOT of use on every Windows OS and client software combination I’ve ever used - I can’t even remember the equivalent hotkey on MacOS although it’s now been my daily driver for ~2 years of heavy use.
I haven't had the need to kill anything using task manager either so not sure what I would use CAD for.
At any rate, the applications that make up most of my daily work are all really stable these days-- we've come a long way since the Classic MacOS and Windows 9x days where application (and OS) crashes and freezes were a daily occurence.
I think there is more to it. I think is because they actually don't want obsolete software to be seen on their computers. Imagine people posting a picture with a Macbook on Instagram, and you see some ugly 1990 piece of software running on it. Not cool. So from time to time they remove whole frameworks, to force developers to re-implement the app in a new one, which is prettier. If no one is still around to maintain the app, that's ok too.
This is why you don't see any ugly software on Macs, they make sure to purge it every 5 years or so.
Note: I switched to Win10+WSL in 2018 - it's a good and productive environment, but I do miss certain aspects of MacOS still. I think valuing consistency over backwards compatibility is a valuable choice, as long as the people in charge have very good taste. Not so sure about that anymore in recent iterations though.
Good point, I can definitely see how removing backward compat helps with UI consistentcy. Consistentcy doesn't have to come at the expense of compatibility for a mature desktop operating system but yeah for people valuing consistentcy over everything else thats a good thing.
Personally I thought the whole 32-bit thing was blown out of proportion. It wasn't long between Apples shift to Intel and 64-bit machines becoming the norm. The majority of software got updated and a few vocal haters complained a lot on HN.
J++ was never meant to be "Java", and never technically was even in branding, it was essentially a second language (that Microsoft saw at the time as C++ is to C, it was to Java, and that's very clearly represented in that brand name) that also targeted the Microsoft version of the JVM, and used a couple Microsoft-specific escape hatches for FFI and COM.
(So it absolutely was an "embrace and extend", but it wasn't of the Java language itself so much as it was the JVM that Microsoft wanted to embrace and extend that seemed to fright Sun so badly. That's probably why so much of the legal drama and the consequent blows to the rest of the Java ecosystem at the time was Sun withdrawing JVM licenses from just about everyone as a part of that battle. Originally Sun seemed rather happy licensing the JVM to whoever wanted to implement it, which is why Microsoft had a JVM in the first place, thinking controlling the Java language was enough. Sun worked to put that genie back in the bottle and move everyone back to mostly a single JVM again. There's no lack of irony in the exact same battle playing out between Oracle and Google decades later in the battle of Dalvik [Google's JVM] and Android.)
It wasn't that Sun didn't want Microsoft using Java, they didn't want Microsoft using the JVM any longer, and without a license to build their own JVM, J++ wouldn't run on any other JVM and wasn't a useful language.
When Microsoft lost their JVM they decided to start from scratch, moved the J++ team (including and particularly Anders Hejlsberg, C# lead) to a new VM that they could control from top to bottom (including its FFI mechanics), and much of what had directly been the J++ team used what they learned from the whole mess to create C#.
[1] https://archive.org/search.php?query=creator%3A%22Microsoft%...
I would say the concentration of Czech/Slovak people around .NET at MS is a result of accidents and networking. I got into the team thanks to a friend of a friend who heard I was interested. But yeah, it's a surprising number given the size of the population of Slovakia and Czech republic.
There's a newly opened .NET development center in Prague so the number is likely going to grow (they do hire from all over the world though): https://karelz.github.io/hiring_prague_net/.
Perhaps a better JS baseline would be QuickJS [0].
Once 1.2MB was reached:
> Now we’ve reached the end of what’s possible with the .NET SDK and we need to get our hands dirty. What we’re going to do now is starting to be ridiculous and I wouldn’t expect anyone else to do this. We’re going to rely on the implementation details of the CoreRT compiler and runtime.
QuickJS is 620K.
I guess that doesn't include any kind of facility for rendering to the screen (besides basic barfing to stdout) or interacting with keyboard/mouse. i wonder how much code would be needed to add support for a basic canvas pixeldata api & keyboard event handling.
If by "basic Canvas pixelData" you mean blitting an array of pixels in a loop, that would require a grand total of 4 API calls: CreateWindow, GetDC, CreateBitmap, BitBlt. Keyboard and mouse handling would be a dozen lines of code to process the corresponding window messages in the event loop.
I bet this would all still fit in under 64Kb.