Bug 27110 - Port DBus-Daemon to Windows CE
Summary: Port DBus-Daemon to Windows CE
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.3.x (devel)
Hardware: Other Windows (All)
: medium normal
Assignee: Ralf Habacker
QA Contact: John (J5) Palmieri
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-16 09:21 UTC by Marcus Brinkmann
Modified: 2010-06-12 11:34 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Convert windows port to use Windows API more consistently, in preparation of WinCE port. (51.48 KB, patch)
2010-03-16 09:22 UTC, Marcus Brinkmann
Details | Splinter Review
Make dependency on signal.h and locale.h optional (3.15 KB, patch)
2010-03-16 09:22 UTC, Marcus Brinkmann
Details | Splinter Review
Detect WinCE in configure (1.60 KB, patch)
2010-03-16 09:23 UTC, Marcus Brinkmann
Details | Splinter Review
Support WinCE throughout the code base. (33.20 KB, patch)
2010-03-16 09:23 UTC, Marcus Brinkmann
Details | Splinter Review
Work around CreateProcess discrepancy. (810 bytes, patch)
2010-03-16 09:23 UTC, Marcus Brinkmann
Details | Splinter Review
Port dbus-monitor to WinCE (814 bytes, patch)
2010-03-16 09:24 UTC, Marcus Brinkmann
Details | Splinter Review
Add README.wince (2.29 KB, patch)
2010-03-16 09:24 UTC, Marcus Brinkmann
Details | Splinter Review
Include a patched version of libtool for WinCE (533.03 KB, patch)
2010-03-16 09:25 UTC, Marcus Brinkmann
Details | Splinter Review
Port dbus launch to windows ce. (7.24 KB, patch)
2010-03-16 10:15 UTC, Marcus Brinkmann
Details | Splinter Review
UNICODE version of dbus-launch-win.c (5.35 KB, patch)
2010-03-19 06:58 UTC, Marcus Brinkmann
Details | Splinter Review
Convert windows port to use Windows API more consistently, in preparation of WinCE port. (REVISION 2) (52.06 KB, patch)
2010-04-12 17:30 UTC, Marcus Brinkmann
Details | Splinter Review
Detect WinCE in configure (1.60 KB, patch)
2010-04-12 17:31 UTC, Marcus Brinkmann
Details | Splinter Review
Support WinCE throughout the code base. (40.07 KB, patch)
2010-04-12 17:32 UTC, Marcus Brinkmann
Details | Splinter Review
Work around CreateProcess discrepancy. (810 bytes, patch)
2010-04-12 17:32 UTC, Marcus Brinkmann
Details | Splinter Review
Port dbus tools to windows ce. (6.79 KB, patch)
2010-04-12 17:33 UTC, Marcus Brinkmann
Details | Splinter Review
Add README.wince (3.26 KB, patch)
2010-04-12 17:34 UTC, Marcus Brinkmann
Details | Splinter Review
Add/Fix WinCE support in cmake files. (4.08 KB, patch)
2010-04-12 17:34 UTC, Marcus Brinkmann
Details | Splinter Review
Replace strtoll/strtoull for Windows CE. VARIATION 1/2 (10.91 KB, patch)
2010-04-12 17:35 UTC, Marcus Brinkmann
Details | Splinter Review
Replace strtoll/strtoull for Windows CE. VARIATION 2/2 (1.09 KB, patch)
2010-04-12 17:36 UTC, Marcus Brinkmann
Details | Splinter Review
Custom version of libtool for convenience of potential testers, DO NOT APPLY. (533.03 KB, patch)
2010-04-12 17:37 UTC, Marcus Brinkmann
Details | Splinter Review
Support WinCE throughout the code base. (40.07 KB, patch)
2010-04-12 17:52 UTC, Marcus Brinkmann
Details | Splinter Review
Add missing HAVE_ macros to cmake (3.32 KB, patch)
2010-04-13 08:21 UTC, Marcus Brinkmann
Details | Splinter Review
Include strtoll.c and strtoull.c in distribution (856 bytes, patch)
2010-04-13 18:28 UTC, Marcus Brinkmann
Details | Splinter Review
Remove obsolete files. (20.16 KB, patch)
2010-04-13 18:29 UTC, Marcus Brinkmann
Details | Splinter Review
Fix warnings on windows builds (2.41 KB, patch)
2010-04-13 18:30 UTC, Marcus Brinkmann
Details | Splinter Review
Fix warnings on windows ce builds (3.06 KB, patch)
2010-04-13 18:32 UTC, Marcus Brinkmann
Details | Splinter Review
Move definition of _WIN32_WCE to configure.in (1.25 KB, patch)
2010-04-21 05:30 UTC, Marcus Brinkmann
Details | Splinter Review
Fix GetModuleFileNameA and RegQueryValueExA (2.88 KB, patch)
2010-05-03 10:20 UTC, Marcus Brinkmann
Details | Splinter Review
Fix infinite recursion on Windows CE. (2.88 KB, patch)
2010-05-05 08:10 UTC, Marcus Brinkmann
Details | Splinter Review
Define _WIN32_WCE for autoconf based builds. (1.23 KB, patch)
2010-05-06 17:22 UTC, Marcus Brinkmann
Details | Splinter Review
Fix infinite recursion on Windows CE. (3.04 KB, patch)
2010-05-07 03:14 UTC, Marcus Brinkmann
Details | Splinter Review
Fix _IOLBF for Windows CE and also define _IONBF (648 bytes, patch)
2010-05-12 05:55 UTC, Marcus Brinkmann
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Brinkmann 2010-03-16 09:21:19 UTC
Hi,

this is a series of patches porting DBus-Daemon to Windows CE, using cegcc cross compilation under GNU/Linux.  As Windows CE only provides a limited subset of the Windows API, and an even more minimal and broken subset of the POSIX'ish Windows API, I approached this port in the following way: Convert the existing Windows port fully to the Windows API, replacing remnants of Unix-ish interfaces (_open, _mkdir, _readdir etc) by their Windows-ish counterparts (CreateFile, CreateDirectory, FindNextFile etc).  The advantage is that this makes the port more uniform and also avoids confusion (for example, POSIXish checking of return values of Windowsish interfaces, as happened for MoveFileExA).  If you are not with me on this design decision, the whole set of patches needs to be abandonend (or rather: reworked).  The alternative I can think of is implementing the POSIXish interfaces for Windows CE, but that may be messy as this may conflict with what's there already.  Please let me know if you feel strongly about this.

I have isolated the changes to the Windows port in a first patch (0001).  This patch is tested not to break the Windows build (the unit tests "dbus-test" complete successfully, and a KDE program still works).  Issues addresses are, among others: Use of Windows API instead of POSIXish APIs; indirect use of errno (which does not(!) exist in Windows CE, and needs to be replaced by Set/GetLastError).

The second patch (0002) makes more code that depends on signal.h and locale.h conditional.  These header files and associated interfaces simply don't exist on Windows CE.

The third patch (0003) adds Windows CE detection to configure.in and also adjusts the winsock library (it's -lws on CE instead of -lws_2 on NT, nobody seems to know why this is different).

The fourth patch (0004) then fulfills the promise of the 0001 patch and implements the parts of the Windows API that are missing on Windows CE.  Notably, it provides wrappers for the ASCII variants of the interfaces, as Windows CE only has Unicode interface variants.  The alternative to switch the dbus code base to unicode is too invasive for this port (but would make large parts of this patch obsolete).

The fifth patch (0005) is an unfortunate work around for a discrepancy of the Windows NT and Windows CE command line parser in the wrapper around main() [Windows standard is to have WinMain as entry point, which gets a command line string that is then parsed by the application.] Windows CE and NT have different ideas how to break the cmdline into strings for argv.  In particular, Windows NT expects the first component of the cmdline to be the program name (argv[0]), while Windows CE gets the program name from the ModuleName and expects the first component of the cmdline to be the first argument (argv[1]).

The sixth patch (0006) ports the dbus-monitor.c program from tools.

The seventh patch (0007) adds a README.wince to the root directory with further information on the port.

The eighth patch (0008) includes a patched version of libtool for the build.  Current versions of libtool unfortunately don't support Windows CE cross-builds correctly: The libtool wrapper programs do not compile for this platform, and there is an error in the detection order.  Note that this patch would become obsolete by upgrading to an upcoming, working libtool version (our changes needed for WinCE have been submitted and accepted upstream).

I also have a port of the dbus-launch tool in the works, but I want to clear the queue before cleaning that up.  I will append it to this bug report shortly.
Comment 1 Marcus Brinkmann 2010-03-16 09:22:10 UTC
Created attachment 34111 [details] [review]
Convert windows port to use Windows API more consistently, in preparation of WinCE port.
Comment 2 Marcus Brinkmann 2010-03-16 09:22:41 UTC
Created attachment 34112 [details] [review]
Make dependency on signal.h and locale.h optional
Comment 3 Marcus Brinkmann 2010-03-16 09:23:00 UTC
Created attachment 34113 [details] [review]
Detect WinCE in configure
Comment 4 Marcus Brinkmann 2010-03-16 09:23:24 UTC
Created attachment 34114 [details] [review]
Support WinCE throughout the code base.
Comment 5 Marcus Brinkmann 2010-03-16 09:23:45 UTC
Created attachment 34115 [details] [review]
Work around CreateProcess discrepancy.
Comment 6 Marcus Brinkmann 2010-03-16 09:24:07 UTC
Created attachment 34116 [details] [review]
Port dbus-monitor to WinCE
Comment 7 Marcus Brinkmann 2010-03-16 09:24:23 UTC
Created attachment 34117 [details] [review]
Add README.wince
Comment 8 Marcus Brinkmann 2010-03-16 09:25:06 UTC
Created attachment 34118 [details] [review]
Include a patched version of libtool for WinCE
Comment 9 Marcus Brinkmann 2010-03-16 10:15:53 UTC
Created attachment 34123 [details] [review]
Port dbus launch to windows ce.
Comment 10 Colin Walters 2010-03-16 19:33:11 UTC
Comment on attachment 34112 [details] [review]
Make dependency on signal.h and locale.h optional

This patch looks fine to me.
Comment 11 Colin Walters 2010-03-16 19:34:15 UTC
Comment on attachment 34116 [details] [review]
Port dbus-monitor to WinCE

Looks fine.
Comment 12 Colin Walters 2010-03-16 19:38:57 UTC
Comment on attachment 34123 [details] [review]
Port dbus launch to windows ce.


>+#ifdef DBUS_WINCE
>+#define _mbsrchr strrchr

Kind of eww...

>+/* Return a malloced string encoded in UTF-8 from the wide char input
>+   string STRING.  Caller must free this value.  Returns NULL on
>+   failure.  Caller may use GetLastError to get the actual error
>+   number.  The result of calling this function with STRING set to
>+   NULL is not defined.  */
>+static char *
>+wchar_to_utf8 (const wchar_t *string)

We should probably preemptively put these in say dbus-sysdeps-util-win32.c.

The rest of the changes are a bit hard for me to evaluate but don't seem offhand crazy.  Could be a bit cleaner of course but I wouldn't block you on it.
Comment 13 Colin Walters 2010-03-16 19:40:51 UTC
Comment on attachment 34118 [details] [review]
Include a patched version of libtool for WinCE

This needs to be used *ONLY* if we're building on wince.  

You could call it libtool.wince and reference it in the README file you made.

Or it needs to just live on the machine of whoever builds on Windows CE for now.
Comment 14 Colin Walters 2010-03-16 19:41:31 UTC
Comment on attachment 34113 [details] [review]
Detect WinCE in configure

Looks ok.
Comment 15 Colin Walters 2010-03-16 19:43:24 UTC
Comment on attachment 34111 [details] [review]
Convert windows port to use Windows API more consistently, in preparation of WinCE port.

Scanned through quickly, looks good.
Comment 16 Marcus Brinkmann 2010-03-17 03:34:45 UTC
Comment on attachment 34123 [details] [review]
Port dbus launch to windows ce.

Putting sysdeps stuff for tools/ into its own file is a good idea.  If you want, I can refactor the dbus-monitor and dbus-launch-win patches and submit new ones, or I can send you patches for that refactoring on top of those.

It's not a problem for me to allocate time to improve the patches to be cleaner.  If we can go forward with them anyway and make them cleaner down the road, even better (less ping-ponging with git rebase -i for me :).

I have my own idea of which parts of the port are not super-clean yet, but if there are items beside those you mentioned that you would like to see cleaned up, please tell me so I can allocate the time for it.
Comment 17 Marcus Brinkmann 2010-03-17 03:37:26 UTC
Comment on attachment 34118 [details] [review]
Include a patched version of libtool for WinCE

As your policy seems to be that no autoconf-auto-installed files are part of the build, it would be better to just not apply this patch.  I will submit a patch for the README.wince file that explains the situation, provides a patch for a recent libtool version, and explains which version of libtool meets the requirement.  That will do fine for now!
Comment 18 Ralf Habacker 2010-03-17 04:54:18 UTC
(In reply to comment #1)
> Created an attachment (id=34111) [details]
> Convert windows port to use Windows API more consistently, in preparation of
> WinCE port.
> 

I see one issue with dbus_file_read: 

there are no functions for opening and closing files on the same level as
dbus_file_read  

By introducing dbus_file_open and dbus_file_close in which the related native
api calls are encapsulated, code will be more readable and easier to maintain. 

Comment 19 Marcus Brinkmann 2010-03-17 06:36:03 UTC
(In reply to comment #18)
> I see one issue with dbus_file_read: 
> 
> there are no functions for opening and closing files on the same level as
> dbus_file_read  
> 
> By introducing dbus_file_open and dbus_file_close in which the related native
> api calls are encapsulated, code will be more readable and easier to maintain. 

If a generic file API is desired, then yes, it should have more functions, but it also needs to abstract a file descriptor/handle.  The existing _dbus_file_read did not do that, so I removed its public declaration (which was not used or exported anyway) and made the function static (and moved it up in the file).  I didn't introduce it, though.
Comment 20 Ralf Habacker 2010-03-18 00:51:53 UTC
(In reply to comment #12)
> (From update of attachment 34123 [details] [review])
> 
> >+#ifdef DBUS_WINCE
> >+#define _mbsrchr strrchr
> 
> Kind of eww...
> 
> >+/* Return a malloced string encoded in UTF-8 from the wide char input
> >+   string STRING.  Caller must free this value.  Returns NULL on
> >+   failure.  Caller may use GetLastError to get the actual error
> >+   number.  The result of calling this function with STRING set to
> >+   NULL is not defined.  */
> >+static char *
> >+wchar_to_utf8 (const wchar_t *string)
> 
> We should probably preemptively put these in say dbus-sysdeps-util-win32.c.
> 
> The rest of the changes are a bit hard for me to evaluate but don't seem
> offhand crazy.  Could be a bit cleaner of course but I wouldn't block you on
> it.
> 
Instead of emulating the ...A functions in dbus-launch-win.c would not make using the ...W functions by default the code much cleaner and much of the emulation functions obsolate ? 


Comment 21 Marcus Brinkmann 2010-03-18 04:08:36 UTC
(In reply to comment #20)
> (In reply to comment #12)
> > (From update of attachment 34123 [details] [review] [details])
> Instead of emulating the ...A functions in dbus-launch-win.c would not make
> using the ...W functions by default the code much cleaner and much of the
> emulation functions obsolate ? 

I don't know, but probably not.  Let's look at the options.  Right now, the conversion happens at the Windows API level, which is identical to what was already happening (internally, Windows FooA functions convert and dispatch to FooW).  The conversion is isolated to 17 functions in a single file (dbus-sysdeps-wince-glue) and contained in functions which only do conversions and nothing else.

If you bump it up one layer, you end up with conversion back and forth in all string-processing sysdeps functions.  Those functions already do interesting stuff, and adding conversions to them does not seem appealing.  The ones using DBusString are probably easy to convert by extending the DBusString class, but the ones using const char * will get more messy.  There are probably more of those than 17.
Comment 22 Marcus Brinkmann 2010-03-18 04:17:21 UTC
I didn't want to post it just yet. Gr.

(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #12)
> > > (From update of attachment 34123 [details] [review] [details] [details])
> > Instead of emulating the ...A functions in dbus-launch-win.c would not make
> > using the ...W functions by default the code much cleaner and much of the
> > emulation functions obsolate ? 
> 
> I don't know, but probably not.  Let's look at the options.  Right now, the
> conversion happens at the Windows API level, which is identical to what was
> already happening (internally, Windows FooA functions convert and dispatch to
> FooW).  The conversion is isolated to 17 functions in a single file
> (dbus-sysdeps-wince-glue) and contained in functions which only do conversions
> and nothing else.
> 
> If you bump it up one layer, you end up with conversion back and forth in all
> string-processing sysdeps functions.  Those functions already do interesting
> stuff, and adding conversions to them does not seem appealing.  The ones using
> DBusString are probably easy to convert by extending the DBusString class, but
> the ones using const char * will get more messy.  There are probably more of
> those than 17.

Continueing, if you cut at the public library API, you have to change all of the libdbus code to use string literals L"" instead of "", affecting non-windows targets, which seems highly undesirable.

It is true that taking these larger approaches would get rid of 17 wrapper functions in the dbus-sysdeps-wince-glue.c file.  However, having UNICODE in these places provides no real benefit, as there are almost no strings processed that are expected to be non-ASCII.  The main exception are filenames, but even those are mostly ASCII on WinCE, certainly in the paths that are of concern here (installation paths, configuration files etc).  The only function that is not multibyte safe in this port is the one stripping of the last filename component from a full absolute filename, and the reason is that the simple approach (converting utf to utf16, stripping off the component, converting back and checking if the result is a prefix of the original string) didn't seem particularly safe either to me (in the presence of non-canonical forms).

The main reason for doing it in its own file for Windows CE only is to reduce the impact of the port on the other ports, including Windows.  Even if it is decided that the Windows (and Windows CE) port should use the UNICODE interface as broadly and early as possible, I would suggest to make that a separate project.  I am willing to help with that, if that's what you want.
Comment 23 Marcus Brinkmann 2010-03-19 06:15:35 UTC
(In reply to comment #12)
> >+/* Return a malloced string encoded in UTF-8 from the wide char input
> >+   string STRING.  Caller must free this value.  Returns NULL on
> >+   failure.  Caller may use GetLastError to get the actual error
> >+   number.  The result of calling this function with STRING set to
> >+   NULL is not defined.  */
> >+static char *
> >+wchar_to_utf8 (const wchar_t *string)
> 
> We should probably preemptively put these in say dbus-sysdeps-util-win32.c.
> 
> The rest of the changes are a bit hard for me to evaluate but don't seem
> offhand crazy.  Could be a bit cleaner of course but I wouldn't block you on
> it.

Colin, I said before that's a good idea, but now I am thinking you may have meant something different from what I thought you meant.

There are _dbus_win_utf8_to_utf16 and _dbus_win_utf16_to_utf8 functions which do the same job as utf8_to_wchar and wchar_to_utf8, and they work just fine, but they are not available in the tools/ directory, as they are part of the internal static version of libdbus.

I think I will rewrite dbus-launch-win.c to use the unicode interfaces on Windows and Windows CE, which will get rid of this code duplication.


Comment 24 Marcus Brinkmann 2010-03-19 06:58:10 UTC
Created attachment 34241 [details] [review]
UNICODE version of dbus-launch-win.c

This is the unicodified version of dbus-launch-win.c
Comment 25 Ralf Habacker 2010-03-19 13:46:03 UTC
The following patch is moved to here from bug 27194

diff --git a/dbus/dbus-sysdeps-wince-glue.c b/dbus/dbus-sysdeps-wince-glue.c
index 38b59c6..204e719 100644
--- a/dbus/dbus-sysdeps-wince-glue.c
+++ b/dbus/dbus-sysdeps-wince-glue.c
@@ -26,6 +26,7 @@
  *
  */

+#include <config.h>
 #include "dbus-internals.h"
 #include "dbus-sysdeps.h"
 #include "dbus-sysdeps-win.h"
Comment 26 Ralf Habacker 2010-03-19 14:52:46 UTC
(In reply to comment #24)
> Created an attachment (id=34241) [details]
> UNICODE version of dbus-launch-win.c
> 
> This is the unicodified version of dbus-launch-win.c
> 

I tried this msvc++ 2008 express edition and have been forced to use the local implementation of wcscat_s. Appended is the required patch


diff --git a/tools/dbus-launch-win.c b/tools/dbus-launch-win.c
index a192b8a..62dc743 100644
--- a/tools/dbus-launch-win.c
+++ b/tools/dbus-launch-win.c
@@ -31,11 +31,17 @@
 #include <mbstring.h>
 #include <assert.h>

-#if defined __MINGW32__ || (defined _MSC_VER && _MSC_VER <= 1310)
+#if defined __MINGW32__ || (defined _MSC_VER && (_MSC_VER <= 1310 || _MSC_VER == 1500))
 /* save string functions version
 */
 #define errno_t int

+#if _MSC_VER == 1500
+/* wcscat_s does not work in vs 2008 express*/
+#define wcscat_s _wcscat_s
+#define wcscpy_s _wcscpy_s
+#endif
+
 static errno_t
 wcscat_s (wchar_t *dest, size_t size, wchar_t *src)
 {
Comment 27 Marcus Brinkmann 2010-03-19 15:06:35 UTC
(In reply to comment #26)
> (In reply to comment #24)
> I tried this msvc++ 2008 express edition and have been forced to use the local
> implementation of wcscat_s. Appended is the required patch

I don't know what's right for _MSC_VER, the <=1310 was probably true for the strcat_s/strcpy_s stuff.  It may very well be <=1500 for the wcs variants, but I don't have any version of VS and the online MSDN documentation doesn't seem to give me any info on this either.
Comment 28 Ralf Habacker 2010-03-20 10:32:48 UTC
(In reply to comment #24)
> Created an attachment (id=34241) [details]
> UNICODE version of dbus-launch-win.c
> 
> This is the unicodified version of dbus-launch-win.c
> 
I compiled this with msvc and mingw and got a runtime error: 

prompt>cd <...path>
prompt>set DBUS_VERBOSE=1
prompt>dbus-launch 
<...path>\dbus-daemon.exe --session
Could not start dbus-daemon. error=6 'invalid handle error'

Directly starting dbus-daemon --session let dbus daemon run

Any idea how to fix ? 



Comment 29 Ralf Habacker 2010-03-22 07:34:15 UTC
(In reply to comment #1)
> Created an attachment (id=34111) [details]
> Convert windows port to use Windows API more consistently, in preparation of
> WinCE port.
> 
Please run bus-test with this patch applied. It will break on windows "Testing valid files":  basic.conf  with 

Failed to load valid file but still had memory: Failed to read directory <build_root>\test\data\valid-config-files\basic.d\basic.d": Das System kann den angegebenen Pfad nicht finden.

I guess the new implementation do not distingiush between files an dir as the old one does. 

This let _dbus_directory_get_next_file return a directory 'basic.d' as file which is wrong. 


Comment 30 Ralf Habacker 2010-03-22 07:46:28 UTC
(In reply to comment #2)
> Created an attachment (id=34112) [details]
> Make dependency on signal.h and locale.h optional
> 

looks good, I committed this and a related patch for the cmake build system. 

Comment 31 Ralf Habacker 2010-03-22 07:51:19 UTC
Comment on attachment 34112 [details] [review]
Make dependency on signal.h and locale.h optional

committed
Comment 32 Marcus Brinkmann 2010-03-22 17:59:36 UTC
(In reply to comment #29)
> (In reply to comment #1)
> > Created an attachment (id=34111) [details] [details]
> > Convert windows port to use Windows API more consistently, in preparation of
> > WinCE port.
> > 
> Please run bus-test with this patch applied. It will break on windows "Testing
> valid files":  basic.conf  with 
> 
> Failed to load valid file but still had memory: Failed to read directory
> <build_root>\test\data\valid-config-files\basic.d\basic.d": Das System kann den
> angegebenen Pfad nicht finden.

Thanks for finding this.  It's just a missing error code conversion:

diff --git a/dbus/dbus-sysdeps-win.c b/dbus/dbus-sysdeps-win.c
index 174b8a1..b3fd9c0 100644
--- a/dbus/dbus-sysdeps-win.c
+++ b/dbus/dbus-sysdeps-win.c
@@ -123,6 +123,7 @@ _dbus_win_error_from_last_error (void)
       return DBUS_ERROR_FILE_EXISTS;
 
     case ERROR_FILE_NOT_FOUND:
+    case ERROR_PATH_NOT_FOUND:
       return DBUS_ERROR_FILE_NOT_FOUND;
     }
   

> I guess the new implementation do not distingiush between files an dir as the
> old one does. 
> This let _dbus_directory_get_next_file return a directory 'basic.d' as file
> which is wrong. 

What is actually happening:

test/data/valid-config-files/basic.d/basic.conf contains the instruction:
"<includedir>basic.d</includedir>" but the directory test\data\valid-config-files\basic.d\basic.d does not exist.  But PATH_NOT_FOUND is not mapped to DBUS_ERROR_FILE_NOT_FOUND, so the test case does not ignore it.
 


Comment 33 Marcus Brinkmann 2010-03-22 19:12:01 UTC
(In reply to comment #28)
> (In reply to comment #24)
> > Created an attachment (id=34241) [details] [details]
> > UNICODE version of dbus-launch-win.c
> > 
> > This is the unicodified version of dbus-launch-win.c
> > 
> I compiled this with msvc and mingw and got a runtime error: 
> 
> prompt>cd <...path>
> prompt>set DBUS_VERBOSE=1
> prompt>dbus-launch 
> <...path>\dbus-daemon.exe --session
> Could not start dbus-daemon. error=6 'invalid handle error'
> 
> Directly starting dbus-daemon --session let dbus daemon run
> 
> Any idea how to fix ? 
> 

Ah ok.  The actual error is not 6, but 87: The CloseHandle instructions overwrite the last error value.  That should be fixed by moving CloseHandle after the error check.

The actual error is the use of CREATE_NEW_CONSOLE if DBUS_VERBOSE is set(!) in conjunction with DETACHED_PROCESS, which is not allowed (they are mutually exclusive).  I think that using DETACHED_PROCESS is correct (that's why I added it), but I also see a need for being able to see the output of dbus-daemon.

As I am not sure what CREATE_NEW_CONSOLE and DETACHED_PROCESS *really* do (the Windows console and window code is bizarrly mysterious in this area, and poorly documented), I will try to find some wizards to get some advice (or maybe you know something).  It will be easy to fix though (use one flag or the other, depending on what the desired effect is).  Simply not setting DBUS_VERBOSE and/or removing either CREATE_NEW_CONSOLE and/or DETACHED_PROCESS from the patch will work for now.  Stay tuned for the follow up.
Comment 34 Ralf Habacker 2010-03-23 10:55:08 UTC
(In reply to comment #33)
> (In reply to comment #28)
> > (In reply to comment #24)
> > > Created an attachment (id=34241) [details] [details] [details]
> > > UNICODE version of dbus-launch-win.c
> > > 
> > > This is the unicodified version of dbus-launch-win.c
> > > 
> > I compiled this with msvc and mingw and got a runtime error: 
> > 
> > prompt>cd <...path>
> > prompt>set DBUS_VERBOSE=1
> > prompt>dbus-launch 
> > <...path>\dbus-daemon.exe --session
> > Could not start dbus-daemon. error=6 'invalid handle error'
> > 
> > Directly starting dbus-daemon --session let dbus daemon run
> > 
> > Any idea how to fix ? 
> > 
> 
> Ah ok.  The actual error is not 6, but 87: The CloseHandle instructions
> overwrite the last error value.  That should be fixed by moving CloseHandle
> after the error check.
> 
> The actual error is the use of CREATE_NEW_CONSOLE if DBUS_VERBOSE is set(!) in
> conjunction with DETACHED_PROCESS, which is not allowed (they are mutually
> exclusive).  I think that using DETACHED_PROCESS is correct (that's why I added
> it), but I also see a need for being able to see the output of dbus-daemon.
> 
> As I am not sure what CREATE_NEW_CONSOLE and DETACHED_PROCESS *really* do (the
> Windows console and window code is bizarrly mysterious in this area, and poorly
> documented), I will try to find some wizards to get some advice (or maybe you
> know something).  It will be easy to fix though (use one flag or the other,
> depending on what the desired effect is).  Simply not setting DBUS_VERBOSE
> and/or removing either CREATE_NEW_CONSOLE and/or DETACHED_PROCESS from the
> patch will work for now.  Stay tuned for the follow up.
> 
As far As i remember does CREATE_NEW_CONSOLE open a command windows for the created process, which makes it able to see verbose messages for the daemon.

Comment 35 Marcus Brinkmann 2010-03-23 15:33:35 UTC
(In reply to comment #34)
> As far As i remember does CREATE_NEW_CONSOLE open a command windows for the
> created process, which makes it able to see verbose messages for the daemon.

Solid information is hard to come by, but CREATE_NEW_CONSOLE creates a new console instead of inheriting the current one, while DETACHED_PROCESS creates the new process without a console, which is of course mutually exclusive.  There is also the issue of a console popup (SHOW_MINIMIZE).

I added DETACHED_PROCESS because it seems to me to be desirable to start dbus-daemon as a daemonized process that does not share its console with dbus-launch.  I am not sure if CREATE_NEW_CONSOLE is desirable/useful in the logging/debugging case.  I'll play around with the flags and see if there are any visible differences.


Comment 36 Ralf Habacker 2010-03-25 11:23:32 UTC
(In reply to comment #35)
> (In reply to comment #34)
> > As far As i remember does CREATE_NEW_CONSOLE open a command windows for the
> > created process, which makes it able to see verbose messages for the daemon.
> 
> Solid information is hard to come by, but CREATE_NEW_CONSOLE creates a new
> console instead of inheriting the current one, while DETACHED_PROCESS creates
> the new process without a console, which is of course mutually exclusive. 
> There is also the issue of a console popup (SHOW_MINIMIZE).
> 
> I added DETACHED_PROCESS because it seems to me to be desirable to start
> dbus-daemon as a daemonized process that does not share its console with
> dbus-launch.  

> I am not sure if CREATE_NEW_CONSOLE is desirable/useful in the
> logging/debugging case. 

dbus logging uses stderr for debug output when DBUS_VERBOSE=1 is set. How would it be possible to see the log when dbus-launch runs the daemon in the background ? 

Comment 37 Marcus Brinkmann 2010-03-25 12:20:08 UTC
(In reply to comment #36)

> > I added DETACHED_PROCESS because it seems to me to be desirable to start
> > dbus-daemon as a daemonized process that does not share its console with
> > dbus-launch.  
> 
> > I am not sure if CREATE_NEW_CONSOLE is desirable/useful in the
> > logging/debugging case. 
> 
> dbus logging uses stderr for debug output when DBUS_VERBOSE=1 is set. How would
> it be possible to see the log when dbus-launch runs the daemon in the
> background ? 
> 

In the logging case, DETACHED_PROCESS should not be used.  But I am not sure if CREATE_NEW_CONSOLE should be used, or just 0, instead.  CREATE_NEW_CONSOLE creates a new console, while not specifying it causes dbus-daemon to inherit the console from dbus-launch.  On Windows, inheriting the existing console is probably ok, on Win CE one may want to use CREATE_NEW_CONSOLE, I have to test that.
Comment 38 Ralf Habacker 2010-03-25 12:35:42 UTC
(In reply to comment #37)
> (In reply to comment #36)
> 
> > > I added DETACHED_PROCESS because it seems to me to be desirable to start
> > > dbus-daemon as a daemonized process that does not share its console with
> > > dbus-launch.  
> > 
> > > I am not sure if CREATE_NEW_CONSOLE is desirable/useful in the
> > > logging/debugging case. 
> > 
> > dbus logging uses stderr for debug output when DBUS_VERBOSE=1 is set. How would
> > it be possible to see the log when dbus-launch runs the daemon in the
> > background ? 
> > 
> 
> In the logging case, DETACHED_PROCESS should not be used.  
agreed 
> But I am not sure if
> CREATE_NEW_CONSOLE should be used, or just 0, instead.  CREATE_NEW_CONSOLE
> creates a new console, while not specifying it causes dbus-daemon to inherit
> the console from dbus-launch.

yes, but inheriting parents console does not work because dbus-launch starts dbus-daemon and exists immediatly, which means there is no parent console for dbus-daemon. 

> On Windows, inheriting the existing console is probably ok, 
As mentioned above - it does not work yet, so there is only the CREATE_NEW_CONSOLE option. 

Or do you see a way to redirect dbus-launch's parent console to CreateProcess ?

> on Win CE one may want to use CREATE_NEW_CONSOLE, I have to test that.
 

Comment 39 Marcus Brinkmann 2010-03-25 15:41:32 UTC
(In reply to comment #38)
> yes, but inheriting parents console does not work because dbus-launch starts
> dbus-daemon and exists immediatly, which means there is no parent console for
> dbus-daemon. 

Right.  So it should be DETACHED_PROCESS if !verbose and CREATE_NEW_CONSOLE if verbose.  I will test this combination.

Comment 40 Marcus Brinkmann 2010-04-12 17:30:14 UTC
Created attachment 34933 [details] [review]
Convert windows port to use Windows API more consistently, in preparation of WinCE port. (REVISION 2)
Comment 41 Marcus Brinkmann 2010-04-12 17:31:44 UTC
Created attachment 34934 [details] [review]
Detect WinCE in configure
Comment 42 Marcus Brinkmann 2010-04-12 17:32:11 UTC
Created attachment 34935 [details] [review]
Support WinCE throughout the code base.
Comment 43 Marcus Brinkmann 2010-04-12 17:32:32 UTC
Created attachment 34936 [details] [review]
Work around CreateProcess discrepancy.
Comment 44 Marcus Brinkmann 2010-04-12 17:33:23 UTC
Created attachment 34937 [details] [review]
Port dbus tools to windows ce.
Comment 45 Marcus Brinkmann 2010-04-12 17:34:03 UTC
Created attachment 34938 [details] [review]
Add README.wince
Comment 46 Marcus Brinkmann 2010-04-12 17:34:47 UTC
Created attachment 34939 [details] [review]
Add/Fix WinCE support in cmake files.
Comment 47 Marcus Brinkmann 2010-04-12 17:35:50 UTC
Created attachment 34940 [details] [review]
Replace strtoll/strtoull for Windows CE. VARIATION 1/2
Comment 48 Marcus Brinkmann 2010-04-12 17:36:20 UTC
Created attachment 34941 [details] [review]
Replace strtoll/strtoull for Windows CE. VARIATION 2/2
Comment 49 Marcus Brinkmann 2010-04-12 17:37:22 UTC
Created attachment 34942 [details] [review]
Custom version of libtool for convenience of potential testers, DO NOT APPLY.
Comment 50 Marcus Brinkmann 2010-04-12 17:51:59 UTC
I updated the series of patches, incorporating the input from the discussion and testing.  If anything is missing for inclusion into mainline (more testing, etc), please let me know if I can be of any assistance.  Changes to first round of patches:

0001-Prepare-for-WinCE-port-Convert-windows-code-to-nativ.patch: This now includes a port of dbus-pipe-win.c to the native Windows API (contributed by Romain).  Also includes the error code mapping fix from the comment #32.

0002-Add-WinCE-detection-to-configure.in-and-choose-right.patch: Unchanged.

0003-Add-support-for-Windows-CE-to-the-code-base.patch: Includes changes needed for Microsoft SDK (by Romain), which differs from cegcc in minor ways.

0004-Windows-CE-has-a-different-understanding-of-command-.patch: Unchanged.

0005-Port-dbus-tools-to-Windows-CE.patch: Contains all patches related to the tools directory, and a version of dbus-launch-win.c that accumulates the discussion on spawn flags in the comments.

0006-Add-README-for-Windows-CE.patch: Contains a reference to the libtool requirements for Windows CE.

0007-update-WinCE-cmake-support.patch: Adjustments to WinCE building with cmake under Windows (using Microsoft SDK) by Romain.

0008-Add-replacement-functions-strtoll-strtoull-for-dbus-.patch, 0009-Simple-fix-for-Windows-CE-s-lack-of-strtoll.patch: Two patches (alternatives) for the same problem: Windows CE does not have strtoll and strtoull, needed by dbus-send.  The first patch provides replacement implementations taken from BSD, the second patch cripples dbus-send and is thus much simpler (just an ifdef).  You decide (we feel 64 bit args for dbus-send is not important to have on windows ce but provided a full patch for correctness anyway).

0010-Include-a-patched-version-of-libtool-good-for-Window.patch: Just provided for easy access to a working libtool, for reference only.  Do not apply.
Comment 51 Marcus Brinkmann 2010-04-12 17:52:52 UTC
Created attachment 34943 [details] [review]
Support WinCE throughout the code base.

The previous submission contained an embarrassing typo.
Comment 52 Marcus Brinkmann 2010-04-12 17:56:09 UTC
With regards to the strtoll/strtoull patches, please note that these have not been part of the previous revision of the patches as they are only needed with the Microsoft SDK: cegcc provides them.
Comment 53 Ralf Habacker 2010-04-13 06:57:10 UTC
Comment on attachment 34939 [details] [review]
Add/Fix WinCE support in cmake files.

committed
Comment 54 Marcus Brinkmann 2010-04-13 08:21:24 UTC
Created attachment 34967 [details] [review]
Add missing HAVE_ macros to cmake

Patch by Romain to bring the cmake build up to the other patches.  This includes tests, among others, for strtoll/strtoull, which would be needed for the 34940 patch (VARIATION 1/2), and would not do much harm (but are not required) for the second variation.
Comment 55 Ralf Habacker 2010-04-13 10:59:22 UTC
Comment on attachment 34933 [details] [review]
Convert windows port to use Windows API more consistently, in preparation of WinCE port. (REVISION 2)

committed
Comment 56 Ralf Habacker 2010-04-13 11:01:45 UTC
Comment on attachment 34933 [details] [review]
Convert windows port to use Windows API more consistently, in preparation of WinCE port. (REVISION 2)

no problems on win32 detected 

committed
Comment 57 Ralf Habacker 2010-04-13 11:04:27 UTC
Comment on attachment 34934 [details] [review]
Detect WinCE in configure

committed
Comment 58 Ralf Habacker 2010-04-13 11:07:50 UTC
Comment on attachment 34936 [details] [review]
Work around CreateProcess discrepancy.

committed
Comment 59 Ralf Habacker 2010-04-13 11:08:51 UTC
Comment on attachment 34936 [details] [review]
Work around CreateProcess discrepancy.

committed
Comment 60 Ralf Habacker 2010-04-13 11:10:42 UTC
Comment on attachment 34967 [details] [review]
Add missing HAVE_ macros to cmake

committed
Comment 61 Ralf Habacker 2010-04-13 11:33:07 UTC
Comment on attachment 34943 [details] [review]
Support WinCE throughout the code base.

committed. 
You may add a copyright note to dbus-sysdeps-wince-glue.*
Comment 62 Ralf Habacker 2010-04-13 11:52:36 UTC
Comment on attachment 34937 [details] [review]
Port dbus tools to windows ce.

committed
Comment 63 Ralf Habacker 2010-04-13 12:03:49 UTC
Comment on attachment 34940 [details] [review]
Replace strtoll/strtoull for Windows CE. VARIATION 1/2

committed
Comment 64 Ralf Habacker 2010-04-13 12:04:15 UTC
Comment on attachment 34938 [details] [review]
Add README.wince

committed
Comment 65 Ralf Habacker 2010-04-13 12:16:52 UTC
Review of attachment 34933 [details] [review]:

On win32 there are warnings: 

D:\daten\kde\download\svn-src\dbus-freedesktop-src-ssh\dbus\dbus-file-win.c(71) : warning C4102: 'again': Unreferenzierte Marke
D:\daten\kde\download\svn-src\dbus-freedesktop-src-ssh\dbus\dbus-file-win.c(170) : warning C4018: '<': Konflikt zwischen 'signed' und 'unsigned'
Comment 66 Marcus Brinkmann 2010-04-13 18:27:22 UTC
Comment on attachment 34941 [details] [review]
Replace strtoll/strtoull for Windows CE. VARIATION 2/2

Obsolete because the other variant was applied.
Comment 67 Marcus Brinkmann 2010-04-13 18:28:53 UTC
Created attachment 34982 [details] [review]
Include strtoll.c and strtoull.c in distribution

This patch adds two missing files to the distribution with autoconf.  They are not added automagically because they are .c files that are #include'd.  A bit lame, but as we have more than one built system to support, this seems the simplest solution.

There may be a corresponding change necessary in the cmake files.
Comment 68 Marcus Brinkmann 2010-04-13 18:29:36 UTC
Created attachment 34983 [details] [review]
Remove obsolete files.

Since we use smart exports now, the def.in and def.pre files are no longer used.
Comment 69 Marcus Brinkmann 2010-04-13 18:30:33 UTC
Created attachment 34984 [details] [review]
Fix warnings on windows builds

This fixes the remaining warnings on Windows under autoconf builds (except for an annoying -ffunction-sections warning that may be a bug in gcc).
Comment 70 Marcus Brinkmann 2010-04-13 18:32:23 UTC
Created attachment 34985 [details] [review]
Fix warnings on windows ce builds

Windows CE had a couple of warnings that are fixed with this patch.

There are also the same bogus(?) -ffunction-sections warnings as with windows.

Also, there are many bogus(?) alignment warnings on windows ce builds with autoconf.  I checked some of them and they were all false warnings (a proper alignment macro was used by dbus in the source line before the warning).  Not sure how to fix those.
Comment 71 Marcus Brinkmann 2010-04-13 18:38:23 UTC
Ralf, thanks a lot for applying the previous round of patches, it's a great relief to be able to work off master instead of a custom branch.  Now the energy can go into clean up, more testing and keeping everything up to date.

As a first step, I just added 4 patches that clean up a bunch of minor issues.

I have another issue on my list I plan to work on soon: Testing the various combinations with/without maintainer mode, with/without tests etc.  I think that there are still some issues with symbol exports in some of these at least (at least for autoconf based builds).

A bigger open issue is porting the test suite to Windows CE.  I won't have time for this in April, but it's in our backlog, so we'll see.
Comment 72 Ralf Habacker 2010-04-13 23:20:42 UTC
Comment on attachment 34985 [details] [review]
Fix warnings on windows ce builds

committed
Comment 73 Ralf Habacker 2010-04-13 23:21:01 UTC
Comment on attachment 34982 [details] [review]
Include strtoll.c and strtoull.c in distribution

committed
Comment 74 Ralf Habacker 2010-04-13 23:21:18 UTC
Comment on attachment 34983 [details] [review]
Remove obsolete files.

committed
Comment 75 Ralf Habacker 2010-04-13 23:21:33 UTC
Comment on attachment 34942 [details] [review]
Custom version of libtool for convenience of potential testers, DO NOT APPLY.

committed
Comment 76 Ralf Habacker 2010-04-13 23:21:48 UTC
Comment on attachment 34984 [details] [review]
Fix warnings on windows builds

committed
Comment 77 Ralf Habacker 2010-04-13 23:29:44 UTC
(In reply to comment #71)
> Ralf, thanks a lot for applying the previous round of patches, it's a great
> relief to be able to work off master instead of a custom branch.  Now the
> energy can go into clean up, more testing and keeping everything up to date.
> 
> As a first step, I just added 4 patches that clean up a bunch of minor issues.

Applying Fix warnings on Windows CE target.
.dotest/patch:73: trailing whitespace.
#define _WIN32_WCE 0x0401
warning: 1 line adds whitespace errors.

> 
> I have another issue on my list I plan to work on soon: Testing the various
> combinations with/without maintainer mode, with/without tests etc.  I think
> that there are still some issues with symbol exports in some of these at least
> (at least for autoconf based builds).

okay 

> A bigger open issue is porting the test suite to Windows CE.  I won't have time
> for this in April, but it's in our backlog, so we'll see.

I suggest to check before, that there are no issues on win32, otherwise you may fight on areas which has to be solved on a deeper level. 

I spent some time on the testsuite to analyse where it works and where not, fixed already some issues and will report the remaining to the list probably next week.
Comment 78 Marcus Brinkmann 2010-04-14 01:17:31 UTC
(In reply to comment #75)
> (From update of attachment 34942 [details] [review])
> committed

Colin vetoed this patch (he wants to keep libtool out of the repository).

OTOH, I am not sure you committed it, because when I pull from the repo, I still get the same version as last night.
Comment 79 Ralf Habacker 2010-04-14 02:50:44 UTC
(In reply to comment #78)
> (In reply to comment #75)
> > (From update of attachment 34942 [details] [review] [details])
> > committed
> 
> Colin vetoed this patch (he wants to keep libtool out of the repository).
> 
> OTOH, I am not sure you committed it, because when I pull from the repo, I
> still get the same version as last night.

no,

-> restored obsolate flag
Comment 80 Marcus Brinkmann 2010-04-15 14:39:09 UTC
(In reply to comment #72)
> (From update of attachment 34985 [details] [review])
> committed

Ralf, for this and the other three patches I recently submitted, I can't find them in the dbus master git repository.  Is there another branch I should look at?
 I've seen in the git history that you seem to merge from another branch at times, but I don't know if that's the case here.

Thanks,
Marcus
Comment 81 Ralf Habacker 2010-04-15 22:54:05 UTC
(In reply to comment #80)
> (In reply to comment #72)
> > (From update of attachment 34985 [details] [review] [details])
> > committed
> 
> Ralf, for this and the other three patches I recently submitted, I can't find
> them in the dbus master git repository.  Is there another branch I should look
> at?

no 

>  I've seen in the git history that you seem to merge from another branch at
> times, but I don't know if that's the case here.
> 
> Thanks,
> Marcus

git push did it :-)
Comment 82 Marcus Brinkmann 2010-04-21 05:30:16 UTC
Created attachment 35206 [details] [review]
Move definition of _WIN32_WCE to configure.in

This moves _WIN32_WCE = 0x502 to configure.in.  Romain pointed out that cmake already defines it.  This is just as well or even better than defining it only in a single header file.
Comment 83 Marcus Brinkmann 2010-05-03 10:20:14 UTC
Created attachment 35390 [details] [review]
Fix GetModuleFileNameA and RegQueryValueExA

There were two bugs: Some memory leaks in RegQueryValueExA both in error and normal case, and a too restrict buffer limit in GetModuleFileNameA.
Comment 84 Marcus Brinkmann 2010-05-05 08:10:44 UTC
Created attachment 35432 [details] [review]
Fix infinite recursion on Windows CE.

A recent change in dbus memory allocation (adding a dbus_verbose call) causes an infinite recursion on Windows CE, because getenv for DBUS_VERBOSE does call the dbus memory allocation routines.

This patch special cases this code path so the infinite recursion is avoided.
Comment 85 Marcus Brinkmann 2010-05-06 17:22:54 UTC
Created attachment 35475 [details] [review]
Define _WIN32_WCE for autoconf based builds.

This is necessary to get the getaddrinfo prototype in autoconf based builds (cmake already defines it).
Comment 86 Ralf Habacker 2010-05-07 02:33:43 UTC
Comment on attachment 35432 [details] [review]
Fix infinite recursion on Windows CE.

This patch seem to be a duplicate of https://bugs.freedesktop.org/attachment.cgi?id=35390
Comment 87 Ralf Habacker 2010-05-07 02:34:58 UTC
Comment on attachment 35475 [details] [review]
Define _WIN32_WCE for autoconf based builds.

committed
Comment 88 Marcus Brinkmann 2010-05-07 03:14:56 UTC
Created attachment 35485 [details] [review]
Fix infinite recursion on Windows CE.

Correct version.
Comment 89 Ralf Habacker 2010-05-08 08:10:16 UTC
Review of attachment 35485 [details] [review]:

get_verbose_setting() returns a string created with malloc. Do you take care of freeing this memory anywhere ?
Comment 90 Marcus Brinkmann 2010-05-08 09:53:49 UTC
Ralf, see the (In reply to comment #89)
> Review of attachment 35485 [details] [review]:
> 
> get_verbose_setting() returns a string created with malloc. Do you take care of
> freeing this memory anywhere ?

Sure, see the static char pointer "past_result" in our getenv() substitute (line 287ff).
Comment 91 Ralf Habacker 2010-05-10 13:00:41 UTC
Comment on attachment 35390 [details] [review]
Fix GetModuleFileNameA and RegQueryValueExA

committed
Comment 92 Ralf Habacker 2010-05-10 13:01:01 UTC
Comment on attachment 35485 [details] [review]
Fix infinite recursion on Windows CE.

committed
Comment 93 Marcus Brinkmann 2010-05-12 05:55:07 UTC
Created attachment 35593 [details] [review]
Fix _IOLBF for Windows CE and also define _IONBF

This fixes a wrong constant for MSVC based builds, and also fixes a failure-to-build-from-source due to c38809e8da115ec9bf2b46837a88557e1607d5a6 (2010-05-12)
Comment 94 Ralf Habacker 2010-05-12 06:01:08 UTC
Comment on attachment 35593 [details] [review]
Fix _IOLBF for Windows CE and also define _IONBF

committed
Comment 95 Ralf Habacker 2010-05-12 06:01:22 UTC
Comment on attachment 35593 [details] [review]
Fix _IOLBF for Windows CE and also define _IONBF

committed
Comment 96 Fridrich Strba 2010-05-12 08:28:56 UTC
Concerning the use of *W api. I would actually militate in favour of using UTF-8 internally everywhere in dbus and of converting the corresponding strings to UTF-16 when we use them in the Win32 api calls.
This is something glib uses in the Gnome world and it works pretty well. And as I don't expect us ever supporting unmaintained windows 9x and Me, it would be really a nice thing for people that name their folders in Thai, Arabic, or Traditional Chinese.
Comment 97 Marcus Brinkmann 2010-05-14 04:44:12 UTC
(In reply to comment #96)
> Concerning the use of *W api. I would actually militate in favour of using
> UTF-8 internally everywhere in dbus and of converting the corresponding strings
> to UTF-16 when we use them in the Win32 api calls.
> This is something glib uses in the Gnome world and it works pretty well. And as
> I don't expect us ever supporting unmaintained windows 9x and Me, it would be
> really a nice thing for people that name their folders in Thai, Arabic, or
> Traditional Chinese.

You are right that the FooA ANSI interfaces do not actually support UTF-8 but expect some native encoding (for example for Chinese they expect gb2312).  This is a limitation only if you expect the dbus install and service directories to be non-ASCII.  I am not sure that is the case.  What's the program directory called on russian and chinese Windows?

If there is a desire or need to support non-ASCII filenames, then the way you said it is the way to do it.  Of course, this would greatly simplify the Windows CE port.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.