[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 3/14/2023 5:20 AM, Martin Burnicki wrote:
Dave Hart wrote:
Currently the NTP distribution has Visual Studio solution and project files for:

Visual Studio 2005 (earliest supported)
Visual Studio 2008
Visual Studio 2013
Visual Studio 2015

Once upon a time some of the NTP maintainers decided to use VS2008, because there was an "Express" version available (IIRC). I'm still using that version today to build the installation package we provide at Meinberg.

I think you can blame me for that.  Back in 2009 I started contributing using Visual C++ 2008 Express Edition (cost-free).
I'm not going to blame you for that. :-)

As mentioned earlier, I'm still using VS2008 to build the NTP package and also some other projects.

I don't like VS very much and try to avoid using it whenever possible. The main reason is because it is very hard to keep track of the properties, especially if you change some setting via the GUI, etc.

Part of my work creating a set of VS 2022 solution/project files was to heavily hand-edit the .vcxproj files to reduce redundancy introduced by the GUI settings, pulling elements under 6 different variant sections that were all the same into a common section leaving only the differences under Condition="...".

That's exactly what I meant in an earlier email. If you just click around in the GUI, you can't be sure what is really affected by your click. If you want a proper setup you have to edit the project files manually, and repeat this for each VS version you want to support.

Using a single Makefile is much easier IMO.

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

With that in mind, I've been redoing that cleanup under winnt/vs2015 as it will need to stay around to support building for XP. Then I'll use the 2015 project files as the initial revision of the vs2022 files so the change history makes clear what is novel for 2022.

For what it's worth, I dont have VS 2022, but only a professional version of VS2019, which I use for 1 single (external) project I occasionally have to build.

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 GetSystemTi