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 23:02, Corinna Vinschen wrote: > > 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. Ok. Well for now, I'm going to leave the thunks in place, until / if they become nothing more than if (unicode) ...W() else A(). That said, all the calls we are thunking require kernel mode transitions, so I really don't believe that the thunking will add any overhead on it's own: the context switch going into kernel will obliterate the much smaller overhead of checking which call we want to make. > > 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. Never mind, thinko on my part: the A and W versions would still be directly accesible. 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] |