windbus-devel — Development list

Re: cmake error with patched trunk

[Peter K. <syn...@gm...>]

Marcos Pinto wrote:
> I've patched trunk, which went fine with no errors.  However, when I
> try to run cmake, it fails with the following.  Any help is greatly
> appreciated.  Thanks!
> 
> Determining if the C compiler works failed with the following output:
> 
> Microsoft (R) Development Environment  Version 7.10.6030.
> Copyright (C) Microsoft Corp 1984-2001. All rights reserved.
> ------ Build started: Project: cmTryCompileExec, Configuration: Debug
> Win32 ------
> 
> Compiling...
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
> cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D
> "CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /FD /RTCs /MDd /GS
> /Fo"cmTryCompileExec.dir\Debug\\" /Fd"C:/Documents and
> Settings/James/Desktop/windbus-build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.pdb"
> /W3 /c /Zi /TC   /Zm1000
>    ".\testCCompiler.c"
> testCCompiler.c
> Linking...
> link.exe: missing operand after `@c:\\Documents and
> Settings\\James\\Desktop\\windbus-build\\CMakeFiles\\CMakeTmp\\cmTryCompileExec.dir\\Debug\\RSP000002.rsp'
> Try `link.exe --help' for more information.
> cmTryCompileExec : error PRJ0002 : error result returned from 'link.exe'.
> 
> Build log was saved at "file://c:\Documents and
> Settings\James\Desktop\windbus-build\CMakeFiles\CMakeTmp\cmTryCompileExec.dir\Debug\BuildLog.htm"
> cmTryCompileExec - 1 error(s), 0 warning(s)
> 

Maybe the spaces in your path to windbus-build are responsible for the trouble.

Peter

Re: cmake error with patched trunk

[Christian E. <Ch....@gm...>]

Marcos Pinto schrieb:
> 2.4.8 with VC 7.1.  You?  Which version of VC?  Know the SVN revision?
> Thanks
> 
2.4.8, same svn version (nobody checked something in since then afaik) 
and vc8.
Did you have a properly set up build environment (vsvars32.bat)?

This is more a generic cmake error than some error inside the cmake 
scripts in windbus. Try to create an own cmake project with just one 
source and see if you get the same error - if so ask cmake ml.


Christian

Re: cmake error with patched trunk

[Marcos P. <mar...@gm...>]

2.4.8 with VC 7.1.  You?  Which version of VC?  Know the SVN revision?
Thanks

On Feb 8, 2008 5:24 PM, Christian Ehrlicher <Ch....@gm...> wrote:
> Marcos Pinto schrieb:
> > I've patched trunk, which went fine with no errors.  However, when I
> > try to run cmake, it fails with the following.  Any help is greatly
> > appreciated.  Thanks!
> >
> What cmake version do you have?
> Worked fine for me here ->
> http://download.cegit.de/kde-windows/repository/win32libs/single/
>
>
> Christian
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Windbus-devel mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/windbus-devel
>

Re: cmake error with patched trunk

[Christian E. <Ch....@gm...>]

Marcos Pinto schrieb:
> I've patched trunk, which went fine with no errors.  However, when I
> try to run cmake, it fails with the following.  Any help is greatly
> appreciated.  Thanks!
> 
What cmake version do you have?
Worked fine for me here -> 
http://download.cegit.de/kde-windows/repository/win32libs/single/


Christian

cmake error with patched trunk

[Marcos P. <mar...@gm...>]

I've patched trunk, which went fine with no errors.  However, when I
try to run cmake, it fails with the following.  Any help is greatly
appreciated.  Thanks!

Determining if the C compiler works failed with the following output:

Microsoft (R) Development Environment  Version 7.10.6030.
Copyright (C) Microsoft Corp 1984-2001. All rights reserved.
------ Build started: Project: cmTryCompileExec, Configuration: Debug
Win32 ------

Compiling...
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D
"CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /FD /RTCs /MDd /GS
/Fo"cmTryCompileExec.dir\Debug\\" /Fd"C:/Documents and
Settings/James/Desktop/windbus-build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.pdb"
/W3 /c /Zi /TC   /Zm1000
   ".\testCCompiler.c"
testCCompiler.c
Linking...
link.exe: missing operand after `@c:\\Documents and
Settings\\James\\Desktop\\windbus-build\\CMakeFiles\\CMakeTmp\\cmTryCompileExec.dir\\Debug\\RSP000002.rsp'
Try `link.exe --help' for more information.
cmTryCompileExec : error PRJ0002 : error result returned from 'link.exe'.

Build log was saved at "file://c:\Documents and
Settings\James\Desktop\windbus-build\CMakeFiles\CMakeTmp\cmTryCompileExec.dir\Debug\BuildLog.htm"
cmTryCompileExec - 1 error(s), 0 warning(s)


---------------------- Done ----------------------

    Build: 0 succeeded, 1 failed, 0 skipped

dbus-python

[Marcos P. <mar...@gm...>]

I've built and installed windbus from source, but I havent figured out
how to build dbus-python in Windows.  Does anyone have any tips on
this or have binaries for it?
Thanks,
Marcos

Re: [ANNOUNCE] D-Bus 1.1.4 (1.2.0RC2) - "Opps, I did it again" released

[<syn...@gm...>]

Olivier Hochreutiner wrote:
>> Depends on the Windows port maintainers.  A decision was made not to
>> wait for them as the UNIX port needs the system activation feature to
>> support a lot of the future Linux infrastructure.  Under Linux D-Bus is
>> a vital part of the core system.  That is not to say I wouldn't release
>> a 1.2.1 just for windows support but we are not going to block on it.
>> If the Windows port ever stabilizes we would be happy to coordinate
>> releases.
> 
> I see. Actually my point was to have a 1.2.0 version that at least
> compiles under Windows, but I guess making a version 1.2.1 is fine
> too. This way there should be more time to test and polish things.
> BTW, Peter, Ralf, is there a TODO list for the Windows port ?
> 
> Olivier

Hi Oliver,

the status is as follows:

In sourceforge's /windbus/trunk is the last working version
of windbus, with the last update to the official code at July 2005:
http://windbus.svn.sourceforge.net/viewvc/windbus/trunk/CVS/?view=log&pathrev=724

Now it has some new patches (cvs diff) which are maybe already upstream.

Additional to the file dbus-win.patch which is part of git-dbus, there is the
file DBus-win32.patch which is also needed to have a running win port.
But maybe you know all this stuff.


In windbus/branches/sync is the attempt to update the code
to the cvs-dbus from Aug 11. 2007:
http://windbus.svn.sourceforge.net/viewvc/windbus?view=rev&revision=744

We have not managed it to make this upgrade work. Mainly because of some
new stuff in the cvs code.


Currently there is no TODO list, but following is TO DO ;)

- Patch the actual freedesktop-dbus code with dbus-win.patch, DBus-win32.patch,
   cvs diff in trunk, and maybe some patches from /branches/sync; and get all
   tests working
- replace the CVS code in our svn with git, or create somewhere a git repo with
   a win32 branch (e.g. branch on freedesktop's git or at repo.or.cz)


I think ATM it is more important to have working patches somewhere (dbus-win.patch,
svn, git branch, ore alternative repository git) than to get all our patches upstream.

I don't know if your posted patch is enough, but when you could run all the tests
successfully then I think it is good enough. If not, you could have a look at
all the other patches and check, if they are still needed or are obsolete now.

Cheers,
Peter

Re: [ANNOUNCE] D-Bus 1.1.4 (1.2.0RC2) - "Opps, I did it again" released

[Ralf H. <ral...@fr...>]

Olivier Hochreutiner schrieb:
>> Depends on the Windows port maintainers.  A decision was made not to
>> wait for them as the UNIX port needs the system activation feature to
>> support a lot of the future Linux infrastructure.  Under Linux D-Bus is
>> a vital part of the core system.  That is not to say I wouldn't release
>> a 1.2.1 just for windows support but we are not going to block on it.
>> If the Windows port ever stabilizes we would be happy to coordinate
>> releases.
>>     
>
> I see. Actually my point was to have a 1.2.0 version that at least
> compiles under Windows, but I guess making a version 1.2.1 is fine
> too. This way there should be more time to test and polish things.
> BTW, Peter, Ralf, is there a TODO list for the Windows port ?
>   
some todo's are listed here 
http://windbus.svn.sourceforge.net/viewvc/windbus/trunk/README.win?revision=611&view=markup 

and there are still some open patches 
http://windbus.svn.sourceforge.net/viewvc/windbus/trunk/dbus-win.patch?revision=642&view=markup

One additional issue raised in the meantime is that the code does not 
have any import/export decorations, which is required to build a shared 
dbus library with msvc.
Currently a def file 
http://windbus.svn.sourceforge.net/viewvc/windbus/trunk/cmake/dbus/dbus-1.def.cmake?revision=743&view=markup 
is used for linking.

It may also be that the dbus git and the windbus svn are out sync. It 
will be probably required to update the win32 related stuff from the 
windbus svn.

Ralf

Re: [ANNOUNCE] D-Bus 1.1.4 (1.2.0RC2) - "Opps, I did it again" released

[Ralf H. <ral...@fr...>]

Olivier Hochreutiner schrieb:
> Hi there,
>
> Before releasing 1.2.0 I propose to fix the Windows port so that it
> builds and somehow work. For now it doesn't even build.
>   
I had synced dbus cvs sources from time to time from the sourceforge 
windbus sources. This account seems to be lost with the git move.

Ralf

Re: [ANNOUNCE] D-Bus 1.1.4 (1.2.0RC2) - "Opps, I did it again" released

[Olivier H. <oli...@gm...>]

> Depends on the Windows port maintainers.  A decision was made not to
> wait for them as the UNIX port needs the system activation feature to
> support a lot of the future Linux infrastructure.  Under Linux D-Bus is
> a vital part of the core system.  That is not to say I wouldn't release
> a 1.2.1 just for windows support but we are not going to block on it.
> If the Windows port ever stabilizes we would be happy to coordinate
> releases.

I see. Actually my point was to have a 1.2.0 version that at least
compiles under Windows, but I guess making a version 1.2.1 is fine
too. This way there should be more time to test and polish things.
BTW, Peter, Ralf, is there a TODO list for the Windows port ?

Olivier

Re: [ANNOUNCE] D-Bus 1.1.4 (1.2.0RC2) - "Opps, I did it again" released

[Olivier H. <oli...@gm...>]

Hi there,

Before releasing 1.2.0 I propose to fix the Windows port so that it
builds and somehow work. For now it doesn't even build.
So ... here is a patch to fix the build.
I tested it a bit I did not found any problem, but I did not run the
test suite, though.

The changes are the following:

* Updated version to 1.1.4
* Small fixes in CMakeLists.txt
* Modified _dbus_connect_tcp_socket() and _dbus_listen_tcp_socket() in
dbus-sysdeps-win.c to match their declarations in dbus-sysdeps.h. In
principle IPv6 should work, but I did not test it.
* Copied and adapted unix version of  _dbus_write_pid_to_file_and_pipe()
* Added missing _dbus_babysitter_get_child_exit_status()
* Fixed a problem under Windows Vista in _dbus_accept() preventing
dbus-daemon to accept incoming connections and using 100% of CPU.
* Added missing _dbus_get_standard_system_servicedirs(). The function
returns nothing as suggested in comments.

The above changes do not affect the unix code so I believe they can be
applied safely. Is it possible to include it in 1.2.0 ?

Best,

Olivier Hochreutiner

Re: Threading problems in WinDBus

[<syn...@gm...>]

Olivier Hochreutiner wrote:
> Hi!
> 
> As you can see I am still working on D-Bus when I have time :-) and I
> am having problems with the win32 version of WinDBus.
> The problem can be easily reproduced with the echo-server example of
> the c++ binding.
> Just building it and using the "echo-client" program attached allows
> to reproduce the problem.
> 
> Every time there is one of the following 4 asserts in the client (but
> maybe others can happen ?):
> 
> ----------SNIP----------
> assertion failed "connection->io_path_acquired" file
> "..\..\branches\patched\dbus\dbus-connection.c" line 1082 function
> _dbus_connection_release_io_path
> 
> assertion failed "!(connection)->have_connection_lock" file
> "..\..\branches\patched\dbus\dbus-connection.c" line 351 function
> _dbus_connection_lock
> 
> assertion failed "(connection)->have_connection_lock" file
> "..\..\branches\patched\dbus\dbus-connection.c" line 362 function
> _dbus_connection_unlock
> 
> assertion failed "!(connection)->have_connection_lock" file
> "..\..\branches\patched\dbus\dbus-connection.c" line 2188 function
> check_for_reply_and_update_dispatch_unlocked
> ----------SNIP----------
> 
> Note that the function DBus::_init_threading_default() at the
> beginning is just a wrapper to dbus_threads_init_default().
> I didn't have this situation under WinCE so I tried to build the WinCE
> version for Win32 but the problem is the same. I also tried an older
> version from SVN (revision 609 from may 14th) without success.
> I tried to investigate the bug further but I think I am not familiar
> enough with D-Bus internals... What I can say is that it seems to be a
> thread/lock problem (as suggested by the asserts ...)
> 
> Having no linux box where I can try, I did not try under that OS.
> 
> Any clue of what it can be ?
> 
> Thanks,
> 
> Olivier
> 

I couldn't build your example code, which dbus-c++ version do you use?

Peter

Re: Threading problems in WinDBus

[Havoc P. <hp...@re...>]

If you send along a backtrace (one with function names, i.e. with debug 
info available) from the crash it might be revealing.

Another thing to try is just see if the same bug exists on unix so you 
know whether it's a Windows-specific issue.

Havoc

Re: Threading problems in WinDBus

[Olivier H. <oli...@gm...>]

After a try on Debian 4.0, the same problem exist in the linux distro of D-Bus.


2007/7/6, Olivier Hochreutiner <oli...@gm...>:
> Hi!
>
> As you can see I am still working on D-Bus when I have time :-) and I
> am having problems with the win32 version of WinDBus.
> The problem can be easily reproduced with the echo-server example of
> the c++ binding.
> Just building it and using the "echo-client" program attached allows
> to reproduce the problem.
>
> Every time there is one of the following 4 asserts in the client (but
> maybe others can happen ?):
>
> ----------SNIP----------
> assertion failed "connection->io_path_acquired" file
> "..\..\branches\patched\dbus\dbus-connection.c" line 1082 function
> _dbus_connection_release_io_path
>
> assertion failed "!(connection)->have_connection_lock" file
> "..\..\branches\patched\dbus\dbus-connection.c" line 351 function
> _dbus_connection_lock
>
> assertion failed "(connection)->have_connection_lock" file
> "..\..\branches\patched\dbus\dbus-connection.c" line 362 function
> _dbus_connection_unlock
>
> assertion failed "!(connection)->have_connection_lock" file
> "..\..\branches\patched\dbus\dbus-connection.c" line 2188 function
> check_for_reply_and_update_dispatch_unlocked
> ----------SNIP----------
>
> Note that the function DBus::_init_threading_default() at the
> beginning is just a wrapper to dbus_threads_init_default().
> I didn't have this situation under WinCE so I tried to build the WinCE
> version for Win32 but the problem is the same. I also tried an older
> version from SVN (revision 609 from may 14th) without success.
> I tried to investigate the bug further but I think I am not familiar
> enough with D-Bus internals... What I can say is that it seems to be a
> thread/lock problem (as suggested by the asserts ...)
>
> Having no linux box where I can try, I did not try under that OS.
>
> Any clue of what it can be ?
>
> Thanks,
>
> Olivier
>
>

Threading problems in WinDBus

[Olivier H. <oli...@gm...>]

Hi!

As you can see I am still working on D-Bus when I have time :-) and I
am having problems with the win32 version of WinDBus.
The problem can be easily reproduced with the echo-server example of
the c++ binding.
Just building it and using the "echo-client" program attached allows
to reproduce the problem.

Every time there is one of the following 4 asserts in the client (but
maybe others can happen ?):

----------SNIP----------
assertion failed "connection->io_path_acquired" file
"..\..\branches\patched\dbus\dbus-connection.c" line 1082 function
_dbus_connection_release_io_path

assertion failed "!(connection)->have_connection_lock" file
"..\..\branches\patched\dbus\dbus-connection.c" line 351 function
_dbus_connection_lock

assertion failed "(connection)->have_connection_lock" file
"..\..\branches\patched\dbus\dbus-connection.c" line 362 function
_dbus_connection_unlock

assertion failed "!(connection)->have_connection_lock" file
"..\..\branches\patched\dbus\dbus-connection.c" line 2188 function
check_for_reply_and_update_dispatch_unlocked
----------SNIP----------

Note that the function DBus::_init_threading_default() at the
beginning is just a wrapper to dbus_threads_init_default().
I didn't have this situation under WinCE so I tried to build the WinCE
version for Win32 but the problem is the same. I also tried an older
version from SVN (revision 609 from may 14th) without success.
I tried to investigate the bug further but I think I am not familiar
enough with D-Bus internals... What I can say is that it seems to be a
thread/lock problem (as suggested by the asserts ...)

Having no linux box where I can try, I did not try under that OS.

Any clue of what it can be ?

Thanks,

Olivier

Re: Evaluating Qt 4.3: IPC support - QtDBus?

[Christian E. <Ch....@gm...>]

Von: "Brown, Richard"
> All,
<snip>
> 
> So much for the background - here's the thing:  The only IPC mechanism
> for passing data around appears to be the QtDBus.  I've seen where
> others have said its not supported in Windows, or perhaps is... but you
> need to do some "tweaking" to get it to work.  Anybody know the story on
> this?   
> 
Hi,

There is a ongoing windows port (because kde4 uses dbus for it's ipc too, sse sf.net/projects/windbus) but we've problems to get our patches into the mainline dbus cvs because the maintainer doesn't like how we define platform independency (or the other way round...).
For now we can say that it's working but needs some more love to fix the outstanding issues which are mostly
a) user authentification
b) the underlaying transport mechanism (currently using tcp/ip but shm or pipes should be more safe and faster)

But what I can say is, that those problems will be fixed in the next few months and that there will be a working qdbus on windows. :-)
> Any problems I should look for when trying to build my test application
> (developed under the Windows release) over on our Linux box using the
> Linux based Qt?
> 
> Thanks!
> 
If you're interested in helping us with windbus, join dbus and windbus or kde-windows mailing list  :-)

Christian Ehrlicher
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: WinDBus CE port state

[Ralf H. <ral...@fr...>]

Olivier Hochreutiner schrieb:
> Dear all,
>
> After being silent for some time, I have some good news! D-Bus is now
> working pretty good under Windows CE and the first version of the
> application we are developping is out! Unfortunately due to a weird
> decision of my company's management, I cannot give more details about
> it, but anyway, it's working!
>   
nice to hear :-)
> Now before committing all the changes to windbus SVN, I have a couple
> of points that should be discussed:
>
>   
<snip>
> 3) The fact that there is no "current directory" or %PATH% under WinCE
> creates some problems too, for two reasons: (a) for the autolaunch to
> work dbus-daemon.exe should be placed in \Windows or \ (when launching
> an EXE under WinCE without specifying its path, these are the only two
> locations where it looks for it); 
> (b) the path to the config file
> cannot be relative (e.g. "etc\session.conf") but absolute; 
Is on wince a function like GetModuleFileName available ? Then you can
create absolutes pathes relative to the dbus-daemon executable see  and
example on http://lists.freedesktop.org/archives/dbus/2007-May/007797.html

Ralf

Re: WinDBus CE port state

[<syn...@gm...>]

Olivier Hochreutiner wrote:
> Dear all,
> 
> After being silent for some time, I have some good news! D-Bus is now
> working pretty good under Windows CE and the first version of the
> application we are developping is out! Unfortunately due to a weird
> decision of my company's management, I cannot give more details about
> it, but anyway, it's working!

Good to hear, and if you are allowed to commit the patches it isn't
that hard not knowing what you company has shipped. ;)

> 
> Now before committing all the changes to windbus SVN, I have a couple
> of points that should be discussed:

I've copied the current trunk with your ce changes to branches/wince,
there you could commit all your changes.

> 
> 1) To allow an application running on PC (e.g. dbus-monitor) to
> connect on a bus working on a PocketPC through Wifi or an USB cable, I
> had to do two hacks that should be discussed/modified:
>     (a) I added an "ANONYMOUS" authentication mechanism in dbus-auth.c
> because the other mechanisms could not work for obvious reasons.
> Should we keep it under WinCE ? Implement a new auth mechanism that
> would work in this situation ?

We have still to fix the current auth mechanism for getting it into cvs.
So it is very interesting to see how you've managed to create a new one.

>     (b) I added the ability to specify in session.conf that the daemon
> should listen on every network interfaces and not only the loopback
> one; for this purpose the address specified in the <listen> entry can
> have its host set to * (star, for "any") but as it is a character that
> must be escaped, it should actually be set to %2A (2A being the ascii
> code for *), so we have something like:
> 
> <listen>tcp:host=%2A,port=12434</listen>
> 
>     I know this is ugly (some would say evil :-) and should be done
> some way else, so suggestions are welcome.

Why do you not just use "any" for the host name?

> 
> 2) When the bus daemon is automatically launched by a client, the
> Win32 port used WaitForInputIdle() to wait that the bus daemon is
> ready, but it does not exist under WinCE. As a workaround for now I
> use a Windows Event (i.e. CreateEvent(), SetEvent(), etc) that is set
> by the bus daemon and that the client waits for. Is this acceptable ?
> Any better solution ?
> 
> 3) The fact that there is no "current directory" or %PATH% under WinCE
> creates some problems too, for two reasons: (a) for the autolaunch to
> work dbus-daemon.exe should be placed in \Windows or \ (when launching
> an EXE under WinCE without specifying its path, these are the only two
> locations where it looks for it); (b) the path to the config file
> cannot be relative (e.g. "etc\session.conf") but absolute; it can be
> set in config.h to e.g. "\Windows\session.conf" so that the --session
> option (and thus autolaunch) works.

a) isn't that a problem of installing dbus
b) Why not using the macro for wince?
> 
> 4) I did not update the cmake script for WinCE and I actually build
> WinDBus for WinCE with a standard VS2005 vcproj/sln because it is
> quite painful to have to manually recreate the WinCE platform from the
> Win32 one every time I rerun cmake. The best thing would be to add the
> support for the WinCE platform to cmake (I might do it some time...).
> Till this is done should I commit the VS2005 project too ?

Yes, check them in, I will see if it is possible to fix the cmake files.


Really good news!

Peter

WinDBus CE port state

[Olivier H. <oli...@gm...>]

Dear all,

After being silent for some time, I have some good news! D-Bus is now
working pretty good under Windows CE and the first version of the
application we are developping is out! Unfortunately due to a weird
decision of my company's management, I cannot give more details about
it, but anyway, it's working!

Now before committing all the changes to windbus SVN, I have a couple
of points that should be discussed:

1) To allow an application running on PC (e.g. dbus-monitor) to
connect on a bus working on a PocketPC through Wifi or an USB cable, I
had to do two hacks that should be discussed/modified:
    (a) I added an "ANONYMOUS" authentication mechanism in dbus-auth.c
because the other mechanisms could not work for obvious reasons.
Should we keep it under WinCE ? Implement a new auth mechanism that
would work in this situation ?
    (b) I added the ability to specify in session.conf that the daemon
should listen on every network interfaces and not only the loopback
one; for this purpose the address specified in the <listen> entry can
have its host set to * (star, for "any") but as it is a character that
must be escaped, it should actually be set to %2A (2A being the ascii
code for *), so we have something like:

<listen>tcp:host=%2A,port=12434</listen>

    I know this is ugly (some would say evil :-) and should be done
some way else, so suggestions are welcome.

2) When the bus daemon is automatically launched by a client, the
Win32 port used WaitForInputIdle() to wait that the bus daemon is
ready, but it does not exist under WinCE. As a workaround for now I
use a Windows Event (i.e. CreateEvent(), SetEvent(), etc) that is set
by the bus daemon and that the client waits for. Is this acceptable ?
Any better solution ?

3) The fact that there is no "current directory" or %PATH% under WinCE
creates some problems too, for two reasons: (a) for the autolaunch to
work dbus-daemon.exe should be placed in \Windows or \ (when launching
an EXE under WinCE without specifying its path, these are the only two
locations where it looks for it); (b) the path to the config file
cannot be relative (e.g. "etc\session.conf") but absolute; it can be
set in config.h to e.g. "\Windows\session.conf" so that the --session
option (and thus autolaunch) works.

4) I did not update the cmake script for WinCE and I actually build
WinDBus for WinCE with a standard VS2005 vcproj/sln because it is
quite painful to have to manually recreate the WinCE platform from the
Win32 one every time I rerun cmake. The best thing would be to add the
support for the WinCE platform to cmake (I might do it some time...).
Till this is done should I commit the VS2005 project too ?

Best,

Olivier

Re: State of WinDBus

[<syn...@gm...>]

Olivier Hochreutiner wrote:
> Hi,
> 
> I was not very talkative these days, but I've got good news: WinDBus
> is running under WinCE! I was able to compile dbus-c++ too, and run

Great news!

> several small test apps. I did not commit to svn yet because I have to
> clean things up first, and there are some problems with cmake:
> actually since we only have a pseudo-wince cmakefile it is quite
> unpractical to work with it. The best thing to do would be to add
> WinCE platform to cmake but I would probably take some time. For now I
> have a "fork" of the sources with non-cmake VS2005 project files. What
> do you think we should do ?

So the cmake generated project files with the creation of new
configuration by the MSVC dialog doesn't fit your needs?
What is missing or unpractical? When it is not possible to solve
the problems within the cmake files, then--your are right--the best
would be to add project generators to cmake, I assume most would be
a copy and past of the MSVC2005 C++ code.


And here a new link which could be help full for more porting

http://www.rainer-keuchel.de/wince/celib.html

The base of newlib/wince:
http://sourceforge.net/mailarchive/forum.php?thread_name=46115589.6080903%40gmx.net&forum_name=cegcc-devel


> 
> I also want to modify dbus-monitor to be able to monitor a bus running
> on a pocket pc from a PC, through the USB cable. It is quite easy to
> achieve since the PC and the pocket pc both have a virtual network
> interface corresponding to the USB link. So I just have to tell
> dbus-monitor to connect to the pocket pc's ip address instead of
> localhost. As it gets the bus address through shared memory, I've
> thought of adding a cmdline parameter to dbus-monitor which allows the
> user to specify to bus address, in which case dbus-monitor creates the
> shared memory (dbus-daemon is not running on the PC so it does not
> exist yet) and writes the bus address to it. Then the dbus engine will
> open the shared memory and read the address as usual.
> There is also another issue, which is that there is no way to tell the
> daemon to listen to all the network interfaces, which will prevent
> dbus-monitor to connect remotely. In the bus config file there should
> be a way to write something like:
> <listen>tcp:host=*,port=12434</listen>
> or
> <listen>tcp:host=any,port=12434</listen>
> or even
> <listen>tcp:port=12434</listen>
> which instruct the bus daemon to listen to any interface, not only a
> specific one (currently localhost by default).
> 
> What do you think ?
> 
> Best
> 
> Olivier
> 


-- 
Peter Kümmel

Re: State of WinDBus

[Olivier H. <oli...@gm...>]

> I also want to modify dbus-monitor to be able to monitor a bus running
> on a pocket pc from a PC, through the USB cable. It is quite easy to
> achieve since the PC and the pocket pc both have a virtual network
> interface corresponding to the USB link. So I just have to tell
> dbus-monitor to connect to the pocket pc's ip address instead of
> localhost. As it gets the bus address through shared memory, I've
> thought of adding a cmdline parameter to dbus-monitor which allows the
> user to specify to bus address, in which case dbus-monitor creates the
> shared memory (dbus-daemon is not running on the PC so it does not
> exist yet) and writes the bus address to it. Then the dbus engine will
> open the shared memory and read the address as usual.

This totally sucks, please disregard it. I don't even need to modify
the code of dbus-monitor, but just to set the DBUS_SESSION_BUS_ADDRESS
environment variable. Monday morning's ideas are not often good ;-)

Olivier

Re: State of WinDBus

[Olivier H. <oli...@gm...>]

Hi,

I was not very talkative these days, but I've got good news: WinDBus
is running under WinCE! I was able to compile dbus-c++ too, and run
several small test apps. I did not commit to svn yet because I have to
clean things up first, and there are some problems with cmake:
actually since we only have a pseudo-wince cmakefile it is quite
unpractical to work with it. The best thing to do would be to add
WinCE platform to cmake but I would probably take some time. For now I
have a "fork" of the sources with non-cmake VS2005 project files. What
do you think we should do ?

I also want to modify dbus-monitor to be able to monitor a bus running
on a pocket pc from a PC, through the USB cable. It is quite easy to
achieve since the PC and the pocket pc both have a virtual network
interface corresponding to the USB link. So I just have to tell
dbus-monitor to connect to the pocket pc's ip address instead of
localhost. As it gets the bus address through shared memory, I've
thought of adding a cmdline parameter to dbus-monitor which allows the
user to specify to bus address, in which case dbus-monitor creates the
shared memory (dbus-daemon is not running on the PC so it does not
exist yet) and writes the bus address to it. Then the dbus engine will
open the shared memory and read the address as usual.
There is also another issue, which is that there is no way to tell the
daemon to listen to all the network interfaces, which will prevent
dbus-monitor to connect remotely. In the bus config file there should
be a way to write something like:
<listen>tcp:host=*,port=12434</listen>
or
<listen>tcp:host=any,port=12434</listen>
or even
<listen>tcp:port=12434</listen>
which instruct the bus daemon to listen to any interface, not only a
specific one (currently localhost by default).

What do you think ?

Best

Olivier

Re: State of WinDBus

[Ralf H. <ral...@fr...>]

Olivier Hochreutiner schrieb:
> Hi,
>
>> I don't know if it is better, but it more comfortable when changing the
>> -win files:
>> in svn we commit to all -win files. As before, all other changes have 
>> to go
>> into DBus-win32. From time to time Ralf could commit to cvs the cmake 
>> files and
>> the dbus-win.patch file. When we generate dbus-win.patch by diffing 
>> against cvs
>> we also have the CE changes in cvs, and by diffing against svn when 
>> generating
>> DBus-win32 we have all changes but the these of the -win files.
>>
>> By checking that svn always compiles under win32 and wince, and by 
>> updating from
>> time to time to the cvs status, the final merge wouldn't be so hard, 
>> as when we
>> start a completely branch, at least this is what I hope.
>
> I also think a new branch would make things more complicated. I'll pay
> more attention to win32 compilation problems after a wince
> modification (sorry about that :-/  ).
> For now I think this solution is fine, but we should work to have
> windbus merged with dbus as soon as possible to finally get rid of
> this DBus-win32 patch. 
Yes, I'm working on this :-)
> Have you finally agreed with Havoc about what
> should be changed to do the merge ? (I hope no one is gonna kick me
> for asking :)
partial, I'm in that process single patch by patch. The iteration is

1. Understand the code
2. create a patch
3. submit it into bugzilla.freedesktop.org
4. wait for a replay (sometime fast, sometimes slow)
5. update the patch and goto 3
6. commit patch into cvs  (i have dbus-cvs write access)


You can follow and/or participate to the ongoing discussion in 
http://lists.freedesktop.org/mailman/listinfo/dbus/
>
> One more thing: is dbus-sysdeps-win-thread.c still an exception, or is
> it again a "-win" file?
>
it is a -win file. Thanks for this pointer, i have update the name to 
avoid this problem in future.

Ralf

Re: State of WinDBus

[Olivier H. <oli...@gm...>]

Hi,

> I don't know if it is better, but it more comfortable when changing the
> -win files:
> in svn we commit to all -win files. As before, all other changes have to go
> into DBus-win32. From time to time Ralf could commit to cvs the cmake files and
> the dbus-win.patch file. When we generate dbus-win.patch by diffing against cvs
> we also have the CE changes in cvs, and by diffing against svn when generating
> DBus-win32 we have all changes but the these of the -win files.
>
> By checking that svn always compiles under win32 and wince, and by updating from
> time to time to the cvs status, the final merge wouldn't be so hard, as when we
> start a completely branch, at least this is what I hope.

I also think a new branch would make things more complicated. I'll pay
more attention to win32 compilation problems after a wince
modification (sorry about that :-/  ).
For now I think this solution is fine, but we should work to have
windbus merged with dbus as soon as possible to finally get rid of
this DBus-win32 patch. Have you finally agreed with Havoc about what
should be changed to do the merge ? (I hope no one is gonna kick me
for asking :)

One more thing: is dbus-sysdeps-win-thread.c still an exception, or is
it again a "-win" file?

Thanks,

Olivier

State of WinDBus

[<syn...@gm...>]

Don't get lost in the depths of the commit list.

http://sourceforge.net/mailarchive/forum.php?thread_id=31402726&forum_id=49112
http://sourceforge.net/mailarchive/forum.php?thread_id=31405300&forum_id=49112
http://sourceforge.net/mailarchive/forum.php?thread_id=31483625&forum_id=49112