delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2008/03/13/19:18:00

X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <47D9C3EC.40103@tlinx.org>
Date: Thu, 13 Mar 2008 17:16:44 -0700
From: Linda Walsh <cygwin AT tlinx DOT org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Flakiness; libdups? and MS-POSIX privileges?
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Dave Korn wrote:
>   Ah.  So the error only arises when the binary is located in windows system
> dir.  Right alongside all those thousands of DLLs.  All those DLLs which are
> now all of a sudden higher up in the DLL search path than they were when the
> binary was located somewhere else. 
>   Just a WAG, but that could be significant.
----
	Yeah.  That thought occurred to me as well.  However there are
no libs in the windirs of the pattern "cyg*.dll".  Those _should_ be
the key libs, though let me check for any other possible dups...

/tmp> for d in /bin /windows /windows/system32;do
   log="$(echo $d|sed -r 's!/(...)[^/]*!\1!g')dll.txt"
   'ls' -1 "$d"/*.dll >$log
   done
/tmp> wc -l *dll.txt
   230 bindll.txt
     6 windll.txt
  1624 winsysdll.txt
  1860 total
/tmp> cat *dll.txt|tee rawconcat.lst|sort|tee sorted_concat.lst|\
   uniq -d >zdups.lst; wc -l *.lst|grep lst
   1860 rawconcat.lst
   1860 sorted_concat.lst
      0 zdups.lst
--------
It doesn't appear that there should be any conflicts...unless I messed
something else up...


>   The native API, to the very best of my knowledge, exports exactly the same
> set of interfaces to every subsystem.  Can you explain exactly what you're
> talking about here?
----
	(reading ahead)...so MS is back to their old *illegal* tricks?
Wasn't them using "private" or "hidden" interfaces in the OS to make
their products run better one of the reasons for the monopoly suit -- or
an unfair trade-practice type suit?

	If they really only permit their version of a "POSIX" subsystem
to use certain WinNT calls, it would seem that's using their monopoly
power to exclude or degrade functionality in cygwin.  IANAL (but I've
been exposed to a few and seen them on TV! :-)), but that practice would
seem to be of questionable legality.

	Maybe while MS is "feeling in the mood" (forced by EU decisions) to
release specs of internals, someone (of properly, appropriate legal
'scariness') could nudge them on this if it would be useful to the cygwin?

	I wonder -- haven't tested it, but wonder if their posix
implementation handles allowing the removal of open files properly.
They could "do it under the covers"...any attempt to delete an open
file or write to an open file would silently move the locked file
to some 'temporary name' and mark it "delete-on-close" -- or at
worst, add it to the "pending delete&rename registry key" to be
deleted at next boot.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019