4 ms·
Isn't this the model that has been encouraged on Windows forever with COM, WinRT and .NET etc? When you consume an API in one of those environments you don't ha
by nly 6y ago
Isn't this the model that has been encouraged on Windows forever with COM, WinRT and .NET etc? When you consume an API in one of those environments you don't have to worry about the location of the physical assets (library files).
I don't see the big deal as long as app local copies of e.g. curl can still be used
- Hello71 6y agoSounds like it to me. Similar to Windows WinSxS directory, or system32 redirection, or Program Files (x86).
- jjoonathan 6y agoNow we need a /System/Library/WOWARM to contain old x64 libraries and /System/Library/AMD64 to contain arm libraries and it will be perfect!
- djxfade 6y agoI know that you are ironic here, but for the uninformed, macOS supports "fat" binaries, where the machine code for multiple archetictures can be embedded in the same bundle
- brian_herman__ 6y agocan we get a binary with 68k, powerpc, x86, and arm and call the binary .fatso
- saagarjha 6y agoSadly by tradition standalone dynamic libraries on macOS end in "lib", as in "dylib" or "jnilib", unless there is a good reason to not do so (pam, for example).
- jjoonathan 6y agoYep, and for the sake of making sure everyone can appreciate the joke I suppose I should explain the other half. During the 32 -> 64 bit transition, Windows took the opposite approach: instead of packing both architectures into a single "fat" library file, they would separate them into different folders. 64 bit libraries would be "native" and go into the usual system library folder and legacy 32 bit versions would go into a new "Windows on Windows" emulation folder. Good so far. The problem is that the usual system library folder was /Windows/System32 which alludes to 32-bit-ness but will now hold 64 bit libraries. That's a bit facepalm, but sacrifices had to be made for compatibility, or something (I would assume). For the emulation folder they chose /Windows/SysWOW64 because "Windows on Windows" ran on 64 bit and emulated 32 bit. Fair enough, I suppose, but now a folder with a name alluding to 64-bit-ness will contain 32 bit libraries, so we have a double facepalm: C:\Windows\System32 is where the 64 bit libraries live C:\Windows\SysWOW64 is where the 32 bit libraries live This is silly enough that it deserves a good-natured elbow-jab every now and then.
- muststopmyths 6y agoTo be the "well, actually" guy, "Windows on Windows" was the name for 16-bit windows on win32. Because "Windows" meant Windows 3.1 in those days. But "Windows on Win64" is WOW64, i.e., Win32 on Win64. Because by then "Windows" meant Win32. so "SysWow64" is the "System directory for WOW64". I've been on Windows too long because it all seems perfectly logical to me.
- gruez 6y agoHow does it work on mac? Do you have to specify the full path of the library to load it?
- deleted 6y ago[deleted]
- ratww 6y agoIn practice it's transparent, like using a static library. The linker handles it all for you during compilation: it stores the paths at a special section in your executable, and a injects a dynamic linker in your code. The paths can be either absolute (for system libs) or relative (useful for distributing Bundled apps). The cool thing is that you can see those hardcoded paths using otool -L and you can modify them using install_name_tool. Useful for debugging misbehaving closed-source tools.
- saagarjha 6y agodyld, the dynamic linker on macOS, handles it for you. You tell it what you need it will handle mapping in the correct pages for you from the big file; both statically (based on your binary's load commands) and dynamically (using dlopen, etc.) The process is essentially transparent unless you look really carefully at what it's doing under the hood.
- badsectoracula 6y agoFWIW it is also how you can use Win32 APIs introduced in recent versions of Windows when you want to also support older versions - call LoadLibrary with a system DLL name (no path) and use GetProcAddress to check if the call you want to perform is supported. AFAIK it is very rare for Windows applications to hardcode any DLL path.
- tonyarkles 6y agoOn the flip side of that, Win32 also includes the local directory near the start of the LoadLibrary search path. The result being that a lot of applications bundle all of their own dependencies when there are already 15 copies installed on the system. In some cases I’m good with that, in others it’s a pretty big waste of space compared to having a system with an easily configurable versioned shared library repository.
- ascagnel_ 6y agoOne side effect of this is users can use patched DLLs for compatibility or to add new features (this is how tools like ReShade work).
- tannhaeuser 6y agoHmm I think shared lib loading on Mac OS isn't supposed to work like that. DYLD_LIBRARY_PATH is only a method of last resort; normally, an app should have any lib path baked in (where the baked in path can be relative, and can also contain variables as path steps). At link-time, the linker picks up the install name of any shared libs needed, and bakes these into the executable. I find this to be a saner model than on Linux where an executable can't have an RPATH (only a shared lib can). Actually, it seems the whole concept of shared libraries might be more trouble than worth, especially on F/OSS operating systems; on Linux, there's a whole cottage industry based on the problem of shared libs not being uniform across versions and distros (ie Docker).
- badsectoracula 6y agoApplications on Linux also do that often when they are released in binary form (especially closed source software) outside of some repository, they just use a shell script to add the current directory (or a subdirectory) to the library search path before starting the executable.
- makomk 6y agoMaybe for new libraries, but I know that enough older Windows apps rely on expecting existing system libraries to exist as actual files that Wine has to create fake DLL files in order to keep them all happy.