Steam Survey Reports The Latest Linux Gaming Marketshare For October

[oiaohm]

No, LD_PRELOAD doesn't hook anything. LD_PRELOAD preloads a library. What a shock, right?

It is still hooking. That is what the loader is in fact up to. Job of a dynamic loader is to hook everything together.

A library can get loaded WITHOUT LD_PRELOAD before another library, and it would STILL "hook" the APIs. Because this "automatic hooking" is the insanity that is global namespace in ELF. There's no automatic hooking in DLLs so that's why they are MUCH SAFER.

ELF has versioned symbols and versioned gives filtered symbols that should be just as safe as DLL. That these features are not implemented and used a lot is another problem.

Exactly, you have to be specific about hooking and explicit. It can't happen by mistake, like with ELF. That's EXACTLY my point and why it's much safer.

Its not safer because each dllmain executed individually can be distrupted while hooking and in fact mangle everything.

Hooking need to be processed in a order. Even without LD_PRELOAD the libraries and applications files in ELF hook themselves in a predictable order.

Weasel the nightmare with AppInit_DLL is if you read careful the Appinit_DLL can only use kernel32.dll You don't have a global namespace. So now the dllmain has to go to sleep until more of the application loads. This creates a race condition.

Like it or not having a global symbol namespace to fill in with information from the start line has some serous advantages particularly if you have to hook stuff and not to race condition it.

Would I like to see the information in the global symbol namespace more used. Yes the ELF global symbol namespace records what file the symbol comes from. Would I like to see applications use versioned symbols more include filters. The more usage of filters would lead to having to add in extra information for exports. Like this export please pretend that it comes from x file for hooking. This would cure your problems. The global symbol namespace of elf is storing all the need information. The general elf import without versioned does not check what one it gets.

You really want you dll exported symbols to have all the information for hooking. So that only the dynamic loader has to perform hooking and you don't have hooking order cat fight.

ELF format has something right. Now I am not going say that lacking usage of versioned and complete implementation of versioned on ELF is right.

Windows style of hooking where it can race condition and end up applied in wrong order..... is absolutely dangerous. Yes hooking in the wrong order can happen by mistake under windows and randomally.

ELF symbol conflicts happen because you are mixing binaries with each other but when you have a error is absolutely reproducible nothing random about it. Usage of versioned with ELF would block a lot of these conflicts.

[Weasel]

It is still hooking. That is what the loader is in fact up to. Job of a dynamic loader is to hook everything together.

LD_PRELOAD is not the loader. LD_PRELOAD preloads a library. A normal library loaded would also hook in the same way. LD_PRELOAD simply loads that library before anything else, and uses THE SAME MECHANISM for hooking, so the hooking is NOT part of LD_PRELOAD.

ELF has versioned symbols and versioned gives filtered symbols that should be just as safe as DLL. That these features are not implemented and used a lot is another problem.

Yeah, you love going back in circles don't you?

Clearly we're talking about global namespace here, not versioned symbols. Global namespace -- without versioning -- should simply not exist.

Its not safer because each dllmain executed individually can be distrupted while hooking and in fact mangle everything.

And ELF has constructors that can fuck everything up. Your point?

Seriously, stop grasping for straws.

Everything else you said literally applies to ELF as well, just different naming (constructor vs DllMain).