FWIW, the normal Win32 API idiom for such a function would be something like:

STATUS PacketGetTimestampModes(LPADAPTER AdapterObject, ULONG *Modes, ULONG *cNodes)

which returns an API specific STATUS value, normally typed to an integer, e.g. a LONG with 0 as success, anything else is an error and cNodes indicating the elements available in the Modes array on input and the number of elements written to the array on output. Calling with Modes as a nullptr will set the required size in cNodes.

FWIW, the normal Win32 API idiom for such a function would be something like:

STATUS PacketGetTimestampModes(LPADAPTER AdapterObject, ULONG *Modes, ULONG *cNodes)

which returns an API specific STATUS value, normally typed to an integer, e.g. a LONG with 0 as success, anything else is an error and cNodes indicating the elements available in the Modes array on input and the number of elements written to the array on output. Calling with Modes as a nullptr will set the required size in cNodes.

I know of at least one company up in the US state of Washington that has some APIs that don't follow that convention - those APIs return a BOOL to indicate success or failure, with a status being returned by GetLastError() That's how FlushFileBuffers() works, for example. :-)

Other APIs from that company, such as CreateFile() return HANDLEs, with INVALID_HANDLE indicating failure.

The Packet32.dll routines also follow that convention - not that any of them are APIs; I'm one of the few people who should be writing code that calls them. :-) (I.e., the Packet32.dll API is not guaranteed to be stable; it exists primarily to serve libpcap's pcap-npf.c, and if the API changes, so does pcap-npf.c.)

FWIW, the normal Win32 API idiom for such a function would be something like:

STATUS PacketGetTimestampModes(LPADAPTER AdapterObject, ULONG *Modes, ULONG *cNodes)

which returns an API specific STATUS value, normally typed to an integer, e.g. a LONG with 0 as success, anything else is an error and cNodes indicating the elements available in the Modes array on input and the number of elements written to the array on output. Calling with Modes as a nullptr will set the required size in cNodes.

I know of at least one company up in the US state of Washington that has some APIs that don't follow that convention - those APIs return a BOOL to indicate success or failure, with a status being returned by GetLastError() That's how FlushFileBuffers() works, for example. :-)

Those ones are annoying, hence I chose the "better" example.

Other APIs from that company, such as CreateFile() return HANDLEs, with INVALID_HANDLE indicating failure.

The Packet32.dll routines also follow that convention - not that any of them are APIs; I'm one of the few people who should be writing code that calls them. :-) (I.e., the Packet32.dll API is not guaranteed to be stable; it exists primarily to serve libpcap's pcap-npf.c, and if the API changes, so does pcap-npf.c.)

My observation, which didn't spell it out, was to move the number of nodes from the return to an in\out parameter, which then allows the return to indicate success or failure, or something richer without having to use "out-of-range" values as the return to indicate things went wrong.

This is just an update/summary that we added the Packet* calls a while back, but we still need to make and submit a patch to upstream libpcap (and possibly our wpcap.dll while we wait for upstream incorporation). We also should document the Npcap-specific details on how these calls are implemented on Windows into the Npcap users' guide.

This is just an update/summary that we added the Packet* calls a while back, but we still need to make and submit a patch to upstream libpcap

You added PacketSetTimestampMode(), but not PacketGetTimestampModes(); the libpcap changes will require both.