Ah, sorry, I was just experimenting with different options trying to get "xlate" to convert Unicode correctly (do you know if APR can successfully translate between UTF-16 and UTF-8?).
But yes, you're right, APR works fine when *my* code is compiled with _UNICODE enabled, so there's no problem. -david > -----Original Message----- > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 30, 2004 3:00 PM > To: David Barrett > Cc: dev@apr.apache.org > Subject: Re: Compiling APR with _UNICODE flag breaks Win32 > > At 01:27 PM 9/30/2004, you wrote: > >I found that enabling Unicode support in the Win32 APR project breaks > many > >functions that rely on the Win32 API, including (at least) > >"apr_app_initialize( )" and "apr_file_copy( )". Specifically, setting > the > >following compile flag: > > > ># /D "_UNICODE" > > > >Or enabling "Use Unicode Character Set" in the General property tab > >(automatically sets said flag) causes the "apr_file_copy( )" function to > >fail in "filestat.c" at line 258: > > David, > > first, you aren't allowed to change such flags while building apr. > Just don't do it... but beyond that... > > It's POINTLESS! APR is already utf-8 on Win32. NOT Unicode > (and I've heard no intention of directly supporting unicode, > although I see no reason why someone couldn't create a trivial > wrapper to do so, on any platform.) > > But better yet - we _should_ still be using ALL Win32FooW() calls > in the win32 build. All of the conversion is under the hood > between utf-8 and wchar (it's a trivial and very fast conversion.) > > There _should_ be no problem with that flag when building your > own code against APR. If there is, that problem should be fixed. > > Bill
