Feature/rdk 4115/windows port

[vdm-dev]

Greetings from RoboDK Team.
We've done some work here and now your library builds and runs on Windows (including RTDE protocol).
We added the 3rdparty folder with two sub-projects:

1. endian.h for converting between BIG ENDIAN and LITTLE ENDIAN,
2. pthread-win32 for POSIX threads on Windows (added as git sub-module).

[urfeex]

Thank you very much for the input. I am not completely sure whether the licensing model with the 3rdparty projects would work in that constellation. I'll come back to that.

There might be the chance of removing the pthread calls, though / replace them with Windwos threads where needed. E.g. by using SetThreadPriority on windows and sched_setscheduler on POSIX. What would you think about that?

[vdm-dev]

pthread-win32 is licensed under two licenses: Apache 2.0 and GNU LGPL.
endian.h is licensed as public domain.

But anyway, I agree with you and think it's wasteful to use a POSIX Thread Layer for the sake of a couple calls.
Give me some time to do some in-depth research on the possibility of doing away with pthreads on Windows.

[vdm-dev]

It's done. pthreads are no longer needed on Windows. I left endian.h because I don't want to make more #ifdef's.
Here is the license for the endian.h:

// https://gist.github.com/panzi/6856583
//
// I, Mathias Panzenböck, place this file hereby into the public domain. Use
// it at your own risk for whatever you like. In case there are
// jurisdictions that don't support putting things in the public domain you
// can also consider it to be "dual licensed" under the BSD, MIT and Apache
// licenses, if you want to. This code is trivial anyway. Consider it an
// example on how to get the endian conversion functions on different
// platforms.

[urrsk]

Thanks for the PR. Really interesting.
Is there any reason why you are not suggesting the updated one at https://gist.github.com/panzi/6856583
It seems that there has been added something that relates to windows and QNX

[vdm-dev]

Thank you.
The reason is that version uses the htons/htonl/htonll methods from WinSock2.h, while my version uses the _byteswap_ushort/_byteswap_ulong/_byteswap_uint64 methods from stdlib.h within MSVC (https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/byteswap-uint64-byteswap-ulong-byteswap-ushort?view=msvc-170).
WinSock2.h is too big to include it for the sake of three functions. It slows down compilation.
Besides, calls to htons are guaranteed to result in a full method call from ws2_32.dll, while methods from the Standard C library can be inline or translated into platform-dependent processor instructions (e.g. bswap: https://c9x.me/x86/html/file_module_x86_id_21.html).

[urfeex]

Could we combine this PR with a Windows CI? I am not experienced with compiling things on Windows, so if you could help us out there, that would be great :-)

[vdm-dev]

That would be great, but unfortunately I've been pretty busy with work lately.
It is possible that I will prepare scripts for CI in the future, but I don't know when yet.

[urfeex]

That would be great, but unfortunately I've been pretty busy with work lately. It is possible that I will prepare scripts for CI in the future, but I don't know when yet.

Thank you for the reply. I'll see whether I can draft something up quickly, myself, then.

[urrsk]

@panzi will you be that we include the 3rdparty/endian/endian.h into this project under Apache 2.0 or BSD3 license?
Just want to be completely sure as the statement in the header is only referring to apache and bsd.

The header seems very useful. Thanks for the great work.

[panzi]

You may include it under whatever license, even without referencing where you got it from. As I said, I put it under the public domain. Anyone can do anything with it. If that is too vague for you, you may consider it to be Apache 2.0, as is your project, to make things simpler. But again, I don't care. It's trivial. And I don't think I would do it like that nowadays anyway. You can make endian independent macros that should compile away if the endianess matches your machine. Like:

/** @param uint8_t* PTR */
#define READ_U32_LE(PTR) (uint32_t)((uint32_t)(PTR)[0] | ((uint32_t)(PTR)[1] << 8) | ((uint32_t)(PTR)[2] << 16) | ((uint32_t)(PTR)[3] << 24))

Example that shows it has the same assembly for gcc -O2: https://godbolt.org/z/5v61vz7ad