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

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Friday, January 05, 2001 8:51 AM
Subject: Re: PATCH: Cygwin: file mode support and ufs writecleanswap bugfix

> Robert Collins wrote:
>
> > Have you looked into cygwin? It is native code.
>
> Erhm... yes you can write code which uses the native interfaces in
> cygwin, but not that easily. The default build mode is UNIX emulation,
> which does change quite many standard-C functions to behave in a more
> UNIX:ish manner compared to pure native compilers.

Actually very easily. Perhaps a year or so ago it was difficult, but it is becoming much easier nowadays. (As I already indicated
the inetd shipped with cygwin is 'mixed' if that term grabs you.

>
> There is an option to link with a smaller runtime library (mingw I think
> it is called), however last time I looked there was no good set of
> header files to use together with that library.

mingw is a completely different toolkit. Cygwin does ship with a separate set of headers for it, triggered by the --no-cygwin option
to gcc. Mingw uses the microsoft CRT library to provide a very small set of unix like routines. It doesn't provide a runtime library
at all - and doesn't provide the unix-like environment cygwin does. (I.E. unix style process enumeration/path
management/dl_open/....)

> > 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)
>
> True, unless you manage to get autoconf to use the MS compiler.. isn't
> there a command line mode for it? if so it should be little more than
> setting the variable CC when calling configure..

Microsoft? Command line? Seriously there used to be a command line version, but I'm thinking back to Visual C, not C++. There may
still be - and certainly don't object to other's using MS compilers. (BTW: Cygwin && mingw can both compile 'native' code - that is
to say that you do not need to link programs compiled under cygwin to cygwin1.dll. In other words once I get time you will be able
to build Romeo and Serassio's code with gcc without linking cygwin1.dll in).

> > 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.
>
> Well, there is not that many pecularities. The major one being the
> separation of files and sockets, but given the direction things are
> takin this is not a major obstacle.

File path semantics. IPC is different. threading is different. But most of these things will fit very neatly into modularised code
(as you say).

> Then there is a differen process model which is relevant for how
> helpers.

Sure. My point is that cygwin *is native* and *runs on window 9x*. One of my interests in caching is massively distributed LAN
caches - ie 3 Mb of ram on every workstation on a LAN running a background cache. Not that I have time to work on pure research
goals at the moment :-[.

> > 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.
>
> I will import the NT port to sourceforge as soon as Serassio Guido has
> posted the latest version of his sources..

I have them - they are available on his web page. Do you want to me import it?

Rob
Received on Thu Jan 04 2001 - 17:10:59 MST