That little extra thing, that soothing/warm Windows 95 chime is what's missing from today's things.
I ported thousands of apps to Windows 95 [video]
11–20 of 27 posts
Re: I ported thousands of apps to Windows 95 [video]
#12MattKC 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.
Re: I ported thousands of apps to Windows 95 [video]
#13MattKC 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 o…
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.
Re: I ported thousands of apps to Windows 95 [video]
#14MattKC 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 o…
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 enou…
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.
Re: I ported thousands of apps to Windows 95 [video]
#15MattKC 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 o…
Youtube basically forces you to use clickbait titles to get views at all.
Re: I ported thousands of apps to Windows 95 [video]
#16Very 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 :)
ELI5?
Re: I ported thousands of apps to Windows 95 [video]
#17Very 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 :)
Re: I ported thousands of apps to Windows 95 [video]
#18Very 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 :)
ELI5?
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.
Re: I ported thousands of apps to Windows 95 [video]
#19Very 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.
Re: I ported thousands of apps to Windows 95 [video]
#20Wouldn'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?