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