apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r920897 - /apr/apr/trunk/file_io/win32/open.c
Date Fri, 21 May 2010 13:03:08 GMT
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.

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.

>> 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
> 


Mime
View raw message