3 ms·
It's partly a Linux-specific problem. Windows programs are fine with having multiple copies of MSVCRT loaded into the same process. It's often unavoidable; any
by Arnavion 5y ago
It's partly a Linux-specific problem. Windows programs are fine with having multiple copies of MSVCRT loaded into the same process. It's often unavoidable; any process that loads plugin libraries will have its own CRT plus other CRTs pulled in by the plugins in its address space.
Just open up some process in procexp and see how many msvcrt##.dll you find loaded.
It means every library has to be careful about providing both malloc and free calls in their API. Eg if a library has a `Foo *create_foo(void)` it has to provide a `void delete_foo(Foo*)`, instead of expecting the user to call `free(the_foo)` because that `free` might be from the wrong CRT. With Linux libraries I often find that you have a `create_foo` but no `delete_foo`, and you're expected to just `free` it.
I assume Linux libraries never took this much care historically because software was generally open-source, so everyone was getting their software from distro repos that rebuilt the world to link to a single libc.
- yjftsjthsd-h 5y agoYou should know that HN lets you prefix stars with a backslash to escape them, so your text ends up saying, ex. foo*bar and bar*baz rather than foobar and barbaz
- Arnavion 5y agoI know. I fixed it shortly after I posted the comment.
- jcranmer 5y agoglibc serves multiple purposes, and these purposes are broken up into separate libraries on Windows. One of those purposes is to act as the C standard library, which is what is provided by msvcrt.dll. But another purpose is to act as the library of system services, which is provided by kernel32.dll instead. The actual functionality that glibc broke in this specific ABI break is really the sort of functionality that is provided by kernel32.dll (i.e.., that's where the SEH functions live) on Windows. And you can't provide multiple copies of kernel32.dll on Windows, just like you can't have multiple copies of glibc.
- Arnavion 5y agosetjmp, longjmp, jmp_buf are defined in the CRT, not in kernel32. Of course their implementations will eventually depend on kernel32, but that's not relevant to the callers of setjmp/longjmp.
- jcranmer 5y agoIf glibc were set up to have a kernel32/CRT divide like Windows does, I suspect the ABI breakage would have impacted the kernel32 side of the divide, given that the rationale was for better support of hardware stuff in s390. Of course, in Windows, setjmp/longjmp/jmp_buf being the C way of doing things, the implementations live in CRT-land, but the underlying implementation (being essentially SEH/unwind) actually lives in kernel32.
- Arnavion 5y agoSure? My point is, even if it impacted the CRT side of the divide, it would likely have not been a problem, because it would be a new version of the CRT with the breaking API and would not have affected existing code linking to the old CRT. And because libraries are generally more hygienic about not leaking CRT details across their own API boundaries, it would not have been a problem for old and new CRTs to be mixed in the same process.