This is the mail archive of the
mailing list for the Cygwin project.
Re: Anecdotal: Rebase and Visual Studio 2015 and /etc
- From: "KARL BOTTS" <kdbotts at usa dot net>
- To: <cygwin at cygwin dot com>
- Date: Fri, 01 Jul 2016 17:12:49 -0500
- Subject: Re: Anecdotal: Rebase and Visual Studio 2015 and /etc
- Authentication-results: sourceware.org; auth=none
- Z-usanet-msgid: XID854ugawmY6432X34
> 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,
>> 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
> 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
Basically, that 32-bit software runs so smoothly under an opsys running on
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
I concur wholeheartedly: Cygwin is delightfully non-intrusive, given what it
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
next VS will be "XCOPY deployable", which means what sane software, such as
has always been. Mostly, it means they have to rip out all the dependencies
the goddamn Registry. Which will require many thousand kiddy-coder-hours,
>> 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,
> by some wild coincidence there is an overlap in memory load spaces.
"It" being Windows. That is why you get the screen after
"Configuring windows, please don't turn off your machine", and so forth.
Among other things, they are delay-replacing DLLs (for which there are
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
Good luck to him. Heroin might help.
Karl Botts, email@example.com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple