Thanks everyone for your responses. Like I mentioned in my original
post, I was looking for some APIs to get the ports and the
corresponding processes "programatically". I am not inclined to use
netstat or lsof for two reasons:

1. External program. May not be available. Hence cannot depend on it.
2. External program. Don't want to spawn a process.

It seems that there is no easily available documentation for doing
this especially on Windows. There has to be a way which is why netstat
, Openfiles and PortQuery work. But I was not able to lay my hands on
any document for that (or some sample code).

I will continue to search for it. Else I'll start to think of the
external utilities or some workarounds for my requirements.

Regards,
AS

--- In [email protected], Thomas Hruska <[EMAIL PROTECTED]> wrote:
>
> Indika Bandara Udagedara wrote:
> > --- In [email protected], "Paul Herring" <pauljherring@> wrote:
> >> On Wed, Aug 27, 2008 at 6:29 AM, Thomas Hruska <thruska@> wrote:
> >>> Amitabh Shukla wrote:
> >>>> Greetings
> >>>>
> >>>> I need to get the process name that is using an open port on
Windows
> >>>> and Unix programatically in C. On unix I think the best way may be
> >>>> read the /proc fs.(I would be glad to know of a better/more
portable
> >>>> way.) I don't know how to obtain that information on Windows.
> >>>> Please help me with some pointers on how to go about it.
> >>>>
> >>>> Thanks,
> >>>> AS
> >>> Hmm...not sure about *NIX, but the simplest way would be to
> > capture the
> >>> output of 'netstat -o' under Windows (Win2000 and later) and then
> > parse
> >>> it.  'netstat' exists for *NIX, but I don't know if it maps open
> > sockets
> >>> to process IDs.  That would be the most portable (albeit "hacky")
> > method.
> >> netstat -p
> >>
> >> -- 
> >> PJH
> >>
> >> http://shabbleland.myminicity.com/
> >>
> > 
> > why not lsof ?
> 
> That could work too.  'netstat' is more likely to be installed. 
> Regardless, the point of this discussion is that there is no very 
> "portable" method of doing it and any APIs that the OS may or may not 
> expose may or may not be documented.  Any APIs that are exposed are
also 
> likely going to be difficult to use as they will tend to dig around in 
> the nitty-gritty details of the OS.  It would be best to let an
external 
> program handle those parts.  'lsof' doesn't exist on Windows but the OP 
> could write multiple parsers to cover a larger set of scenarios.
> 
> -- 
> Thomas Hruska
> CubicleSoft President
> Ph: 517-803-4197
> 
> *NEW* MyTaskFocus 1.1
> Get on task.  Stay on task.
> 
> http://www.CubicleSoft.com/MyTaskFocus/
>


Reply via email to