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

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.

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

To accomodate cygwin-based COM users, one should probably swallow the MSDN prescription and find a better place to call  CoInit/CoUninit. 

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.


Unsubscribe info:
Bug reporting:

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