We accept contributions from other sites (e.g., Vimeo, Dailymotion, etc) who wanted to replace their long tail of in the wild embeds prior to Flash removal.
IMO this was good practice to keep the web running smoothly at the time.
It is reminiscent of Windows 95's specific code to see if SimCity is running, and allocate memory differently if it was.
> Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.
When I was at Apple in the mid 90's (Before Steve) I remember the Mac OS source code had tons of special app checks, mostly for various Microsoft (also others) apps that did odd things, so that older versions would keep running. When they were working on Copland, I thought it was nuts to write a new OS from scratch, but still do reimplement the hacks so that everything would still run. Good thing it all went away.
My astonishment is that Microsoft knew about SimCity. I was 15 in 1995 and I thought the world was so big that Microsoft couldn’t possibly know about the myriad of software that their OS could run.
It turns out the world was so small that Microsoft could, probably, inventory less than a hundred products that made 99% users happy.
Raymond Chen talked about how periodically the devs were tasked with getting a handful of software purchased at CompUSA or w/e out of a grocery cart, opening them up, installing them and testing that they worked with the then-unreleased Win95.
The comparison is apt. The multiprotocol thick client platforms we call "web browsers" are easily on par with operating systems in both their complexity, and their mission criticality. LoC has never been a great comparison measure, but I'd anticipate that all current evergreen browsers have more lines of code than Windows 95 did.
Very cool and very swag, but down this road lies nightmares. I respect the dedication to backwards compat but we shouldn’t pretend this kind of thing has no cost.
Back then you couldn't just bug the game developer to issue an update patch, and anything significant breaking between Windows versions affects Windows adoption and not the adoption of the software the user is actually interested in. We see the latter even today, with Windows 8 being a failure for how much it changed and broke user workflows and Windows 11 getting a decent bit of pushback too.
In a way this realization is what's finally making Linux viable for gaming. Instead of expecting developers to bring compatibility and bug fixes, have the system provide it and suddenly you can even have an entire gaming console designed for PC gaming on Linux, thus also giving you enough momentum for developers to make adjustments so their game runs better on the compatibility layer.
We're talking early 90s. Not only were automatic updates not a thing, manual updates were hardly thing. If Windows wanted SimCity to work on their new windows release, the only option was to make the new windows release work with SimCity, not the other way around.
Yeah. I had this version of SimCity. It came on floppy disk. I had a 14.4k modem at the time (or maybe still the stock 2400?) the only way for MSFT to make this work was to add code like this. Honestly we still do it sometimes. Emulators routinely emulate bugs because those bugs were never fixed in the real systems.
The hack being described was very very old, this is exactly what the AppCompat system does in Windows now. AppCompat shims only apply to specific versions of specific apps (or get rolled up into "layers" which is what you get when you mark an app to "Run under XP compatibility"), and don't end up affecting other ones
That'd break SimCity updates, and probably trigger antivirus warnings, and annoy Maxis devs and lawyers...
Whereas "we'll tweak our OS to suit your app to ensure it doesn't break with an upgrade"? That just wins loyalty from the game devs, users, and everyone involved except purist-coder types.
By changing the system they have a flag they can turn on for any applications that would be helped by a similar hack. It's not like use after free was a particularly rare event in mid 90s code.
You mean, like watch for an install of SimCity, and modify the game's files? I don't have enough experience in hardware and PCs to know if that was at all possible or practical.
I remember the days of going down to my friends store because he had a modem and knew which BBSes would have software downloads. I had to bring my own floppy disk because those things cost money.
Yeah... I've put well over 10k hours into writing FOSS and consistently encounter this attitude there, too. I never imagined we could get this far tolerating such frequent contempt for both end-users and their advocates, such as interface designers. If your PR poses even a theoretical future inconvenience to developers, good luck getting it merged, regardless of the user benefit. Until this changes, user-facing open source alternatives will always be alternatives rather than the standard.
Not just devs and end users, but also devs and other devs. Not in rejecting pulls but changing API's like renaming functions, removing functions, swapping argument positions, changing the complete workflow of a library, etc... without care. The amount of breakage in the OSS world is just ridiculous.
I'm probably biased because I deal with a lot of Javascript where this sort of behaviour is rampant.
It’s easy to optimize for developer convenience when you aren’t getting paid to do the work… arguably it’s the only way non-profit open source software can progress at all on average. The tails are heavy, though.
A workaround does not necessitate tech debt. "Workaround" is a conflated term - it basically implies something works differently than one might expect, which is subjective. Anyway, what is the alternative? Saying "that's not my problem"? Users don't care about who is technically at fault, they care about a well functioning product.
"Tech debt" is doing things quickly now with the price that you have to clean up (i.e. invest more time) later, hence the word "debt". This is sometimes a good trade-off, just as financial debt is. Not everything that looks a bit ugly is "tech debt".
And yes, it's ugly, but reality is ugly so we have to deal with it.
I would have more sympathy for that if Windows 95 were just suddenly dropped out of the sky to some rock music, but my experience with MSDN is that they are quite liberal with access to beta versions so software vendors can test their products before the unwashed masses get it
And I say this as someone who remembers the binders full of CDROMs that arrived, so not just "download this iso" modern day conveniences
Let's say SimCity took advantage of this beta program and fixed their buggy software. Great!
Now how do you get that fixed software to every user who bought a SimCity CD or floppies? Remember, most of your users don't have a modem and there is no widespread internet infrastructure at the time of the Windows 95 release.
You're arguing who is truly at fault, but as a consumer with less sophistication than "MSDN Subscriber" who are you going to blame when Win95 doesn't run your favorite software?
Those who prioritize code correctness over user experience will soon find themselves in that blessed paradise where they never have to worry about user experience anymore... because there are no more users.
Microsoft made most of its money back then in two ways - corporations and individuals buying Windows upgrades and bundling Windows with new computers.
If Windows got a reputation for being incompatible with apps, people wouldn’t upgrade.
iOS doesn’t really have that problem. New phones are always going to come with new operating systems and if your app doesn’t run on the new OS, users are going to blame the app developers.
Also most of the incompatibility with apps and new operating systems comes from developers using unpublished APIs. Apple is very strict about not allowing developers to use unpublished methods [1].
[1] I refuse to use the term “private APIs”. An API is a documented method that the platform vendor documents and promises to support
Probably also the <object> equivalent, maybe only that and not <embed>, I’m not sure. I never had a great deal to do with those two tags.
I don’t know why it has to be done this way. I’d have thought that without this extra code it’d roughly fall back to being an iframe on the original URL, and then YouTube could just check if it’s in a frame and behave as an embed instead of the main UI. But there’s probably a reason why they’ve all done it this kind of way.
Someone correct me if I'm wrong, but I think <embed> was used because it embedded a flash player, back when flash existed on the web. Then browsers decided to get rid of flash, and something had to replace it. You can't <embed> HTML pages, so wasn't really up to YouTube if to break it or not.
16 people say I'm right, one person say I'm wrong. I'm not doubting you, but I'd love it if you could show how I'm wrong? Maybe I misremember how to use <embed>.
Where? To be clear, it doesn't matter—being wrong is wrong. Those other people, even if they exist, are wrong, too.
(I can half-understand not checking before you posted the original comment. But why wouldn't you, in response to someone letting you know that you are wrong—which was itself in response to you asking, by the way—take half as much time to just check as the amount of time it took to type out such an bewilderingly obnoxious followup?)
Youtube didn't change - browsers did. Embed loads plugin content: browsers broadly moved away from plugins (they'll still technically work if you feel like jumping through installation hoops as a user but they're not maintained and not broadly preinstalled as they used to be).
During this broad migration by the browser community away from supporting plugins within embed tags, there was likely some audits of how widely they were relied upon across the web, and compat hacks put in place to account for the most common uses.
It's very likely Youtube removed endpoints after the browser hacks were in place for some time.
It’s pragmatic. End users don’t care enough to place the blame correctly. All they think is “my iPhone can’t play this video that my friend sent me, my phone sucks”. It just doesn’t matter whose fault it is that that’s the reality.
the all the embed tags video broke on my old site with youtube video embed when this was done, I just changed my code, but I guess a lot people probably complained. So there you go.
So much that the poor people who were also randomly given a URL finishing with XcQ can’t make people read their video, and Youtube will need a specific exception to ensure generated codes don’t finish with that.
Some people here are complaining that this is a hack, technical debt, etc. I thought the point would be the political one, as it were. YouTube.com gets special treatment in a major web browser, whereas Sal's discount video website has to conform to standards like all the other plebs.
It's an erosion (however minor, by itself) of the idea of an open standard.
Apple has a list of websites with quirks that don’t support its “generate strong passwords” feature even though there is HTML spec where you can specify the types of passwords you support.
I’d rather have the companies fighting for the user. What is the purpose of a standard anyway, other than to serve the users? The idea is counterproductive if it results in a worse UX, even if just in the medium term.
In this case, getting those companies to fix their broken code is unrealistic. Less realistic than just providing a whitelist anyway.
You think Google is doing this because they "fight for the user"?! Maybe in the same way cattle ranchers "fight for the livestock" by plumbing wells and seeding grasslands. BTW, almost anything can be justified with this logic: "We propose a convoluted device level tracking scheme that locks down all advert/databroker revenue... a tech moat so wide that, coincidentally, we are the only potential beneficiaries... because we fight for the user!"
I just appreciate that the end result is a better UX. How we got there, I don't care. The standards are important, but they're ultimately there to provide a nice UX and that's it.
Well that is a good way of ensuring that the same class of problems will endlessly reappear, while also providing a broken utilitarian end-justifies-the-means rationale that is certain to be abused.
> The standards are important, but they're ultimately there to provide a nice UX and that's it.
No, standards are there to make interoperability possible, which overcomes the hazards of market network effect, leveling the field for more competing solutions, thus yielding a better <insert literally anything in the whole world, including UX>.
Most platform vendors have this in some form or the other. WebKit has far more here, for example: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa.... These are cool and all for when you want software to keep working, but if you're the person writing these, the one thing you should absolutely make sure to do is reach out to the authors of the software you're working around to see if they are willing to fix their code. Most of the time they are! But I invariable see code go into the OS/browser/whatever and engineers bemoaning how they have to work super hard on backcompat, and I'm like…"ok, but when did you send us a bug?"
I'm not sure if it's still there, but for a long time there was a chunk of code in the Mozilla code base that hunted for several browser extensions in Windows every time the browser started up and did some patch up work in the file system to make sure that those extensions could be found in the browser because some older installers would dump them in non-standard places. This was to avoid the issue that if the user had already installed the application with the corresponding extension and it was working in Internet Explorer, it wouldn't automatically work in Firefox without this patch up process. And in that case, it wasn't the extension that was broken from the user's point of view... It was Firefox.
Some technologies are so fundamental to the web experience that when they break, the user perceives the browser to be broken, not that technology.
I bet the AskBar was always in the perfect standard place for Firefox to find it, despite being run by Oracle (Yes, Oracle installers for Java included the AskBar. A crime in my opinion).
This is interesting.
It looks like there was even some discussion of making this behaviour part of the standard, since it's implemented by all of the major browsers.
When the first iPhone was released, YouTube used Flash instead of HTML5. Safari had special code to play the video with the native player instead of displaying a blank square. I suppose (from the flash-specific detection in the supportsMIMEType method) that this code was in charge of that logic.
Note that while the code was written in 2014 (well after the iphone was released), someone tried to remove the code this year[1], and gave up because some sites now rely on this hack.
The code was added to the public WebKit source tree, but it wasn't written at the time. It was upstreamed from the internal fork of WebKit that Apple used for iOS.
I was just about to make this same exact comment! I was half way down the page and thought, "Wait... What language is this again?" I had to scroll back up to confirm.
Nah, it’s just having professional coding and review standards that are very heavily enforced. This particular code is also aided by being fairly simple in function of course. In my experience C code is generally worse than C++, as a lot of what large C projects do is stuff that C++ does automatically, and with more safety.
That said for the most squirrely code in webkit you need to look to JSC where the perf critical and machine abusing code is stuck (though obviously minimized as much as possible). My most terrible contribution there is the parser which uses macros and templates together (parsing JS is extremely perf critical in real world page loading because the parser often has to deal with megs of code, all of which has to be parsed before you can consider executing it and in many places page loading is blocked on said execution)
We accept contributions from other sites (e.g., Vimeo, Dailymotion, etc) who wanted to replace their long tail of in the wild embeds prior to Flash removal.