News for hackers. Stuff that matters.
Re:The Windows malloc() implementation from MSVCRT is slow by leajkinUnk on Saturday July 02, 2022 @06:27PM (#31963006)
Could you elaborate why Glibc isn't any better?

I remember some funny problems with Glibc, like, 20 years ago, but it's been invisible to me (as a user) since then. You get a new Glibc, old binaries still work, it's fine.

Re:The Windows malloc() implementation from MSVCRT is slow by FreakLegion on Saturday July 02, 2022 @06:57PM (#31963255)
Just like with Windows the challenges affect developers rather than users.

> You get a new Glibc, old binaries still work, it's fine.

Indeed, but when you need to build for an older glibc it's not so simple. This is a common use case, since e.g. AWS's environments are on glibc 2.26.

Ideally you'd like to build for all targets, including older systems, from a single, modern environment (this is trivial in Windows) -- and you can do some gymnastics to make that happen[1] -- but in practice it's easier to just manage different build environments for different targets. This is partly why building Linux wheels is so convoluted for Python[2].

Hardly a world-ending problem, but my point is simply that C runtimes are a pain everywhere.

1. https://stackoverflow.com/questions/2856438/how-can-i-link-t...

2. https://github.com/pypa/manylinux

Re:The Windows malloc() implementation from MSVCRT is slow by josephcsible on Sunday July 03, 2022 @12:19AM (#31965028)
> Ideally you'd like to build for all targets, including older systems, from a single, modern environment (this is trivial in Windows)

https://github.com/sjmulder/netwake does what you're talking about, but it does a lot of gymnastics to make it work, and it also needs to use MinGW rather than MSVC for that to be the case.

Re:The Windows malloc() implementation from MSVCRT is slow by FreakLegion on Sunday July 03, 2022 @12:31AM (#31965084)
I was thinking specifically of how easy it is to build for Windows 2000 even today. Going back to 3.11 is pretty cool!
Re:The Windows malloc() implementation from MSVCRT is slow by usrn on Saturday July 02, 2022 @06:54PM (#31963228)
I'm pretty sure I've run into binaries breaking on new versions of Glibc but maybe it's because the architecture or calling convention changed. I've never really gotten the sense that GNU cares much about binary compatibility (which makes sense, they argue that sharing binaries is mostly counter productive.)