In my project, we use the ACE ( Adaptive Communication Environment) middleware to write OS independent code that would run on both Windows and Linux.
The requirement is to the get the process id from process name.
Since ACE does not support this, we will have to use platform specific macros to separate the code for windows and linux.
For windows I would have to use either of - EnumProcesses or CreateToolhelp32Snapshot
How to do the same on linux using an API ?
Programming language is C++
if i understand your question correctly, you can do this from c++
char buf[512];
FILE *cmd_pipe = popen("pidof -s process_name", "r");
fgets(buf, 512, cmd_pipe);
pid_t pid = strtoul(buf, NULL, 10);
pclose( cmd_pipe );
here is an another example: Get process id by name in Linux using C++
Related
I have a program using Named Pipes to communicate with another process, but it fails in a user's computer when they're running Linux Proton emulating windows instead of native Windows. "Proton" is what Steam Deck devices uses to play Windows games. There is "Proton" and "Proton GE" and this fails in both cases.
import win32pipe, win32file
pipe = win32pipe.CreateNamedPipe(
r'\\.\pipe\\'+'my_pipe',
win32pipe.PIPE_ACCESS_DUPLEX, win32pipe.PIPE_TYPE_MESSAGE | win32pipe.PIPE_READMODE_MESSAGE | win32pipe.PIPE_WAIT,
1, 65536, 65536, 0, None)
win32file.SetFilePointer(pipe, 0, win32file.FILE_BEGIN)
No error in regular Windows.
Error in Linux "Proton" running Windows: pywintypes.error: (66, 'SetFilePointer', 'Bad device type.')
Any workaround for this? Or do I just have to abandon named pipes entirely when developing for users to use Proton? I was thinking about having it write to a file on disk instead of using named pipes and then polling that file, but that would be a last resort...
This is a bug in Linux Proton and doesn't look like it will be fixed any time soon.
The workaround was thus: Have the python program put the SetFilePointer in a try/except block. If it fails, fall back to a different protocol (an http protocol) and don't try to use named pipes.
I amm writing a little python script that will grab information from VMs of Windows that I am running.
At the moment I can list the processes on a 32bit XP machine with the following method:
http://code.activestate.com/recipes/305279/
Is it possible to somehow detect the version of windows running and excute a different method for getting the processes on a 64bit machine, I am trying to get the processes from a 64Bit Vista and 64bit Windows 7.
Any ideas?
If you don't want to rely on any extra installed modules then you can parse the output of wmic, e.g.:
c:\> wmic process get description,executablepath
...
explorer.exe C:\Windows\explorer.exe
cmd.exe C:\Windows\SysWOW64\cmd.exe
conhost.exe C:\Windows\system32\conhost.exe
...
Reference: http://geekpedia.wordpress.com/2008/08/18/use-command-line-to-track-windows-processes/
There is another recipe on activestate that does a similar thing, but uses the Performance Data Helper library (PDH) instead.
I have tested this on my Windows 7 64bit machine and it works there - so presumably the same function will work on both 32bit and 64 bit windows.
You can find the recipe here: http://code.activestate.com/recipes/303339/
Another method is using WMI, there is an example here in Python using the wmi module:
http://timgolden.me.uk/python/wmi/cookbook.html
import wmi
c = wmi.WMI ()
for process in c.Win32_Process ():
print process.ProcessId, process.Name
The cleanest way I found to solve this was to use the psutil library as recommended by Robert Lujo:
psutil.process_iter()
Note that it returns a generator object, issuing a process object at a time. For example if you need the list of process names, you can do something like:
[p.name() for p in psutil.process_iter()]
For similar purposes I have used psutil library. Some hints:
list processes with psutil.pids() (reference)
inspect process information with process = psutil.Process(pid) (reference)
do process.kill or process.terminate()
Installation on windows - pip will do installation from the source (which means compiling), so you probably want to download binary installation from https://pypi.python.org/pypi/psutil/#downloads.
You should be able to do this by exposing Windows Management Instrumentation within each VM. This tool gives you access to a bunch of system data, including processes, see http://technet.microsoft.com/en-us/library/cc757287%28WS.10%29.aspx
You should be able to popen one of the commands in the preceding link to get the info you're looking for.
My main requirement is to profile the mentioned anti-debugging check program twice ( Once in the presence of a debugger and the other without it ) to collect some information for analysis during run-time (Assuming only the binary is available)
#include <stdio.h>
#include <sys/ptrace.h>
int i_am_debugged()
{
if (ptrace(PTRACE_TRACEME, 0, 1, 0) < 0)
{
printf("Avoid debugging please");
return 1;
}
return 0;
}
int main()
{
if(i_am_debugged())
{
return 1;
}
printf("It's going well ! No debugging !\n");
return 0;
}
Currently , I wrote a Intel PIN tool for the same but I am unable to profile a run when a debugger is not attached because of the way PIN works and always executes 'It's going well ! No debugging !'.
So, my question:
Is there anything I can do (attach a debugger and run the pin tool or something) to profile both types of runs using my PIN tool or will any other type of profiling (for ex Binary translation, etc) help me in this case?
I want to collect specific information about instructions and not just Call graph,etc and hence would like some functionality similar to PIN's C++ programmer interface.
A detailed answer would be great, Thanks.
Pin uses ptrace to inject itself into the application. This means that using gdb won't be possible when attempting to launch an application with Pin, and also that Pin won't successfully attach to an application that is being debugged.
My suggestion is to start Pin with the -pause_tool knob, and then attach gdb to the process. This will make the application's ptrace call return what you want.
I hope i get what you want.
Intel PIN is NOT a debugger. It's more like a VM which on-the-fly instruments binary code (for x86/x64) and then executes this freshly instrumented code.
Because PIN is not opensource, it's internals are rather "secret" ;).
But its CLEARLY not a debugger.
If i understand you correctly you want some sort of test-suite which
runs your application twice, one time with a debugger attached and one time without?
Then you probably should use gdb.
Just start:
./a.out for the normal run
and e.g. (this one is a little hacky ;-) ) for the debugger-run:
Create a file mygdbscript (needs arguments to gdb like: gdb -x ./mygdbscript)
The content of this file is just:
# you probably dont want gdb to stop under ANY circumstances
# as this is an automatic check. So pass all signals to the application.
handle all nostop print pass
run
quit
Then run with gdb -x ./mygdbscript --args ./a.out
Hope this helps :)
I hope I'm posting on the right forum for this!
Recently I have started programming with the Directx 11 June (2010) SDK on VC++ 2010, on a Dell LapTop with a NVidia GeForce GT 630M GPU and a Intel HD 4000 chip.
One of the things you do, is to try and enumerate available adapters and outputs, and so on. Here's an example:
IDXGIFactory1 *factory;
CreateDXGIFactory1(__uuidof(IDXGIFactory1), (LPVOID *)&factory);
IDXGIAdapter *adapter;
factory->EnumAdapters(0, &adapter);
DXGI_ADAPTER_DESC desc;
adapter->GetDesc(&desc);
When I run this, the desc structure contains the information for my Intel HD chip, and NOT the information for my GPU!
Now, when I open my NVidia control panel, and select the GPU as the preferred processor, and re-run the sample, I get the info for my GPU in desc - which is right! And also, when I then try to enumerate outputs for this adapter, I find that there is at least one.
My question is: Is there a way to accomplish this programmatically, like in the DirectX 11 SDK, so that I don't have to set the setting in my NVidia control panel?
I went through the SDK code (for EmptyProject11), and somehow they "grab" the GPU instead of the Intel chip. I commented out all the code in the WinMain function, and inserted the above code, and it still grabbed the GPU! Is it something to do with the Project Setup, environment variables, command line arguments, or....? I mean how do they do it!?!?!?
I would appreciate any insight into this matter.
Thanks
You can run through all of the adapters presents and get information on them by looping through all possible adapters using the same function that you're already using:
HRESULT r = S_OK;
unsigned int adapterindex = 0;
std::unique_ptr<IDXGIAdapter, ReleaseDirectX> dxgiadapter = null;
// Save the result of EnumAdapters to r, and then check if it's S_OK
while ( ( r = factory->EnumAdapters( adapterindex, &dxgiadapter ) ) == S_OK ) {
++adapterindex;
/* Work with your adapter here, particularly DXGI_ADAPTER_DESC */
}
Usually, you will have to choose the default one automatically or enumerate all of them and in some kind of settings panel let the user choose. The other way to do it is use the Adapter Description which has the most video memory. It's not a foolproof heuristic, but it's one I use to get the "best" (used liberally) video card for the system. More often than not, however, the default is the default for a reason.
Good luck!
All standards compliant applications in Linux store a desktop schema in /usr/share/applications/. In my particular use case, I have a WnckWindow data structure and I can get a pid from that. Using this pid, I can extract the command line from the proc.
Unfortunately, it seems that the proc command line entry does not match the desktop schema launch parameters. For example, the 'thunderbird' application is launched via /usr/bin/thunderbird but this is just a shell script which activates the real executable: /usr/lib/thunderbird-8.0/thunderbird-bin.
The real executable cannot be launched directly as it is dependent on the library paths configured in the /usr/bin/thunderbird script. Does anyone have any advice on how to match process id numbers to the appropriate desktop schema without getting caught by the issue I've described?, Thanks.
Ok, well, it appears that there's no nice way of solving this using the pid, however, it is relatively easy to match the Wnck windows class to application desktop schemas. The Wnck windows class needs to be preprocessed a little first to ensure that the filter works but it's pretty trivial stuff. Once you've got a good set of target strings, eg 'Thunderbird' or 'Google' + 'Chrome', you can use the system application menu API to zero in on a likely candidate, for example, by using garcon on Xfce.