thunking, the next step

[Robert Collins]

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>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20031117/a9fc7f14/attachment.sig>