Windows port

[wig...@gmail.com]

Hi!

I have been looking for a Windows DBus C++ library without much success recently. In the end I have bitten the bullet and ported dbus-cxx from master branch. The port is available here:

https://github.com/wigbam/dbus-cxx/tree/win

The port itself wasn't that hard, but it took some time, perhaps mostly due to the fact I am not a primarily C++ developer. The commit history pretty much explains everything which had to be done, below is a brief summary:

• Moved all POSIX imports from headers to implementations utilising private implementation pattern
• Added a POSIX compatibility layer for poll, read and write (mostly borrowed from https://github.com/libressl-portable/portable/tree/master/include)
• Renamed interface symbols to avoid clashes on Windows
• Changed all boolean operators to symbol-like form, i.e. 'not' -> '!' etc.
• Replaced pthread locks with STD locks where possible and abstracted the rest via platform independent macros
• On Windows, use BoostASIO header-only library for timers (timeout.cpp)
• Clean-up CMake linking to make it platform-independent, e.g. use '-lrt' or '-pthread' only if supported etc.
• Other minor fixes, clean-ups and improvements

As a part of the change I have also added a CMake option to enable/disable building of static libraries.

The port has been tested on Windows7 x64 running Visual Studio 16 (2019) targeting Win32 with all features working as expected:

• Both shared and static library builds (including glibmm)
• Tools
• Examples
• All tests pass, although two filedescriptor tests had to be excluded (because of dbus, not dbus-cxx)
• Packaging works and a nice NSIS GUI installer/uninstaller is generated
• A test CMake project dependent on dbus-cxx, builds, links and runs fine

I have also regression-tested building on Linux (Elementary OS 64, based on 18.04.1-Ubuntu) without any issues.

I haven't opened a Pull Request yet as I wanted to get some feedback/opinions here first.

Regards,

--Stepan 

[Robert Middleton]

Hi,

Some thoughts so far:

• I've never tried dbus-cxx on Windows, so just to warn you some things may or may not work properly.
  
• Most of the CMake stuff looks good, nothing pops out as being bad to me
• Not that it really matters, but it does look like MSVC supports keywords like 'not' if you set some options[1].  I haven't changed these over to being symbols as it's never really been important with g++/clang++.
  
• I would be surprised if the glibmm code works in the first place; it's not really done in the correct manner.
  
• Renaming 'interface': is this an MSVC extension of some kind?  I'm trying to keep the API/ABI stable at this point.  Perhaps instead of renaming the method we add a new method that does the same thing, and surround the default one with a macro so that non-Windows systems get both methods.
• The pipe stuff should probably use an Event object on Windows[2], as the pipe is really just to wakeup the processing thread, the actual data in it doesn't matter.  As long as it works though it's probably not important enough to change.
  

A few of these fixes have been done on the dbus-cxx-2 branch already, have you seen that branch?  The current version in master I'm not planning any more large fixes for, so I'm not sure if this makes sense to bring in or not.  Note that if you do look at anything on the dbus-cxx-2 branch note that it is a complete reimplementation of dbus, so some custom Windows support would definitely need to be added.  I would definitely prefer to add this stuff to that branch, as it's in an alpha stage, so if there's something that needs to be fixed for Windows to work now would be the best time to do it.

The dbus-cxx-2 branch does have proper support for Qt and GLib, if you're using either of those libraries.

-Robert Middleton

[1]: https://stackoverflow.com/questions/24414124/why-does-vs-not-define-the-alternative-tokens-for-logical-operators

[2]: https://docs.microsoft.com/en-us/windows/win32/sync/using-event-objects

--
You received this message because you are subscribed to the Google Groups "Dbus-cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dbus-cxx+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dbus-cxx/c86c2f54-d023-4dd2-94b2-542cf3a025c5o%40googlegroups.com.

[wig...@gmail.com]

Hi Robert,

Thanks for having a look!

Renaming 'interface': is this an MSVC extension of some kind?  I'm trying to keep the API/ABI stable at this point.  Perhaps instead of renaming the method we add a new method that does the same thing, and surround the default one with a macro so that non-Windows systems get both methods.

 

Yes, under Windows interface is defined as struct:
https://github.com/wine-mirror/wine/blob/2211de9eeb38503db0f5b47e111c9dd6c5f71585/include/objbase.h#L221

Makes total sense regarding surrounding those with macro guards - I will re-work that part.

A few of these fixes have been done on the dbus-cxx-2 branch already, have you seen that branch?  The current version in master I'm not planning any more large fixes for, so I'm not sure if this makes sense to bring in or not.  Note that if you do look at anything on the dbus-cxx-2 branch note that it is a complete reimplementation of dbus, so some custom Windows support would definitely need to be added.  I would definitely prefer to add this stuff to that branch, as it's in an alpha stage, so if there's something that needs to be fixed for Windows to work now would be the best time to do it.

Sure, again makes sense. I will see how easy it is to get whatever change are necessary over to dbus-cxx-2 branch.

Regards,

--Stepan

To unsubscribe from this group and stop receiving emails from it, send an email to dbus...@googlegroups.com.

[Robert Middleton]

Stepan,

Just a quick note on the dbus-cxx-2 branch: the API isn't set yet, so changing the 'interface' method to 'iface' is perfectly fine there.  If you can try it out on Windows(and open some issues on Github) that would be helpful to track progress; I can probably do some of the work for that, but I need to know what the issues are first(as I don't do much on Windows).

-Robert Middleton

To unsubscribe from this group and stop receiving emails from it, send an email to dbus-cxx+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dbus-cxx/1c2dfa4a-df18-48dd-afc3-0bede11a6dc2o%40googlegroups.com.

[wig...@gmail.com]

A little update on dbus-cxx-2 Windows port progress.

I have got all of the main library compiling on MSVC, apart from transport.cpp. It looks as currently transport.cpp can only handle 'unix' socket connections, but 'unix' connections are only supported on very recent Windows10 platforms and completely unsupported on earlier versions.

Originally, libdbus can also handle 'autolaunch' and 'tcp' type of connections. Are those planned to be implemented?

To view this discussion on the web visit https://groups.google.com/d/msgid/dbus-cxx/1c2dfa4a-df18-48dd-afc3-0bede11a6dc2o%40googlegroups.com.

[Robert Middleton]

I think we can at least support TCP connections.  The SimpleTransport that already exists should be able to work with unix-style TCP sockets as-is, as it simply uses 'write' and 'read'.

One thing that might have to change with that is the wait_for_fd_activity function - I don't know how well that will be supported on Windows, it may need to use a HANDLE instead.

-Robert Middleton

To unsubscribe from this group and stop receiving emails from it, send an email to dbus-cxx+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dbus-cxx/250d3820-3cdc-4edb-9fe0-76db1155f0a2o%40googlegroups.com.

[Stepan Kolesnik]

I have opened an issue to track this and will look into implementing `autolaunch`  connection type for Windows.
https://github.com/dbus-cxx/dbus-cxx/issues/63