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

[Dave Hart <davehart@xxxxxxxxx>]

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.

> 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?

> >> It would be great when we could simply use something like MSYS2/Mingw
> >> to build the Windows version of the binaries.
> >
> > I don't think that's practical as I doubt cygwin or mingw support our
> > nuances around time, such as GetSystemTimeAsFileTime vs.
> > GetSystemTimePreciseAsFileTime, or adjtime implemented in terms of
> > SetSystemTimeAdjustment.
>
> The only requirement for a single binary that uses
> GetSystemTimePreciseAsFileTime on systems that support it, and falls
> back to GetSystemTimeAsFileTime on systems that don't support it, is
> that the program checks at runtime whether
> GetSystemTimePreciseAsFileTime is available or not.
>
> To do so, it simply tries to import the address of the
> GetSystemTimePreciseAsFileTime function from the kernel at startup, and
> it uses a stanard Windows API call to do that.
>
> This has been used in NTP for Windows for a long time, and similarly in
> the Meinber driver package for windows.
>
> Doing so doesn't depend on the compiler at all, otherwise VS2008
> wouldn't be able to do this, either. So why shouldn't mingw be able to
> do it?

I was referring to the idea of getting rid of Windows-specific code
and relying on mingw to implement an adjtime() interface on Windows.

> >>> What I'm wondering is which of those versions are actually being used
> >>> today.  If you build the NTP distribution from source, or would like
> >>> that retain the capability even if you haven't done it lately, please
> >>> speak up about which Visual Studio version you're using, and whether
> >>> you'd have a problem installing a newer version.  Visual Studio 2022
> >>> Community Edition is cost-free and I believe it can be installed
> >>> side-by-side with older versions.
> >>
> >> Basically I wouldn't have a problem with porting changes from some
> >> newer version like VS2022 back to an older version like VS2008.
> >
> > I know you have other things to worry about, but I'd love to see you try
> > using Visual Studio 2022 Community Edition with the older toolchain I
> > mentioned in my response to Terje to preserve the ability to produce
> > WinXP-compatible binaries.  we might be able to whittle down the
> > port/winnt/vs* directories to just vs2015 and vs2022 at that point.
>
> That's exactly the 2 VS versions I *don't* have installed. ;-)
>
> Concerning VS2022, I've heard that there are other hassles if you are
> trying to use it for kernel driver development. Something like
>
> - it comes with an WDK
>
> - you better use a different WDK
>
> - you may have to use different WDKs if you want to "target" different
> Windows version (whatever make the difference between those versions).

I understand your frustration.  I just want to point out you can
likely use VS 2019, and can definitely use VS 2022, to build the
Meinberg NTP binaries that will still support Windows XP if you
install the optional toolchains I mentioned to Terje.  Also, you can
have multiple versions of Visual Studio installed side-by-side on the
same machine, it's not an either-or choice.

Take care,
Dave Hart
-- 
This is hackers@xxxxxxxxxxxxx
Subscribe: hackers+subscribe@xxxxxxxxxxxxx
Unsubscribe: hackers+unsubscribe@xxxxxxxxxxxxx