Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID:	<37271344.90F42BF5@bgs.com>
Date:	Wed, 28 Apr 1999 09:55:16 -0400
From:	Eugene Kanter <eugene AT bgs DOT com>
X-Mailer:	Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language:	en
MIME-Version:	1.0
CC:	cygwin AT sourceware DOT cygnus DOT com
Subject:	Re: putenv does not put env into win32?
References:	<Pine DOT SUN DOT 3 DOT 93 DOT 990427205504 DOT 16286B-101000 AT modi DOT xraylith DOT wisc DOT edu>

Mumit Khan wrote:
> 
> On Tue, 27 Apr 1999, Eugene Kanter wrote:
> 
> >
> > I did not find where it says to use dlopen. I replaced LoadLibrary with
> > dlopen and received the identical results. The advantage of using dlopen
> > over LoadLibrary is that I did not have to convert Unix path to Windows
> > path. I did not look at the actuall cygwin code (where?). I guess dlopen
> > calls LoadLibrary eventually. However I must call CoFreeLibrary() at the
> > end (OLE requires) so I guess I must use LoadLibrary.
> >
> > Still in magic why mingw32 application allows me to change PATH so all
> > DLLs could be loaded and cygwin does not. You mentinoed that putenv
> > modifies only current process environment. Which process does the dll
> > loader belongs to?
> >
> > I solved the problem eventually by doing chdir(). However what if more
> > then one directory is required to be added to the path??
> 
> Hi Eugene,
> 
> I haven't followed the thread, but adding to PATH using putenv() should
> and does work with B20.1, at least on NT where I tested it. I'm attaching
> a small testcase. Here's what it does when you run make:
> 
>   - create a subdirectory called "foo"
>   - create a small DLL in "foo"
>   - create a dll caller that uses dlopen after adding "foo" to PATH.
> 
> Please let me know if this helps (or if it doesn't work).
> 
> This is code from the time when I was testing dlopen implementation prior
> to b20.1, so hopefully it's still working ... In theory, LoadLibrary
> should work just as well.
> 
> There should be no issue for parent process and so on here, since PATH
> belongs to the current, which is looking for the DLL.
> 

Mumit,

Your test works just fine. However it does not exactly exersize my
conditions. I guess I must clarify.

I am trying to register a selfregistered DLL (OLE server kind of). The
registration done by calling function DllRegisterServer from the DLL to
be registered, let's name it DLLA. DLLA requires DLLB to function. DLLB
is just a regular dll located in the same directory (name it DIRDLL) as
DLLA outside of the PATH enviroment.

Results:

cygwin

adding DIRDLL to the PATH (getenv/putenv) and calling
LoadLibrary("DIRDLL/DLLA") (or dlopen("DIRDLL/DLLA",RTLD_NOW)) fails
ONLY if current directory (chdir()) is not DIRDLL.

mingw32

adding DIRDLL to the PATH using getenv/_putenv and calling
LoadLibrary("DIRDLL/DLLA") always worked.

Eugene.

PS. ldd output:

bash-2.02$ ldd /test/DLLA.dll
DLLA.dll        -> /test/DLLA.dll
DLLB.dll        -> /test/DLLB.dll
mfc42u.dll      -> /WINNT/system32/mfc42u.dll
msvcrt.dll      -> /WINNT/system32/msvcrt.dll
kernel32.dll    -> /WINNT/system32/kernel32.dll
user32.dll      -> /WINNT/system32/user32.dll
advapi32.dll    -> /WINNT/system32/advapi32.dll
shell32.dll     -> /WINNT/system32/shell32.dll
comctl32.dll    -> /WINNT/system32/comctl32.dll
ole32.dll       -> /WINNT/system32/ole32.dll
oleaut32.dll    -> /WINNT/system32/oleaut32.dll
msvcirt.dll     -> /WINNT/system32/msvcirt.dll
msvcp50.dll     -> /WINNT/system32/msvcp50.dll
ws2_32.dll      -> /WINNT/system32/ws2_32.dll
gdi32.dll       -> /WINNT/system32/gdi32.dll
ntdll.dll       -> /WINNT/system32/ntdll.dll
ws2help.dll     -> /WINNT/system32/ws2help.dll
rpcrt4.dll      -> /WINNT/system32/rpcrt4.dll
bash-2.02$

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

- Raw text -