Greg Parker

Top three replies to the PS thread:

> . . . It's a miserable language, full of unexpected behaviors and badly designed features. . .

> I haven't met a single person who likes PowerShell. It's perhaps the textbook example of ugly design that looks technically consistent but utterly unfriendly and mind bogglingly verbose. . .

> PowerShell is one of the few bits of software which has actually made me throw a computer in anger. The idea has potential but the implementation is just bad. . .

No one is really looking into his IC but the thread is not positive. I have no idea who contributed what, but I’m not sure anyone would want to claim part of the credit for powershell.

——

Here’s a thread for man behind AMD’s zen architecture: https://news.ycombinator.com/item?id=14989551

First comment:

> Zen is the work of a huge team of talented engineers. To single one out as "the man behind Zen" seems very wrong. . .

——

The man behind objective-c: https://news.ycombinator.com/item?id=8422695

Second comment:

> The man behind Objective-C these days (and for the past decade plus) is this guy: http://www.sealiesoftware.com/blog/

——

For the other threads I saw, some were actually individual efforts, others were just ignoring “the man behind” and talking about the tech. Changing my search to “woman behind”, I saw no comments disparaging the level of contribution.

EDIT: I’m also by no means justifying the vitriol in the black hole thread or the harassment. Just doing some legwork.

I'm very familiar with CFG flattening and other obfuscation techniques, thanks.

That's interesting; I suppose I must not have touched the parts of the platform that use them, and I've touched a fair amount of the platform.

Again, I _have_ seen plenty of obfuscation techniques in DRM/FairPlay, but otherwise I have not, and again, I am entirely sure the ANE toolchain from CoreML down through Espresso and into AppleNeuralEngine.framework definitely does not employ anything I would call an obfuscation technique.

> Ever wonder why Apple stopped shipping system frameworks as individual .dylib files?

If the dyld cache was supposed to be an obfuscation tool, shipping the tools for it as open source was certainly... a choice. Also, the reason early tools couldn't preserve selector information was selector uniqueing, which was an obvious and dramatic performance improvement and explained fairly openly, for example - http://www.sealiesoftware.com/blog/archive/2009/09/01/objc_explain_Selector_uniquing_in_the_dyld_shared_cache.html . If it was intended to be an obfuscation tool, again it was sort of a baffling one, and I just don't think this is true - everything about the dyld cache looks like a performance optimization and nothing about it looks like an obfuscator.

Dyld (dynamic linker) does this I think, it's effectively similar to other relocations. Each dynamic library brings its own set of selectors (I just think of them as strings in the data section of the binary, referenced indirectly via a pointer in the objc_selrefs section of the binary which can be updated as needed) and at runtime they're uniqueified.

See https://www.sealiesoftware.com/blog/archive/2009/09/01/objc_explain_Selector_uniquing_in_the_dyld_shared_cache.html and https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_selectors_are_hashes.html

I actually can't find much authoritative discussion about this on the internet, just those two posts. But since the objc-runtime is open source, you can probably find it there. I think it might be this method?

https://github.com/opensource-apple/objc4/blob/cd5e62a5597ea7a31dccef089317abb3a661c154/runtime/objc-runtime-old.mm#L1441-L1468

--

But I'm not sure what GP meant by "at compilation". I suppose the compiler could be smart by reading the selectors of any shared libraries you link against and avoid duplicates in _your_ binary, but that wouldn't work for two shared libraries that know nothing about each other nor anything mapped in via dlopen.

It's not that easy. I mean, just sending a message could entail one of objc_msgSend, obj_msgSend_stret or objc_msgSend_fpret, and which one you want to use is not always as clear-cut as you might prefer (http://www.sealiesoftware.com/blog/archive/2008/10/30/objc_explain_objc_msgSend_stret.html). And then there's the hassle of defining classes dynamically, which entails six function calls just to create a class with one empty method, and one of those essential functions is not actually provided for you AFAIK unless you're using Apple's compiler where it's a builtin, so you'll need to write it yourself.

It's not ridiculously hard, but it's somewhat less easy than normal C FFI.

There's some good info on that here:

"Dissecting objc_msgSend on ARM64"
https://www.mikeash.com/pyblog/friday-qa-2017-06-30-dissecting-objc_msgsend-on-arm64.html

"Let's Build objc_msgSend"
https://www.mikeash.com/pyblog/friday-qa-2012-11-16-lets-build-objc_msgsend.html

There's also the "Illustrated history of objc_msgSend", although it appears a bit dated, it has some nice commentary on the evolution of this very performance-critical part of the objective-c runtime:
http://sealiesoftware.com/msg/index.html

There's a github repo trying to rewrite it for the web: https://github.com/jackinloadup/lunatic-fringe

There's also this, which I vaguely remember working for me years ago, but can't vouch for now: http://www.sealiesoftware.com/fringe/

I have incredibly fond memories of playing Lunatic Fringe, despite being very bad at it, and despite catching a ridiculously bad case of strep throat one year shortly after discovering it, and having some bad, vaguely-related fever dreams about.