windbus-devel Mailing List for winDBus

Peter Kümmel schrieb:
> then windbus is in sync with freedesktop's version plus some win specific patches?
the windbus source used for building dbus binary packages for kde [1] is based on freedesktop tag 1.2.4 - windbus is in sync with this version. 

[1] http://windbus.svn.sourceforge.net/viewvc/windbus/tags/


Regards
 Ralf

Peter Kümmel wrote:
> Ralf Habacker wrote:
>> Peter Kümmel schrieb:
>>> Currently there are several repositories and branches with
>>> dbus code for windows, and I wonder which one is the HEAD if
>>> any.
>>>
>>> Am I right winDBus on sourceforge is used for KDE windows?
>>>   
>> currently yes, but it going to switch to the freedesktop sometime in the 
>> future.
>>
>>> And http://repo.or.cz/w/dbus4win.git is only a public repository
>>> from KDAB with unknown usage?
>>>   
>> this could probably be answered by kdab people
>>> And what is the status of the windows code in the official code?
>>>   
>> mostly code from windbus and dbus4win is now merged into the dbus git 
>> master branch http://cgit.freedesktop.org/dbus/dbus/
> 
> 
> Thanks Ralph,

Ralf!

> 
> then windbus is in sync with freedesktop's version plus some win specific
> patches?
> 
> Peter
> 
>> Tor Lillqvist took the time to prepare a big patch and I checked the 
>> patches as far as I was able to do so and applied them to dbus git 
>> master branch. There is a related item in the dbus bug tracker. 
>> https://bugs.freedesktop.org/show_bug.cgi?id=25213
>>> Maybe someone who knows what is going on could also update the
>>> debus wiki: http://www.freedesktop.org/wiki/Software/dbus
>>>   
>> Who has write acces to this page ?
>>> Some more technical questions:
>>> What does 'nonce' mean?
>>>   
>> from http://marc.info/?l=freedesktop-dbus&m=124388381621642&w=2
>>
>>> 3. Implement the unix transport for Windows using the design already chosen
>>>    for libassuan. This consists of writing plain text files with a nonce
>>> and the tcp port number of the server into the filesystem location where on
>>> Unix the Unix Domain Socket special file would go. Current windbus is not
>>> really usable for multiuser systems, though there was a patch recently
>>> trying to address that, but falling short of the full solution. There are
>>> certainly other ways to implement a per-user transport on Windows, but this
>>> design has proven itself in libassuan, an extremely security-conscious
>>> library (IPC lib for gnupg components).
>>
>>> Does dbus still use sockets on Windows?
>>>   
>> yes, also nonce transport is based on tcp.
>>
>> Regards
>>  Ralf
>>
> 
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Windbus-devel mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/windbus-devel
> 

Ralf Habacker wrote:
> Peter Kümmel schrieb:
>> Currently there are several repositories and branches with
>> dbus code for windows, and I wonder which one is the HEAD if
>> any.
>>
>> Am I right winDBus on sourceforge is used for KDE windows?
>>   
> currently yes, but it going to switch to the freedesktop sometime in the 
> future.
> 
>> And http://repo.or.cz/w/dbus4win.git is only a public repository
>> from KDAB with unknown usage?
>>   
> this could probably be answered by kdab people
>> And what is the status of the windows code in the official code?
>>   
> mostly code from windbus and dbus4win is now merged into the dbus git 
> master branch http://cgit.freedesktop.org/dbus/dbus/


Thanks Ralph,

then windbus is in sync with freedesktop's version plus some win specific
patches?

Peter

> 
> Tor Lillqvist took the time to prepare a big patch and I checked the 
> patches as far as I was able to do so and applied them to dbus git 
> master branch. There is a related item in the dbus bug tracker. 
> https://bugs.freedesktop.org/show_bug.cgi?id=25213
>> Maybe someone who knows what is going on could also update the
>> debus wiki: http://www.freedesktop.org/wiki/Software/dbus
>>   
> Who has write acces to this page ?
>> Some more technical questions:
>> What does 'nonce' mean?
>>   
> from http://marc.info/?l=freedesktop-dbus&m=124388381621642&w=2
> 
>> 3. Implement the unix transport for Windows using the design already chosen
>>    for libassuan. This consists of writing plain text files with a nonce
>> and the tcp port number of the server into the filesystem location where on
>> Unix the Unix Domain Socket special file would go. Current windbus is not
>> really usable for multiuser systems, though there was a patch recently
>> trying to address that, but falling short of the full solution. There are
>> certainly other ways to implement a per-user transport on Windows, but this
>> design has proven itself in libassuan, an extremely security-conscious
>> library (IPC lib for gnupg components).
> 
> 
>> Does dbus still use sockets on Windows?
>>   
> yes, also nonce transport is based on tcp.
> 
> Regards
>  Ralf
> 

Peter Kümmel schrieb:
> Currently there are several repositories and branches with
> dbus code for windows, and I wonder which one is the HEAD if
> any.
>
> Am I right winDBus on sourceforge is used for KDE windows?
>   
currently yes, but it going to switch to the freedesktop sometime in the 
future.

> And http://repo.or.cz/w/dbus4win.git is only a public repository
> from KDAB with unknown usage?
>   
this could probably be answered by kdab people
> And what is the status of the windows code in the official code?
>   
mostly code from windbus and dbus4win is now merged into the dbus git 
master branch http://cgit.freedesktop.org/dbus/dbus/

Tor Lillqvist took the time to prepare a big patch and I checked the 
patches as far as I was able to do so and applied them to dbus git 
master branch. There is a related item in the dbus bug tracker. 
https://bugs.freedesktop.org/show_bug.cgi?id=25213
> Maybe someone who knows what is going on could also update the
> debus wiki: http://www.freedesktop.org/wiki/Software/dbus
>   
Who has write acces to this page ?
> Some more technical questions:
> What does 'nonce' mean?
>   
from http://marc.info/?l=freedesktop-dbus&m=124388381621642&w=2

> 3. Implement the unix transport for Windows using the design already chosen
>    for libassuan. This consists of writing plain text files with a nonce
> and the tcp port number of the server into the filesystem location where on
> Unix the Unix Domain Socket special file would go. Current windbus is not
> really usable for multiuser systems, though there was a patch recently
> trying to address that, but falling short of the full solution. There are
> certainly other ways to implement a per-user transport on Windows, but this
> design has proven itself in libassuan, an extremely security-conscious
> library (IPC lib for gnupg components).


> Does dbus still use sockets on Windows?
>   
yes, also nonce transport is based on tcp.

Regards
 Ralf

Currently there are several repositories and branches with
dbus code for windows, and I wonder which one is the HEAD if
any.

Am I right winDBus on sourceforge is used for KDE windows?
And http://repo.or.cz/w/dbus4win.git is only a public repository
from KDAB with unknown usage?

And what is the status of the windows code in the official code?

Maybe someone who knows what is going on could also update the
debus wiki: http://www.freedesktop.org/wiki/Software/dbus

Some more technical questions:
What does 'nonce' mean?
Does dbus still use sockets on Windows?

Thanks,
Peter

Bruce, Henry wrote:
> I am working on a Visual Studio 2008 port for dbus-c++ and have hit
> compile errors in dbus-message.h as some function parameters are named
> ‘interface’  (see below), which is a reserved word in the Microsoft
> extensions.
>  
> DBusMessage* dbus_message_new_method_call(const char 
> *bus_name,                                    
>                                           const char  *path,
>                                           const char  *interface,
>                                           const char  *method);
>  
> I have tried disabling extensions, but hit other problems when Microsoft
> headers are pulled in. In the short term I have worked around this by
> renaming the parameter, but would like to avoid changing the source. Has
> anyone hit this problem and found a fix?
>  
> Thanks,
>  
> Henry

Isn't 'interface ' just a macro definition? Then '#undef interface' will help.

Peter

I am working on a Visual Studio 2008 port for dbus-c++ and have hit compile errors in dbus-message.h as some function parameters are named 'interface'  (see below), which is a reserved word in the Microsoft extensions.

DBusMessage* dbus_message_new_method_call(const char  *bus_name,
                                          const char  *path,
                                          const char  *interface,
                                          const char  *method);

I have tried disabling extensions, but hit other problems when Microsoft headers are pulled in. In the short term I have worked around this by renaming the parameter, but would like to avoid changing the source. Has anyone hit this problem and found a fix?

Thanks,

Henry

Hi,

Let me give you a status update on our work:

On Tuesday April 21 2009, Marc Mutz wrote:
> Hi,
>
> I'd like to announce that we at KDAB are working on 'dbus4win', which we
> like to think of as a re-unification of the freedesktop.org GIT tree and
> the windbus.sf.net SVN tree. To this end, we already spent some time to
> graft the SVN tree onto the git tree (windbus-svn branch).
>
> There are three areas we are currently focusing on:
> 1. cleaning up the SVN history (dbus4win branch)
>    This is an attempt to rebase the remaining diff between the SVN tree and
>    dbus-1.2 onto dbus-1.2, preserving the windbus history where possible.

This has been completed meanwhile.

In addition, we've integrated contributions of Tor Lillquist and  
Ole André Vadla Ravnås.

As a result, internal testing indicates that the current dbus4win fixes quite 
some issues the Kontact on Windows windbus code still showed. Till can give 
details on what exactly we found has improved.

> 2. Make dbus cross-compile with mingw (xcompile branch)
>    This is needed for the gpg4win (www.gpg4win.org), and Kontact-on-Windows
>    projects, as well as for all the reasons mentioned in
>    http://lwn.net/Articles/307732/

This is in an intermediate stage. At one point, cross-compilation worked, but 
it has since deteriorated again. We intend to fix this up again, but two of 
our engineers working on the projects are now going on vacation (me 
included), so it won't happen before the second half of June. The current 
state can be found in the dbus4win-xcompile2 branch.

> 3. Implement the unix transport for Windows using the design already chosen
>    for libassuan. This consists of writing plain text files with a nonce
> and the tcp port number of the server into the filesystem location where on
> Unix the Unix Domain Socket special file would go. Current windbus is not
> really usable for multiuser systems, though there was a patch recently
> trying to address that, but falling short of the full solution. There are
> certainly other ways to implement a per-user transport on Windows, but this
> design has proven itself in libassuan, an extremely security-conscious
> library (IPC lib for gnupg components).

Here, we're still working on both code and spec. For interested parties, the 
work is ongoing in branch dbus4win-noncetcp (that's nonce-tcp, not 
non-ce-tcp, we're doing tcp since that one _does_ work on WinCE :)

Thanks, and see you at the other side of vacation,
Marc

-- 
Marc Mutz <ma...@kd...> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

Marc Mutz wrote:
> Hi,
> 
> I'd like to announce that we at KDAB are working on 'dbus4win', which we like 
> to think of as a re-unification of the freedesktop.org GIT tree and the 
> windbus.sf.net SVN tree. To this end, we already spent some time to graft the 
> SVN tree onto the git tree (windbus-svn branch).
> 

Great to hear some is interested in finishing this port!


> There are three areas we are currently focusing on:
> 1. cleaning up the SVN history (dbus4win branch)
>    This is an attempt to rebase the remaining diff between the SVN tree and
>    dbus-1.2 onto dbus-1.2, preserving the windbus history where possible.
> 2. Make dbus cross-compile with mingw (xcompile branch)
>    This is needed for the gpg4win (www.gpg4win.org), and Kontact-on-Windows
>    projects, as well as for all the reasons mentioned in
>    http://lwn.net/Articles/307732/

I don't think anybody will have objections.

> 3. Implement the unix transport for Windows using the design already chosen
>    for libassuan. This consists of writing plain text files with a nonce and
>    the tcp port number of the server into the filesystem location where on
>    Unix the Unix Domain Socket special file would go. Current windbus is not
>    really usable for multiuser systems, though there was a patch recently
>    trying to address that, but falling short of the full solution. There are
>    certainly other ways to implement a per-user transport on Windows, but this
>    design has proven itself in libassuan, an extremely security-conscious
>    library (IPC lib for gnupg components).

Does this mean communication by filesystem, or only to get the socket infos?

> 
> Please note that all this is still work in progress. None of the three focus 
> points are completed yet. In particular, the branches in the above repository 
> are subject to regular rebasing (exceptions: dbus-1.2 and master, which track 
> FD.org git), so don't git-pull, but git-fetch/git-rebase instead. Nonetheless 
> we invite interested parties to review the patches, and FD.org dbus 
> maintainers to pull from our for_upstream branch.
> 
> Find the tree at
>    http://repo.or.cz/w/dbus4win.git
> Drop me a note if you'd like push access. You need a repo.or.cz account for 
> that, though you can use the open mob account (http://repo.or.cz/mob) for 
> fire-and-forget commits.
> 
> Our hope is that
> - windbus developers consider using GIT from now on for easier patch migration
>   and merging.

There will not much happen in windbus therefore it is not hard to integrate
new changes into dbus4win without using git.
And because kde-windows needs a running dbus I'm not sure how much will
go into windbus from dbus4win.

> - freedesktop.org maintainers will consider Windows a first-class citizen once
>   crosscompilation works

I'm sure they will, when you do it the "right" way.

> - world peace
> 
> To this end, KDAB is committed to doing its share in continually maintaining 
> dbus on the Windows platform.
> 
> Signed-off-by: Till Adam <ti...@kd...> :)
> 
> Thanks,
> Marc
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dbus mailing list
> db...@li...
> http://lists.freedesktop.org/mailman/listinfo/dbus
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [announce] dbus4win
> From:
> Matthew Johnson <db...@ma...>
> Date:
> Tue, 21 Apr 2009 11:40:35 +0100
> To:
> Marc Mutz <ma...@kd...>
> 
> To:
> Marc Mutz <ma...@kd...>
> CC:
> db...@li..., win...@li..., Sebastian Sauer
> <seb...@kd...>, Frank Osterfeld <fr...@kd...>, Till Adam
> <ti...@kd...>
> 
> 
> On Tue Apr 21 11:04, Marc Mutz wrote:
>> I'd like to announce that we at KDAB are working on 'dbus4win', which we like 
>> to think of as a re-unification of the freedesktop.org GIT tree and the 
>> windbus.sf.net SVN tree. To this end, we already spent some time to graft the 
>> SVN tree onto the git tree (windbus-svn branch).
> 
> This is great news
> 
>> 3. Implement the unix transport for Windows using the design already chosen
>>    for libassuan. This consists of writing plain text files with a nonce and
>>    the tcp port number of the server into the filesystem location where on
>>    Unix the Unix Domain Socket special file would go.
> 
> I'd like to work with you guys to make sure that dbus-java works with
> any transport/auth/etc mechanisms which differ on Windows.
> 
> Matt
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [announce] dbus4win
> From:
> "Daniel P. Berrange" <da...@be...>
> Date:
> Tue, 21 Apr 2009 12:26:05 +0100
> To:
> Marc Mutz <ma...@kd...>
> 
> To:
> Marc Mutz <ma...@kd...>
> CC:
> db...@li..., win...@li..., Sebastian Sauer
> <seb...@kd...>, Frank Osterfeld <fr...@kd...>, Till Adam
> <ti...@kd...>
> 
> 
> On Tue, Apr 21, 2009 at 11:04:10AM +0200, Marc Mutz wrote:
>> Hi,
>>
>> I'd like to announce that we at KDAB are working on 'dbus4win', which we like 
>> to think of as a re-unification of the freedesktop.org GIT tree and the 
>> windbus.sf.net SVN tree. To this end, we already spent some time to graft the 
>> SVN tree onto the git tree (windbus-svn branch).
>>
>> There are three areas we are currently focusing on:
>> 1. cleaning up the SVN history (dbus4win branch)
>>    This is an attempt to rebase the remaining diff between the SVN tree and
>>    dbus-1.2 onto dbus-1.2, preserving the windbus history where possible.
>> 2. Make dbus cross-compile with mingw (xcompile branch)
>>    This is needed for the gpg4win (www.gpg4win.org), and Kontact-on-Windows
>>    projects, as well as for all the reasons mentioned in
>>    http://lwn.net/Articles/307732/
> 
> This is great news. For the Fedora mingw32 SIG, we've got a package of
> the current windbus code building under Mingw32, but it is a bad hack[1].
> We would much prefer to be able to build the official released dbus 
> tar.gz under mingw without any patching required and so look forward to
> trying the results of your work when its ready...
> 
> Daniel
> 
> [1] http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/file/tip/dbus/mingw32-dbus.spec
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and 
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today. 
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Windbus-devel mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/windbus-devel

On Tuesday April 21 2009, Colin Walters wrote:
> See also Tor's outstanding patch:
>
> http://bugs.freedesktop.org/show_bug.cgi?id=16788
>
> Is any of that work in your tree?

Not yet. But thanks for pointing that out to us, we will make sure to take 
that patch into account.

Thanks,
Marc

-- 
Marc Mutz <ma...@kd...> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

On Tuesday April 21 2009, Havoc Pennington wrote:
> On Tue, Apr 21, 2009 at 5:04 AM, Marc Mutz <ma...@kd...> wrote:
> > 3. Implement the unix transport for Windows using the design already
> > chosen
>
> One of the main discussion points in the past was avoiding "unix
> emulation" - here are some posts I dug out of google, though none of
> them explains it very succintly hopefully you get the idea:

These talk about public API abstractions, and I have not yet made my mind up 
on any of that. I wasn't feeling in the position to have to, since the API is 
set in stone anyway, and the remaining diff isn't that big anymore.

Seeing as you quoted point #3 in this reply, though, I guess this is about 
the "unix transport", not public API (though transports could be considered 
part of it, of course).

I can't see from your mails whether you are objecting to the use of plain 
files to "emulate" Unix domain sockets, or to using the "unix:" transport URL 
for that?

Thanks,
Marc

-- 
Marc Mutz <ma...@kd...> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

[the initial mail bounced]
-- 
Marc Mutz <ma...@kd...> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

Christian Ehrlicher wrote:
> Thorvald Natvig schrieb:
>   
>> Hi.
>>
>> If, for some reason, dbus-daemon.exe fails to launch,
>> _dbus_get_autolaunch_address will get stuck in an endless loop when it
>> calls _dbus_get_autolaunch_shm. The daemon may fail to launch due to
>> missing DLLs, wrong file permissions; a myriad of reasons over which we
>> have no control.
>>
>> The attached patch makes the following changes:
>> If launching for some reason fails, set an error message. I'm not sure
>> how to do this correctly, so it probably needs changing.
>> _dbus_get_autolaunch_shm will abort getting the shared memory after 20
>> attempts (2 seconds).
>> _dbus_get_autolaunch_address checks if the return state of
>> WaitForInputIdle before calling _dbus_get_autolaunch_shm.
>>
>> Thanks for the great work on windbus, keep it up :)
>>
>>     
> thx - I've applied the patch to trunk.
> trunk is synced with 1.2.12 and contains a fix to allow to use a random
> tcp port for the dbus-daemon. It's also the default now.
>
> Christian
>
>   
Excellent :) Thank you.

Uhm. I've found a small buglet in my script. If dbus-daemon is compiled 
or launched as a non-console application, it doesn't have input, so 
WaitForInputIdle always fails. You might want to simply remove that 
line, and have it fall back to the "try to get the shared memory", which 
will fail after 2 seconds if launching fails. It doesn't really matter 
that it takes 2 seconds, as we expect it to succeed (and hence finish 
long before 2 seconds pass).

Best Regards,
Thorvald

Thorvald Natvig schrieb:
> Hi.
> 
> If, for some reason, dbus-daemon.exe fails to launch,
> _dbus_get_autolaunch_address will get stuck in an endless loop when it
> calls _dbus_get_autolaunch_shm. The daemon may fail to launch due to
> missing DLLs, wrong file permissions; a myriad of reasons over which we
> have no control.
> 
> The attached patch makes the following changes:
> If launching for some reason fails, set an error message. I'm not sure
> how to do this correctly, so it probably needs changing.
> _dbus_get_autolaunch_shm will abort getting the shared memory after 20
> attempts (2 seconds).
> _dbus_get_autolaunch_address checks if the return state of
> WaitForInputIdle before calling _dbus_get_autolaunch_shm.
> 
> Thanks for the great work on windbus, keep it up :)
> 
thx - I've applied the patch to trunk.
trunk is synced with 1.2.12 and contains a fix to allow to use a random
tcp port for the dbus-daemon. It's also the default now.

Christian

Hi.

If, for some reason, dbus-daemon.exe fails to launch, 
_dbus_get_autolaunch_address will get stuck in an endless loop when it 
calls _dbus_get_autolaunch_shm. The daemon may fail to launch due to 
missing DLLs, wrong file permissions; a myriad of reasons over which we 
have no control.

The attached patch makes the following changes:
If launching for some reason fails, set an error message. I'm not sure 
how to do this correctly, so it probably needs changing.
_dbus_get_autolaunch_shm will abort getting the shared memory after 20 
attempts (2 seconds).
_dbus_get_autolaunch_address checks if the return state of 
WaitForInputIdle before calling _dbus_get_autolaunch_shm.

Thanks for the great work on windbus, keep it up :)

Best Regards,
Thorvald Natvig

[I'm cross-posting this to the dbus & windbus mailing lists because
I'm not sure what the status of dbus/windbus integration is at the
moment]

Fedora are currently sponsoring a project to package the MinGW
cross-compiler and a selection of libraries.  The idea is that you can
build and test Windows software without needing to use Windows at all;
and you can continue using ordinary Unix build systems (autoconf,
make, etc).  More about that here: http://fedoraproject.org/wiki/MinGW

As a result I've packaged up dbus, since it's a significant dependency
for many desktop programs.  I started with windbus, since that seems
to be the "official" port of dbus to Windows (AIUI).

Windbus seems to prefer to use cmake.  To make windbus build using the
ordinary dbus build system (automake etc), I needed this patch:

http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=c88f6f7675ccbd5042087b5a45b0ef51cc9f2c5b;path=/dbus/

  mingw32-dbus-1.2.4-20081031-mingw32.patch
    - patch against recent SVN windbus for building C dbus library

  mingw32-dbus.spec
    - RPM spec file (ie. build instructions)

  mingw32-dbus-1.2.4-20081031-c++-mingw32.patch
    - nearly-working patch for dbuscxx, you can ignore this for now

The C library patch isn't really great at the moment.  In particular I
just removed unneeded Unix source files.  A better way is to include
both Unix and Win source files and make sure each source file is
defended by either #ifdef WIN32 .. #endif or #ifndef WIN32 .. #endif
as appropriate.  If that work were done, then this patch stands a good
chance of building correctly on both Unix and Windows systems.

So my questions:

(1) Is windbus the 'official' Win port?

(2) What are the plans for finally integrating windbus into main dbus
code?

(3) Is a cross-compilation approach better for the Unix developers?

(4) Are the Unix dbus developers interested in using a reworked,
correct version of the above patch, and continuing development of it
using a cross-compiler (not needing Windows to build or test)?  In
general terms, all you need to do from your Linux system is:

  ./configure --host=i686-pc-mingw32 ; make
  wine ./bus/dbus-daemon.exe

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

Frank Osterfeld schrieb:
> Hi,
> 
> this patches is needed for cross-compiling windbus from linux using mingw, as 
> case matters on unix. 
> 
> Cross-compilation using cmake 2.6 works in principle, but right now it needs 
> some modifications in dbus-sysdeps-win.c to avoid linking errors regarding  
> freeaddrinfo, getaddrinfo and especially gai_strerror. I'll send the patch 
> when I cleaned that up. (config checks, basically).
> 
> Regards,
applied, thx

Christian

Hi,

this patches is needed for cross-compiling windbus from linux using mingw, as 
case matters on unix. 

Cross-compilation using cmake 2.6 works in principle, but right now it needs 
some modifications in dbus-sysdeps-win.c to avoid linking errors regarding  
freeaddrinfo, getaddrinfo and especially gai_strerror. I'll send the patch 
when I cleaned that up. (config checks, basically).

Regards,

-- 
Frank Osterfeld -- fr...@kd...
Klarälvdalens Datakonsult AB, Platform-independent software solutions

S S schrieb:
> My environment :
> MinGW5.1
> win32libs
> cmake2.6
> 
> I got the latest sources from the head of svn repository and have been able
> to use cmake gui to past the configuration.
> However, when I go to the next step and execute mingw32-make in the build
> directory I get the following errors (below)
> Any pointers on what I am missing out?
> 
I've fixed it with a hack - you need wspiapi.h from ms platform sdk.
The problem is (the well known) getaddrinfo-problem. It's only available 
in wxpsp2 and up. For w2k ms added a wrapper to call some internal 
functions.
The real solution would be to try to resolve 
getaddrinfo/getnameinfo/freeaddrinfo on runtime and if it's not 
possible, emulate them with getnameinfo() & co. Maybe we can switch to 
getnameinfo() completly because we don't need IPv6 at all (really).


Any comments? Oliver do you have some time?
Christian

My environment :
MinGW5.1
win32libs
cmake2.6

I got the latest sources from the head of svn repository and have been able
to use cmake gui to past the configuration.
However, when I go to the next step and execute mingw32-make in the build
directory I get the following errors (below)
Any pointers on what I am missing out?

Any help appreciated.
-SS

C:\WinDBusDownloads\svncvs>cd dbus-build
C:\WinDBusDownloads\svncvs\dbus-build>mingw32-make
Linking C shared library ..\bin\libdbus-1.dll
Creating library file: ..\bin\libdbus-1.dll.a
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_read_socket':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:305: undefined reference
to `
recv@16'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:309: undefined reference
to `
WSAGetLastError@0'
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_write_socket':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:365: undefined reference
to `
send@16'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:369: undefined reference
to `
WSAGetLastError@0'
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_close_socket':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:402: undefined reference
to `
closesocket@4'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:404: undefined reference
to `
WSAGetLastError@0'
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_set_fd_nonblocking':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:471: undefined reference
to `
ioctlsocket@12'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:473: undefined reference
to `
WSAGetLastError@0'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:473: undefined reference
to `
WSAGetLastError@0'
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_write_socket_two':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:545: undefined reference
to `
WSASend@28'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:555: undefined reference
to `
WSAGetLastError@0'
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_win_startup_winsock':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:605: undefined reference
to `
WSAStartup@8'
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_full_duplex_pipe':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:964: undefined reference
to `
socket@12'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:967: undefined reference
to `
WSAGetLastError@0'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:972: undefined reference
to `
ioctlsocket@12'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:974: undefined reference
to `
WSAGetLastError@0'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:981: undefined reference
to `
htonl@4'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:983: undefined reference
to `
bind@12'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:985: undefined reference
to `
WSAGetLastError@0'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:989: undefined reference
to `
listen@8'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:991: undefined reference
to `
WSAGetLastError@0'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:996: undefined reference
to `
getsockname@12'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:998: undefined reference
to `
WSAGetLastError@0'
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1002: undefined reference
to
`socket@12' <%60socket@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1005: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1010: undefined reference
to
`ioctlsocket@12' <%60ioctlsocket@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1012: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1016: undefined reference
to
`connect@12' <%60connect@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1016: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1019: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1029: undefined reference
to
`select@20' <%60select@20'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1031: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1035: undefined reference
to
`__WSAFDIsSet@8' <%60__WSAFDIsSet@8'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1037: undefined reference
to
`accept@12' <%60accept@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1040: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1050: undefined reference
to
`select@20' <%60select@20'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1052: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1056: undefined reference
to
`__WSAFDIsSet@8' <%60__WSAFDIsSet@8'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1061: undefined reference
to
`ioctlsocket@12' <%60ioctlsocket@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1063: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1068: undefined reference
to
`ioctlsocket@12' <%60ioctlsocket@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1070: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1077: undefined reference
to
`ioctlsocket@12' <%60ioctlsocket@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1079: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1090: undefined reference
to
`closesocket@4' <%60closesocket@4'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1095: undefined reference
to
`closesocket@4' <%60closesocket@4'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1097: undefined reference
to
`closesocket@4' <%60closesocket@4'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1099: undefined reference
to
`closesocket@4' <%60closesocket@4'>
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_poll':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1332: undefined reference
to
`select@20' <%60select@20'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1337: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1354: undefined reference
to
`__WSAFDIsSet@8' <%60__WSAFDIsSet@8'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1357: undefined reference
to
`__WSAFDIsSet@8' <%60__WSAFDIsSet@8'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1360: undefined reference
to
`__WSAFDIsSet@8' <%60__WSAFDIsSet@8'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1373: undefined reference
to
`__WSAFDIsSet@8' <%60__WSAFDIsSet@8'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1376: undefined reference
to
`__WSAFDIsSet@8' <%60__WSAFDIsSet@8'>
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:C:/Wi
nDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1379: more undefined
references to
 `__WSAFDIsSet@8' <%60__WSAFDIsSet@8'> follow
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_connect_tcp_socket':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1469: undefined reference
to
`socket@12' <%60socket@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1473: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1514: undefined reference
to
`closesocket@4' <%60closesocket@4'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1521: undefined reference
to
`socket@12' <%60socket@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1532: undefined reference
to
`connect@12' <%60connect@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1534: undefined reference
to
`closesocket@4' <%60closesocket@4'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1556: undefined reference
to
`closesocket@4' <%60closesocket@4'>
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_listen_tcp_socket':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1639: undefined reference
to
`socket@12' <%60socket@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1649: undefined reference
to
`bind@12' <%60bind@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1651: undefined reference
to
`closesocket@4' <%60closesocket@4'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1658: undefined reference
to
`listen@8' <%60listen@8'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1660: undefined reference
to
`closesocket@4' <%60closesocket@4'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1670: undefined reference
to
`closesocket@4' <%60closesocket@4'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1693: undefined reference
to
`getsockname@12' <%60getsockname@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1758: undefined reference
to
`closesocket@4' <%60closesocket@4'>
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-sysdeps-win.obj:
In f
unction `dbus_accept':
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1777: undefined reference
to
`accept@12' <%60accept@12'>
C:/WinDBusDownloads/svncvs/dbus/dbus-sysdeps-win.c:1781: undefined reference
to
`WSAGetLastError@0' <%60WSAGetLastError@0'>
CMakeFiles\dbus-1.dir\C_\WinDBusDownloads\svncvs\dbus\dbus-spawn-win.obj: In
fun
ction `babysitter':
C:/WinDBusDownloads/svncvs/dbus/dbus-spawn-win.c:529: undefined reference to
`se
nd@16'
mingw32-make[2]: *** [bin/libdbus-1.dll] Error 1
mingw32-make[1]: *** [dbus/CMakeFiles/dbus-1.dir/all] Error 2
mingw32-make: *** [all] Error 2
C:\WinDBusDownloads\svncvs\dbus-build>

Thorvald Natvig schrieb:
> Fixes a small logical bug. It's been sitting in my repository for ages, 
> so I'm not sure if it still causes dbus to crash.. but it used to.
> 
thx, applied


Christian

Hi,

I've had a few users ask why there is a leftover dbus-daemon.exe after 
they quit my application. Is there a way to have the automatically 
spawned dbus-daemon quit on it's own if there are no more connected clients?

Sincerely,
Thorvald Natvig

Fixes a small logical bug. It's been sitting in my repository for ages, 
so I'm not sure if it still causes dbus to crash.. but it used to.

Hi,

What's the correct procedure for submitting patches for the Win32 stuff 
of dbus these days? Should it be sent here or to the main dbus list?

Best regards,
Thorvald Natvig

>  update to 1.1.2 - don't know if it compiles, cmake scripts are not updated yet

It may help to use the patch I submitted to the D-Bus ML a couple of weeks ago:
http://lists.freedesktop.org/archives/dbus/2008-January/009174.html

Olivier