Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Tue, 27 Apr 1999 22:06:24 -0400
Message-Id: <199904280206.WAA05486@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: fortinj AT ibm DOT net
CC: cygwin-developers AT sourceware DOT cygnus DOT com
In-reply-to: <37266BBC.F8F24A3A@ibm.net> (fortinj@ibm.net)
Subject: Re: cygwin1.dll startup and GDB
References: <37265A6E DOT 813F8ED8 AT ibm DOT net> <199904280131 DOT VAA28701 AT envy DOT delorie DOT com> <37266BBC DOT F8F24A3A AT ibm DOT net>


> 	Either way, mapname will be NULL since NULL is being passed as the
> first parameter to open_shared.

Not always.  When NULL is passed, we musn't call OpenFileMapping(),
because it doesn't fail gracefully when passed NULL.

There are three cases this code handles:

* name==NULL - create a private shared memory area

* name!=NULL, area doesn't exist - create a public named area

* name!=NULL, area does exist - attach to existing public named area

> My understanding ( misunderstanding :) ) was that with OpenFileMapping()
> a name for the shared memory was needed.  However, we are passing a NULL
> pointer to it instead...

Not always.  Sometimes we pass a name.  When we pass a name, we try
OpenFileMapping() to see if the area exists (was created by another
process, for example).  If the area doesn't exist, we drop through and
try creating it.  If we pass NULL, we will always be creating the area
anyway, so skip the open and go right to the create.

> Is OpenFileMappingA() different.  I only have a reference for
> OpenFileMapping().

FooA() and FooW() are the ascii/wchar variants of Foo().  Windows
macros normally hide them.