5 ms·

This seems like it would be a lot of maintenance effort to get right, considering Windows shuffles their syscall table every release, including releases within

• gizmo686 6y ago
  If applications are calling these syscalls directly; then there needs to be some form of stability; otherwise, the applications would only work on the particular version of Windows they were compiled for.
  • frabert 6y ago
    The Win32 API (and nowadays the WinRT API as well) is that interface, system calls are explicitly unstable and internal-use-only I believe.
    • gizmo686 6y ago
      If all windows applications used the APIs like they were supposed to, then there would be no need to emulate the Windows syscalls. The point of this emulation is that some applications (games, apparently) were not using these APIs, and instead performing syscalls directly. In order for this to be feasable on Windows, there needs to be some stability in the syscalls; even if that stability involves angry MS engineers complaining that major applications are doing something that they were explicitly told not to do.
      • leeter 6y ago
        You'd be surprised, MS doesn't do this randomly. They'd rather break a game if the game is actively in production or the company is around. They only put in shims for applications if the vendor isn't still in business usually or can't get source code. But in quite a few cases they'll just put in a patch binary in the shims that just removes the anti-cheat all together from the binary when loaded. Game still runs... nobody cares.
        • saagarjha 6y ago
          Until the game checks its integrity?
          • Const-me 6y ago
            Files on disk aren’t affected, the OS applies these patches in RAM only. It’s gonna be very hard to check integrity of code in RAM. The complications include relocation table (applied when loading; see also ASLR) and global variables (modified as the software runs).
      • kazinator 6y ago
        > If all windows applications used the APIs like they were supposed to, then there would be no need to emulate the Windows syscalls. The Win32 API's require certain operating system semantics, and not all of that semantics comes nicely from Linux syscalls. A Win32 API library on Linux benefits from Windows-like syscalls underneath, even if nobody is bypassing that library to get to those syscalls. Think about it; that is exactly like saying that if programs were just written to the C API described in the POSIX spec, we wouldn't need a Unix-like kernel underneath. While that isn't an outright false statement, it has implications for the nature and quality of the system.
      • Someone 6y ago
        It need not be stable. The OS could provide each application with the system call table it expects to see (with most of them getting the standard one) Determining what table a program expects likely would be a black art, but I don’t think that would stop Microsoft from trying that for programs deemed important for the platform.
        • freeone3000 6y ago
          The target windows version is part of the standard set of defines set when compiling the program. It's visible in the manifest and the linked c library.
  • leeter 6y ago
    MS has always held that system calls are not guaranteed ABI stable. So any application doing this is subject to breakage at any time. That said I wouldn't be surprised if they are doing something not to dissimilar to this for those processes in kernel mode to emulate for things that are out of support and have no living vendor. That said if you look at the list linked above some are "stable" meaning that MS probably knows this happens and kept those specific ones stable. But the rule still applies... never do direct system calls on NT.
  • kazinator 6y ago
    That stability comes from the C interfaces of the Win32 API implemented by a DLL like kernel32.dll. I think when the article is talking about Windows system calls, it's about the interface between the kernel32.dll and the kernel, not about the Win32 API.
    • anthk 6y ago
      Wine translates those too I think.
    • poizan42 6y ago
      The syscall api is in ntdll.dll (and user32.dll for win32k.sys calls). kernel32 does not know the syscall numbers, it just calls functions in ntdll.
      • my123 6y ago
        Before, it used to be user32.dll/gdi32.dll calling directly while also having tons of logic inside. Nowadays, it's split up as it should always have been, with the path being user32.dll -> win32u.dll -> win32k.sys.
        • poizan42 6y ago
          Ah yes forgot about that. The kernel side has also been split up into win32kbase.sys and win32kfull.sys/win32kmin.sys (I think win32kmin may have only been used for the now discontinued Windows 10 Mobile), and win32k.sys just calls into those.
• deleted 6y ago
  [deleted]