"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.
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.
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.
Love this guy, make sure you check out his 8kb C# game: https://medium.com/@MStrehovsky/building-a-self-contained-ga...
It really is a great article and truly interesting techniques to get the size down.
That's like gold to me. Really useful tips right there. At the end things went crazy haha. I'm satisfied with 1MB size hahah.
"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."
This really blew my mind.
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.
His twitter feed is pretty interesting. He's a damn wizard. https://twitter.com/MStrehovsky/status/1214542538079690757
It's funny that someone else on HN just managed to run a Java program on Amiga 1000. https://news.ycombinator.com/item?id=22011199
https://www.xkcd.com/801/
Holy backwards compatibility, Microsoft!
Raymond Chen has lot of good stories about the lengths Microsoft would go to to ensure old programs still worked.
https://devblogs.microsoft.com/oldnewthing/tag/history
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!
Try it now MacOS X
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.
13 replies →
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?
[1] https://archive.org/search.php?query=creator%3A%22Microsoft%...
The author mentioned in a reply that they got their copy with a VS subscription.
If anyone else is curious what else you can get, Microsoft publishes this Excel list: https://download.microsoft.com/download/1/5/4/15454442-CF17-...
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.
6 replies →
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/.
Could be as simple as a networking thing. Czech/Slovak people know Czech/Slovak people, those people get recommended, etc.
Great minds - Microsoft is an increasingly diverse company and you'll see smart people from everywhere in the world there.
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.
Could be that they aqui-hired some Slovak/Czech company that ended up working on .NET Core.
Oh... Win32s. For a moment, I was wondering how he got the C# compiler to generate 16-bit code.
As much as I needed to run Java on an Amiga, at least.
Truly mind-boggling!
the last 2 articles from this dude have amazed me. he is a NINJA!!!
> 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.
[0] https://bellard.org/quickjs/
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.
I bet this would all still fit in under 64Kb.