The Folder of God
excelsiorjet.comThe poster does not give any blame to who ever came up with this:
> 1. Right-click on your desktop and select New Folder 2. Type in or copy and paste the following as the name: GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} 3. Hit Enter and the folder icon will change to GodMode 4. Enjoy easy access to all Windows 10 settings!
I know that the exception came from GetDisplayNameOf handling it incorrectly, but this whole thing begs the question:
Why is this a good way to do shortcuts?
the godmode feature is undocumented probably _because_ it's a terrible way to do shortcuts.
It's a feature for developers:
https://msdn.microsoft.com/en-us/library/cc144096(VS.85).asp...
Nice write up, I really enjoy these types of postmortems. Also, the best issues are always ones you can blame upstream for :D
Side note, does anyone have experience using Excelsior Jet to deploy natively compiled applications or services?
Was about to ask the same. Also wondering how excelsiorjet's business is going, now that Java has AOT compilation out of the box. Or hasn't it?
Excelsior guy here.
Overall, I would say that AOT suddenly becoming kosher helps our business way more than competition hurts it.
Then, "JDK9 has AOT out of the box" is a bit of exaggeration. Oracle AOT is only available for Linux/x64 ATM, yields huge binaries and may be a bit cumbersome to use: http://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html
The main difference however is that a binary produced by Oracle AOT is to a big extent just a pre-populated HotSpot cache, whereas Excelsior JET has been AOT-centric since day one. In practice that means that with Oracle AOT you have to ship both the native binary and the original class files to your customers, and with Excelsior JET you only ship the native binary, which makes reverse engineering your application more difficult.
I recall us being quite surprised when a customer survey had shown that IP protection is more important than application performance for many of our customers, even though it was just a byproduct of our optimization efforts.
Thanks, appreciate the response. I guess Oracle's AOT is only addressing slow startup times in eg. command-line/batch apps.
It doesn't. AIUI jlink creates a binary image of the VM + referenced classes. AOT is a lot easier to do with modules implemented and I'm sure it's on the roadmap, but not available yet.
> Deleting the God Mode folder fixes the problem, because that is the only filesystem object for which GetDisplayNameOf() returns a malformed structure.
I wouldn't call it "malformed" -- the OS simply returned a null pointer: "the field that is supposed to point to the buffer containing the resulting string is NULL." Which in C means "nothing there." And the Java native interface code didn't check for that (it could have returned an empty Java string in that case), but dereferenced the null pointer instead. "Fail fast" indeed.
Problem is, the God Folder dates back to Vista and it is the Windows 10 Creators Update that began setting that field to NULL. Apparently the author of that change did not foresee any backward compatibility issues.
See my other comment for the details, I believe now that the field was actually not set to null, the returned structure has a union which is documented to be able to be of different types. It's surely the type STRRET_CSTR that wasn't covered by Java, the API is then valid before and after the update, returning the structure with STRRET_CSTR and zeroes in the union is valid.
If we're talking about this [1] call, then it could be argued that it's malformed. Unless I missed it, the documentation does not specify that a NULL pointer may be returned there. Defensive programming practice says it's wise to check for NULL, but the function, as documented, would appear to be behaving incorrectly.
1: https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
Looking this more carefully, I guess the pointer to the STRRET always remains valid but whoever implemented the decoding of STRRET didn't cover all the cases of uType, and the GodMode had a different uType than others that the developers tested? In that case instead of the pointer to null the API actually returned an empty string (uType STRRET_CSTR actually then means that what would be a null pointer are actually the bytes of the string, and being zero, the string is empty, saving one allocation), but the returned structure wasn't properly understood by the caller.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
That would mean the API behaved according to the specs. See an example here, it's impossible for the call to destroy the pointer to STRRET:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
You're probably right. Looks like the article mentions it fills in the structure, not setting the pointer to NULL (which as you point out would be impossible because it's not a pointer to a pointer).
At the risk of sounding trite, this reminds me an awful lot of the "Missingno" glitches in the Red and Blue Pokemon Gameboy games.
Who the hell thought it was a good idea to let people write operating systems. Asking for trouble if you ask me.
Patience, young fhood, patience.
"Let"? Given the limited intelligence of other Earth species, I'm unsure how else operating systems would've been developed.
> "Let"? Given the limited intelligence of other Earth species, I'm unsure how else operating systems would've been developed.
I suspect that you missed fhood's joke, or else I missed yours.
(It is not unreasonable to suppose that another path to the existence of operating systems would be the, perhaps human-guided, evolution of progressively less primitive programs. I am not sure that I'd want to use the result, but it's at least a conceiveable way for history to have developed.)