HTML has special rules depending on the tag's type, ie a bunch of them are just written () and the parser doesn't even really want to see a matching closing tag, or tags like is found. (1)

A HTML parser can become a XML parser by disabling a bunch of special-features and supporting self-closing tags (depending on XML level).

A XML parser needs a ton of "hacks" to become a HTML parser.

Also browsers needs an XML parser anyhow to support svg that's an xml-based format, also the DOM spec is written to support namespaces's like XML.

XSLT did complicate things, and most importantly it seems many relied on that one old implementation written in the 90s that was a swiss-cheese when it came to security concerns that nobody wanted to spend money on maintaining.

(1): https://html.spec.whatwg.org/multipage/parsing.html#script-d...

Audio however was a crapshoot for years, especially for games.

Even basic WebAudio took until 2015, and the final piece to match Flash being AudioWorklet was only first available in 2018(Chrome) and took until April _2021_ land in Safari.

So before 2021 you needed to either write your own abstractions to support multiple API's with different execution models with so-so capabilties to be somewhat on-par with what Flash provided or even for years resort to simpler solutions (ie just samples).

I've adapted a crypto-lib for TLS connections and had a mistake during negotation that truncated some algo-selection value, worked up until the other party started trialling post-quantum algorthims that apparently had algo-id's that collided with the truncated values I was using.

Claude figured out that from the code and trialling TLS handshakes.

Besides, since there was a bounty on finding the curve it seems unlikely that someone would've found out and not shared that? (unless working at a security service that figured out that it was possible to attack?)

I was quite nervious, but check Youtube, there's guaranteed some people that has documented the steps, do check multiple ones as some people are more detail oriented or just know what parts can be dangerous/tricky. Good tools can be a lifesaver also (isoprop alcohol for cleaning, lotsa q-tips, good screwdrivers and plastic picks like the fixit toolkits to pry gently).

Not entirely sure if those rules were relaxed, but the state and banks with higher cash handling fees did have a fair share in pushing cash out.

I'm actually also rewriting a header-only server (std c++ and sockets) I wrote a few years back to take advantage of C++26 reflections and similar to give it something similar in capability to AspNetCore+EFCore.

Also, I think programmers/mathematicians (the ones that should be calling out bullshit) are enthralled because many of our jobs was so suitable to automation (this was the secret of the 10x engineers, they didn't shit out too much unnecessary crap.. now that unnecessary crap is spit out at rocket-speed so everyone is working at that speed or even faster).

That said, information-gruntwork that a nominally competent person could do is up for grabs and many previously so called "bullshit" jobs were tied to that.

You can probably even promise 99% uptime (sounds good enough to most buyers probably?) even if people sleep 8 hours a day as long as the failures comes no earlier than than 15 minutes into their sleep and only happens at most once a month (1% of 30 days is 7,8 hours).

But the focus shifted in recent years to treating "OCS" (ie "standard" Amiga500 with original chipset and 1mb,etc) more like a fixed platform like the C64 instead and imho has seen a bit of a revival since is mostly in the interesting part of pushing the OCS HW.

I guess the point is that a pre-compiled version could have HW checkpoints from a slow emulated run, so that it can then run at full speed and just advance the HW to the required timestate when a write is to occur (ie, instead of costly cycle-accurate emulationg, most HW operations can be batched inbetween time-sensitive checkpoints).

Then again, why not just record a video at that point? :P

No, the debugger (when using Visual Studio proper) breaks at the point of throwing (be it an explicit throw or something underlying like a NPE or out-of-bounds access), _I_ literally use this _all_ the time to fix code while in motion (set next statement on a line a bit back or even the same line to rewind just a tiny bit, change the code, fix errant variables, press F5 to continue and the IDE will rebuild and reposition instruction pointers and update stacks).

What the spec says about execution semantics of exceptions is one thing, what capabilities the debugger provides can be something entirely different.

Perhaps VSCode or some other environments don't have as good debuggers, but trust me when I say that it allows you do do exactly what you need.

Someone saying something in a comment doesn't negate a capability that person doesn't know about.

I was offered my first outside job after the second year of highschool, I kinda accidentally interviewed for a at the time respected gamedev firm (since I was looking for a summerjob heh) and when we started talking about when to start and I mentioned my school semesters the interviewer realized that I was younger than he had assumed.

(I'm not looking forward to people automatically AI-upressing of old games, I'd just prefer them to render-upscale and be faithful to the resolutions the games were built for back in the day).

1: Local models are catching up quickly

2: Visual Studio Intellicode (not to be confused with Intellisense) was/is surprisingly good at suggestions (when it first appeared before people went over to CLI's I felt that it was almost magically good for it's time, turned off co-pilot and whatever backend for a reason of compliance for a local workspace and the suggestions are quite good still even if not on the same level as the frontier suggestions).

If it pans out, with their brand people many would probably be happy to fork over for a Jetbrains licence.

Visual Studio has done this since the 90s for C++ code (and C# code for a good while also, just most people have debugger exception catching turned off).

How I know? Back in 2000-2001 we were working on a Dreamcast game with a 3dfx/Glide PC renderer, that 3dfx driver on WinNT was unstable and crashed the machine every 3rd-5th start of the game so being able to edit-continue was a damn lifesaver since a lot of common tweaking of custom stuff outside of what connected to the scripting system could be done at runtime.

This is one thing I think so makes people loyal to MSVC despite it having been behind on standards (gonna be interesting to see if they get reflection up to speed for the 2027 release, GCC's there but not yet Clang).

1: Ice-mass that isn't contaminated by atomic testing fallout (if the ice has been there since the 40s it's without radioactive waste (faschinating to read about how WW2 wrecks is a prime resource of steel since it's a huge amount of steel without trace amounts of radionucletiods from testing fallout).

2: No current interference (nuclear power, radiowaves,etc) creating possible test uncertainties.

3: I'm sure there are other reasons

The negative naturally is cost, but since the expriment succeeded it will probably be useful for any attempts to send robots or even humanity into space beyond the solar system.

No breakdown on the age of the patents though so it'd be interesting to see how things evolve over the years.