From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10110111357.AA18726@clio.rice.edu>
Subject: Re: _findfirst() patch
To: djgpp-workers AT delorie DOT com
Date: Thu, 11 Oct 2001 08:57:13 -0500 (CDT)
Cc: ebotcazou AT libertysurf DOT fr
In-Reply-To: <008701c15237$58c3f240$de1c24d5@zephyr> from "Eric Botcazou" at Oct 11, 2001 11:27:01 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> I examined the wrapper solution and I eventually didn't choose it because:
> - the possible problem with the handle (see below),
> - while Borland findfirst()'s semantics was the right one for int 21h
> function 4eh, I think Watcom's _findfirst() is the right one for int 21h
> function 714eh which explicitly makes use of a handle. I found it a bit
> convoluted to first hide the handle in a structure and then expose it
> through the interface,

Convoluted maybe, but a few memory moves are negigible in speed compared
to the time to do the interrupt.  It's all a tradeoff.  See the other info
below to help you decide.

> - I was told the implementation (wrapper or low-level function) doesn't
> really matter.
> 
> But I can make the wrapper version if you do want it.

The current findfirst code is linked into (almost) every image anyway
to handle command line wild card expansion (unless you explicitly 
disable it).  So attempting to use a common code base makes both library
size sense, exe size sense and maintainability sense - if possible.

> Maybe the use of the handle: when findfirst() detects no wildcard in the
> pathname or findnext() doesn't find any more files, they automatically
> release the handle. I don't think that's the semantics of _findfirst() and
> _findnext(), given that there is precisely _findclose() to do it (although
> the Watcom docs doesn't say anything about that case).

In this case I would say pass back a known "already closed" handle so
the _findclose() is a no operation.  If the handle is "finished" it would
be useless anyway.

> A wrapper would certainly minimize low-level code but I don't understand why
> it would decrease code size: we are talking about a library and IMHO the
> size that matters is the size of code that gets linked to the user program.
> Then a wrapper would obviously increase the code size.

If findfirst was not currently linked into the image that would be true.

I worry about the low level interrupts because of some of the issues we've
seen under Windows 2000 and XP - they are somewhat broken in implementation
of some long file name interrupts.  If you have to put special handling
code in the library you end up having to patch multiple places instead of
a single location (we have a nightmare in our seek implementations today).

I'm not saying that the implementation must be a wrapper (if it is 
incompatible or some horrible performance hit) - I'm just saying that if
we can do it with a wrapper we'll all probably be happier in the long
run.  Thanks for taking the time to help out on this.