Martin Burnicki <martin.burni...@meinberg.de> wrote: > Rob wrote: >> Martin Burnicki <martin.burni...@meinberg.de> wrote: >>> Extracting some refclock driver code from ntpd, modify it so that it >>> uses the SHM interface instead of ntpd's "native" refclock interface, >>> and putting all this into an own Windows service would be quite some effort. >>> >>> Maybe it would make more sense to try to port gpsd or something similar >>> to Windows, if this is not yet supported. >> >> The SHM interface in gpsd is Unix-specifc (shmget/shmat). >> Maybe it is better to investigate what SHM interfaces Windows supports >> and find if one of them is compatible with something available on >> Linux/Unix, and then use that as the SHM for the new improved driver. >> >> That would make the porting between Unix and Windows easier. > > As far as I know there is only a single type of shared memory support in > Windows.
Ok. That amazes me. I thought that Windows always retained all earlier API methods for backward compatability, starting from the days of DOS. I would not be surprised when there was still a Windows API to create and attach an EMS/XMS/HMA or whatever it was once called block. And there were also the days of Windows NT when Windows tried to be a Posix-compatible OS (because that was required to get US Government jobs). So I expected that there would be at least an API for Posix shared memory, a current Windows API, and maybe 2 or 3 backward compatible APIs. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
