Red_Fist wrote:
So by my estimation, if an old EXE can just be stripped of it's version, win7 64 would not know it was old, the same way UT still works.
On the other side, did they write UT knowing to make it always work 20 years later ?
I really don't see why every program since DOS or win 3.1 cannot just run, 16 bit, 32 bit, the CPU still takes the EXACT same commands built on the chip, like machine code, 100% the same for x86 and less of the same commands for 16 bit.
That's not how it works at all. As Chris explained, it all goes down to the actual "dependencies" the program has, once you're in 64 bits.
UT and, consequently, UEd, do not rely on pretty much anything whatsoever from Windows itself (comparatively to many other programs and engines), nor other stuff which relies itself on Windows either, it's a whole self-contained program where almost everything it needs to run is built within the program itself, and that's mainly what made it still work nowadays in modern systems.
If you build a simple program in C++, like the basic "Hello World", this program will probably run without issues for the next 20 years or more, since you don't need any external libs and you are using standard stuff, which is always supported in one way or another.
However, the moment you depend on libs which themselves depend on other things which may change drastically over time (such as drivers or any APIs), you run the risk for it to simply stop working once the lib stops being updated and the functionality it needs from the operating system is stripped away in newer versions.
A great example of this are the renderers themselves. If you try to run the renderer the game comes with, since it depends on DirectX 6 or 7, something already completely obsolete in newer Windows versions, it will not work at all in most cases.
So you have to install a more modern renderer, such as D3D9, D3D10 or even D3D11, or OpenGL which tends to have better retro-compatibility.
And this is why you can still load the UT C++ headers in a modern Visual Studio and start to extend the engine with it, and it still works (after a few changes here and there that is, which have mostly to do with existing macros and deprecated stuff in newer compilers).
The version that you see in Windows itself, is just metadata, it's only informative to you, the user, it has no significance whatsoever when the program actually runs, and it's still optional (you can build a modern program and not define it anywhere afaik).
The only things which are able to make an old broken program to work again in a modern system, are:
1 - The compatibility mode of the program: "run as Windows 98" for example, which simply makes Windows provide to the program a Windows 98 API for example, which is generally just a wrapper to the actual modern libs in other to work.
2 - Installing manually libs (.dll files and the like) which the program needs, which might still work in a modern system, but are no longer present by omission as they're not supported any longer.
3 - Running it in a virtual machine: slower, but it generally guarantees that it will work, unless it uses stuff that a VM cannot provide yet (until a few years ago it had trouble with 3D acceleration, but that's figured out now I think).
4 - Recompiling it in a modern Visual Studio (after perhaps a few key changes here and there).
and maybe a few more, but those are all which come to mind.