This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: thunking, the next step


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

> Also we would need a fairly big change to path_conv.  It would have to
> create the POSIX path in ascii on 9x and in wide char on NT.  If the
> path name creation is done in wide char directly, we neither need a
> strlen, nor an explicit conversion from ascii to wide char.

I agree that moving a lot of the logic into path_conv would be a good
idea. This is orthogonal to whether we use :

> I think this method is preferable over the IOThunkState technique since
> it will have more or less no speed impact.  It also has the advantage,
> that the Cygwin code doesn't have to use all new function calls like
> "create_file" instead of using the "real" Win32 function calls directly.

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.
There is some interesting reading on the issues in the win32 unicode
layer for win9x systems on msdn.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]