Re: Implementing stat() with FindFirstFile()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, 30 Mar 2009, Magnus Bäck wrote:

> On Friday, March 27, 2009 at 03:25 CET,
>      Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> 
> > Magnus, it is the official policy to reply-to-all on this list.  This
> > has been mentioned in the past quite often, and it will be mentioned
> > in the future, too.
> 
> Sorry, I was not aware. Doesn't seem to have been mentioned in the last
> month or so. Perhaps it could be included in the list introduction
> message? All people obviously won't read it, but some will.
> 
> > You actually forced me to manually look up and re-add Hannes' address.
> > I do not appreciate having to waste my time like that.
> >
> > If that sounds negative, please understand that I am used to the ways
> > of this list, and when I am annoyed by somebody not fitting in, then
> > it is not totally _my_ mistake.
> 
> A plain "please use reply all" would've sufficed.

I do recognize that I was too harsh: I apologize!

> > On Thu, 26 Mar 2009, Magnus Bäck wrote:
> >
> > > I'd be very surprised if ZwQueryDirectoryFile() hasn't always been
> > > around (I just verified ntdll.dll from NT 4.0), so that's not a
> > > worry. Don't know why MSDN reports it as introduced in XP.
> >
> > As the current maintainer of msysGit, I refuse to have something in
> > the installer I ship that relies on not-at-all guaranteed interfaces.
> 
> Although I do appreciate the importance of guaranteed interfaces,
> I am also pragmatic. An incompatible change in ntdll.dll would break
> vast amounts of programs, including cygwin. There is a lot to be said
> about Microsoft and their APIs, but I don't think they have a habit of
> changing ABIs or function semantics for userland libraries that have
> been around for 15 years.

That does not give me the warm and fuzzy feeling I want to have when 
shipping a new Git for Windows.

Had you pointed to some document that states that the function has been in 
all NT-based versions, that would have done the trick.

> > > All right, I'll see if I can find time to take a look at this. I 
> > > just wanted to check that it wasn't a project policy or whatever to 
> > > bypass Win32.
> >
> > You can do whatever you want... This is Open Source.
> >
> > However, I will try to stay with the officially supported functionality,
> > even if that makes msysGit slower -- Windows will never reach the
> > performance levels of Linux anyway.
> 
> Okay, thanks. Just like you I hate wasting time, in my case with patches
> that'll be refused.

Sorry, that was not at all what I meant.

Of course, I wanted to avoid having time wasted: yours and mine.  But if 
you find said document, or another proof that the function was not 
introduced by pure chance in some of NT's service packs, then that's 
perfectly fine with me.

But if it is, say, only in NT when upgrading to Explorer 6 or newer, I do 
not want to take it: I personally know a machine running NT without 
service packs, and with Internet Explorer 5.5, because every attempt at 
upgrading freezes the complete machine 10 seconds into the login screen.  
And no, the machine cannot run with another setup, because there is a 
6-figure microscope plugged in that refuses to be controlled by anything 
else than the proprietary software that just happens to run only on said 
NT4, with said IE5.5.

Again, I am sorry for my harsh reaction, but please understand that I 
_need_ better proof that nobody will be bitten by your change (chances are 
that I'd have to clean it up...).

After all, in the short time since the release of 1.6.2.1, we had over 
4000 downloads already.

Ciao,
Dscho

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux