"Turns out the object files produced by the CoreRT ahead of time compiler from 2020 can still be linked with the linker that shipped with Visual C++ 2.0 in 1994."
Yeah, for all the shit that Microsoft gets, their backwards compatibility efforts are extraordinary. I work in games and we recently dug out a project from 1998, last built using Visual Studio 5, and everything just compiled, linked and ran using Visual Studio 2019 with some extremely minor changes in project config.
For what it’s worth, CPU compatibility with old segmented code (like Windows 3.11) is a bit iffy these days for a silly legacy reason. The old x87 floating point coprocessor had two registers FCS and FDS — they’re the CS and DS segments at the time of the last x87 data instruction. This was used for the 386’s asynchronous FPU exception handling. Fast forward to the ultramodern 486, and floating point exception handling was cleaned up and FCS and FDS became unnecessary, but they were kept for compatibility. All was well.
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.
Yes, one of my favorite bloggers for more years than I can count. What is crazy isn’t just how crazy the stories he has to share are but also just how many of them he has. You’d think with the craziness bar set so high he wouldn’t have this much content, but he still manages to be one of the most prolific bloggers!
I'm ok with Apple having different priorities so long as it benefits the end users of the product (and I'm sure some people will go to lengths to make up end user benefits ) but whenever I use OS X I just don't see any benefits of not having backwards compatibility - it's not faster than Windows , nor stabler, it's not like it updates faster and it's only getting iOS features backported. So it feels like not caring about backward compat is just a self serving easy way out for Apple.
> So it feels like not caring about backward compat is just a self serving easy way out for Apple.
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.
I agree with what you write about performance and stability, but there is one other metric where MacOS has always excelled: Consistency. From the way hotkeys work to how screen elements look, to how macs interact with other Apple products in your possession.
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.
You could argue the more time Apple spends maintaining legacy code the less time they have for other work.
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.
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 have to force quit apps all the time on macOS. I'll admit I also routinely forget the key combination, but that's just because the Dock makes force quitting easy, and the Windows task bar does not (afaik).
Recent versions of Windows have gotten pretty good at identifying programs that aren't responding and offering to close them; it's gotten pretty rare that I actually have to open Task Manager to close a program. macOS, on the other hand, never offers to kill a hanging program-- it'll let an application beach ball for hours until you go out of your way to force quit it via the Dock or keyboard shortcut.
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.
Cmd-Opt-Esc on a Mac is analogous to Ctrl-Shift-Esc on a Windows machine (Cmd-Alt-Del brings you back to the login page with a button to open task manager on post-Vista Windows PCs).
I don't remember using Ctrl+Alt+Del on any personal Windows machine either. It's the corporate client systems that make you use it for login. Heck on surface devices you don't even have to touch the keyboard to login :)
I haven't had the need to kill anything using task manager either so not sure what I would use CAD for.
Are you a time traveler? Ctrl-alt-del brings up task manager or the login dialog. While I do frequently have to shut down an application forcibly, I don't think I've had Windows itself crash in years. Or at least enough months I've forgotten about the last time.
I've been seeing a lot of stuff about Windows 3.11 lately, did they release it free recently? Like they did early versions of MSDOS? https://github.com/microsoft/MS-DOS
People uploads a lot of old Microsoft OSes and software on Internet Archive [1], but curiously, no one uploaded Windows 3.11 installer yet (plenty of Windows 3.1 though). I wonder why. Legal reason?
Yes, and until about a year back Windows 95 and 98 were available also but they have been taken offline. If I recall it correctly it is due to some copyright issue.
Microsoft thought Java was a good idea in that they liked the JVM a lot, but the language itself they saw as flawed and missing key features that would make it a truly modern language, in particular they heavily disagreed with Sun's approach to FFI (foreign function interface) [Java's slow, laborious efforts eventually building JNI, the Java Native Interface], because of their many years of experience for better and worse with COM (component object model).
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#.
How come there are so many Slovak and Czech people working on .NET Core at MS? Tomas Petricek, Karel Zikmund, Jan Kotas, Jan Vorlicek, Tomas Matousek,...
(Author of the "C# on Windows 3.11" hack here - and a Slovak.)
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/.
Aye. My team in DevDiv (home of .NET) had a Brit (me), a Turkish lady, two Russians, two Canadians (one French), three Indians, my lead was Mexican, and only 1 American.
> This will produce a single EXE file that has whopping 65 MB. The produced EXE includes the game, the .NET Runtime, and the base class libraries that are the standard part of .NET. You might say “still better than Electron” and call it good, but let’s see if we can do better.
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.
Very little, actually. You'd need CreateWindow to get a surface to render onto, and from there you have access to GDI, GDI+, OpenGL, and D3D via P/Invoke
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.
