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 2015Once 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 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="...". 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. 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.
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.
Currently there's really lot of confusion when you do kernel driver development for Windows, with different signing requirements, some of which Microsoft refuses to keep supporting, options for inf files that are not supported anymore, the way installation directories have to be specified in inf files for different Windows builds, etc.
You described some of those hassles to me in private email. I'm disappointed Microsoft is making life so difficult for device driver developers.
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.
However, the big problem that I see in the NTP project is a missing clean way to access pre-release versions of the NTP code base, which seem to be distributed across the home directories of several developers.It would be good if a repo with 4.2.8p15 plus the collected changes would be available, so that everybody could easily keep track of the changes, and make commits based on the latest pre-release version, like it's usual today e.g. with git repos.
I agree completely. Due to a screwup on my part, this will need to wait until after the upcoming release of 4.2.8p16, but I'd like to see all non-security staged changes published by bk://bk.ntp.org.
Thanks for the response, Dave Hart -- This is hackers@xxxxxxxxxxxxx Subscribe: hackers+subscribe@xxxxxxxxxxxxx Unsubscribe: hackers+unsubscribe@xxxxxxxxxxxxx