What are the odds that some idiot will name his mutex ether-rot-mutex (2017)
etherrotmutex.blogspot.com
etherrotmutex.blogspot.com
> This is a comment made in a software called InstallShield, version X at last, a software intent to create installers, so it probably will appear in many other products.
> Found in a InstallShield sample that I was reversing to check if it's a malware. The line made me chuckle, and it's so heartwarming to see someone actually made a blog on it and the fact the line has been around since 2003. Relics like these make me so nostalgic for the 00's Internet days. To anyone reading this, fist bump from a fellow Int3rW3bz lurker.
I keep all the bundled installers I've ever had in a folder. Currently there are files there from 2009 onwards (older ones are archived somewhere). I didn't bother looking for the older ones, but running grep -a ether-rot-mutex quickly yielded a match containing the entire snippet! The culprit is the installer for Ulead (now Corel) PhotoImpact 12 and it has been there since 2010.
Under the next -> next -> finish you saw, was basically a fountain of tears. That software directly relished and consumed the salty tears of engineers. It demanded them as sacrifice, to make the installs keep happening.
You would think that a product which did nothing but facilitate that workflow would hide, or somehow ease your pain but somehow it made it so that it never worked by default and it was your problem as "installer engineer" (aka short-straw-haver) to fix it.
Part of the problem is that most Windows installers are based off MSIs, and MSIs were made for MS Office by some engineers who thought relational databases were cool, so they made everything in MSI be a relational table.
But yes, I remember that a lot of installers were InstallShield, and the thought that it might be a mess on the inside has never once crossed my mind.
From user's POV, I've always preferred IS installers than Wise, but I haven't created any packages even once. I was always just the "next-next-finish"-type of user ;)
And the included version had a wizard to quickly create an installation project so unless you wanted something advanced, making an installer was a matter of selecting your program's files, the name of any Start menu shortcuts (and perhaps a couple of other things i forget) and then building the installer. For a ton of people it was more than enough.
I think at the time its main "drawback" was that it made installer downloads from the internet a bit awkward since it generated tons of files, but many archiving tools (WinZip, WinRAR, etc) added options for making self-extracting archives that can launch applications, so the combo of a WinZip self-extracting archive that launches an InstallShield setup.exe was very common for a very long time.
But basically the reason it was used a lot was that it was easily available to the users of the most popular development tools at the time.
There wasn't really effective competition, probably because it's hard to get people to pay for developer tools and it's a hard problem to do well.
What's the idea? Just in case you ever need the installer again and it's no longer hosted online?
I have nothing from before April 26, 1999, the date when the Chernobyl virus destroyed my hard drive and wiped out all of kid me's QBasic programs (what a loss for humankind). Kid me could not afford the storage space for backups, nor did he have the discipline anyway.
A few design decisions from the early Windows days tend to keep installers around on windows, though.
Windows uses a single shared registry for persistent application settings (instead of something like a plist/config file local to the application) which has some clear upsides because settings are centralized and can be deployed fairly easily by admins and applications can read settings for other applications and change behavior accordingly - But... it also means applications need a step to configure those settings at install time.
Additionally - Windows is a MUCH more diverse ecosystem than macOS in terms of hardware (and the associated software). Installers give applications a chance to ensure all required dependencies are correctly in place.
Finally - There's a lot of work and tooling for enterprise customers in Microsoft's MSI toolchain. Not the least of which - they can allow enterprise customers to verify the exact state changes on the end machine that will occur as a result of installation, and to do updates as patches rather than complete replacements, making them much faster and less network intensive (matters when you're deploying a patch to something like say Visual Studio, which is 40+GB on disk on the small end).
Basically - Installation is a lot more complicated with a wide variety of business use-cases, much less hardware control, and a strong legacy of supporting old software.
The NT Registry was intended for Kernel settings only. Persisting application settings to it was a bug that didn't get squashed early enough, in part because Windows 95 copied the idea without understanding the design/architecture/reasoning behind it. It is a bug that will live on "forever" for backwards compatibility.
There, it listed what COM components were available and how to start them. These components were meant to be available for all applications, so e.g. embedding 1 component like a spreadsheet in any other OLE application like avword processor could work, even for applications never meant to be connected together.
So it was at first meant as some meeting center, where anyone could drop anything for anyone else.
Meanwhile, the .ini files became a bit long in the tooth, so NT and 95 both adopted it as a config store.
When you use a meeting center for personal config, it makes sense that other passerby's would notice and start to mess with your config. This was both a blessing and a curse: It allowed all kinds of deep integration, but also injects all kinds of other peoples bugs in your code.
OLE 1.0 in the Windows 3.x era (which was a predecessor to COM, but not yet COM, and an evolutionary baby step between DDE [passing data through Windows messages] and COM) did not use "the" Registry but more complex DLL VTABLEs and INI files.
Meanwhile the NT Registry was built for the NT Kernel settings store, and primarily just the NT Kernel.
But COM did think to use the Registry as a central store of COM component registration. In part because the Kernel may need to call COM components sometimes. Largely because COM relied on it, the NT Registry was then backported (sideported?) to Windows 95.
So yes, I agree with you that my understanding is that COM is largely to blame for the inflation of the NT Registry from "just a Kernel data store" to something larger.
But my understanding is that while COM still needed a central registry, the Registry was never intended to replace INI files. That was a combination of accidents/mistakes by general developers at the time:
1. The Windows 1.x to 3.x INI reading/writing functions developed for a single user operating system had an unfortunate default to reading/writing files out of the current working directory which in Windows 3.x was still often C:\WINDOWS (but sometimes the application's install directory)
2. Windows 95 (correctly) added permissions restrictions to C:\Windows and C:\Program Files and asked developers to start using User folders instead (such as %LocalAppData% and %Documents%)
3. The INI APIs stopped working by default because they still defaulted to C:\WINDOWS or application folders for backward compatibility with Win16 apps.
4. Developers misunderstood this to mean that INI files were dead (because of those bad defaults causing the APIs to "glitch"/not work as expected/not work at all in Win32 apps)
5. Developers saw COM registrations going to the Registry and thought that was the replacement for INI files (in part because OLE 1.0 had used INI files in that registration way)
6. Because the Windows 95 Registry was already a weird port/fork of the NT Registry there weren't enough eyeballs on it from the NT Kernel team to try to push the brakes hard enough against the accidents/mistakes above
Certainly the cat is more than out of the bag this many decades later. But the moral of the story is that the Registry as used for application configuration (as opposed to mostly Kernel configuration) is an unhappy accident. Unhappy for the NT Kernel team that tried to optimize the Registry for Kernel operations only to see it flooded by application developers. Unhappy for application developers because it made install/uninstall more complex, baroque, and ugly than it ever needed to be in Windows 95+. Unhappy for users in how messy the Registry can get (when not sandboxed) and how easy to accidentally corrupt it can be when trying to "clean" it.
To be fair to third party developers, and to make it clear I don't assign them much blame for "missing the memo that the Registry was not for application data", the mistakes were clearly coming "from inside the house": never forget that the first Win32 developers were dogfooding teams at Microsoft. If even the Office teams never got the memo, there's no expectation that third party developers could have psychically intuited that the memo even existed.
Also to be fair to disclosure I'm sure that most of my understanding of all this is badly paraphrased Raymond Chen.
- The whole dmg file where you have to drag the app to your applications folder is quite confusing compared to the app store experience.
- Ever try to uninstall a Mac app? Merely deleting the .app file still leaves behind everything else. The everything else can be very large files in your ~/Library folder. It's not always straightforward where those files are, and how to find them. (Think of a virtual disk drive product like Google Drive, Dropbox, Onedrive, ect, where the backing storage is usually hidden.)
- Some products legitimately need to install things, like Finder extensions or drivers.
Here is a not so savory story on how winget came to be: https://keivan.io/the-day-appget-died/
Or the "Don't Steal MacOS.kext" that was used to prevent Hackintoshes from booting if it was messed with
https://www.ironicsans.com/2006/09/interview_seetharaman_nar...
> The extension contains a kernel function called page_transform() that performs AES decryption of "apple-protected" programs. A system lacking a proper key will not be able to run the Apple-restricted binaries, which include Dock, Finder, loginwindow, SystemUIServer, mds, ATSServer, backupd, fontd, translate, or translated.
Even if they stop selling it on the App Store, you can still buy a fully licensed copy of OSX buy picking up an older Mac Mini.
> The "on fire" message remains in the Linux source code as of version 5.14-rc6
Tangent: I actually experienced this message multiple times over the aforementioned timeframe.
Meanwhile the odds that your tweet or FB post will be searchable and archivable anywhere close to that is extremely low.
The open Internet is so much better. I hope we start moving back towards it.
So yeah, I can believe it happens by mistake at times.
TIA.
Xra Gubzcfba jnf bapr nfxrq jung ur jbhyq qb qvssreragyl vs ur jrer erqrfvtavat gur HAVK flfgrz. Uvf ercyl: "V'q fcryy perng jvgu na r."
Found here: https://en.wikiquote.org/wiki/Ken_Thompson
"I object to my own urban dictionary / reddit-based post-hoc interpretation of this abbrevation. It's offensive.".
Which is fine. We can fix all the things, and yes it's short term pain but not a big deal. What was said isn't the same as what is heard.
Where there are historically unfortunate names, we can deal with them just like all the other changes we make as a matter of course.
That's magical.
We have a lot of “analysis” in our application and I bet I have shortened them a few times, and in my head I would have pronounced it as uh-naa-l not realizing what it also looked like.
Personally, I'd so something like (Name of company / Product)-(Guid). This way it's unlikely there will be a collision, and if there is, someone's going to have to answer some interesting questions.
In some languages, rather than comments being a special syntactic thing, you just write a string-literal expression as its own statement.
Before dead code elimination was a thing, I imagine these string-literals would end up in the binary.
C
Javascript (Node)
Python
Perl
Ruby
Rust
The strings did end up in my Python 2.7 .pyc bytecode, though not in my C or Rust binaries.
My intuition was that this would work in most of these languages, but not all. For example, I thought Rust would probably complain about a value being unused.
There's no such thing in general as an expression as a complete command in shell scripting, but there is a silly way to write comments as
: comment
instead of the normal
# comment
where : is a shell builtin equivalent of the "true" program, and anything otherwise syntactically valid on the line after it will be treated as command-line arguments to that builtin.
I think you meant "in the source code sense" not "in the true sense."
It could very well be a comment in installware.
for background: it wasn't uncommon in the old dark days of proprietary windows software to have an installer generate a machine id that would then be used to compute a machine specific install or registration key.
i don't want to use the word sign, because that was probably more advanced than what actually went on, but the registration key was often a function of the machine id.
solidity programs can be hosted on? run on? ethereum. people can and do implement mutexes in solidity. (e.g.: https://medium.com/coinmonks/protect-your-solidity-smart-con...)
what would happen if somebody, in their solidity-based smart contract, called a mutex "ether-rot-mutex". ether is one shortening of ethereum so it's not hard to guess. neither is mutex. rot is frequently short for rotation. also German for red.
if it's easy enough to get scope wrong or cause leaky namespaces in solidity (disclaimer: i do not know enough about solidity to guess at this) then could somebody calling a mutex "ether-rot-mutex" little-bobby-tables themselves into exploiting your smart contract?
i don't know. i don't even know what i don't know in this particular field. i'm just letting my apophenia out to play :)
Now, comments don’t end up inside compiled files right? This has to be a string, not a comment??
What am I missing?
The author found "ether-rot-mutex" amusing enough to start the blog and name it after the thing. They anticipated more posts in the future, but they didn't happen.
If you do today the exact same search that the OP does on his screenshot, that result does not show up. ALL the results I get are either a reference to this Hacker News post, or computer generated pages. A short 2 pages worth of useless computer generated content, including binary analysis pages and alternative frontends to the HN post.
The original article on Frankie's Joint still exists, here it is: https://frankiesjoint.blogspot.com/2014/08/nein-doktor-nein....
If the full list were public then the results could of course be gamed, but if only a sample were public and the full set were private then it would probably provide a useful metric (and would be able to measure attempted gaming by the score on the public and private datasets).
For instance, a named mutex is a good way to ensure the program can only be running in a single instance. Specifically, the program creates a named mutex on startup, and locks it forever. If failed to lock, it shows a message saying "another instance is already running" and quit. When the program quits normally, the OS will automatically unlock the mutex, allowing the program to run once again.
Now, imagine that by coincidence, 2 unrelated programs have implemented that approach using the same name for the mutex. This gonna break both of them with weird bugs. Launch program A, then launch program B, and it won't run complaining "another instance is already running" despite that's not true.
For this reason, mutex names are better be very unique.
A typical solution is generating a GUID and using it for the name of the mutex.
But the developer of that particular program instead used the string "What are the odds that some idiot will name his mutex ether-rot-mutex!" They're not wrong in the sense the odds are miniscule, however GUIDs are unique too and much shorter, only 36 characters.
How good is "the man tried to think of a name no one ever thought of before?"
Rot might have referred to decay or a rotation cipher, like ROT13. https://en.m.wikipedia.org/wiki/ROT13
I think here they are essentially random like “I hope no one else uses Correct Battery Horse Staple for their globally unique ID”.
How can the ether rot? Is it not eternal?
Whereas Meta == Facebook + an absurd $$$$$ attempt to convince the public wearing headsets is revolutionary + forget about that whole destroying society thing.
At least the self driving cars might have positive net impact.
;-)
And YouTube
That said, "facebook" was not in my vocabulary as a native American English speaker, and I'd wager that was true for over 99% of Americans. My impression is that it's something that only existed at Ivy League schools. Perhaps regular colleges also had them? Maybe someone could fill me in on that.