Re: PATCH: Cygwin: file mode support and ufs writecleanswap bugfix

I believe you may have meant to cc this back to the list? I recall Henrik mentioning you had a problem with the Reply All button on
your mail client? (grin).

----- Original Message -----
From: "Adrian Chadd" <adrian@creative.net.au>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Sent: Thursday, January 04, 2001 11:10 PM
Subject: Re: PATCH: Cygwin: file mode support and ufs writecleanswap bugfix

> On Thu, Jan 04, 2001, Robert Collins wrote:
> > A) When I first looked at Romeo's port it was of 2.2 and was feature incomplete
> > B) It is an 'NT' port. The cygwin port runs on windows 9x & ME as well. This raises possibilities of massively distributed
caches.
>
> What would be needed to have it run natively on all three. I haven't
> hacked windows code for such a long time ..

Have you looked into cygwin? It is native code. Cygwin provides a .dll that the programs are linked to which provides the Unix API.
Direct access to all windows functions is possible (without translation or any fluff). But it's optional. For example inetd is
linked to cygwin.dll but integrates with the Service Control Manager and runs as a service. So the Cygwin port is also a native port
(in a very real sense). There is _one_ key difference: cygwin currently shares memory across all cygwin1.dll linked process's as
part of it's unix-API provision. This does raise a possible security issue. I do not know if the process's memory is opened, or just
the things used by cygwin1.dll.

I run squid 2.4 as a different user as a service using a thing called SrvAny from the NT resource kit on the local server at the
office and I have not had any unexpected issues with it. There are a few things (pid file semantics for service restarts) that I
plan to fiddle with when I get some time.

>
> > C) Romeo's NT port requires MS Visual C to compile - not all developers users have that.
>
> Ah, thats a good point.

Also the NT port does not use ./configure. So turning on/off authentication schemes/helpers/modio modules and the like has to be
done by hand. (And just hope that there are no interrelated settings in the autoconf.h file)

>
> > D) new development is being done by you guys in a UN*X platform - I don't believe that Romeo's port supports shared mem daemons
>
> Shared memory is only being used by diskd.

Sure. The point I meant to make was that the unix based developers will not (nd I believe it is unreasonable to ask them to) take
into consideration the peculiarities of the Win32 environment when coding.

>
> > (which cygwin can).
>
> > E) Currently the NT port requires work at each step to bring it up to date - because cygwin is 'unix like' little or no work
should
> > be required on each release to bring it up to date.
> > F) I am aiming at slowly bringing across the 'native' NT features as configure script options for Cygwin.
> >
>
> Ok. I should look at the differences between Romeo's latest NT port
> and the tree its based upon, as I'm curious to know what needs

2.3 stable4. I can drop a diff to the list if folk are interested. I was considering starting a new branch on sourceforge and then
syncing that up to HEAD. But I sat back and thought that bringing the bits and pieces into the cygwin branch is an easier bet.

> changing. I'd hope that with the modio and commloops work squid
> would become modular enough to just need "NT modules" (and
> perhaps some extra bits like a memory allocator..)

Lots of things. I don't agree with them all as a matter of fact (but that's a different topic). The comms calls are wrapped to WSA
(windows sockets), syslog & daemon mode is disabled, the registry is parsed instead of /etc/resolv.conf for DNS configs, Squid runs
as a service not a background process. I don't believe the ufs module has _any_ changes for windows (I haven't checked yet either
:-/ ).

The OS/2 code makes the number of changes relatively small. There are some optimisations to use async disk calls (provided by the
win32 API) that would be very useful.

But as I said - I am planning to bring a lot of it over to the 'cygwin' branch anyway. They can coexist. Cygwin provides things like
syslog that I happen to find _very_ useful, and running as a service is no good for development _OR_ for use on windows 9x/98/ME.

Rob
Received on Thu Jan 04 2001 - 05:53:30 MST