upvote

points

by okanat11 hours ago |
comments
upvoteby cylemons6 hours ago|
[-]
Windows doesn't even have a concept of a loader binary right? I think its hardcoded into the kernel/win32 itself.
reply
upvoteby dwattttt5 hours ago|
parent|
[-]
Windows loader is part of the system ABI, and programs' libc(s) are loaded by it.

One of the ways Windows manages to support multiple libc's is by being careful not to mix allocators; if a system API you call allocates on your behalf, your libc can't free it, the system API will offer a function to free it.

Windows loader is certainly available to user programs though; LoadLibrary has been around longer than many developers.

reply
upvoteby account424 hours ago|
parent|
[-]
LoadLibrary will also not be able to load arbitrary libraries compiled for newer versions of Windows though. Just like with gcc, Windows also does not guarantee forwards compatibility - because that would men freezing the feature set the system libraries provide.
reply
upvoteby pg834 hours ago|
parent|
next
[-]
Windows handles this much better than any other OS. The API passes versions (== structure sizes on the calling side), and WinAPI can handle that.

As for older Windows systems not being able to load new DLLs, they can; the format hasn't changed in a very long time. I've had experience with installing some DLLs on Windows NT 3.51 and running a modern Firefox, which is about 20 years behind the times.

reply
upvoteby dwattttt3 hours ago|
parent|
prev|
[-]
Targeting an older version of Windows is "set a define so that the system headers don't expose functions that didn't exist on older Windows". You don't need an old toolchain to target old systems, you ask the newer toolchains to target it.

MS haven't made this work arbitrarily far back, I believe they deprecated targeting Windows XP in one of the more recent toolchains, but that was purely a "not worth supporting" situation.

EDIT: mixed up talking about older & newer

reply