Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com From: "Andy Moreton" To: "'Robert Collins'" , Subject: RE: dlsym discussion.. Date: Mon, 4 Jun 2001 10:08:00 +0100 Message-ID: <006801c0ecd5$db486d80$2b0b070a@cam.virata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <023c01c0ec36$7da728f0$0200a8c0@lifelesswks> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal > -----Original Message----- > From: cygwin-developers-owner AT sources DOT redhat DOT com > [mailto:cygwin-developers-owner AT sources DOT redhat DOT com]On Behalf Of Robert > Collins > Sent: Sunday, June 03, 2001 3:07 PM > To: cygwin-developers AT cygwin DOT com > Subject: Re: dlsym discussion.. > > > ---- Original Message ----- > From: "Christopher Faylor" > > > Thoughts? I'm a bit hesitant at trying to second guess what > > > dll's have been implicitly loaded by the Win32System, but if > > > that information is readily available to cygwin, I'm happy to > > > code up a iterating dlsym(). > > > > cygwin keeps a list of DLLs loaded via dlopen. It could register > > other modules via dll_entry() but that is not a foolproof method > > due to load order problems. > > BTW: There's no rush on this for me - it doesn't affect what I'm doing - > I'm just interested in seeing if I can find a way to provide the unix > dlsym behaviour. Likewise no-one in userland is complaining about this, > so I hope it won't suddenly become an issue. > > Hmm. Well it seems to me there are two sets of dlls: implicitly loaded > dll's that we were linked against, and > "modules"/"plugins"/whateveryouwanttocallthem that get dlopened. > > Both should behave the same, but the key difference is that implicitly > loaded dll's should be visible to a dlopen(NULL,);dlsym() combination, > whereas "modules" will give us access to a path name. Thus tracking via > dlopen()'s isn't likely to provide a comprehensive list. Looking at this from the Win32 side of things, perhaps you should look at the ToolHelp library, in particular CreateToolHelp32Snapshot(), Module32First(), and Module32Next(). This will give you a list of all modules for the current process. Checking the module handle against the list maintained by cygwin should give the information you need. HTH, AndyM -- Virata, Unit 230 Cambridge Science Park, Milton Road, Cambridge CB4 4WB, UK http://www.virata.com/ Tel: +44 1223 707400 Fax: +44 1223 707447