Question about old win32 api

Question about old win32 api

[Jacob.A.Lamberson]

Hi all,

I'm attempting to compile cygwin 1.7.18. I've made some progress, but have run into what appears to be an incompatibility between minGW's Win32 api and this version of cygwin. The same problem is identified here: https://sourceware.org/ml/cygwin/2013-10/msg00348.html. I have run into the same THREAD_INFORMATION_CLASS double declaration as the link, among other things. So far as I can tell, I need to get some older minGW Win32api packages to compile this. Could someone point me to these? I haven't been able to find anything besides the most recent version.

Thanks,

Jake


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

Re: Question about old win32 api

[Yaakov Selkowitz]

On Mon, 2015-09-21 at 16:10 +0000, Jacob.A.Lamberson@l-3com.com wrote:
> I'm attempting to compile cygwin 1.7.18. I've made some progress, but have 
> run into what appears to be an incompatibility between minGW's Win32 api 
> and this version of cygwin. 

Better yet, why are you trying to build such an old version?

--
Yaakov



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

RE: Question about old win32 api

[Jacob.A.Lamberson]

Yaakov,

Upgrading would be a pain, but I have to re-create the binaries I'm using from source.

-Jake

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Yaakov Selkowitz
Sent: Monday, September 21, 2015 11:53 AM
To: cygwin@cygwin.com
Subject: Re: Question about old win32 api

On Mon, 2015-09-21 at 16:10 +0000, Jacob.A.Lamberson@l-3com.com wrote:
> I'm attempting to compile cygwin 1.7.18. I've made some progress, but 
> have run into what appears to be an incompatibility between minGW's 
> Win32 api and this version of cygwin.

Better yet, why are you trying to build such an old version?

--
Yaakov



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

Re: Question about old win32 api

[Andrey Repin]

Greetings, Jacob.A.Lamberson@l-3com.com!

1. https://cygwin.com/acronyms/#TOFU pretty please.

> Upgrading would be a pain,

Who said that?...


-- 
With best regards,
Andrey Repin
Monday, September 21, 2015 22:24:28

Sorry for my terrible english...


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

Re: Question about old win32 api

[Michael Enright]

On Mon, Sep 21, 2015 at 12:25 PM, Andrey Repin  wrote:
> Greetings, Jacob.A.Lamberson@l-3com.com!
>
> 1. https://cygwin.com/acronyms/#TOFU pretty please.
>
>> Upgrading would be a pain,
>
> Who said that?...
>
>

PMFJI,

Between Cyg 1.5 and 1.7 the command-line interface changed on the "nc"
utility and, from the point of view of someone who at the time did not
read this list, it was a silent, breaking change. So I would not be
surprised if OP had a situation where recompiling an old version was
best.

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

RE: Question about old win32 api

[Jacob.A.Lamberson]

Hello anrdaemon@yandex.ru!

> 1. https://cygwin.com/acronyms/#TOFU pretty please.
> 
> > Upgrading would be a pain,
> 
> Who said that?...

1. Here we go.

2. While I doubt it would be technically difficult, it would be easier to keep the same version as far as good ol' corporate policy goes.

Sincerely,

Jake Lamberson

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

Re: Question about old win32 api

[Marco Atzeri]

On 21/09/2015 21:55, Michael Enright wrote:
> On Mon, Sep 21, 2015 at 12:25 PM, Andrey Repin  wrote:

>>
>>> Upgrading would be a pain,
>>
>> Who said that?...
>>
>>
>
> PMFJI,
>
> Between Cyg 1.5 and 1.7 the command-line interface changed on the "nc"
> utility and, from the point of view of someone who at the time did not
> read this list, it was a silent, breaking change. So I would not be
> surprised if OP had a situation where recompiling an old version was
> best.
>

the change in nc had nothing to do with cygwin
change between 1.5 and 1.7

https://sourceware.org/ml/cygwin-announce/2012-05/msg00015.html



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

Re: Question about old win32 api

[Marco Atzeri]

On 21/09/2015 22:02, Jacob.A.Lamberson@l-3com.com wrote:
> Hello anrdaemon@yandex.ru!
>
>> 1. https://cygwin.com/acronyms/#TOFU pretty please.
>>
>>> Upgrading would be a pain,
>>
>> Who said that?...
>
> 1. Here we go.
>
> 2. While I doubt it would be technically difficult, it would be easier to keep the same version as far as good ol' corporate policy goes.
>
> Sincerely,
>
> Jake Lamberson
>

than download all the source software from the Cygwin Time Machine

http://www.fruitbat.org/Cygwin/

Regards
Marco


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

Re: Question about old win32 api

[Michael Enright]

On Mon, Sep 21, 2015 at 1:31 PM, Marco Atzeri  wrote:
>
> the change in nc had nothing to do with cygwin
> change between 1.5 and 1.7
>
> https://sourceware.org/ml/cygwin-announce/2012-05/msg00015.html
>

Implying a tie between the nc version to the release of 1.7.0-0 was
wrong on my part. I am not wrong in this change to 'nc' did happen.
Because I was not tracking all things Cygwin all the time I didn't
know about it at first, and the people who had problems with it in my
world were those who had deployed new workstations with Cygwin 1.7
while those who could just keep using Cygwin 1.5 did not have
problems. The point is that Cygwin doesn't stay the same all the time
in the ways that all users may care about.

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

Re: Question about old win32 api

[Vince Rice]

> On Sep 21, 2015, at 7:04 PM, Michael Enright <mike@kmcardiff.com> wrote:
> 
> On Mon, Sep 21, 2015 at 1:31 PM, Marco Atzeri  wrote:
>> 
>> the change in nc had nothing to do with cygwin
>> change between 1.5 and 1.7
>> 
>> https://sourceware.org/ml/cygwin-announce/2012-05/msg00015.html
>> 
> 
> Implying a tie between the nc version to the release of 1.7.0-0 was
> wrong on my part. I am not wrong in this change to 'nc' did happen.
> Because I was not tracking all things Cygwin all the time I didn't
> know about it at first, and the people who had problems with it in my
> world were those who had deployed new workstations with Cygwin 1.7
> while those who could just keep using Cygwin 1.5 did not have
> problems. The point is that Cygwin doesn't stay the same all the time
> in the ways that all users may care about.

It did happen, and as Marco pointed out, it was _announced_ that
it happened. If someone is using Cygwin, not following the mailing
list (at the very least the announce list), and updating the software
blindly, then there's not much else to be done. They're almost
guaranteed to run into problems.

This is no different than any other software on the planet —
blindly updating Linux versions without knowing what’s in the
update, or blindly updating Word without knowing what’s in
the update, and so on, leads to the same thing — problems
can, and will, happen.
--
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

Re: Question about old win32 api

[Michael Enright]

On Mon, Sep 21, 2015 at 5:50 PM, Vince Rice  wrote:

>blindly

The blindness was blindness to the fact that new users were getting a
different version than existing users in some way other than fixing
vulns. Since Cygwin isn't the sort of product that needs to make up
sham reasons to upgrade as Microsoft Word does ("Look! A Ribbon!"),
one assumes that constant incorporation of upstreams, constantly
switching away from unmaintained upstreams to maintained-but-different
upstreams etc is what the Cygwin user base wants. Or at least most of
it.

Do Cygwin'ers ever debate or think about an LTS track for Cygwin? Is
that why there's a "time machine?"

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

Re: Question about old win32 api

[Vince Rice]

On Sep 21, 2015, at 8:11 PM, Michael Enright <mike@kmcardiff.com> wrote:
> 
> On Mon, Sep 21, 2015 at 5:50 PM, Vince Rice  wrote:
> 
>> blindly
> 
> The blindness was blindness to the fact that new users were getting a
> different version than existing users in some way other than fixing
> vulns.
> …

The blindness was, as I’ve already pointed out, caused by blindly
updating software without knowing the reason for the update. Had
you/they been doing so, you/they would have known there was a
“different” version. Again, it was _announced_ as being “different”.

Software changes. It changes whether you, or I, like it or not. It
changes for lots of reasons, some of them you/I might agree with,
some of them you/I might not agree with. Nevertheless, it changes.
Telling us it changed, and why, is good practice for software providers.
That was done here. Reading why it changed, and knowing how that
will affect us, is good practice for software users. That apparently
wasn’t done here. The fault does not lie with the software provider.
--
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

Re: Question about old win32 api

[Michael Enright]

On Mon, Sep 21, 2015 at 9:16 PM, Vince Rice  wrote:
>
> The blindness was, as I’ve already pointed out, caused by blindly
> updating software

No one was "updating"! I have diagnosed what I did "wrong" before and
I am satisfied with my conclusion. I don't yet know of a way to keep
changes from affecting me, but I know some things I can do to be
prepared for the changes that might happen, so I'm doing those things.

No one was updating. New workers needed new Windows boxes with Cygwin
on them. What is the process for putting Cygwin on a new Windows box?
It isn't "rsync Cygwin from IT".

Cygwin's default (or only) distribution method has a role to play in
this. Does anyone ever setup Cygwin on a new Windows install other
than by downloading setup_x86.exe or setup_x86-64.exe and working from
there? Is any such alternative given equal priority on cygwin.com ?

I am interested to hear if anyone has managed a group of Cygwin users
and the configuration they use, and how they went about it.

More out there, I'm interested in thoughts about making it possible to
tell a group such as a customer base (a group of autonomous,
free-will-possessing individual organizations) how to setup Cygwin so
a non-Cygwin component can be added on top and work even though it
might not still work with a regular default fresh Cygwin.

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

Re: Question about old win32 api

[Yaakov Selkowitz]

On Tue, 2015-09-22 at 10:16 -0700, Michael Enright wrote:
> No one was updating. New workers needed new Windows boxes with Cygwin
> on them. What is the process for putting Cygwin on a new Windows box?

Installing with Cygwin Setup.

> Cygwin's default (or only) distribution method has a role to play in
> this. Does anyone ever setup Cygwin on a new Windows install other
> than by downloading setup_x86.exe or setup_x86-64.exe and working from
> there? Is any such alternative given equal priority on cygwin.com ?

This is the only supported installation method.

--
Yaakov



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

Re: Question about old win32 api

[David Stacey]

On 22/09/15 18:16, Michael Enright wrote:
> New workers needed new Windows boxes with Cygwin
> on them. What is the process for putting Cygwin on a new Windows box?
> It isn't "rsync Cygwin from IT".
>
> Cygwin's default (or only) distribution method has a role to play in
> this. Does anyone ever setup Cygwin on a new Windows install other
> than by downloading setup_x86.exe or setup_x86-64.exe and working from
> there? Is any such alternative given equal priority on cygwin.com ?
>
> I am interested to hear if anyone has managed a group of Cygwin users
> and the configuration they use, and how they went about it.

We're drifting off topic, but never mind...

It sounds like you're deploying Cygwin in a corporate environment. Most 
corporate development environments require a degree of stability, and 
most Open Source programmes update faster than your average corporate 
software department can cope with. So *you* have to take responsibility 
for managing your own development environment.

In terms of Cygwin, that means downloading Cygwin setup and the packages 
you need, then testing, updating and patching until you have a Cygwin 
installation that meets your needs. How you deploy that to your 
engineers depends on your infrastructure:

   - Update a master VM image that your developers use;
   - Remote deploy the new Cygwin installation at the appropriate PCs;
   - Upload the Cygwin packages to a local web server and point Cygwin 
Setup at that (on each PC);
   - Store the Cygwin packages in whatever binary repository your 
company uses;
   - Get low-tech: Burn a DVD and pass it round the office(!)

Use this installation and keep your development environment stable until 
such a time when you're ready to update. Then repeat the process. Oh, 
and remember to archive your old development environment in some way, as 
sooner of later you're going to need to maintain an old build and you'll 
want to go back to how things were a couple of years ago.

Every company is going to have a different balance between stability and 
frequency of updates, and it would be impossible for Cygwin to come up 
with a model that works for everyone.

Hope this helps,

Dave.


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

Re: Question about old win32 api

[Achim Gratz]

Michael Enright writes:
> I am interested to hear if anyone has managed a group of Cygwin users
> and the configuration they use, and how they went about it.

I do and the only sane way is to have a local mirror with exactly the
packages and versions that you are going to install and your own
setup.ini.  I integrate Cygwin upstream, Cygwin Ports plus literally
hundreds of locally built packages via some scripting.  In principle
it's possible to provide multiple versions (e.g. for staged rollouts) by
having separate setup.ini files, but there's no automation for keeping
the mirror in sync at the moment.  I also compile setup.exe myself
(although at the moment I have no patches on top of upstream).  There's
a wrapper script around setup that will install the correct variant of
Cygwin initially and keep it updated later.

> More out there, I'm interested in thoughts about making it possible to
> tell a group such as a customer base (a group of autonomous,
> free-will-possessing individual organizations) how to setup Cygwin so
> a non-Cygwin component can be added on top and work even though it
> might not still work with a regular default fresh Cygwin.

You could replace the Cygwin key in setup.exe with your own, remove the
ability to install without the signature check and sign your setup.ini;
that should take care of any inadvertent use of the "wrong" Cygwin.
I've not done that yet, but eventually will so the installations can not
be manipulated without some real effort, even inadvertently.  If the
users still get themselves into trouble, then it's their problem, not
yours.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

Re: Question about old win32 api

[Michael Enright]

On Tue, Sep 22, 2015 at 10:54 AM, Yaakov Selkowitz  wrote:
>
> Installing with Cygwin Setup.
>
>
> This is the only supported installation method.
>

On Tue, Sep 22, 2015 at 10:59 AM, David Stacey wrote:
> We're drifting off topic, but never mind...

Thanks Yaakov, David, Achim, Vince and whoever else may be moved to
chime in.  I don't wish to take over the list with this subject. The
answers so far have given me much to think about, and are complete
enough that I don't need to ask follow-up questions at this time.

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

Re: Question about old win32 api

[Warren Young]

On Sep 21, 2015, at 7:11 PM, Michael Enright wrote:
> 
> The blindness was blindness to the fact that new users were getting a
> different version than existing users in some way other than fixing
> vulns.

Why should you believe that in the first place?  There is only one Cygwin, so why would you expect that it or its standard packages have had no features in the last N years?  You’d expect to see at least two different Cygwins, a stable one and a bleeding-edge one, if that were happening.

> one assumes that constant incorporation of upstreams, constantly
> switching away from unmaintained upstreams to maintained-but-different
> upstreams etc is what the Cygwin user base wants.

Yes, Cygwin is basically a bleeding-edge type of “OS” distribution.[*]  It ships whatever is current, as long as there are maintainers willing and able to keep its packages up to date.

This is the case because almost all of the packages in Cygwin are maintained by people who do not get paid by a Cygwin organization to do so.  These maintainers are either scratching their own itches or just plain volunteering.  Therefore, you get whatever is good for each package’s maintainer, which may or may not match with what is good for you.



[*] Never mind that Cygwin and its package set runs on top of an existing OS.  That’s a side issue, as far as this discussion goes.

> Do Cygwin'ers ever debate or think about an LTS track for Cygwin?

If it comes up, it does so so rarely that I can’t remember the last time it did.

LTS generally implies a business model,[**] and as far as I know, the current Cygwin business model only pays for one person’s time:

  http://www.redhat.com/services/custom/cygwin/

She’s plenty busy already without adding LTS distro maintenance on top of that.

I expect if the Cygwin support and license buy-out businesses were making enough money for Red Hat that an LTS version of it would already exist.

I suspect this is what is behind the weak push to get all packages cygport-ified and set up an automated build server.  But, this is still in the planning stages, AFAIK, and thus may never become a reality.


[**] Canonical is unprofitable, but has Shuttleworth’s millions backing its LTS releases.  Red Hat is very profitable, which indirectly sustains the RHEL clones,[***] but that’s no model for a Cygwin LTS, since you need RHEL to clone from in the fist place.

[***] And all the stuff built on top of RHEL clones indirectly sustains Red Hat, so it all works out.  But other than the license buy-out, I don’t see how people building stuff on top of Cygwin helps Red Hat.

> Is that why there's a "time machine?”

There is a time machine because Peter Castro has kindly decided to provide one. It is not an official product of the Cygwin project.  (The URL should have been enough of a clue as to this fact.)

The time machine could go away at any time.  We are grateful to have it for as long as it exists.
--
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