X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:mime-version:message-id
	:content-type:content-transfer-encoding; q=dns; s=default; b=MDC
	KuEgtbREplIh+w97VW6EgSfEqrY0cLBq6ydYOekJvr9QAYr3ORWKeDiyeU81WOJZ
	h+2/BuD4WcPO0KCbUYfgsYDVHWEEZzSjAyMc9e9rxonDYTdOwQcSnOHScO9vCqHA
	XyCI6cDJvGQjc+AmKI3yoFQo+mi+gGKHqSOyb+74=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:mime-version:message-id
	:content-type:content-transfer-encoding; s=default; bh=PCZa/hCyG
	kBMNdpt2+XsnNcElLY=; b=yxzaPwumpR43F3Tp4vSu+R4nFb+fD5SqNAcLLN8Wr
	/NnSYtHEdErpGWF4JfnbSeUkyAWZ405Ky0sn9jGa3Gn/ZaIsw90VSw39yN718VXj
	0XHap2vtwumYTi/5emVUZUuHneWiDN/rVcReY84X1igq2K0p/PA35IO9ULSO6276
	KY=
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
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=1.8 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,SPF_PASS autolearn=no version=3.3.2 spammy=latex, databases, smoothly, culture
X-HELO:	co02.mbox.net
X-USANET-Received:	from co02.mbox.net [127.0.0.1] by co02.mbox.net via mtad (C8.MAIN.4.02J) with ESMTP id 208ugawmY4432M02; Fri, 01 Jul 2016 22:12:50 -0000
X-USANET-Routed:	3 gwsout-vs Q:bmvirus
X-USANET-Routed:	3 gwsout-vs Q:bmvirus
X-USANET-GWS2-Tenant:	usa.net
X-USANET-GWS2-Tagid:	UNKN
X-USANET-Source:	165.212.11.134 OUT kdbotts AT usa DOT net ca34.cms.usa.net CLR
X-USANET-MsgId:	XID393ugawmY5217X02
X-USANET-Auth:	165.212.8.201 AUTO kdbotts AT usa DOT net web01.cms.usa.net CLR
Date:	Fri, 01 Jul 2016 17:12:49 -0500
From:	"KARL BOTTS" <kdbotts AT usa DOT net>
To:	<cygwin AT cygwin DOT com>
Subject:	Re: Anecdotal: Rebase and Visual Studio 2015 and /etc
Mime-Version:	1.0
Message-ID:	<157ugawLx3936S01.1467411169@web01.cms.usa.net>
Z-USANET-MsgId:	XID854ugawmY6432X34
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id u61MDMrZ010194

> A VS installation shouldn’t affect the rebase setup of Cygwin.

I'm with you.  But it did.  I am not blaming Cygwin; I am a friend of Cygwin.


>> Eventually, I reinstalled a fresh cygwin

> Did you install all the same things, or a minimal install,

Most of the same packages, but a from-scratch install.  And it is a pretty
light Cygwin: no gcc, no X, no Apache, no databases, no LaTeX...


>> 1) After you do the full rebase, before you even start anything cygwin,
reboot
>> Windows, then start a bash or something. Reboot Windows, early and often,
>> whenever upgrading anything.

> I’ve never had to resort to such voodoo to keep Cygwin going. The
standard
> schedule of reboots due to Patch Tuesday has been sufficient.

I resort to such voodoo to keep Windows going.  Windows is much better than
it used to be, but I still say: whenever you feel nervous about the state of
Windows, reboot it.  You will feel better, even if it doesn't.
Voodoo is not always sufficient: silver crosses and garlic help, too.


BTW: I use Cygwin32 on Windows-64.  I'm happy with that.  Windows itself also
uses lots of 32-bit components even under Win-64.  In fact, VS itself is
a (very large) 32-bit app.  There are good reasons for that, for them and for
us.
Basically, that 32-bit software runs so smoothly under an opsys running on
Intel64,
is one of the latter's best features.


> Cygwin should never cause a Windows box to become unbootable. It simply
> doesn’t get its hooks into the system deeply enough to cause such
trouble,

I concur wholeheartedly: Cygwin is delightfully non-intrusive, given what it
does.
I have never seen Cygwin hose Windows: only the reverse.
MS should take a lesson.  In fact, I think they are trying: they claim that
the
next VS will be "XCOPY deployable", which means what sane software, such as
Cygwin,
has always been.  Mostly, it means they have to rip out all the dependencies
on
the goddamn Registry.  Which will require many thousand kiddy-coder-hours,
methinks.


>> And, it moves DLLs around, even installs more, on the way back up.

> “It” being Windows, or Cygwin?
> If the former, new Windows DLLs shouldn’t interfere with Cygwin DLLs,
unless
> by some wild coincidence there is an overlap in memory load spaces.

"It" being Windows.  That is why you get the screen after
install-stuff-then-reboot,
"Configuring windows, please don't turn off your machine", and so forth.
Among other things, they are delay-replacing DLLs (for which there are
special
Windows syscalls).  Also, they "rebase" lots of DLLs, notably .NET.Framework
parts, to try to optimize load time, by avoiding runtime fixups: they don't
really use PIC code, if at all.  Given all that, it does not seem to me that
some load-address conflicts would be a "wild coincidence".


> Because Satya Nadella has been in charge for only about two years now.

You think he's in charge?  Ha-ha, I bet so did he, when he took the job.
But he is trying to change a corporate culture, without breaking too many
eggs.
Good luck to him.  Heroin might help.
 

---
Karl Botts, kdbotts AT usa DOT net


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

- Raw text -