[ntp:questions] Any chance of getting bugs 2164 and 1577 moving?

Dave Hart hart at ntp.org
Tue Mar 20 15:33:36 UTC 2012

On Tue, Mar 20, 2012 at 14:58, David J Taylor wrote:
> "Harlan Stenn" <stenn at ntp.org> wrote in message
> news:E1S9ySB-000KQp-RU at stenn.ntp.org...
>> I will say (knowing full well that I am not a windows guy) that we use
>> net-snmp for this for Unix, and it sure looks to me like that code
>> should build under Windows.
>> What we need is somebody to build the net-snmp code under Windows and
>> then build the ntpsnmpd piece as well.
>> Again, paches welcome, or sooner or later somebody will get to it.
> If I did "C" I would happily submit patches, but my software is in Delphi
> for higher productivity and a most helpful user community.  I find "C"
> almost unreadable.
> 2164 needs discussion, unless altering the number of significant digits in
> the ntpq output wouldn't break anything.  Do we need to have this
> discussion?  I have looked through ntpq.c, but I can't see where the number
> of decimal digits in the output for offset is set.

ntpd/ntp_control.c, I'm guessing look for _OFFSET

> I would give priority to 2164 over 1577, but I suggested 1577 for the Google
> Summer of code and received precisely zero response!  I do see that net-snmp
> does include a note for Windows users:
>  http://www.net-snmp.org/download.html
> so adding support doesn't involve starting from scratch.

That note shows the author apparently applying POSIX knowledge
inappropriately to Windows.  Arguably, the issue is with OpenSSL not
net-snmp, but both are at risk of having development dominated by
folks less than fluent in Windows development.  There is no problem
installing multiple OpenSSL versions used by multiple apps on Windows,
when done properly, which is to day putting the DLLs in the directory
containing the the executable.  One can choose to install openssl DLLs
in systemwide directories if leaving behind Windows 3.1's DLL Hell is
just too much change to process, I suppose.

It's less than encouraging about the amount of effort required to use
net-snmp on Windows.  So far we have a single monolithic build setup
on Windows without configure options such as --with-net-snmp or
whatever.  That means the straightforward way to add use of net-snmp
would provide another barrier to entry to building the reference
implementation on Windows from source.  In addition to a working
compiler, openssl headers and libraries, we'd need net-snmp headers
and libraries.  Given how little ntpsnmpd is used on the
far-more-prevalent POSIX ntpd systems porting it to Windows is pretty
far down my list.

Dave Hart

More information about the questions mailing list