[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