Sorry, but you read too fast. I didn't say "invest"(*), I said "investigated":

Microsoft was being investigated for antitrust since 1990

Microsoft was in legal troubles due to monopolistic practices.

This is probably what led them to decide to settle out of court and pay those 150$ million you mention (as part of the settlement) rather than try to completely crush Apple. Given the warchest of Microsoft, they could probably have been able to go to court and extended the legal battle for long enough until Apple goes bankrupt and disappears (with Microsoft buying up the remnants).

But doing so (killing off Apple and ingesting it) would probably have looked very bad in their other lawsuit about monopoly. Letting Apple live another day (and, as you point out, spinning the public opinion as "Microsoft investing into Apple to save them!") was probably the smart move to reduce the antitrust troubles.

Regarding the long list of products destroyed by Microsoft's ruthless practices:
Yup. There's a reason why the Microsoft Cuisine joke is so funny: it definitely close to how most of the Microsoft related accident happened back then.

(Was using Stac' Stacker during my DOS days back then).
(Of course a pirated copy, because as a teenagers I was too broke to either afford a bigger disk or even buy the software).

---

(*): though yes, the source I point at does mention the 150$ millions, without expanding on their context (as an out-of-court settlement).

Speculations cross my mind:

One of the explanations I've heard about why Win95 merely only "nearly did kill Apple" instead of "completely killing" it, is that Microsoft was being investigated for antitrust since 1990 and definitely needed to still have a somewhat not completely dead Apple around to point at whenever the word "monopoly" came in the discussion. (see: this article)

If Microsoft had launched an Apple-crusher a bit earlier, they would still have launched it during their antitrust lawsuit era, so they would still need to keep Apple on life support.
They would still need to put efforts in keeping Apple alive to avoid getting accused monopoly.

and that's usually how Mono applications are named on Linux.
(Given that the same bytecode has to work on Windows .NET too)

That's the morally correct way to consider it, it does make sense, and I really hope the court sees it this way.
(And that is the way in practice in several jurisdictions around the world).

But AFAIK, in the US tools to circumvent DRM are illegal acording to DMCA.
Also see Right To Repair as another example were the US' stance on DRM circumvention doesn't make sense.

But doesn't forbid them either from trying to sue, in a sort of "Legal-budget-based war of attrition".

Tropic Haze LLC is based in Washington, US.
Correct me if I am wrong, but on your side of the Atlantic, *distributing tools* for DMCA circumvention is illegal, and there are people pushing for even forbidding to merely *link* tools.
I am not saying Nintendo could win, merely that they won't be immediately laughed out of court, or at least not before having cost legal fee to Tropic Haze.

And I presume is Nintendo's plan to try to argue this in court, hopefully until Tropic Haze runs out of legal defense budget.

It's even worse that with AACS movie.

Yuzu on purpose does NOT come with keys baked in.

You're supposed to copy the key from an actual Switch that you own.

(Nintendo is abusing DMCA laws about the necessity to hack said own Swtich to achieve that).

Though it remains to be seen how soon this will happen for Switch games, depending on the upcoming Switch 2's backward compatibility.

But yeah, eventually only emulators and dumped games will remain at some point in the future.

Yes, that's perfectly moral. Should be legal. And is actually legal in some jurisdictions. But not all.

That's what Nintendo is arguing:
- dumping your own console's DRM keys and dumping your own games requires a that you hack your own Switch. Nintendo argues this is a violation of DMCA and outbound links to instructions to do so are illegal.

- running such way games on hardware which is not a Switch (e.g.: on a SteamDeck) is a violation of Nintendo's licensing term, as they decide what they will allow you to run your games on.

Switches employ (per-device) DRM and, AFAIK, Switch' game use per-copy keys.

The canonical (and simplest) way to use Yuzu is to duplicate the DRM key of the Switch you already own, and dump your own game.

(But that requires rooting your own Switch, and Nintendo actually argues this is a DMCA violaiton and that outbound links to instruction to do so are illegal).

(Keep in mind that Nindento is typically making money by selling games. In the whole gaming sector, consoles are usually either sold at a loss, or close to costs. Selling fewer Switches isn't costing them money, only public visibility and less lock-in. So the whole arguments of emulator versus sales of machines isn't very convincing).

Yuzu technically cannot cannibalize sales of Switch consoles: it doesn't break the DRM. Instead it relies on duplicating the key of a Switch you already own
(and Nintendo's argument is that you need to hack the Switch in order to do so, which would be some DCMA violation, and Yuzu's website or Discord is pointing to instruction how to do so).
The way the DRM scheme is designed, you couldn't use Yuzu without an actually paid-for Switch (though probably some pirate could try using keys downloaded from some warez website. Though Nintendo could very trivially black list those DRM keys).

The main use of Yuzu (given the way it is designed) is to allow you to leave your Switch at home, only take your, e.g., SteamDeck with you, and still be able to run your usual games while pretending to have your exact Switch (and it's DRM keys) with you.
The advantage being not needing to lug around multiple devices, higher performance of some platforms (including SteamDeck), or alternative inputs (e.g. accessibility).
Nintendo argument is that running game on non-Switch hardware is a violation of Nintendo's licensing term and they only should decide which devices you're allowed (or not) to run your games on.

AFAIK Nintendo games nowadays employ per-copy keys, so it would be more difficult to use a pirated copy downloaded from the internet than a dump from your own game using your own Switch (which need to be hacked, so again Nintendo arguing the same DCMA violations and links-to-instructions as above).

Tears of The Kingdom is a bad example, as the version pirated before release wasn't used on Yuzu but on Ruijinx back then.

Funnily, that part was a bit easier earlier in the 90s, specially when making simple 2D games, as there weren't that many fancy effects.

A "sound engine(*)" was mostly mixing multiple samples (in software, unless you were lucky to have a Gravis, or later an AWE) and playing them over the soundcard.
Which by then mostly meant either a Sound Blaster-family card or something at least compatible with the SBPro, so with a relatively narrow number of hardware interfaces to support.
(And throw in support for digital samples on PC Speaker used in pulse-width mode to support lower end machines. Add some parallel-port home-made resistor ladder (COVOX Speech Thing compatibles). Or if you feel very fancy, playing digital samples over FM chips like AdLib to cover for older machines).

Once you got the mixing, you can use it both for music, to play MODs and other similar tracker music (by mixing instrument's digital samples at varying volumes and frequencies), and sound effect (mixing digital sound effects at various volumes, mostly based on distance).

As the games were much simpler back then, sound effect were really just that: play sample more or less loudly based on how far away they are, have different left-right volumes for stereo effect.
So most of the programming tricks boiled down to mixing fast enough on slower CPUs, smoothing somewhat the sound when changing frequency and mostly the driver to make sure it's compatible across the widest amount of cards.

Contrast with graphics programming which tried to get as many effects as possible out of the limited hardware capabilities of EGA, VGA and SVGA, requiring tons of low-level register tweaking (planar 256 color modes, latches, etc.) or complex programming (using VESA bank swapping). Getting more even more complex once you want to do software 3D.

That's probably why there weren't that many good libraries when you started: the past decade was spent putting efforts into graphics and thinking "yeah, simple sample mixing will do it" about the sound (Spoiler: no, not anymore. If you want more realistic 3D games, you suddenly need a lot more efforts into 3D audio, well beyond "closer is louder": you need to map environments, do Doppler, do echo and reverb, etc. cue in A3D and the like)

(*): for the amateurs, indie, and demoscene.
For big companies (think Sierra, LucasFilm, etc.) it was mostly about supporting MIDI and tweaking a few specific musical synthetisers (tweaking the hardware registers of AdLib's FM synth, or SysEx on Roland MT-32, etc.) or later supporting General MIDI and the music sounding crap - if you weren't using the same synth as the artist (usually a Roland SC-55), you were stuck with whatever General MIDI sound bank your sound card had to offer (often some very twangy instruments in a botched OPL clone chip, or an aweful rompler).

The part that makes it worse (both for you and for making this work in general) is that by the time the nerve has reached the carpal tunnel, it's mostly only sensory input (that's why you feel pain when it's compressed) and a lot let muscle motor output (that's why it won't work).

Most of the stronger muscle that move your finger (specially for strong motion like strong grasp) are in your forearm.
At the level of the wrist, there isn't any nerve output for those muscle, even the muscle themselve have endeded and you have a large bunch of tendons.

It would probably be possible to detect movement with ultrasounds, but if you try picking either nerve impulses or muscle eletrical activity, you'll mostly only pick up the few muscles in your palm that are in charge with the fine motion.
i.e.: on a "pinching" motion, you'll detect which finger are aligning (based on the impulses going to the thenar and lumbrical muscles), but you won't pick up the finger flexing (pulled by tendons coming from muscles in the forearm whose nerves aren't in the wrist).

(Here's an Anatomy poster with only paintings, no photos: https://anatomywarehouse.com/m...,
Sources with more detailed explanations, warning contains cadaver photos at the end:
https://teachmeanatomy.info/up...
https://teachmeanatomy.info/up...
https://teachmeanatomy.info/up... )

...and are encumbered with a couple of DRM systems, some which are rather convoluted.

Which means that at a point in the future:
- you will need to connect your player to the internet (or use an USB stick) and update it's firmware to view newer discs.
- ..but that upgrade could potentially block you from watching older media that you already hold but which Disney and Sony have decided to deprecate and not cover in the newer firmware.

or:
- never connect the player to internet and keep the current firmware (and its precious keys) as-is forever (until the player breaks) and be guaranteed that your current disc will continue to work (until the disc bitrots) even if Sony and Disney decide to deprecate some encryption kyes.
- ..but then newer disc might not be playable anymore

or:
- you need to keep a collection of players of various vintage (might be easier with software players).

or:
- you need to RIP those discs onto your server, and/or keep you own cracked keys to keep access to the disc.
- this should very likely be under local equivalent of fair use in most European countries here around.
- but this could land you in prison and/or severe fines in other jurisdictions, including in the US.

Given that internally the Sony Portal is running Android, it's not a surprise they eventually managed.

Yup, Sony's official statement is that the Portal is streaming only and there wouldn't be any way to run games directly on it.

So these guys' effort are basically a big "Well actually, ..." regardng that last point.

Andy's bio states:

Cloud Vulnerability Research @ Google

i.e.: he specialises in investigating vulnerabilities.
in other words: hacking shit is actually his job descrition.

(But yeah, the fact that he usually does it at Google isn't relevant, and TFS on /. could have emphasized that day job better)