LALALALALALALALALA...

I can't hear you!



Thanks for all the info. Guess I've been away from the Amiga too long.

Quote:

Hacks? Why should those be hacks? They're documented features, to be used exactly for the purpose of patching libraries at runtime.

As for them changing... anything may change, which doesn't mean it will. As Georg pointed out, even AmigaOS' SetFunction() has changed and is now deprecated, you need to use SetMethod() or something like that now. See?

Quote:

In AOS4 SetFunction() was basically declared as evil, not to be used anymore in new code. The function is still there but it only catches 68k Code, not PPC Code. So if a program patches for example OpenWindow(), the replacement function will only be called if the call came from 68k Code, but not if it came from PPC Code.

Okay, you can patch DLLs. Thanks for the links. However, you will admit both are hacks taking advantage of certain OS features which may change. Patching Amiga libs is part of exec and fully supported across all versions.

Quote:

If I tell you that you can, it's because I know you can, so yes, you can

[SNIP]

Quote:

Sure, although I'm certain you know how to use google

On *nix, the LD_PRELOAD environment variable can be set to a list of libraries which need to be loaded before any other, for the programs that are going to be run from that point on. Loading such libraries means filling the symbols namespace with those libraries' symbols, which in turn means that if the program, or any of its libraries, need that symbol, it will be taken from the preloaded libraries rather than from the real libraries. In turn, the preloaded libraries can access the real symbols by manually opening the library whose function(s) they're meant to override.

Useful link.

Also, man ld.so in Linux gives this:



As for Windows, it's got its own official API to do this stuff: 5 seconds of googling gave me this link.
How else do you think stuff like WindowsBlind can work at all?

No, you can't patch DLLs on the fly. That is why many programs come with a specific version of a DLL which may often conflict with the "standard" version. DLLs are all or nothing.

This can be mitigated a bit if the DLL can be in the same directory as the executable. It used to be that all DLLs had to be in the system folder, which REALLY screwed up windows bad. This was called "DLL Hell."

Of course, having the DLL in the program folder means even more resources are wasted when you have several copies of the same DLL in several program directories. This is also common in Windows.

You'll have to tell me the name of the function called to replace a single procedure in a DLL (either *ix or Windows). I don't know of a single one.

Quote:

You can do that with unix-style DLL's as well, even on a per-program basis.

Probably you can do that with Windows-style DLL's as well, seeing how many "run time" system patches there are for windows, and knowing that Windows-style DLL's also have a sort of jumptable.

DLLs aren't any more powerful than Amiga libraries, and not nearly as flexible. You can patch individual Amiga library functions on the fly and other fun stuff.
:)

Quote:

That doesn't necessarily have to be the case, and often it's not. The code is usually shared among all instances of the library, only the writable data is duplicated, but only when needed (copy-on-write). Windows and OS/2 DLL's even let you decide which portion of the writable data has to be shared amongst all instances of the libraries and which one has to be duplicated.

DLL's are way more flexible and powerful than Amiga shared libraries, but they do consume a little bit more time at loading stage, as all symbols need to be resolved. Hardly an issue on nowadays computers, though.

Statically linked libraries are linked into the program by the linker at compile time. It makes the program bigger, but you don't need to have libs available somewhere on the drive at run-time.

Dynamically linked libraries are somewhat similar to Amiga libs, they are linked to the program at run-time. This means the program is smaller, but you have to have the dlls available somewhere on the drive.

Dynamically linked libraries aren't as good as Amiga libraries because each time a program is run, a new instance of the library is created, using more system resources. Any number of Amiga programs can be using an Amiga library at any one time. DLLs are slightly easier to program though because you don't have to worry about re-entrancy issues.