> 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.
Good old InstallShield. At one point it was everywhere, and then... it wasn't.
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.
Installshield as a product had... (has?) absolutely incredible incidental complexity. It's really hard to communicate the scars, if you never dealt with it, you dodged a bullet.
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.
I never messed with InstallShield but I have used NSIS (free), Wix (free), and Advanced Installer (paid). Advanced Installer is absolutely worth it in my opinion, although it still has trouble hiding the nightmare of Windows installers. NSIS syntax is a cross between PHP and assembly. Wix is literally an attempt to program a database using XML. That's three things that don't fit together well.
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.
Probably a good thing that when I built a Windows app in 2010 and needed an installer for it, I used InnoSetup. It was surprisingly easy to get something decently working out of it.
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.
But it had to solve some original problem (while maybe introducing others). Otherwise it wouldn't be used?
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 ;)
A cut down (but still very functional) version of Install Shield came bundled with Visual Studio, Delphi, C++ Builder and perhaps others (they were somewhat customized versions for each) so for many it was available out of the box.
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.
It made you a standard executable Windows installer. Inexplicably there wasn't a decent first-party Microsoft solution to this until the Microsoft Store era.
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.
My very first tasks as a new software developer were to revamp some legacy installers created with Installshield. It made me think that I chose the wrong career path. Just about everything I've worked on since then feels easy and painless compared to that.
Yes, I think it is. But, it's not great. The pseudo assembler language is not great, but it was definitely easier for me to deal with, perhaps because there were lots of other people using it and sharing info.
It's true that I don't trust the permanence of online resources, usually with good reason. But I can also be a bit of a digital hoarder. My IRC logs, for instance, go all the way back to 1999. It's funny because in meatspace I'm extremely tidy and don't keep any garbage. I have a single wardrobe with shelves of computer parts (mostly cables, wires and screws) and a few old CDs.
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.
You never know! Not the OP but I encountered a situation recently where my wife needed an old version of some software that was no longer available to download anywhere. (It pairs with an "smart" embroidery machine of hers.) Luckily I managed to find a copy of the installer in the temporary internet files directory of her old PC.
Microsoft store applications are conceptually similar to the dmg/app approach macOS has taken (and have most of the same limitations and restrictions).
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.
> Windows uses a single shared registry for persistent application settings (instead of something like a plist/config file local to the application)
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.
That's not as I understood it. It appeared in windows 3.1 (or before?).
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 technically fair, I believe the Windows 95/Win32 Registry was one of the things backported (from the "sideport") to Windows 3.1 in the strange Win32S backport, so it is very possible a developer's first experience of the Registry was Windows 3.x, late in the Windows 3.x life cycle.
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.
MSIX (formerly APPX) packages exist on Windows and have had a "double click to install" experience since Windows 10 Anniversary Edition. They've supported Win32 apps for as long as they've been called MSIX rather than APPX.
This brought me back to college and me learning about steganography. I wonder how many images are floating around with secret messages in them! Also reminds me of people who immortalized themselves by putting their initials or a favorite phrase in the header of a file format that got popular (like Mike did at Microsoft for .exe's; every exe header starts with MZ, which is really friggin cool)
Or the "Don't Steal MacOS.kext" that was used to prevent Hackintoshes from booting if it was messed with
On a tangent re: immortality: reminds me of the names you'd see in splash screens of various products. After one too many years of seeing “Seetharaman Narayanan” in the Photoshop splash screen, I just had to look him up.
I was REing my insulin pump's uploader at one point, and found that it would always send the phrase "all's well that ends well" to the server as part of the handshake
> 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.
You could purchase a DVD containing MacOS, but calling them "legit" (as far as installing on a Hackintosh) is a stretch. You're paying for the physical disc, not a license to the OS. The only way to get a license to use MacOS is to purchase a Mac.
To elaborate on this: Apple's license only permits installing Max OS X/OS X/macOS on "Apple branded" computers, so it's technically illegal to install it on Hackintoshes, no matter whether you bought the OS or not.
I worked with someone, who previously worked at a hard drive manufacturer, whose initials are coincidentally valid hexadecimal digits. He told me a story how as a low-level firmware programmer, he was in the position to immortalize his initials as the two digit (one byte) magic number that starts some sort of internal control block used by that company's hard drives. Of course, he didn't tell them it was chosen because it was his initials...
5 people have posted about this very thing over the past 14 years and this will be searchable for decades going forward, either through Google or the way back machine, or possibly through a publicly funded way back machine like alternative.
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.
I certainly don’t expect my FB posts to live forever except on some surveillance server. But tweets? They’re almost all public. They’ve been and are being crawled just like the old web. I’m pretty confident I have a higher likelihood of finding my tweets in some distant future than anything I’ve self-published on the web.
From an historian POV, those closed-data communication platforms are going to end up as a black hole.
So much of our life has happened through them, and yet will be invisible to historian. It's really a problem.
Back when I was in high school and programming on the original IBM PCs I wrote a program that would graph "solids of rotation" (a function rotated around the X axis). Well I chose the obvious name based on the 8.3 filename limitations. One day someone looked over my shoulder and said "you named your program solid rot???"
Oops.
It gets worse. A very long time ago a was working for a startup that was doing real-time speech compression, for telephony applications, using a DSP, with the compression/decompression implemented in assembly language. The code had two processes, an analysis process and a synthesis process. My colleague named the entry point to the synthesis process synth_entry, and he named the entry point to the analysis process anal_entry. Either he honestly didn't realize, as he claimed, or he was better at keeping a straight face than anyone I ever met.
I think programmers get used to the idea that some names for things are never meant to be spoken and don't ever say them in their head to see what they'd sound like.
I was whiteboarding with a fellow (girl) student in college. We were sketching out a client/server architecture, and I abbreviated server as "srvr". When it came to the client, I thought I should also make it four letters, so I wrote "clit". I stood back and looked at it. After a couple seconds pause, it dawned on my brain that was probably a terrible shortening. I wordlessly erased my gaffe, and just wrote out the whole word.
So yeah, I can believe it happens by mistake at times.
I once forgot that calling a solution "quick and dirty" is a raunchy double entendre until the lady I was demoing something to said "kinky". But your example is far more embarrassing.
In a functional analysis class ("analisi funzionale" in Italian, shortened "anal fun") our professor suggested us to complete an exercise using one of the most relevant theorems in the field: the dominated convergence theorem ("convergenza dominata" in Italian, shortened "con dom").
Whats sort of funny about that to my mind is, the original authors were very likely innocent / oblivious in terms of alternative meanings and it's the (quote unquote) dirty minds of the PR/MR fix authors which make them a problem.
"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.
I wouldn’t be surprised if I have a few “anal”s lying around in veritable names I’ve written over the years.
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.
I wrote a utility to analyze processes for a database system that liked to capitalize and abbreviate everything. To keep my naming conventions in the spirit of things, and because I was feeling a little spicy that day, I named the table that the utility wrote the analysis results into "PROC.ANAL"
The people who made Docker didn't account for the full range of British double entendres when it came to naming images. I can't remember what the second word was, but I'm pretty sure the first was something along the lines of "excited" and it appeared in a tech brown bag session when I was presenting.
In my head it was just part of solid and rotation which was exactly that the code did and all I ever thought of, but once the other person pointed it out it was like "oh, right".
I was adding juice to a cockpit simulator game, a whole bunch of lerping and dampening of the position/rotation to react to user input. Didn't realise that I had abbreviated cockpitRotation -> cockRot until I submitted the pull request.
Smells to me like the sort of comment I'd put in ahead of a bit of defensive coding. e.g. I originally made an assumption, but now I realise my mutex enumeration code will fail if somebody actually calls their mutex this one specific thing. So now I have to put in an additional test to guard against that.
Code comments are ignored by the compiler. I suspect it's not a comment but the name of the mutex itself.
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.
I just checked, and this method is still syntactically valid (though not recommended style) in...
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.
For Rust the Clippy linter will warn that such a line has "No effect" by default but the compiler itself won't warn you that the literal was unused. I was surprised by that too. This is also true for other literals, such as an integer.
They are recommended for docstrings, but not for comments in general. The compiler has a special case if the first statement of a function/class/module is a string (doesn’t have to be multiline), and it puts that string in the __doc__ attribute of that function/class/module — those are docstrings, and they need to be something visible to the compiler.
A comment existing in various binaries for the past 20 years is not the same as transient comments in source code that are removed prior to translation into a binary.
wild guess: there was some sort of registration or copy protection that generated a unique machine id or cryptographic key by applying some simple transformations to the mac address. it was trivially defeated because it was easy to find where this was calculated because of the naming of a mutex that enclosed it. after defeat and remediation, this was added as a grumble.
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.
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 :)
Why not use a randomly generated (once and then fixed) string with 128 bits of entropy if you want to avoid accidental name collisions but need a well-known name?
maybe they reverse engineer or whitehat/grayhat/whateverhat for a living? hacking, ethical or otherwise, could explain looking through binaries with hex readers.
Can anyone comment on the mindset of someone who creates a Blogspot for a single article? Is it anything beyond "I want to post this anonymously and have it hosted for free indefinitely"? It feels like an odd solution, but I also can't think of a better one.
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.
The best part of this is that it is concrete evidence of Google Search result quality decay. The screenshot of the search in the article shows a result from a Blogspot blog called "Frankie's Joint".
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.
Has anyone attempted to create a "search engine benchmark" of, say, oddly specific phrases that almost certainly need to return a certain set of pages as the top result? This could quantify the loss in quality we keep talking about.
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).
Google gave up on search though right? Like, I assume they’ve just abandoned it, maybe as recently as 2 or 3 years ago. Can anyone prove that they haven’t?
I'm curious if they explicitly excluded their blog from Google search results, they don't seem to have the highest opinion of Google from various posts.
Mutex is a synchronization primitive implementing mutual exclusion. When created with a name, they can be used to synchronize processes across the whole OS.
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.
wondering the same, maybe simple word play on ethernet.. who knows what floats about in the brain of a developer! naming vars is hard dangerous work in my experience!
If a funny story goes 'whoosh' over my head I would might, if I was bothered, say something like "I'm probably just being dense, but I don't get that".
We don't have to let them steal a word from the English language, that belongs to all of us. We don't have to let them cause confusion. Just don't call it the name they want you to call it.
Agree. Though, in my outsider perception Alphabet == Google + a bunch of failed stuff + self driving cars.
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.
afaik, Youtube, Android, and many other bits are still technically under Google organizationally. It's mostly the outside investments that ended up under Alphabet (hence the structure).
Whether it's OK for a company to co-opt an English word for its name depends on how much confusion and inelegance it causes. I didn't have a problem with their original name.
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.
> 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.