How does Windows (mostly) maintain backwards compatibility?

Just recently, I had been looking into how Windows and operating systems in general work because I don't have any other current projects, and I figured that maybe I could learn to program my own tools, as I have come to realize how important that would be.

I think that from a low level, programs interact with the operating system by having the cpu put values in certain processor registers (with one value defining what operation needs to take place) and then perform an instruction called "syscall", that I guess is just like a special jump to wherever the code for the operating system resides or something...

What's puzzling to me though, is that at least according to this reference (http://j00ru.vexillium.org/syscalls/nt/64/) the value associated with every other operating system function appears to change with each new iteration of Windows. Windows does have a compatibility mode for programs for each operating system, but I've only ever had to use it once for a Windows 98 program.

Something notable I found out too, is that Windows 95 through ME were I guess just GUIs for DOS, while 2000 and upwards are not. I'd have thought this would have made most every program developed for ME and earlier incompatible with 2000 and later, although maybe this was the case.

That's ... really not true. Not by any reasonable stretch.

Windows 1, 2, and 3 definitely were.

But 95, 98, and ME had the properties of a "real" OS, even if it was one specifically designed for compatibility and performance rather than security. And although you could "technically" quit Windows 95/98 and get to a DOS prompt ... that really only meant that it knew how to put things back.

Oh; what had made me believe that is discovering the existence of Windows 9x vs Windows NT. I had always assumed Windows 2000 was more of a minor graphical update rather than a complete reworking. I don't really even understand what each new iteration of Windows adds beyond pure cosmetics other than less free hard drive space...

Malware, spying, and other things commonly requested by every user ever

"how does it maintain backwards compatibility", by keeping copies of every DLL version ever made. Think of how you have every version of DirectX installed if you have any older games. Now multiply that for every library.

Yeah, I've been considering going back to Windows 7 after I fully realized the extent of the problem... Supposedly, Windows 10 has slightly better performance than Windows 7, but with how much more bloated Windows 10 is, I do not understand that at all.


Do you know how Windows would know which dll file to use? Do exe files say what version of Windows they were made for?

My subjective experience is that win10 (starting with some improvements in 8) streamlined my workflow so much that any extra recourses it claims is well worth it. I don’t appreciate it launching a huge download while i’m batch processing something that already takes time as it is, but that coincidence is rare enough for me.

What’s worse is the few times it has forced a reboot from sleep mode without telling me on the previous session. The large productivity application makers (adobe etc ) have adapted, but something like NESST won’t keep a backup

Okay, time for a real answer...

You got your core system libraries:
Kernel32.dll (memory allocation, file access, loading DLLs, etc...)
User32.dll (creating windows, setting properties of windows, etc...)
GDI32.dll (drawing stuff to device contexts)
and OLE32.dll (Loading COM components via the system registry)

They all still export the same functions that they did in the early Win32 days, in addition to any new functions added since then.
By supporting all the same functions and the same ABI, then you can still run early software.

Now as for Syscalls...
Kernel32.dll imports Ntdll.dll, and Ntdll.dll contains all the SYSENTER instructions that cause OS system calls. Syscalls do change over time, but that's pretty much only relevant to the thin layer that MS put over them.
I'm not 100% sure about which DLLs actually use system calls, but it's pretty much the OS core libraries mainly.

Yeah, to clarify, on Windows (unlike, say, Linux) you're not supposed to do syscalls directly, since they're not stable from version to version of Windows.

Instead, you're supposed to link to system DLLs like kernel32.dll, and do everything by calling functions in those DLLs, which do the relevant syscalls internally. That way, if Microsoft ever has to change which syscalls need to be used, they can just have the system DLL functions use different ones, and your program will continue to work.

There's this thing called WinAPI that's been growing since it was created decades ago. For the most part all the old functions still behave as they did all that time ago. If a program calls CreateWindow it works the same way on Win3.1 as it does on Win10.

When Windows notifies Notepad++ of a shutdown, Notepad++ stashes otherwise unsaved changes to a temporary directory in the user's profile and restores them the next time Notepad++ opens. If NESST does not stash unsaved changes, this is a defect in NESST and should be reported to the maintainer of NESST.

Any real reason for that? I'd think they'd just give each new function added to Windows a value of 1 higher than the last.


What does link necessarily mean in this case?

Read this, my dude.

Thank you for sharing that, as it improved my understanding a lot. I never quite realized how much preliminary stuff is done before an exe file is "excecuted". Do you have any idea how linking functions actually looks in binary? I'm going to assume there's a big table somewhere in the exe file, separate from the machine code, that tells Windows what files need to be linked and also where to the create jumps to those functions in the code. The only exe explanations I've seen are very brief.

For FreeBSD: KBI/KPI compatibility (kernel-level) -- as well as ABI compatibility (userland/application-level; includes libc et al, as well as ld.so and ELF compatibility) -- is a huge focus. Here's a (somewhat-badly-written) wiki page on the matter, meaning it doesn't explain things thoroughly or cover all bases from beginning to end: https://wiki.freebsd.org/BinaryCompatibility

At the kernel level, there are actually kernel configuration options that control binary compatibility support for older versions; these are options COMPAT_FREEBSDxx directives as demonstrated here.

Any time there is an backwards-incompatible KBI/KPI or ABI change, there's a magic #define on FreeBSD called __FreeBSD_version that is incremented. Documenting that is mandatory as well, which is why this exists: https://www.freebsd.org/doc/en/books/po ... sions.html . Userland programs, like the kernel, can rely on this #define to change their behaviour, else expect breakage. An example I ran into with my bsdhwmon software was when the SMBus subsystem was changed and required me to do this (read the comment, then see the two functions with #ifdefs below to understand).

Sometimes breakage happens. Users usually scream, and someone either fixes it or users are told what the deal is. A common problem that still plagues the OS today are things like third-party kernel modules -- VirtualBox and VMware are two of the big ones -- that require rebuilding from source every time you rebuild the kernel/system (example). This is often a rude awakening for users, but it's reality. In userland, a common third-party utility that has the same problem as the above is lsof, because it's a userland program that actually has very deep insights into kernel structures given what all it does. As such, on FreeBSD, users tend to opt for using alternate utilities like fstat, sockstat, and procstat.

I imagine NetBSD, OpenBSD, etc. do something similar. I don't know how Linux, Solaris, or other *IX or *IX-like OSes do it (I just haven't looked).

So, in short: generally speaking, OS vendors/orgs try very hard to keep KBI/KPI and ABI compatibility when possible, and (usually) implement compatibility shims or make modifications in a way that allow for expansion without breakage, but sometimes breakage happens.

On top of a versioned COM interface, this is most commonly seen if you look at Direct X code. Where you say Can I have a DirectX8Surface object please, and go from there. This allows it to specifically set which interface it expects. To which then MS can either just keep DX8 code in the releases or make a "bridge" that will convert the DX8 interface to DX9 behind the "facade" it presents.

Windows also has a "shim" system, this is where it knows what your program is and it knows that your program needs this specific version/hack or flaw of a specfic version of some API call, and it will inject a custom bit of code to translate what the App wants and converts it to the new API while doing its best to mimic the exact weird side effect that the program was reling upon. There is a great horror story website from an ex dev that I can't remember the name of or find at the moment that tells of some of the horrible stuff MS has to do because some dev did something really janky that one time 9 years ago but it sold 9 millions copies and if it breaks everybody blames MS. For example win95 explorer has mem leaks, there are really popular file view extensions that relied upon said memory leaks so they could get data they needed to work. So MS fixed the leak, then had to go and put the leak back in. The comparability mode says " since you don't know this exe, install all the basic shims for Windows Version X on this app"

I think you're referring to http://ptgmedia.pearsoncmg.com/images/9 ... s_ch01.pdf

The old new thing that is the one, thank you. he has a blog here with more "tales" https://blogs.msdn.microsoft.com/oldnewthing/ sockets is quite the stuff up