This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: thunking, the next step
On Mon, Nov 17, 2003 at 10:31:29PM +1100, Robert Collins wrote:
> On Mon, 2003-11-17 at 22:21, Corinna Vinschen wrote:
> > This would require a decision only on the first time
> > a function is called.
>
> There's more to it than that. you MUST NOT hand the A series call longer
> paths than MAX_PATH, they /really/ don't like it.
That's easily straightened out in path_conv.
> And, structures like
> the FindNext* details change in definition when UNICODE is defined. I
> was trying to avoid all that complexity, which is significant, by
> staying in a thunk approach.
Yep, I agree, that's an extra problem. But it doesn't invalidate the
general idea of putting the work into autoload and path_conv. The
FindFile example might be something which justifies the use of wrapper
functions for these very cases.
> I decided against redefining the 'real' calls because I figured some
> areas may want to use the 'real' calls directly, and only the
> auto-adjusting parts of cygwin should have the ansi/wide dichotomy.
I don't know if I understand you right. I was only talking about
calls which are affecting the file system. Other calls like
CreateSemaphore or what not should still work as before. The autoload
part would define some new LoadDLLfuncBLURB which is used only for
the affected functions. I (and I assume cgf) was not talking about
using that approach for all functions with an ascii and a wide char
implementation.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin@cygwin.com
Red Hat, Inc.