[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [hackers] Which Visual Studio versions are in active use?



Dave Hart wrote:
On Thu, Mar 16, 2023 at 7:14 AM Martin Burnicki <burnicki@xxxxxxx> wrote:
Dave Hart wrote:
On 3/14/2023 5:20 AM, Martin Burnicki wrote:
Dave Hart wrote:
Another reason I've looked at
redoing that work is that it appears VS 2017 is the last version to
support targetting Windows XP, and I presume you'd like to keep the
Meinberg NTP for Windows release working on Windows XP as long as
possible.

This is another restriction from MS. What does "targetting" really mean?

Relying on API calls that may only be available on newer Windows
versions, or simply a policy from Microsoft who try to keep users from
using older windows versions?

To me it looks more like a MS policy.

Apparently I misspelled targeting.  I'm not sure what the technical
reason for dropping XP support in newer compiler toolchains is, but I
suspect there were multiple reasons having to do with things like
assuming a higher baseline of processor features like SSE2.  It's hard
to complain about Microsoft's backwards compatibility for dropping
support for building binaries for Windows XP as of VS 2019 about a
dozen years after the release of Windows Vista, particularly given
even with VS 2022 IDE you can still build XP-compatible binaries by
installing optional older toolchains.

But why do I need one specific toolchain for each Windows version, and even different compilers for user space and kernel space, instead of having a single compiler where I can specify the minimum supported CPU, like i386, i586, or i686?

The binaries of the driver package
for Meinberg PCI cards that I'm maintaining runs fine on all Windows
versions from Windows NT up to Windows 11. The only distinction I have
to make is whether the target system is 32 or 64 bit, and whether the
kernel supports PnP (W2k and above) or not. The latter only makes a
difference *how* to detect a PCI card. Once a card has been detected,
you can use the same API calls to access it.

The only big limitation is from Microsoft, who require that kernel
drivers for Windows 10 and newer be signed by Microsoft, refuses to sign
drivers for Windows versions before Windows 10, and even make it
impossible to to sign a kernel driver with your own certificate, which
was sufficient for older Windows versions but can't be done anymore
because MS prevents it.

Does this mean you have to have one process for drivers for Win10 and
later, and a different process for older drivers, or that you can
simply no longer update drivers for pre-Win10 systems?

This is off-topic for this mailing list, but just to highlight the problems caused by Microsoft:

From the point of view of the driver code, the only difference is that on a non-PnP system (Windows NT) the driver has to be installed and started like a service, and on startup it scans the PCI bus for supported devices, while on PnP systems (all Windows versions after Windows NT), the kernel detects the PCI devices, loads the kernel driver specified by an .inf file, and calls the driver's probe routine for each device that is to be supported by the driver.

I have to admit that drivers for graphic cards, disk controllers, NICs etc. you may have to dis