This is the mail archive of the 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: A Simple Real World Benchmark for cygwin

On Tue, Sep 03, 2002 at 11:38:34AM +0200, wrote:
> Quoting Corinna Vinschen <>:
> > Uhm... it should have nothing to do with NTFS vs. other FS.  The shortcut
> > symlinks are used on all FS.
> That's what I thought to begin with, but cygwin cunningly uses Extended Attributes where available,  bypassing the check_shortcut and the whole COM world altogether on NTFS.

Yeah, that's right, of course.

> > The question is if we can drop CoUninitialize() completely.  If the call
> > to CoUninitialize() is dropped, it should not matter to call CoInitialize()
> > multiple times since it should only return a "The COM library is already
> > initialized on this thread" return code.  That shouldn't take that much
> > time.  The slowness results from the need to load DLLs and such stuff.
> To quote from the MSDN:
> "To close the COM library gracefully, each successful call to CoInitialize or CoInitializeEx, including those that return S_FALSE, must be balanced by a corresponding call to CoUninitialize"
> Another relevant quote:
> "Because there is no way to control the order in which in-process servers are loaded or unloaded, it is not safe to call CoInitialize, CoInitializeEx, or CoUninitialize from the DllMain function"

Yep, that's the problem.  And the reasoning for calling CoInit/CoUnint
always as pair here since there's no way to rely on that the application
will *not* call CoUnit somewhere in the middle of its processing.

> On the other hand, if the shortcut file format is known(?), one could maybe bypass the COM/ IShellXXXX interfaces completely  and read the link directly from the file.

That's ok.  The format is partly known, at least it should be enough
to read the info from Cygwin created shortcuts.  The creation itself
already uses plain WriteFile() calls.  However, the code in shortcut.c
was meant to read all shortcuts (see the


part of the code.  Since we are confident that treating natively created
shortcuts as symlinks is a fault, we could drop that requirement and
just use ReadFile() for that.  This would obviously speed up Cygwin
when reading shortcuts.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

Unsubscribe info:
Bug reporting:

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