If you use only features available on the older version, for sure, you can compile your software in Win-7 and have it run in Win-2000. Without following any special procedure.

I know, I've done that.

> just (dynamically) link with the older glibc!

Except that the older glibc is unmaintained and very hard to get a hold of and use. If you solve that, yeah, it's the same.

> If you use only features available on the older version, for sure, you can compile your software in Win-7 and have it run in Win-2000. Without following any special procedure.

No, you can't. When you use 7-era toolchain (e.g. VS 2012) it sets the minimum client version in PE header to Vista, not XP much less 2k.

If you use VC++6 in 7, then yes, you can; but that's not really that different from me using a Debian Etch chroot to build.

Even within XP era this happens, since there are VS versions that target XP _SP2_ and produce binaries that are not compatible with XP _SP1_. That's the "DecodePointer" debacle I was mentioning. _Even_ if you do not use any "SP2" feature (as few as they are), the runtime (the statically linked part; not MSVCRT) is going to call DecodePointer, so even the smallest hello world will catastrophically fail in older win32 version.

Just Google around for hundreds of confused developers.

> Except that the older glibc is unmaintained and very hard to get a hold of and use.

"unmaintained" is another way of saying "frozen" or "security updates only" I guess. But ... hard to get a hold of ? You are literally running it on your the "security updates only" server that you wanted to target in the first place!