apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: svn commit: r921306 - /apr/apr/branches/1.5.x/file_io/win32/open.c
Date Fri, 12 Mar 2010 11:27:01 GMT


> -----Original Message-----
> From: jean-frederic clere [mailto:jfclere@gmail.com]
> Sent: vrijdag 12 maart 2010 12:12
> To: Bert Huijben
> Cc: dev@apr.apache.org
> Subject: Re: svn commit: r921306 -
> /apr/apr/branches/1.5.x/file_io/win32/open.c
> 
> On 03/12/2010 11:48 AM, Bert Huijben wrote:
> > Why do we even have this block?
> >
> > CreateHardLinkA is only implemented in Windows 2000 and later, which
> implies unicode support.
> > (Why support an ansi version of an API that is only implemented on
> unicode capable systems?)
> >
> > 	Bert
> >
> >
> 
> See http://msdn.microsoft.com/en-us/library/aa363860%28VS.85%29.aspx

That doesn't answer my question. (I checked that exact same page or a local copy of that page
to check if Windows '9X might have supported it for network drives)

We have a unicode check right above that block which uses CreateHardLinkW. What I tried to
say was that there are no Windows versions that don't support the W variant but do support
the A variant. 

I don't think we really have to extend the ansi layer for systems that support unicode. And
the Windows NT development line where Windows 2000 is from, always uses unicode internally.
Why translate to the OEM or Ansi code page just to make Windows convert it to Unicode again?
(The documentation doesn't mention CE, so neither variant works there)

	Bert


Mime
View raw message