Hacker News new | past | comments | ask | show | jobs | submit login
I ported thousands of apps to Windows 95 [video] (youtube.com)
143 points by lonk 40 days ago | hide | past | favorite | 25 comments

MattKC has some interesting content from time to time, like this project he worked on. But I find a decent number of his videos to be weirdly click-bait hell, like the video about installing Windows 98 on a modernish ThinkPad (using CSM - which isn't all that interesting or exotic and seemed to exist to game the Youtube algorithm for clicks) or about a video he put out a few years ago about Super Mario 64 not being optimized, with the implication that Nintendo willfully neglected to disable debug symbols in the final build of the game.

However, the reality is far more nuanced than he was letting on. The likes of Kaze Emanuar set the record straight, and actually did a proper deep dive into optimization for the game (and not just by passing a -O2 compiler flag I might add). I'd say take MattKC's channel and content with a grain of salt.

Youtube basically forces you to use clickbait titles to get views at all.

If you found the video on Super Mario 64 being published with debug symbols interesting, check this out: After finding out about the debug symbols, a developer took a deeper dive through the codebase and optimized the ever living hell out of to get 60fps+.

FIXING the ENTIRE SM64 Source Code (INSANE N64 performance)


I mentioned Kaze in my original post… but yes this video is fantastic and I think Kaze is an absolute legend.

Ope! Missed that. He definitely is.

I think you're being uncharitable. What Kaze does is very different type of optimization and I don't see how it negates (or even relates to) MattKC's analysis of the -O situation? Nintendo did indeed deliberately NOT pass the higher -O flag, MattKC was right. Kaze himself did analysis and came to the conclusion that it was likely because Nintendo wasn't confident it wouldn't introduce bugs, and the game ran fast enough as is. Of course with the power of 30 years better hindsight and tooling, we now know that compiling with the highest -O flag would have been fine.

I think to me it was the premise of MattKC's video that made me question whether or not this was some massive smoking gun. Like you said, the game ran fast enough, and Nintendo wouldn't willfully ship crap out, especially considering this was a flagship title. I still maintain that the compiler flag thing felt more like a MacGuffin for the sake of getting another clickbait video out. Even Nintendo themselves did end up using the compiler flag on the PAL region variant of SM64, which did help performance a bit, but wasn't some major gamechanger (no pun intended) in the end.

I even say this as someone who generally isn't a fan of Nintendo from the perspective of their corporate policies. I don't think Nintendo did anything wrong here, especially given how new this system and the brave new world that was 3D gaming in the home was at the time for them.

Watched this a couple of days ago and was just telling someone about it earlier today...

The technical content is really engaging (the "joy"/"frustration" of digging in some ancient technology for no easily justifiable reason--though in this case...) and there's been a heap of work put into merging the technical deep dive with a cinematic narrative that helps communicate some of the experience of what it feels like when you're three days in trying to find a piece of a puzzle someone probably hasn't cared about in 20+ years. :)

Awesome cinematic masterpiece, it also fills me with nostalgia.

At first I thought no way I'm going to spend almost an hour watching this, but I'm happy I did it haha.

There are many funny gems, like that whiteboard analysis at https://youtu.be/CTUMNtKQLl8?t=2343

Very cool, but i imagine it'll hit a number of fun bugs randomly, with code like:

    // Reimplemented
    LONG WINAPI CORKEL32_InterlockedCompareExchange(LONG *dest,  LONG xchg,  LONG compare)
      LONG temp = *dest;
      Trace(TRACE_FORCE_DONT_PRINT, "InterlockedCompareExchange");
      if (compare == *dest) {
        *dest = xchg;

      return temp;
Not very interlocked at all :)

Well Windows95 probably didn't support multiple CPUs, so it's not bad :)

It did support multiple threads and pre-emptive multitasking.

Are we getting old for knowing that Reentrancy was an issue before multi-core processors became the norm for consumers?

Yup. Let’s go do some bird watching and have a beer and reminisce about computers with kilobytes of RAM, old buddy.

Yeah thanks for pointing this out. It certainly didn't _feel_ like Windows 95 supported preemption when I was using it :)


InterlockedCompareExchange is supposed to be an atomic compare-and-swap API. "Compare-and-swap" means the swap only occurs if the comparison succeeded, ie if the previous value of `*dest` was `compare`, then `xchg` is written to `*dest`. "Atomic" means that another thread cannot make changes between the two steps; if another thread did come in and modified the value between the comparison and the swap, the swap would not occur.

A proper implementation would use some kind of locking in the worst case, but usually would rely on hardware features to provide this atomicity. For example, on x86 this is done by the CMPXCHG family of instructions.

The mock implementation is not atomic. Another thread can change the value between the comparison and swap and the swap will still happen. As for the fix, there might be an intrinsic for it in the W95 SDK, or worst case an inline assembly implementation using CMPXCHG would do the job.

That little extra thing, that soothing/warm Windows 95 chime is what's missing from today's things.

This is a great video, with a cool technical story that is well told. Too bad it didn’t make the front page!

This was "gripping" - I haven't been a developer in ages, but I was intimately familiar with the .net 1.0 (and beta/pre-release) and 2.0 ecosystem.

At one point, I was shouting "gacutil" at the screen, until he got there eventually :-)

Wouldn't it've been easier to compile mono for Windows 95 instead of spending countless hours debugging an ancient release of .net without any sort of debug symbols?

"single use wine port"

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact