Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <17B78BDF120BD411B70100500422FC6309E0C5@IIS000>
From: Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
To: "'Robert Collins'" <robert DOT collins AT itdomain DOT com DOT au>,
        cygwin AT sources DOT redhat DOT com
Subject: RE: DLL naming conventions
Date: Mon, 4 Sep 2000 15:50:10 +0200 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Robert Collins [mailto:robert DOT collins AT itdomain DOT com DOT au]
> Sent: Monday, September 04, 2000 2:44 PM
> To: cygwin AT sources DOT redhat DOT com
> Subject: Re: DLL naming conventions
> 
> 
> ...
> 
> > > However, no modeless users (except for Paul) have 
> complained.  Perhaps
> > > Paul should become modal. :-)
> >
> > The problem iw that when you say "modal" you are really 
> saying that we
> > should have several sandboxes and that a programm from 
> sandbox "cygwin"
> > could not play with (i.e. call) a program with sandbox "pw32" or
> "mingw32";
> > that was exactly what render the Win32 Posix subsystem so 
> inattractive: it
> > can't mix with win32.
> >
> > Here the situation would only be slightly better: it may 
> work by chance
> and
> > suddenly fall apart in the wrong place (i.e. I added 
> something to mingw32
> > sandbox, and then a program from the cygwin sandbox no more works,
> assuming
> > I need to call some mingw32 program from cygwin bash...)
> >
> > I *know* that having cygpng.dll instead of libpng.dll is a 
> bit of a burden
> > for cygwin maintainers, but defining the convention and 
> using it to all
> new
> > ports should prevent the problem to suddenly arise when 
> there will be more
> > conflict than the apparently isolated zlib problem.
> 
> but this also means that mingw32 program won't use the cygwin compiled
> libpng if it is there? is that acceptable?

Not only acceptable but usually needed, as the mingw32 program will use (for
example) MSVCRT version of free() to free some memory allocated by CYGWIN
version of malloc() called from cygwin-compiled libpng; all this will have
one more than probable result: SEGFAULT ;-(

> -> if we are looking to keep the sandbox's separate then 
> yes.. but why care
> about running a (say) mingw32 program from cygwin bash...

Because perhaps some program that is not GPLed nor GPLable was ported from
UNIX to NT and thus cannot be using cygwin...

BTW this mean there must be a way to ensure that a program not compiled for
cygwin will not by error link against cygwin1.dll through some other DLL or
that program will become GPLed without its author being aware of it!...
Hopefully the program will crash without doing anything meaningful I think
so that's not too bad :-)

> -> if we are looking to let things cross the sandbox we 
> should decide _what_
> things, (ie bin/pipes, bin/pipes/libs, binaries only..) we are able to
> support and then make it as flexable as possible.

Anything tha'ts natively supported on WIN32 for inter-process-communication
should be usable and is for now I think, at least starting programs,
reading/writing files, sockets and probably pipes. 

Libs on the opposite are usually NOT mixable between environments. (note
that it's not even possible to link a program using MSVCRT.DLL with a
library built against CRTLIB.DLL, even if they are both almost
source-compatible, and not even possible to mix various versions of
MSVCRT.DLL); so we should not only forget about mixing
native/cygwin/mingw32/PW libraries but I would even favor forbidding it.

The only thing that is needed is that low-level native WIN32 DLLs should be
accessible from all "sandboxes" but the reverse is usually not possible
because the C runtime environments will be incompatible. We have exactly the
same problem on Linux: any program can access the kernel, but a
libc5-compatible library cannot call code from a libc6-compatible one and
vice-versa.

> 
> I think we need to make that decide first, and then the rest 
> falls into
> place....
> 

Sure :-)

> if we want full cross over from the sandboxes then the answer 
> should permit
> only porting layer/method to use another libraries. So a port 
> layer/method
> specific library naming convention is not acceptable. 

I presume you say: suppressing any barrier between sandboxes (i.e. on Linux
should be between libc5 and libc6); I do not think this is even possible.

> likewise if we want
> sandboxes then porting layer/method specific library file 
> names becomes
> mandatory.

This would be what we get now under Linux: programs compiled under libc5 and
libc6 are able to work together freely, but not to share code.

> 
> Personally I think that a mingw32 libpng should be useable by 
> cygwin gcc AND
> cygwin distributed binaries, given that they are the same 
> version... (and
> that should be part of the naming convention).

This would only work if libpng makes NO calls to the C Runtime Library (that
is do NOT depend on MSVCRT.DLL or CRTDLL.DLL); otherwise the program will
just crash.

Cheers,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux AT microprocess DOT com
		b DOT dautrevaux AT usa DOT net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com