MIME-Version: 1.0
Content-Type: text/plain;	charset="utf-8"
Content-class: urn:content-classes:message
Subject: RE: Oracle OCI under cygwin
Date: Wed, 7 Mar 2012 16:37:40 +0100
Message-ID: <6BFA9AF2C7556E42AFF3F187ECAB07B802DAF9BB@bespdc01.mediaxim.local>
In-Reply-To: <20120307145527.GI5159@calimero.vinschen.de>
References: <6BFA9AF2C7556E42AFF3F187ECAB07B802DAF981@bespdc01.mediaxim.local> <20120307144649.GH5159@calimero.vinschen.de> <20120307145527.GI5159@calimero.vinschen.de>
From: "Michel Bardiaux" <MBardiaux@mediaxim.be>
To: <cygwin@cygwin.com>
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Content-Transfer-Encoding: 8bit

> Cygwin applications don't use the WIN32 environment.  Rather they have 
> their own copy of the environment in a POSIX layout.  What happens is 
> probably that the OCI lib calls GetEnvironmentString ("TNS_ADMIN",...) 
> and gets nothing back, since the variable is just not in the Win32 
> environment of the Cygwin application.
> 
> The workaround is to do this before calling ani OCI lib function:
> 
>   #include <sys/cygwin.h>
> 
>   cygwin_internal (CW_SYNC_WINENV);
> 
>  This call copies the POSIX environment over to the Win32 environment
>  of the calling process, so the OCI lib functions should find the
>  TNS_ADMIN variable when called *after* the above call.

This worked like a charm. Thank you.

I suppose the same should be done whenever one calls a function in a non-cygwin DLL that relies on Win32 environment variables?