apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r920897 - /apr/apr/trunk/file_io/win32/open.c
Date Fri, 21 May 2010 15:25:26 GMT
On Fri, May 21, 2010 at 9:03 AM, William A. Rowe Jr.
<wrowe@rowe-clan.net> wrote:
> On 5/21/2010 7:39 AM, Jeff Trawick wrote:
>> On Thu, May 20, 2010 at 4:22 PM, William A. Rowe Jr.
>> <wrowe@rowe-clan.net> wrote:
>>> On 5/20/2010 10:11 AM, Jeff Trawick wrote:
>>>> lame question months late:
>>>> What is the compilation environment in which this ANSI_FS code is
>>>> compiled -- i.e., WINNT is not defined?
>>> Correct; windows 9x compatible versions such as APR 1.3.x and prior.
>> (Did you mean "APR 1.4.x and prior"?)
> No, the project files went from a 'generic', and NT flavor, to now in 1.4
> a 'generic' (NT), and 9x flavor.
>> I'm wondering when WINNT would *not* be defined.  I see '/D "WINNT"'
>> in various .mak and .dsp files, regardless of APR version.
> Not in 1.3 if you were building the normal debug/release build.  ReleaseNT
> would have defined that.  Now, it's the default.

--- CHANGES     (revision 947028)
+++ CHANGES     (working copy)
@@ -27,6 +27,9 @@

 Changes for APR 1.4.0

+  *) Windows: Default build configurations assume NT or higher at run-time;
+     use Release9x/Debug9x build configurations to support Win9x.
   *) Add apr_global_mutex_lockfile() for retrieving the file, if any,
      associated with the mutex.  Add apr_global_mutex_name() for retrieving
      the name of the lock mechanism used by the underlying proc mutex.

> Really not the sort of change that should have slipped through between
> httpd's 2.2.14 and .15 release.  cest la vie, no sane person should use 9x
> anyways, and my commercial builds of APR have used the WINNT flag always
> for the past 8 years, so I have a great deal of confidence in it.
>> Regardless of APR version, does the user have to hack up the provided
>> dsp files (or build via another mechanism) in order to undefine WINNT,
>> which is what is required to even compile the "#if APR_HAS_ANSI_FS"
>> lines?
> Nope, because the Release9x flavor now would allow both NT and ANSI to
> coexist.  If the manually toggle for only ANSI, that is just the sort of
> hack you describe.

apr_arch_misc.h says

#if defined(_WIN32_WCE) || defined(WINNT)
#define APR_HAS_ANSI_FS           0
#define APR_HAS_ANSI_FS           1

Without a manual edit here, how can one of the builds allow both NT
and ANSI to coexist?  It seems that you get either ANSI or Unicode FS
interface based on whether or not WINNT is defined, and not based on
the run-time OS level.


>>> I'm tempted to gut this code, but understood some users hacked to use the
>>> ANSI path only and forget all unicode/utf-8 resource naming, and adopted
>>> only their machine's (SBCS/MBCS) code page.
>>> For 2.0 APR, axing the ansi legacy seems wise.
>> +1

Born in Roswell... married an alien...

View raw message