This is the mail archive of the cygwin 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: Anecdotal: Rebase and Visual Studio 2015 and /etc


> 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@usa.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


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