Perhaps worse than the death of Flash was the death of Shockwave. I feel like so many Shockwave games I played back in the day are completely gone with no reference to them on the modern internet. Today, you can install some version of Flash on most operating systems, but I don't think there's any modern standalone Shockwave player and I could only get the plugin to work in Safari on macOS. Chrome and Firefox don't even run those types of plugins anymore.
There's one particular Shockwave game that I was recently able to recover from the depths of the Wayback Machine, which was a game from Disney for the Inspector Gadget movie; terrible film, but their website had this nifty little game that wasn't necessarily difficult but was addicting in that I wanted to see just how far I could go with it. For years I thought it was gone for good, and was glad to finally see it again after I lost it 15+ years ago.
I always liked it in part because I don't think I've seen a similar game. It's kind of like if you took the random shapes part of Tetris and added a "jigsaw puzzle" element.
When asking the difference between Shockwave and Flash, you'll often get the answer that they're two products that have nothing to do with each other. That is almost true, but not entirely true.
Director was originally meant for creating CD-ROM games. However, in the early 90's, it began finding a new home on the web. "Shockwave" was Macromedia's term which meant "compressed for the web." The first entry in the Shockwave line of products was Shockwave Director Player - so called because it could play Director Movies which had been compressed for the web. Because it was, at the time, the first and only product in the Shockwave line of products, Shockwave Director Player was often shortened to just "Shockwave."
Enter Flash. Again, Macromedia wanted Flash Movies to be able to be compressed so they could be downloaded quickly over the web - so they made the Shockwave Flash Player plugin, so called because it could play Flash Movies which had been compressed for the web. So there was Shockwave Director Player, to play compressed Director Movies, and Shockwave Flash Player, to play compressed Flash Movies.
The problem is, by this point, everyone already knew Shockwave Director Player as just "Shockwave." To those uninformed, it seemed that there was now both a Shockwave AND a Shockwave Flash. Shockwave Flash Player was more often referred to as just Flash, to avoid confusion with what was already being referred to as Shockwave.
So when we say Shockwave, we're referring to the first word in Shockwave Director Player, but when we say Flash, we're referring to the second word in Shockwave Flash Player...
Or at least, this was the case until Adobe acquired these names from Macromedia, at which point they just decided to rename the plugins to what they were being popularly referred to as. Now what was Shockwave Director Player is officially just called Shockwave, and what was Shockwave Flash Player is officially just called Flash. In order to further undo the confusion, SWF was changed to stand for Small Web Files instead of ShockWave Flash.
As for useless trivia, Director actually even predates it's main use of producing multimedia CD-ROMs. When it was still a MacroMind product, it was used for stuff like the "getting started" floppy disk for early Macs (the tutorial where you learned how to use a mouse by feeding fish and stuff)
Right, I suppose it's not fair to say it was originally meant for "creating CD-ROM games," that's an oversimplification. It's more like it was meant as a way to make applications without needing to learn a more advanced language like C++.
Wow, I think I was just over 13 years old when I got my hands on Macromedia Studio MX. I knew the difference between Shockwave and Flash, but I never knew why the authoring program for Flash was called Flash, and the one for "Shockwave" was called Director.
Shockwave and Flash are two distinct technologies to achieve essentially the same thing. At one point either Macromedia or Adobe conflated them by referring to Flash as "Shockwave Flash", but Shockwave was its own thing. Flash's scripting language was ActionScript and Shockwave had a language called Lingo.
In fact, I totally forgot about Lingo until just now. But it actually looks pretty cool:
https://get.adobe.com/shockwave/ is allegedly still a thing that exists and that you can install if you have Windows. It says it works on Windows 7 and 8, IE, and Firefox. My guess is that they haven't updated that, and it'll no longer work on Firefox since Quantum, but it's likely some flavor of IE will work with you there. And my guess is it'll work on Windows 10 with IE, since most things that work on 8 work fine on 10.
Actually, it's still being updated, but only on Windows. Director (the authoring tool used to create Shockwave Movies) was discontinued, but Shockwave was not.
Come and join the multitudes working in big corporate legacy application support, where the applications all have <100 users and are scheduled to be replaced imminently (and have been for the last 10 years).
Yes. Alternatively, you can use Pale Moon which is an actively maintained fork of Firefox that never got rid of NPAPI. Or, if you don't want to leave the comfort of your preferred browser, you can use the IETab extension.
Note that plugins do not work in Microsoft Edge. It has to be Internet Explorer. Edge didn't replace IE, you can still find IE by searching for Internet Explorer in the Windows 10 start menu.
Unfortunately, Java is a bit of an archival nightmare. Java Applets can do pretty much anything they want, they aren't consistent in that sense. Unlike Flash you can't just run them offline in a Projector, and the code structure of an applet is different from that of a normal Java app. This is on top of being unable to play Java games without getting a tonne of (well deserved) security warnings (unless you want to pay Oracle $100 per month for a signature.) Java in the browser was just a bad idea all around.
Because it gives the Java programmer too much power in an environment that should be safe. For example there are applets like AppEmbed that can run an EXE in the browser. That's just insane. Flash and Shockwave in contrast are limited in that sense, you are constrained to doing what you are able to accomplish with ActionScript or Lingo (or at least, that is intended to be the case.) Flash is insecure because it's buggy, Java is insecure because it's buggy AND because it's intended to work in ways you'd think are obviously insecure!
Applets, unless especially privileged by the user, run in a sandbox that prevent them from interacting with the local OS [1]. They certainly cannot run EXEs, again, unless the user consents.
In theory the Applet sandbox works really well. It's an extremely secure environment that's been deployed widely in the most demanding conditions -- think banks and governments. In practice the Applet security model encountered the following problems:
(1) Users are really, really dumb. They are happy to grant escalated privileges to the some 3D farming game they stumbled upon on the internet. Users will literally click on anything you tell them to. [2]
(2) Getting users to upgrade Java was terribly difficult. This meant when a real security flaw was discovered it might hang around for years and years and years. There was no mechanism to force users to upgrade Java or to actively disable Java installations proven insecure.
Maybe I'm confused because it's only relatively recently that I started again to take Java seriously, but isn't that precisely an example of a domain the Java security manager addresses? Again, I am well aware of the implementation bugs that have existed, and I don't know offhand if the security manager was part of Java's initial design or was added later, but I'm still confused as to why your ire's directed at the general concept of Java in the browser, rather than the specifically flawed implementations.
There's just no safe way to do what Java applets enabled (arbitrary code execution), because of the massive attack surface. It's one reason why NPAPI is dead.
Java applets never enabled arbitrary code execution. (Where do people even come up with this stuff?) Spend five minutes on Google and you can learn about the Applet sandbox which prevented Applets from doing most anything but draw to a section of the browser window and connect back to their origin server (not unlike Javascript).
Yeah, what do you think the applet is run on? The JVM. That's the attack surface. And securing that went so well that everybody uses Java applets everywhere and applets are allowed by default (hint: securing it is impossible and they're disabled by default because of it).
Unfortunately Javascript-infested websites are a bit of an archival nightmare. Javascript can do pretty much anything it wants, it isn't consistent in that sense. You can't run them offline.
Javascript in the browser is just a bad idea all around.
You can generally "Save As..." and they tend to work just fine. Like any code which has network access, they can be dependent on various resources. I sometimes run a downloaded file through an insecure chrome instance (--disable-web-security and a unique --user-data-dir) with a catch-all service-worker. That'd probably not work with applets as they make their requests outside the browser AFAIK.
Also the security sandbox of Javascript is one of the best, if not the best. So it cannot do anything it wants.
Not everything is a chat application. But even a chat application can and should partially work without an internet connection: Reading old messages and composing new ones can work offline.
That has nothing to do with Javascript. If you use canonical, cacheable URIs for your requests, my method above works fine.
In my day job, I'm working on a CRM and sales system that is 100% web based and does work offline and is even offline-first (I love you Germany, but your mobile network sucks).
There may be many other problems with it but offline is mostly a solved problem in the web world.
Quick experiment: In a new Firefox profile, I opened a couple of websites [1]. Then I went offline and tried to load them again. Every time I just got the default "server not found" page of Firefox.
"Offline" is no more solved "not hijacking scrolling", "linkable URLs" and "not re-inventing <a href> badly".
Did you try right clicking and choosing "Save as..."?
As I said before, it's a 5-minute thing to get started with service-workers. Web-sites can use that and then you don't even need to save. There is this great offline library, fellow developers! Use it! What other platform gives you such easy-to-use offline capabilities?
> As I said before, it's a 5-minute thing to get started with service-workers. Web-sites can use that and then you don't even need to save.
I don't care if websites can use that if they don't.
> You are dealing with a Turing-complete language here.
That's the fucking problem.
> What is the alternative you are supporting instead the current situation?
Using a proper application platform instead of a pile of hacks on top of the web. Without that pile of hacks, the web would actually be usable because publishers would not be able to break the UX.
It's a damn shame that HTML5 implementations of Flash, like Shumway (https://en.wikipedia.org/wiki/Shumway_(software)) and Swiffy (https://en.wikipedia.org/wiki/Google_Swiffy) are no longer being actively developed. I would have thought running SWFs in the JS sandbox would be a good way to get the compatibility of Flash, without the insane security bugs that it comes with.
And in case anyone is still in doubt about Flash's security woes - take a gander at the Flash CVE page at https://www.cvedetails.com/vulnerability-list/vendor_id-53/p.... There were FIVE CVSS 10 bugs (total and complete remote code execution with minimal user interaction, i.e. visit a malicious page and your computer is owned) published just two months ago. The author of Flashpoint is absolutely correct in his assessment that Flash will be overrun with security bugs as soon as it hits EOL in 2020.
> I would have thought running SWFs in the JS sandbox would be a good way to get the compatibility of Flash
And these days a WebAssembly build of Flash player would be an even better way, but it would depend on Adobe being willing to spend the time and the money to do it.
I’ve spent a ridiculous amount of time reverse engineering SWF files. There was even a time when Adobe published the SWF file bytecode format. It’s not a terribly complicated format like photoshop psd.
WebAssembly is probably a good target. However flash added a ton of apis in their latest versions. They were so ahead of the game before html5 before even became a thing.
I’m sure Adobe has patents/trademark on some of the things. Also Adobe Flex, that was a god send for rich internet applications. Their components were really well done and I still can’t fine equivalent things in this day and age.
I do strongly believe if Adobe had open sourced big chunks of things, Flash and a number of technologies would still be relevant today. Their big money makers were the IDE’s like Flash Studio, dreamweaver, photoshop etc. The formats and the runtimes should have been open from the get go.
Although it was the Ballmer era when most corporate CEOs truly believed OS was cancer.
Flash was mixed with licensed non-opensource-able stuff and it wasn't a trivial code base in the first place. Given that Adobe hasn't actually made much money off Flash, such an effort would have been likely unfeasible and prohibitively expensive.
Someone from the Flash team could chime in here to give more details.
On a sidenote, swf specification was simply great. It was only after I read it that I fully grokked the Flash development (not that I did much of it, because I wasn't a fan of Flash webpages, and couldn't find a way to make money off Flash games).
> However flash added a ton of apis in their latest versions.
Excuse my ignorance: I never used Flash (I was already against abusing the browser for things like that so I only built desktop apps with Delphi etc) but I do use Haxe(with OpenFL) now; is that not supposed to implement those APIs?
Another option might be for them to open source the code and let others do the port. However, there might be legal barriers to doing that if they don't own the rights to it all.
The thing is, Flash is still in use, just not on the web and it's not called Flash. It's called Adobe Animate. Adobe Animate, formerly Flash, is still in use for animating shows on television. Open sourcing Flash would mean creating a potential competitor with Animate, which Adobe surely doesn't want. The only reason Adobe would have to open source Flash is "out of the kindness of their hearts" which is not enough. This is nothing but a needlessly risky business venture to them.
They wouldn’t need to open source the editor, only the player, so competing with Animate shouldn’t be an issue. But yes, there’s not much incentive to open source anything.
Yes, we're in a different situation than people who preserve old console or PC games because those have a platform that is pretty much known and extensively documented. Even if you can't run the hardware anymore there are emulators that work great. It's harder on closed platforms like Nintendo.
With Flash, I don't know that we'll ever have an open source desktop player to allow preserving these games and allowing them to play on all future platforms. You might as well ask someone to write a complete implementation of Java, with no access to the source code, for free. Eventually we'll probably be stuck with old virtualized editions of windows running old versions of Flash. Let alone the possibility of leaving x86 behind completely.
I do understand some of the reasons behind the web community’s rejection of flash over the past decade and a half — security and accessibility issues, closed standards, etc. However Flash and Shockwawe technology enabled smooth interactive graphics on 90’s and 00’s desktop hardware, in packages that are friendly for 56kbps dialup connections. Nothing compares to it, still to this day — web platform tech still horribly underperforms and is only now capable of what flash could do a decade ago. We could also blame Apple and Smartphones and Yourube for its demise, but I feel like we haven’t moved forward in terms of quality shareable interactive media since Flash.
It all moved to mobile. The audience, the devs, the marketing money, all of it. There's 100x more lotto ticket buyers on mobile than there ever were Flash devs which obscures it; but every Flash dev moved on to mobile or simply moved on from games. You could release the perfect canvas game engine tomorrow and if Unity didn't port to it not a single game dev would build a company around it
I hope by smooth you're referring to the graphics being vector vs bitmap, because Flash performed really badly once you added any kind of complexity to a scene. (edit: simple things worked brilliantly though, and often that was enough.) The key innovation of Flash was and still is the creation side of things in Flash Pro rather than the runtime.
My main experience was with Line Rider. I didn't create it, but I became involved in the community and started making tweaked versions with tools that made it easier to create tracks (as opposed to versions that let you do things like change the physics or the rider).
Every line you added to a track caused a new MovieClip to be added to the scene that had a line drawn in it. By the time you had around 3,000 lines or so you'd start to get reduced framerates. 3,000 lines sounds like a lot, but is tiny when you consider tracks that have accompanying artwork.
A few years ago, we released a JS + WebGL rewrite of Line Rider that has a physics engine that's bug-for-bug compatible with the original (you can play it at https://www.linerider.com/ if you're interested - sorry if that's too self promotional). With access to WebGL and a massively faster ECMAScript runtime, the JS version runs multiple orders of magnitude faster than the original Flash version.
It's now possible to work with tracks that have hundreds of thousands of lines without experiencing frame rate drops as opposed to just a few thousand lines. So as for web platform tech underperforming from a runtime point of view, I disagree.
The problem is that all the ingredients are there to make something great, but the developer effort required is monumental in comparison to how fast it was to make something work with Flash Pro.
To be fair, it became possible to do deeper graphical optimizations in Flash later in its lifespan(particularly after the BitmapData API, and towards the very end, Stage3D) but I would agree that it wasn't in the spirit of the tool to work on Flash games with an eye towards high framerates, that just happened as a byproduct of the web-game space professionalizing around the close of the last decade.
It really was an odd, "software is brutal" history in that in a very short timeframe Flash progressed from being the domain of hobbyist game makers, animators and web site designers into the core client technology of every web site using audio and video. And then a few years after that, it was cut off from expanding to mobile and was strangled on the web through expansion of HTML.
I also grew up spending a lot of time playing those games.
I say good ridance to the flash video players, but seeing the screenshots of those games, it makes me pretty sad to think that so many of them might be going away.
Yeah it seems like people don't understand this. We've had an era of JavaScript dominating web standards. I also don't think people realize this is only the start of wasm...
And open platforms, if browser vendors decide to break your content. Hard to say at this point whether HTML5 games will end up lasting any longer than Flash games did. Openness is valuable but you also just have to look at whether the platform owner(s) are going to stick around (Google isn't going anywhere, at least) and whether they have a long-term commitment to the products and APIs they put out there. HTML5 is starting to look like a churn nightmare between arbitrary changes to audio policy and major features getting shut off due to threats like Spectre.
Adobe was a very bad platform steward regardless, but 5 years from now it may turn out that Win32 was a better choice in terms of developer investment/maintenance than HTML5 for many developers. iOS has had an incredible upkeep cost for indie game developers who released products on it early on, and we've seen many developers opt to pull games from the store instead of spend time+money updating them.
Hopefully WebAssembly helps fix things here by providing a much cleaner compile target (with well-defined APIs) that has good performance. Moving to HTML5 had a major performance hit for people previously using Flash or Unity's plugin but most of that hit is gone once you use wasm.
This was the only good option at the time. One alternative was for people to pass .exe files around. That was a great way to spread viruses. Another alternative was Java applets which was a great way to lock up a browser. JavaScript didn't do shit in the the Netscape and IE 4/5 days. So was everyone supposed to make Windows games or just give up? Would that have been better?
Let this be a warning to young developers tying into browser platforms.
For all the openness of web standards, let's remember that browsers are proprietary.
If a browser vendor decide to do something (whatever it is, good or bad), there is pretty much nothing users or developers can do, we saw it with IE6 for a long time, we now see it with Google Chrome too.
AFAIK browser plugins were considered part of those web standards (see [0] and [1])
I was thinking in term of player base size. But now that I think about it more, player base size makes no difference in the context of this conversation.
Essentially, all software has a end of life. I'll grant that Apple has done work to maintain their software across major processor and operating system changes, but at some point that support is dropped.
Yes. Well, since 2002 some old versions aren't, but v7 onwards is. macOS is based on XNU and NeXTSTEP, which are based on Mach and BSD, but macOS is not solely a Unix system and few use it as such. In fact, if you were to make a program using only the FLOSS unixy parts of macOS, porting it to other POSIX systems would likely be trivial. I hardly even count that as "macOS software" in the exclusivity sense.
macOS being unix-based doesn't make it less proprietary. z/OS is Unix certified and proprietary as balls.
People forget that actual Unix descendants are really mostly proprietary. Linux and BSD are what we often think of today, but those are really more "Unix-like's" and many of the "true" Unixes tend to be proprietary systems like AIX, HP-UX, IRIX (now deceased), z/OS etc.
The bare core of macOS (Darwin) is open source, but pretty much everything people identify with macOS is proprietary code built on top of Darwin. You used to be able to get standalone distributions of Darwin (maybe you still can?) that people built from Apple's source and they were almost completely unrecognizable.
Right, that's my point. What most people associate with "macOS" is actually the stuff layered on top of Darwin, which is mostly proprietary. It's not just the GUI, it's also a lot of the frameworks and libraries as well.
Doubt it. There are still dozens of frameworks that still link to OpenGL, and Apple’d need to drop or update them all in a year. Most likely it will remain on the system for at least a couple years.
- Load the game into a real web browser and let it run for a bit
- Intercept all network requests with a caching proxy
- Save the external resources loaded to disk
Would that help? The process could be automated, though only for games which load all their resources without human interaction. But then, clicking through a few screens to get a game to start is a much less time- and knowledge-intensive task per game than reverse-engineering the source code of each, at least to get as much data backed up in some state as possible before it disappears.
While you need to play through the entire game to be sure you have all of it, this is a big time save, though with the downside it doesn't work over HTTPS. It's also possible to use a Fiddler script to accomplish something similar, which defeats the HTTPS problem.
I like this idea, but (and I know barely anything about games) then I wonder that maybe the resources for lets say the final level of a game are not included, if you let it idle only on the first level, no?
There’s eventually going to be one question on the lips of everyone involved, though: is this legal? And the only real answer is nobody knows and really, nobody should care.
I can understand having an urge to preserve something that is in danger of decaying past recovery — I feel the same way when I see an interesting building or a classic airplane rotting away somewhere — but the usual course of action is to choose what you find most worth saving, purchase it from the owner, and restore your new possession. Any other course isn't legal, in most cases, and it isn't here either, in most cases. I care about that, and some of the game creators will care about it too.
Here's the thing. A lot of the games being saved here are games that the original publishers/developers no longer care about - that or the original creators don't even exist anymore. That throws a large portion of Flash games into the gray area of abandonware, although that's a different discussion entirely.
This is actually a place where I differ with BlueMaxima (BlueMaxima is Flashpoint's creator and the writer of the article linked here.) Personally, if I were running the project I would remove a game if the original creator asked, simply out of respect for them.
However, I think that most of the staff involved with Flashpoint would disagree with me here. It is more of a "for now, just go go go and we'll worry about organizing everything and dealing with the repercussions later." There's a lot of Flash games out there to say the least and Flash being discontinued in 2020 leaves us limited time if we hope to save as much as possible.
Copyright isn't really a right in the sense of the public freedoms/choice.
It's there to limit publishing and distribution to only those with the legal document saying they can. It's more of a anti-right. In fact historically it was created for the purpose of censorship.
People have a right to the fruits of their labors. I don't care a tinker's mother about the history of copyright — the principle is simple, and copyright is a flawed protection of that right.
Though it may be used by industry on some occasion to protect someone's ability to profit. Copyright and the right to the fruits of your labor are not the same thing.
In cases like this disregarding one isn't equivalent to infringing on the other.
I expressed the contrast between copyright and the right it attempts to protect above. Notice that I didn't say anything about profiting from the fruit of their labors, but the right to them, no matter whether they choose to profit or let it rot. It's just as much an infringement to preserve it without their permission as it is to sell it.
Say you somehow have advance knowledge of the burning of the Library of Alexandria. Is it legal to steal as many books as you can from the Library prior? Of course not. Is this the only way to save unique volumes from irrevocable destruction when you have no way to convince the librarians of its imminent fate, or even to contact them at all? Yes.
And then return them to the owner once the emergency is over? Yes. I don't see that happening here. What you describe is an emergency response; what's happening here looks like looting.
(Edit: soften what could be read as an outright accusation.)
To clarify, I should have said, "I don't foresee that happening here." I predict, based on the attitudes the article expressed, that the writer has little interest in the owners of these games, and even less interest in their rights.
I think when it comes down to a conflict between an individual's property rights, and the entirety of future human culture having access to a work to learn from and build upon; I say fuck your individual property rights.
Especially in situations where a work is entirely digital, and preserving the work does absolutely no harm to the owner of said work.
You see, that's how you discourage an innovator: if you let society benefit from his work to his detriment, he's likely to tell society to innovate without him and go get a nice office job.
Strongly disagree, at least in situations where the works are abandoned, largely unmonetizable and on the verge of disappearance.
I believe that the risk of discouraging innovators who would be upset at the idea of their works existing in some form, years after their relevance is a reasonable trade off in comparison to the value that the sum collection of these works could provide to the future.
Especially when you consider that every innovator working today is building off of the preserved knowledge of past generations who's works have similarly fallen into the public domain. Disney didn't have to cut a check to Shakespeare Holdings, LLC when they made The Lion King; for example.
That's not to say that I am an anti-IP absolutist in this regard. I think that the ideas of copyrights and patents aren't inherently bad. I think it makes pragmatic sense to offer a temporary monopoly on works. I just think that the balance point between serving the creator and serving society needs to be evaluated.
And this is the problem I have with tying anything to a remote server. Every digital movie, song, book, or video game that requires a remote server for patches, activation, or anything else will eventually end up like this.
What happens in 5 years when Sony turns off their PS3 servers? And what happens in 10 years when most of the hard drives in those PS3s need replacing?
Not only this, but I've had a very difficult time even finding original SWFs of animutations. Albinoblacksheep only seems to host video renders these days. While that works, many authors hid extra content in their videos, and that's now lost to time.
It's about saving cultural goods. The worst thing about the modern age is how transient and impermanent data is. In 100 years, the past 30 years will be effectively a big black hole for anybody interested in studying our culture and civilization.
There's one particular Shockwave game that I was recently able to recover from the depths of the Wayback Machine, which was a game from Disney for the Inspector Gadget movie; terrible film, but their website had this nifty little game that wasn't necessarily difficult but was addicting in that I wanted to see just how far I could go with it. For years I thought it was gone for good, and was glad to finally see it again after I lost it 15+ years ago.
Here it is in all its 1999 glory: https://web.archive.org/web/20031017000018/http://www.disney...
I always liked it in part because I don't think I've seen a similar game. It's kind of like if you took the random shapes part of Tetris and added a "jigsaw puzzle" element.