Re: cygwin Digest 15 Feb 2002 08:06:45 -0000 Issue 1759

Re: cygwin Digest 15 Feb 2002 08:06:45 -0000 Issue 1759

[Joshua Franklin]

Ralf, 

Is this presentation public domain? So it could be
used in classroom networking classes at a uni to 
help explain socket programming? I think it could be
helpful to others, as well. I think there are a few
professors who read the list.

> I'm sorry, I doesn't know that. You can find a
> viewer under
>
http://office.microsoft.com/germany/downloads/2000/Ppview97.aspx
> This presentation is a journey of the linux tcp and
> unix domain socket implementation and show very nice
> how the
> implementation works. An english translation is
> appended :-)
> Perhaps we can use it to create soemthing similar
> for cygwin. I think there are only changes nesessary
> in the
> functions names and functions levels, but the basics
> are the same.
> 
> Please be patiented with the presentation, I think
> the first pages will bore you, so skip to chapter 3,
> there are
> the interesting thinks. I think this could be a good
> starting point for discussion. Especially for guys,
> who are
> not very familiar with unix sockets (like I was)
> 
> Perhaps it would be good to give some hints, in the
> faq I haven't nothin about this topic ?
> 
> Ralf
> 


__________________________________________________
Do You Yahoo!?
Got something to say? Say it better with Yahoo! Video Mail 
http://mail.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Registry freedom

[Doru Carastan]

Hello everybody,

I believe it is time to break free from using the registry. It doesn't
allow for multiple versions to coexists, which creates a nightmare when
it comes to packaging Cygwin with another product. 

I've been rebuilding cygwin1.dll for a while with a custom shared memory
id and registry section and I know that it is possible to have a given
cygwin1.dll version coexist with its modified clone. Why not using
GetModuleFileName() to retrieve the path to the dll and look around it
for an mtab like ASCII file. Once the DLL path is retrieved the mtab
file can be searched in $dllDir/../etc/:$dllDir. If it is missing then
assume that there are no custom settings and use the defaults.

I wonder if this can be done. Does anyone see any technical problems?

Thank you,
Doru Carastan

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Registry freedom

[Christopher Faylor]

On Fri, Feb 15, 2002 at 10:16:42PM -0800, Doru Carastan wrote:
>Hello everybody,
>
>I believe it is time to break free from using the registry. It doesn't
>allow for multiple versions to coexists, which creates a nightmare when
>it comes to packaging Cygwin with another product. 

Hmm.  Packaging Cygwin with another product?  Sounds like you need to
talk to our sales department.

[Insert obligatory warning about GPL here]

>I've been rebuilding cygwin1.dll for a while with a custom shared memory
>id and registry section and I know that it is possible to have a given
>cygwin1.dll version coexist with its modified clone. Why not using
>GetModuleFileName() to retrieve the path to the dll and look around it
>for an mtab like ASCII file. Once the DLL path is retrieved the mtab
>file can be searched in $dllDir/../etc/:$dllDir. If it is missing then
>assume that there are no custom settings and use the defaults.
>
>I wonder if this can be done. Does anyone see any technical problems?

Of course its *technically* doable.

The biggest problem is technical support.  Now that you've set things
up so that you can have 27 different versions of cygwin on your system,
you'll have compounded our technical support alarmingly. I'm not going
to do this.  This isn't that big a problem for the normal release of
cygwin.

I can see why Wind River might have a problem since apparently you're
basing your Windows offering Red Hat's technology.  You probably don't
want to have to install your software into an existing commerical
directory that has the name "redhat" or "cygnus" in it.  However,
accomodating that really isn't a goal that I am very interested in.

If you want to make your own version of cygwin available and package it
with your now-GPLed product then, as you know, you have the power.  Just
make sure that no technical support shows up in cygwin@cygwin.com.

Regardless, I really don't see the problem.  You don't need to install
multiple versions of linux on your system to accommodate different
programs.  It is a little trickier on Windows but it is still not that
hard to do with the right installation software.

Of course, this is the same observation that I make whenever someone has
this interesting new idea.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Registry freedom

[Doru Carastan]

Christopher Faylor wrote:
> 
> On Fri, Feb 15, 2002 at 10:16:42PM -0800, Doru Carastan wrote:
> >Hello everybody,
> >
> >I believe it is time to break free from using the registry. It doesn't
> >allow for multiple versions to coexists, which creates a nightmare when
> >it comes to packaging Cygwin with another product.
> 
> Hmm.  Packaging Cygwin with another product?  Sounds like you need to
> talk to our sales department.

Not necessary. Actually is packaging WITH another product. Cygwin is
used as an enabler for rpm. rpm is the main tool of a cross platform,
package based, product install SDK that on Win32 hosts helps me be MS
Installer free. The only application linked against cygwin1.dll is and
encryption/decryption tool derived from mhash and mcrypt for which
source will be available together with the Cygwin, rpm and other GNU
tools used. I'll have someone talk with your sales before we release
anything to check things. If justified, buying a commercial license it
shouldn't be a problem.
 
> [Insert obligatory warning about GPL here]
> 
> >I've been rebuilding cygwin1.dll for a while with a custom shared memory
> >id and registry section and I know that it is possible to have a given
> >cygwin1.dll version coexist with its modified clone. Why not using
> >GetModuleFileName() to retrieve the path to the dll and look around it
> >for an mtab like ASCII file. Once the DLL path is retrieved the mtab
> >file can be searched in $dllDir/../etc/:$dllDir. If it is missing then
> >assume that there are no custom settings and use the defaults.
> >
> >I wonder if this can be done. Does anyone see any technical problems?
> 
> Of course its *technically* doable.
> 
> The biggest problem is technical support.  Now that you've set things
> up so that you can have 27 different versions of cygwin on your system,
> you'll have compounded our technical support alarmingly. I'm not going
> to do this.  This isn't that big a problem for the normal release of
> cygwin.

Cygwin and a minimal set of GNU packages is all what it gets installed.
I was seriously considering the impact to your support efforts. That is
why a private installation is needed.
 
> I can see why Wind River might have a problem since apparently you're
> basing your Windows offering Red Hat's technology.  You probably don't
> want to have to install your software into an existing commerical
> directory that has the name "redhat" or "cygnus" in it.  However,
> accomodating that really isn't a goal that I am very interested in.

You are making a false assumption. The Cygwin + custom GNU tools
installer I created installs this tools for system wide use by various
product installers.  The default location is %SystemDrive%\wrtools to
avoid cluttering an existing C:\cygwin.  Some users might have various
versions and is not a good practice to mess up what they have.  I really
don't want folks to be creative and make changes to the stuff I rely
on.  They can play with c:\cygwin if they want to.  I also advocate the
slogan "you package it, you maintain it".  

When the user starts a WR product installer he/she will be prompted for
a location to install for that media. The product install dir has no
connection whatsoever with the location of the Unix emulator providing
the POSIX API.

Obviously you have total control over your distribution. Probably other
developers will see the value and be more open to this since it can
simplify the debugging process.
 
> If you want to make your own version of cygwin available and package it
> with your now-GPLed product then, as you know, you have the power.  Just
> make sure that no technical support shows up in cygwin@cygwin.com.

Linking our products against cygwin1.dll is not the goal, neither use of
setup.exe. It's all about packaging and delivering. Our products
documentation clearly states how to get support. See
http://www.windriver.com/corporate/html/tsmain.html for more info.
 
> Regardless, I really don't see the problem.  You don't need to install
> multiple versions of linux on your system to accommodate different
> programs.  It is a little trickier on Windows but it is still not that
> hard to do with the right installation software.

I just can't wait to see Cygwin stable enough to bet the farm on it.
Unfortunately it is still on the bleeding edge with major changes every
3 months or so. We all know that it takes a lot of time and effort to
add features and stabilize the code. Until then one can only isolate and
use something perceived to be stable.

> Of course, this is the same observation that I make whenever someone has
> this interesting new idea.
> 
> cgf

Sincerely,
Doru Carastan

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Registry freedom

[Christopher Faylor]

On Sat, Feb 16, 2002 at 11:18:00AM -0800, Doru Carastan wrote:
>>I can see why Wind River might have a problem since apparently you're
>>basing your Windows offering Red Hat's technology.  You probably don't
>>want to have to install your software into an existing commerical
>>directory that has the name "redhat" or "cygnus" in it.  However,
>>accomodating that really isn't a goal that I am very interested in.
>
>You are making a false assumption.

Are you saying that your Windows tools don't use Cygwin?  I was under the
impression that you used the DLL.  Oh well, live and learn.

>The Cygwin + custom GNU tools
>installer I created installs this tools for system wide use by various
>product installers.  The default location is %SystemDrive%\wrtools to
>avoid cluttering an existing C:\cygwin.

It would hardly be cluttering to produce an /opt/wrtools.  That's what
you'd do on linux or something similar.  You wouldn't create your own
bin directory somewhere off the root on UNIX.

>Some users might have various versions and is not a good practice to
>mess up what they have.  I really don't want folks to be creative and
>make changes to the stuff I rely on.  They can play with c:\cygwin if
>they want to.  I also advocate the slogan "you package it, you maintain
>it".

That's fine, but none of this is really a goal for cygwin as I see it.

>When the user starts a WR product installer he/she will be prompted for
>a location to install for that media.  The product install dir has no
>connection whatsoever with the location of the Unix emulator providing
>the POSIX API.

Ok.  Then the mount table doesn't really matter at all.  Just ignore it.
Use /cygdrive/whatever for everything.

>Obviously you have total control over your distribution.  Probably
>other developers will see the value and be more open to this since it
>can simplify the debugging process.

I'm not sure what having other developers being more open to this might
mean since I'm not convinced in any way that it is a good thing.  I am
no more convinced now than I was the last two or three times this was
suggested.

Or, let me put it another way.  I'm always open to inspecting actual
source code patches.  Until then, I think my stance on "good ideas"
should be well known in this mailing list.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Registry freedom

[Doru Carastan]

> >The Cygwin + custom GNU tools
> >installer I created installs this tools for system wide use by various
> >product installers.  The default location is %SystemDrive%\wrtools to
> >avoid cluttering an existing C:\cygwin.
> 
> It would hardly be cluttering to produce an /opt/wrtools.  That's what
> you'd do on linux or something similar.  You wouldn't create your own
> bin directory somewhere off the root on UNIX.

For UNIX tools in a UNIX environment yes. My need is to control a
separate, 'stable' cygwin.dll + GNU tools installation. I can't put it
in RH distro /. It can cause both of us support problems. It is also
kind of installing the 'stable' distro in the /opt dir of an existing
one. It got to be separate.

> >Some users might have various versions and is not a good practice to
> >mess up what they have.  I really don't want folks to be creative and
> >make changes to the stuff I rely on.  They can play with c:\cygwin if
> >they want to.  I also advocate the slogan "you package it, you maintain
> >it".
> 
> That's fine, but none of this is really a goal for cygwin as I see it.

I can see your point. I thought that other users might need this too.
The lack of replies from other folks tell the story. I will put this on
my to-do list. I still believe it is worth looking into.

> >When the user starts a WR product installer he/she will be prompted for
> >a location to install for that media.  The product install dir has no
> >connection whatsoever with the location of the Unix emulator providing
> >the POSIX API.
> 
> Ok.  Then the mount table doesn't really matter at all.  Just ignore it.
> Use /cygdrive/whatever for everything.

That is what I thought in the beginning. What I discover later was that
yes I can start my own BASH with my own cygwin1.dll version but the DLL
will
read the existing mount table. One need to make sure there are no mount
points in the BASH path to avoid using stuff from the existing
installation. 

> I'm always open to inspecting actual
> source code patches.  Until then, I think my stance on "good ideas"
> should be well known in this mailing list.
> 
> cgf

Time allowing I will try to take a closer look and see what is the
magnitude of the change. You will definitely see a patch if I will be
able to make it work. Thank you Christopher.

Doru Carastan

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/