Loss32: Let's Build a Win32/Linux

Post by Const-me » Wed, Dec 31, 2025, 2:47 PM UTC

Const-me wrote: post #288

afishhh wrote: post #223

Earlier quoted context omitted.

> Hundreds of other widely-used open source libraries don't. Correct me if I'm wrong but I don't think versioned symbols are a thing on Windows (i.e. they are non-portable). This is not a problem for glibc but it is very much a problem for a lot of open source libraries (which instead tend to just provide a stable C ABI if they care).

> versioned symbols are a thing on Windows There’re quite a few mechanics they use for that. The oldest one, call a special API function on startup like InitCommonControlsEx, and another API functions will DLL resolve differently or behave differently. A similar tactic, require an SDK defined magic number as a parameter to some initialization functions, different magic numbers switching symbols from the same library;…

Post by chrismorgan » Wed, Dec 31, 2025, 3:12 PM UTC

rcxdude wrote: post #412

chrismorgan wrote: post #392

Earlier quoted context omitted.

I don’t understand why this is the case, and would like to understand. If I want only functions f1 and f2 which were introduced in glibc versions v1 and v2, why do I have to build with v2 rather than v3? Shouldn’t the symbols be named something like glibc_v1_f1 and glibc_v2_f2 regardless of whether you’re compiling against glibc v2 or glibc v3? If it is instead something like “compiling against vN uses symbols glibc_…

Individual functions may have a lot of different versions. They do only update them if there is an ABI change (so you may have e.g. f1_v1, f1_v2, f2_v2, f2_v3 as synbols in v3 of glibc) but there's no easy way to say 'give me v2 of every function'. If you compile against v3 you'll get f2_v3 and f1_v2 and so it won't work on v2.

Post by draven » Wed, Dec 31, 2025, 3:49 PM UTC

dmacvicar wrote: post #398

draven wrote: post #370

Earlier quoted context omitted.

What about BeOS ?

Not very likely, what if the BeOS API emerged as "the standard" on Linux? https://cosmoe.org/ It would not solve the ABI problem, but it would give at least an opinionated end to end API that was at some point the official API of an OS. It has some praise on its design too.

Post by btdmaster » Wed, Dec 31, 2025, 4:02 PM UTC

btdmaster wrote: post #291

Y_Y wrote: post #179

Earlier quoted context omitted.

In principle you can patch your binary to accept the old local version, though I don't remember ever getting it to work right. Anyway here it is for the brave or foolhardy, here's the gist: patchelf --set-interpreter /lib/ld-linux-x86-64.so.2 "$APP" patchelf --set-rpath /lib "$APP"

Yes you can do this, thanks for mentioning I was interested and checked how you would go about it. 1. Delete the shared symbol versioning as per https://stackoverflow.com/a/73388939 (patchelf --clear-symbol-version exp mybinary) 2. Replace libc.so with a fake library that has the right version symbol with a version script e.g. version.map GLIBC_2.29 { global: *; }; With an empty fake_libc.c `gcc -shared -fPIC -Wl,--v…

Post by PTOB » Wed, Dec 31, 2025, 4:30 PM UTC

PTOB wrote: post #275

mikewarot wrote: post #57

I'm back to running Windows because of the shifting sands of Python and WxWindows that broke WikidPad, my personal wiki. The .exe from 2012 still works perfectly though, so I migrated back from Ubuntu to be able to use it without hassle. It's my strong opinion that Windows 2000 Server, SP4 was the best desktop OS ever.

> It's my strong opinion that Windows 2000 Server, SP4 was the best desktop OS ever. Meanwhile, in 2025, with 64GB RAM and solid state drives, we hear, "Windows 11 Task Manager really, really shouldn't be eating up 15% of my CPU and take multiple seconds to fire up."