Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[burakkucat]

Code: [Select]

PIDOF(8)              Linux System Administrator’s Manual             PIDOF(8)



NAME
       pidof -- find the process ID of a running program.

SYNOPSIS
       pidof [-s] [-c] [-x] [-o omitpid] [-o omitpid..]  program [program..]

DESCRIPTION
       Pidof  finds  the process id’s (pids) of the named programs. It prints those id’s on the standard output. This program is on some sys-
       tems used in run-level change scripts, especially when the system has a System-V like rc structure. In that  case  these  scripts  are
       located in /etc/rc?.d, where ? is the runlevel. If the system has a start-stop-daemon (8) program that should be used instead.

OPTIONS
       -s     Single shot - this instructs the program to only return one pid.

       -c     Only return process ids that are running with the same root directory.  This option is ignored for non-root users, as they will
              be unable to check the current root directory of processes they do not own.

       -x     Scripts too - this causes the program to also return process id’s of shells running the named scripts.

       -o omitpid
              Tells pidof to omit processes with that process id. The special pid %PPID can be used to name the parent process of  the  pidof
              program, in other words the calling shell or shell script.

EXIT STATUS
       0      At least one program was found with the requested name.

       1      No program was found with the requested name.

NOTES
       pidof is actually the same program as killall5; the program behaves according to the name under which it is called.

       When  pidof  is invoked with a full pathname to the program it should find the pid of, it is reasonably safe. Otherwise it is possible
       that it returns pids of running programs that happen to have the same name as the program you’re after but  are  actually  other  pro-
       grams.  Note  that that the executable name of running processes is calculated with readlink(2), so symbolic links to executables will
       also match.


SEE ALSO
       shutdown(8), init(8), halt(8), reboot(8), killall5(8)

AUTHOR
       Miquel van Smoorenburg, miquels@cistron.nl



                                  01 Sep 1998                         PIDOF(8)


[Bald_Eagle1]

KILL(2)                    Linux Programmer’s Manual                   KILL(2)

NAME
       kill - send signal to a process

Unfortunately, the part I have highlighted in red above is a problem.
There doesn't appear to be an alternative function readily available for Windows systems.

However, RONSKI & I may have found a couple of potential methods that might work.

[burakkucat]

B****y BGW!   

[kitz]

Unfortunately, the part I have highlighted in red above is a problem.
There doesn't appear to be an alternative function readily available for Windows systems.

However, RONSKI & I may have found a couple of potential methods that might work.

Ive never programmed in C, but in java you can pass commands to the o/s using the API method  runtime.exec(). I presume there has to be something similar in C and an equivalent runtime method?

From there you can issue commands direct to the o/s via the command line
The windows commands that you will need are

Taskkill & Tasklist

1) Use the tasklist command to get all the running processes using the runtime method and send them to a new array

Code: [Select]

Runtime.getRuntime().exec("tasklist");
Youre now going to have to check for HG612stats.exe & get its PID from the array.  Creating the array and then reading it to get the PID should be the hardest part - or at least for me as I was never much good with BufferedReaders and I'd have to look the code up.

Anyway, when you have the PID you can kill it - to do this
Set up the windows kill command ready & then pass it back again as a runtime

Code: [Select]

String Kill_PID = "taskkill /pid";

Runtime.getRuntime().exec(Kill_PID + PID);
2) OR  You could possibly cheat and go straight for the process name

Code: [Select]

String Kill_ProcessName = "taskkill /im";
String ProcessName = "HG612_stats.exe";

Runtime.getRuntime().exec(Kill_ProcessName + ProcessName);

However the above is said with trepidation as I was taught to always target the PID because it supposedly works more elegantly over different operating systems and our tutor classed it as a cheat by not first running a tasklist check and reading through the array to get the PID.  Im also not sure if by running just on the ProcessName if it kills all or just the first.  Could always check in cmd to see what happens I guess. 

[kitz]

  Im also not sure if by running just on the ProcessName if it kills all or just the first. 

The answer to that question is in the Taskkill command url that I linked to above.

"Ends one or more tasks or processes. Processes can be killed by process ID or image name".

Therefore implying that by passing the very simple  taskkill /im HG612stats.exe it will kill all running instances

So if you can find the C equivalent of runtime.exec() youre cooking on gas.  Simples!

[burakkucat]

Code: [Select]

SYSTEM(3)                  Linux Programmer’s Manual                 SYSTEM(3)



NAME
       system - execute a shell command

SYNOPSIS
       #include <stdlib.h>

       int system(const char *command);

DESCRIPTION
       system()  executes  a  command  specified  in command by calling /bin/sh -c command, and returns after the command has been completed.
       During execution of the command, SIGCHLD will be blocked, and SIGINT and SIGQUIT will be ignored.

RETURN VALUE
       The value returned is -1 on error (e.g.  fork(2) failed), and the return status of the command otherwise.  This latter  return  status
       is  in the format specified in wait(2).  Thus, the exit code of the command will be WEXITSTATUS(status).  In case /bin/sh could not be
       executed, the exit status will be that of a command that does exit(127).

       If the value of command is NULL, system() returns non-zero if the shell is available, and zero if not.

       system() does not affect the wait status of any other children.

CONFORMING TO
       C89, C99, POSIX.1-2001.

NOTES
       If the _XOPEN_SOURCE feature test macro is defined, then the macros described in wait(2) (WEXITSTATUS(), etc.) are made available when
       including <stdlib.h>.

       As  mentioned, system() ignores SIGINT and SIGQUIT.  This may make programs that call it from a loop uninterruptible, unless they take
       care themselves to check the exit status of the child.  E.g.

           while (something) {
               int ret = system("foo");

               if (WIFSIGNALED(ret) &&
                   (WTERMSIG(ret) == SIGINT || WTERMSIG(ret) == SIGQUIT))
                       break;
           }

       Do not use system() from a program with set-user-ID or set-group-ID privileges, because strange values for some environment  variables
       might  be  used  to  subvert system integrity.  Use the exec(3) family of functions instead, but not execlp(3) or execvp(3).  system()
       will not, in fact, work properly from programs with set-user-ID or set-group-ID privileges on systems on which /bin/sh is bash version
       2, since bash 2 drops privileges on startup.  (Debian uses a modified bash which does not do this when invoked as sh.)

       In  versions  of glibc before 2.1.3, the check for the availability of /bin/sh was not actually performed if command was NULL; instead
       it was always assumed to be available, and system() always returned 1 in this case.   Since  glibc  2.1.3,  this  check  is  performed
       because,  even  though  POSIX.1-2001  requires a conforming implementation to provide a shell, that shell may not be available or exe-
       cutable if the calling program has previously called chroot(2) (which is not specified by POSIX.1-2001).

       It is possible for the shell command to return 127, so that code is not a sure indication that the execve(2) call failed.

SEE ALSO
       sh(1), signal(2), wait(2), exec(3)

COLOPHON
       This page is part of release 3.22 of the Linux man-pages project.  A description of the project, and information about reporting bugs,
       can be found at http://www.kernel.org/doc/man-pages/.



                                  2004-12-20                         SYSTEM(3)


[Bald_Eagle1]

My programs already use tasklist run via the system() function.

Here's a snippet from a left over ONGOING ISRUNNING file when 2 instances of HG612_stats.exe attempted to run at the same time:-

Code: [Select]

Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
HG612_stats.exe               2124                            0      2,888 K
conhost.exe                   6104                            0      3,224 K
HG612_stats.exe               8688                            0      2,872 K
conhost.exe                   8656                            0      3,220 K
cmd.exe                       2092                            0      3,544 K
tasklist.exe                  7792                            0      5,312 K
cmd.exe                       3116                            0      3,432 K
IsRunningVB.exe               5672                            0      5,432 K


IsRunningVB.exe is RONSKI's program used to simply check for the number of HG612_stats.exe instances, prompting one of them to be exited.

RONSKI is now putting together a small program to include the PIDs of running processes.

My older batch file scripts also (rather unsuccessfully) used taskkill to kill off any 'stuck' processes such as curl etc.

However, neither tasklist or taskkill are included in XP Home versions, so the tasklist/taskkill commands would be simply ignored as 'not found'.

XP Home & Pro do possess tskill though, that can be used with either PID or process name, to kill one or all instances of a given program.

tskill isn't included with W 7 & quite probably not included in Vista.


My programs do determine which Windows version is running though, so it would be relatively easy to use the relevant OS dependent command via the system() function.

I would prefer to code these directly in 'C' though, rather than have to resort to system() calls.


The final issue here is that some PCs seem to occasionally slow down now & then for various reasons.
This can be an issue when generating scheduled daily ongoing and/or 'snapshot' graphs, sometimes still leaving HG612_stats.exe running into the next minute.

On the assumption the older process is the 'stuck' one to kill, the wrong process would be killed & scheduled graphs/data would be lost.
Hence me attempting to discover how to get HG612_stats.exe to trigger the graphing processes & continue to exit cleanly, leaving the graphing processes to do their own thing in their own time.

If that can be achieved, taskkill or its equivalent should then be able to just kill any genuinely 'stuck' instances of HG612_stats.exe before it is run again for the next minute's sample.

I had thought that 'stuck' instances were now a thing of the past in the latest amended programs.

Maybe an issue with DSLStats caused an issue with HG612_stats which caused another issue with DSLStats which caused another issue with HG612_stats which caused another issue with DSLStats....................................
(Or vice-versa) .

[Ronski]

tskill isn't included with W 7 & quite probably not included in Vista.

You need to check your email. 

Tskill is in  XP Home  (forgot to check Pro), W7,W8 & WHS 2011, but I don't have Vista any more to check that one.

I've emailed an updated TaskListVB,  and also some info which may help with starting programs and not waiting.

[Bald_Eagle1]

Now trying ShellExecute()

I have sent a test version to you.

It seems to work at my end 

[Ronski]

I'm currently testing it both at home and here at work, but my very rushed testing at home before leaving for work would suggest it's still waiting. see edit below

Could you create an entirely separate c program just as an eperiment, and from within the program start two separate bat files using shell execute, first one records the time to a file, waits 10 seconds and records the time, the second one just records the time to a different file.

Checking the contents of the two files would clearly show how things performed.

On the subject of TSKill, my Windows 7 & 8 versions are both Professional.

Edit: Actually, remote logging into my server and taking a look only shows isrunning files for 7:04, 7:05, 7:08 & 7:09. If it had still been waiting, then I would have expected isrunning files for every minute until 7:09

[Ronski]

My testing at work would suggest that it isn't waiting, as you can see both ran at the same time.

I set both ongoing graphs and current stats to run at 11:00, these are the logs:

Code: [Select]

25/10/2013 11:00:04.230 - Start of [graphpd.exe]
25/10/2013 11:00:04.230 - The program full path is      C:\HG612_Modem_Stats\Scripts\graphpd.exe
25/10/2013 11:00:04.230 - The program directory path is C:\HG612_Modem_Stats\Scripts\
25/10/2013 11:00:04.230 - DEBUG_COMMENTS = YES
25/10/2013 11:00:04.230 - You entered (or it was determined) a period of 1 d
25/10/2013 11:00:04.230 - C:\HG612_Modem_Stats\Ongoing_Stats\modem_stats.log opened for reading
25/10/2013 11:00:04.230 - Using the default log file. Creating SUBFOLDER: C:\HG612_Modem_Stats\Ongoing_Stats\Ongoing_Stats_20131025-1100-1Day
25/10/2013 11:00:04.230 - Creating C:\HG612_Modem_Stats\Ongoing_Stats\Ongoing_Stats_20131025-1100-1Day\GDATA$$
25/10/2013 11:00:34.933 - GDATA$$ created
25/10/2013 11:00:35.495 - START of piped plotting with gnuplot
25/10/2013 11:00:52.152 -   END of piped plotting with gnuplot
25/10/2013 11:00:55.667 - GDATA$$ deleted
25/10/2013 11:00:55.667 - End of graphpd. 1440 samples i.e. 1 Day of data should have been plotted

Code: [Select]

25/10/2013 11:00:09.511 - Start of GRAPH6.exe
25/10/2013 11:00:09.511 - The program full path is      C:\HG612_Modem_Stats\Scripts\GRAPH6.exe
25/10/2013 11:00:09.511 - The program directory path is C:\HG612_Modem_Stats\Scripts
25/10/2013 11:00:09.511 - DEBUG_COMMENTS = YES
25/10/2013 11:00:09.511 - Using C:\HG612_Modem_Stats\Current_Stats\Current_Stats_20131025-1100-SCHEDULED\Plink_20131025-1100.log
25/10/2013 11:00:09.511 - About to change folder to the one with the log file stored in it
25/10/2013 11:00:09.511 - Successfully changed directory to C:\HG612_Modem_Stats\Current_Stats\Current_Stats_20131025-1100-SCHEDULED
25/10/2013 11:00:25.902 - The Plink log being used came from a RESYNC or SCHEDULED event, so any pauses were disabled
25/10/2013 11:00:25.902 - End of GRAPH6.exe program, closing ERROR.LOG

Code: [Select]

25/10/2013 11:00:04.355 - Start of Current Stats Harvesting
25/10/2013 11:00:04.667 - The program full path is      C:\HG612_Modem_Stats\Scripts\HG612_current_stats.exe
25/10/2013 11:00:04.667 - The program directory path is C:\HG612_Modem_Stats\Scripts
25/10/2013 11:00:04.667 - DEBUG_COMMENTS = YES
25/10/2013 11:00:04.667 - Temp File CURRENT-ISRUNNING-110004-355 was created
25/10/2013 11:00:04.667 - Before checking for RESYNC or SCHEDULED events, Delay_snapshot_data_harvest_seconds = 0
25/10/2013 11:00:04.667 - A SCHEDULED run was detected via HG612_stats.exe. Initial Pause setting from ini file = NO
25/10/2013 11:00:04.667 - Pause setting for this instance only has been forced to be NO
25/10/2013 11:00:04.667 - After checking for RESYNC or SCHEDULED events, Delay_snapshot_data_harvest_seconds = 0
25/10/2013 11:00:04.714 - malloc() O.K.
25/10/2013 11:00:04.714 - Initializing Winsock
25/10/2013 11:00:04.714 - WSAStartup() SUCCESSFUL!!!
25/10/2013 11:00:04.714 - Starting getaddrinfo()
25/10/2013 11:00:04.714 - getaddrinfo() O.K.
25/10/2013 11:00:04.714 - Starting socket()
25/10/2013 11:00:04.714 - socket() O.K.
25/10/2013 11:00:04.714 - Starting connect()
25/10/2013 11:00:04.714 - connect() O.K.
25/10/2013 11:00:05.855 - About to reply(xdslcmd info --stats)
25/10/2013 11:00:05.855 - reply(xdslcmd info --stats) O.K.
25/10/2013 11:00:06.058 - get_data() for --stats O.K.
25/10/2013 11:00:06.058 - Modem in use = HG612
25/10/2013 11:00:06.058 - About to determine the xDSL mode
25/10/2013 11:00:06.058 - About to parse_stats()
25/10/2013 11:00:06.058 - parse_stats completed
25/10/2013 11:00:06.058 - VDSL2 mode detected so about to reply(xdslcmd info --pbParams)
25/10/2013 11:00:06.058 - reply(xdslcmd info --pbParams) O.K.
25/10/2013 11:00:06.261 - get_data() for --pbParams O.K.
25/10/2013 11:00:06.261 - About to parse_pbParams_data()
25/10/2013 11:00:06.277 - parse_pbParams_data() completed
25/10/2013 11:00:06.277 - reply(xdslcmd info --Bits) O.K.
25/10/2013 11:00:06.761 - get_data() for --Bits O.K.
25/10/2013 11:00:06.808 - reply(xdslcmd info --linediag) O.K.
25/10/2013 11:00:08.464 - get_data() for --linediag O.K.
25/10/2013 11:00:08.495 - reply(xdslcmd info --show) O.K.
25/10/2013 11:00:08.667 - get_data() for --show O.K.
25/10/2013 11:00:08.667 - About to exit Busybox
25/10/2013 11:00:08.667 - Busybox exited
25/10/2013 11:00:08.870 - About to exit ATP
25/10/2013 11:00:08.870 - ATP exited
25/10/2013 11:00:08.870 - About to close (sockfd)
25/10/2013 11:00:08.870 - About to WSACleanup()
25/10/2013 11:00:08.870 - About to free(txbuf)
25/10/2013 11:00:08.870 - About to free(rxbuf)
25/10/2013 11:00:08.870 - CURRENT-ISRUNNING-110004-355 DELETED
25/10/2013 11:00:08.870 - Auto_graph_Snapshot_data = YES, now graphing snapshot stats
25/10/2013 11:00:08.870 - Successfully changed directory to C:\HG612_Modem_Stats\Current_Stats\Current_Stats_20131025-1100-SCHEDULED
25/10/2013 11:00:08.870 - Pause_after_obtaining_snapshot_data = NO
25/10/2013 11:00:08.870 - GRAPHING_COMMAND = ""C:\HG612_Modem_Stats\Scripts\GRAPH6.exe" "C:\HG612_Modem_Stats\Current_Stats\Current_Stats_20131025-1100-SCHEDULED\Plink_20131025-1100.log""
25/10/2013 11:00:25.902 - Snapshot graphs should now have been plotted
25/10/2013 11:00:25.902 - End of HG612_current_stats.exe program, closing ERROR.LOG

Code: [Select]

25/10/2013 11:00:00.964 - [ IN HG612_stats.EXE ] - Start of 1 minute sampling - delayed by user setting of 0 seconds
25/10/2013 11:00:01.073 - HG612_current_stats.exe was NOT running
25/10/2013 11:00:01.073 - Temp File ONGOING-ISRUNNING-110001-073.TXT was created
25/10/2013 11:00:01.245 - malloc() O.K.
25/10/2013 11:00:01.245 - Initializing Winsock
25/10/2013 11:00:01.245 - WSAStartup() SUCCESSFUL!!!
25/10/2013 11:00:01.245 - Starting getaddrinfo()
25/10/2013 11:00:01.245 - getaddrinfo() O.K.
25/10/2013 11:00:01.245 - Starting socket()
25/10/2013 11:00:01.261 - socket() O.K.
25/10/2013 11:00:01.261 - Starting connect()
25/10/2013 11:00:01.261 - connect() O.K.
25/10/2013 11:00:02.464 - About to reply(xdslcmd info --stats)
25/10/2013 11:00:02.464 - reply(xdslcmd info --stats) O.K.
25/10/2013 11:00:02.527 - get_data() O.K.
25/10/2013 11:00:02.527 - About to determine the xDSL mode
25/10/2013 11:00:02.527 - Modem in use = HG612
25/10/2013 11:00:02.527 - About to parse_stats()
25/10/2013 11:00:02.527 - parse_stats completed
25/10/2013 11:00:02.527 - VDSL2 mode detected so about to reply(xdslcmd info --pbParams)
25/10/2013 11:00:02.527 - reply(xdslcmd info --pbParams) O.K.
25/10/2013 11:00:02.761 - get_data() O.K.
25/10/2013 11:00:02.761 - About to parse_pbParams_data()
25/10/2013 11:00:02.792 - parse_pbParams_data() completed
25/10/2013 11:00:02.792 - reply(xdslcmd --version) O.K.
25/10/2013 11:00:02.933 - get_data() O.K.
25/10/2013 11:00:02.933 - parse_version() completed
25/10/2013 11:00:02.933 - About to exit Busybox
25/10/2013 11:00:02.933 - Busybox exited
25/10/2013 11:00:03.230 - About to exit ATP
25/10/2013 11:00:03.230 - ATP exited
25/10/2013 11:00:03.230 - Logged out of modem O.K.
25/10/2013 11:00:03.261 - Current data harvested at 1382695200 seconds past the epoch
25/10/2013 11:00:03.261 - About to get_log_data()
25/10/2013 11:00:03.261 - Previous log stats date/time = 1382695140 seconds past the epoch
25/10/2013 11:00:03.261 - time_difference = 1 minutes
25/10/2013 11:00:03.261 - About to calc_ES_delta()
25/10/2013 11:00:03.261 - About to calc_RSCorr_delta()
25/10/2013 11:00:03.261 - ds_RSCorr_THIS_PERIOD = 573105
25/10/2013 11:00:03.261 - us_RSCorr_THIS_PERIOD = 0
25/10/2013 11:00:03.261 - About to calc_RSUnCorr_delta()
25/10/2013 11:00:03.261 - About to calc_RS_delta()
25/10/2013 11:00:03.261 - About to calc_OHF_delta()
25/10/2013 11:00:03.261 - About to calc_OHFErr_delta()
25/10/2013 11:00:03.261 - About to calc_HEC_delta()
25/10/2013 11:00:03.261 - About to calc_CRC_delta()
25/10/2013 11:00:03.261 - About to calc_FEC_delta()
25/10/2013 11:00:03.261 - About to calc_Bitswap_delta()
25/10/2013 11:00:03.261 - Appending data to C:\HG612_Modem_Stats\Ongoing_Stats\modem_stats.log
25/10/2013 11:00:03.261 - Closing MSLOGFILE.log
25/10/2013 11:00:03.261 - END of 1 minute sampling
25/10/2013 11:00:03.292 - About to close(sockfd)
25/10/2013 11:00:03.292 - About to freeadddrinfo(res)
25/10/2013 11:00:03.292 - About to WSACleanup()
25/10/2013 11:00:03.323 - About to free(txbuf)
25/10/2013 11:00:03.370 - About to free(rxbuf)
25/10/2013 11:00:03.448 - Current  sync speeds are     DS 33690 kbps      US 6076 kbps, AS = 888710
25/10/2013 11:00:03.448 - Previous sync speeds were    DS 33690 kbps      US 6076 kbps, AS = 888649
25/10/2013 11:00:03.464 - Sync speeds have NOT changed since the previous data harvest
25/10/2013 11:00:03.495 - ONGOING-ISRUNNING-110001-073.TXT DELETED
*********************************************************************************************************************
25/10/2013 11:00:03.495 - Scheduled Current_Stats logging is switched ON via the ini file
25/10/2013 11:00:03.495 - Current_Stats_Datum    = 00
25/10/2013 11:00:03.495 - Current_Stats_Interval = 1
25/10/2013 11:00:03.527 - (Time in Hours - Datum) Modulus Interval       i.e. (11 - 0) % 1 = 0
25/10/2013 11:00:03.527 - (Time in Minutes) = 00
25/10/2013 11:00:03.542 - RUN HG612_current_stats.exe
*********************************************************************************************************************
25/10/2013 11:00:03.698 - Scheduled Daily_Graphing is switched ON via the ini file
25/10/2013 11:00:03.698 - Daily_Graphing_hour    = 11
25/10/2013 11:00:03.698 - Daily_Graphing_minutes = 00
25/10/2013 11:00:03.698 - Current Time is Hours 11, Minutes 00
25/10/2013 11:00:03.730 - RUN graphpd.exe
*********************************************************************************************************************
25/10/2013 11:00:03.761 - End of HG612_stats.exe program, EXIT error code = 0
25/10/2013 11:00:04.198 - End of HG612_stats.exe program, closing ERROR.LOG

[kitz]

Thanks for the update.   If you want me to test at any point, I'll try forcing a clash with DSLstats by turning off its compatibility mode.

[Ronski]

I believe the current update I'm testing only deals with  when HG612 stats  starts other programs,  the way  they were being started meant that HG612 stats would wait for the program to finish before continuing,  now it just continues.

The killing of stuck processes is the next step.

[kitz]

Ok cheers ronski and BE for the updated info


<< BE >> However, neither tasklist or taskkill are included in XP Home versions, so the tasklist/taskkill commands would be simply ignored as 'not found'.

I guess youve found TList (as well as tskill).  Unfortunately neither are as powerful as tasklist & taskkill though :/
PITA that you have to ID the o/s too now.  This makes me feel that there must be an easier way in C to query processes for windows.  Otherwise lots of 'c' progs will have just stopped working when the later win versions were released.


<< BE >> I would prefer to code these directly in 'C' though, rather than have to resort to system() calls.

Just a thought.. does your compiler add a windows.lib that will include windows dlls?

I may be talking out of my backside here because I really dont know C.   
But knowing that C is based as a *nix language.. what happens if do you use the linux command KILL.  Does the windows compiler automatically add a library function that converts 'kill' to the relevant o/s?  If so then this also may also be an end to the taskkill problem on older systems.

I just found that Kill seems to be supported for Devs, when I was looking up TList, so its a possibility (long shot/wishful thinking) its part of the standard windows.h library.


Out of interest what IDE are you using, does it have any of its own modules.  If its a windows based environment it may have, because this would surely be a common function.  Some IDEs Ive used have additional common functions that arent part of the the original libraries and they package them at compile.

Finally word of warning from experience.  If the PID is obtained in one environment it doesnt always follow that it will have the same PID when used in another.  For example if you got the PID from a windows environment and tried to pass it via your C program, it may not work. A long ago now, but iirc the IDE seems to obtain a different PID than that obtained via taskmanager and/or tasklist.  So stick to either both in native C functions or do both by system calls.
Sorry if Im teaching grandma to suck eggs.  It may be ok in C, but its just a heads up in case you sit scratching your head wondering why its not always killing properly.

Also sorry that Im not much use in helping to find the solution - particularly when its me that seems to hit any of the clashing problems first.   

[Bald_Eagle1]

Ok cheers ronski and BE for the updated info

<< BE >> However, neither tasklist or taskkill are included in XP Home versions, so the tasklist/taskkill commands would be simply ignored as 'not found'.

I guess youve found TList (as well as tskill).  Unfortunately neither are as powerful as tasklist & taskkill though :/

No, I hadn't found TList so that's a useful addition to my memory bank should it ever be needed

PITA that you have to ID the o/s too now.  This makes me feel that there must be an easier way in C to query processes for windows.  Otherwise lots of 'c' progs will have just stopped working when the later win versions were released.

The programs did that anyway, but didn't use it for much - other than adjusting font sizes for the 'snapshot' montages previously.

<< BE >> I would prefer to code these directly in 'C' though, rather than have to resort to system() calls.

Just a thought.. does your compiler add a windows.lib that will include windows dlls?

Not that I'm aware of.

I may be talking out of my backside here because I really dont know C.

 
Neither do I. I don't really know progarmming at all.....Full stop.

But knowing that C is based as a *nix language.. what happens if do you use the linux command KILL.  Does the windows compiler automatically add a library function that converts 'kill' to the relevant o/s?  If so then this also may also be an end to the taskkill problem on older systems.

It doesn't seem to be available via the command line compiler I use (MingW).

I just found that Kill seems to be supported for Devs, when I was looking up TList, so its a possibility (long shot/wishful thinking) its part of the standard windows.h library.

Out of interest what IDE are you using, does it have any of its own modules.  If its a windows based environment it may have, because this would surely be a common function.  Some IDEs Ive used have additional common functions that arent part of the the original libraries and they package them at compile.

As mentioned above I use a command line compiler (no IDE).

I think I have sussed out how to kill individual processes, but I've parked that aspect for now while I concentrate on program flow now that I have been pointed toward the ShellExecute() function.

It seems like I can use it in different ways to trigger other programs without waiting for the calling program to wait.

 

Finally word of warning from experience.  If the PID is obtained in one environment it doesnt always follow that it will have the same PID when used in another.  For example if you got the PID from a windows environment and tried to pass it via your C program, it may not work. A long ago now, but iirc the IDE seems to obtain a different PID than that obtained via taskmanager and/or tasklist.  So stick to either both in native C functions or do both by system calls.

That doesn't SEEM to be an issue, but I'll double-check when I return to the 'killing' matter (if it's still needed after I have finished fiddling about).

Sorry if Im teaching grandma to suck eggs.  It may be ok in C, but its just a heads up in case you sit scratching your head wondering why its not always killing properly.

That's not at all the case.
Any help/advice is much appreciated as I'm not a programmer. Commencing this project to log/graph my own connection's stats was initially simply a means to an end. i.e. to 'prove' my connection was 'defective' when Plusnet's & BT's own tests were all confirming LTOK.

It basically served that purpose & the result was that physical line problems were eventually fixed back in May 2012.
It did take almost 11 months & numerous engineer visits though before the actual fault was tracked down & repaired.
That's another story though, that isn't relevant to this thread.

Also sorry that Im not much use in helping to find the solution - particularly when its me that seems to hit any of the clashing problems first.   

Again, no need to apologise as it's your & others' feedback that will (hopefully) result in a truly reliable package, fully compatible with DSLStats & a useful tool in our armoury for detecting fixable connection issues (unless BT finally manage to completely block access to our modems as apparently appears to be their wish).