Like Unix based operating system, why is there no process hierarchy in Windows? Is there a reason for it or is it just a choice? How does the processes work in windows then?
Sorry for the necro thread but there is no answer. There is a process hierarchy in Windows. You can't see it from the Task manager but with SysInternal ProcessExplorer you see it all up to the kernel components. You can also easily retrieve that information with various winapi calls.
Related
How do I know in a windows program if a process is running if I only know the exe file name ?
The process in question is TeamSpeak3 ts3client_win64.exe for 64 bit and ts3client_win32.exe for 32 bit.
I am using C++
Use the CreateToolhelp32Snapshot function to create a snapshot of the current process table, then use the Process32First and Process32Next functions to iterate the snapshot. You can get the name for each executable file by looking at the szExeName field of the PROCESSENTRY32 structure.
See the MSDN example for a sample of how to use these functions.
The advantage of this approach is that, unlike any EnumProcesses-based solution, it doesn't suffer from race conditions: with EnumProcesses it can happen that a process gets destroyed after you finished enumerating the processes but before you got around to opening the process (or reading our the process executable name).
You can use a combination of EnumProcesses, OpenProcess, and GetModuleFileNameEx (or alternatively, QueryFullProcessImageName for Vista or later). MSDN even has an example.
Windows NT has several APIs for enumerating processes.
EnumProcesses
ToolHelp
NtQuerySystemInformation (discouraged)
WMI's Win32_Process (works remotely)
I am porting an application which runs as a background service in windows at startup, we are porting the application to linux(SUSE Enterprise server), I'am completely new to linux. Can somebody help me on how to proceed with this. Like
Should I build the linux executable
After builiding the binary, what changes should I make to linux startup files to run this executable
How my service can register call back function to modify or change or send commands to my service while it is running
Yes, you should build a Linux binary. You may want to rephrase your question since I doubt this is the answer you want :-)
You should generally create what is known as an "init" file, which lives in /etc/init.d. Novell has a guide online which you can use to author the file. Note that while the init file is common, the exact method of letting the operating system use it varies depending on the distribution.
This is going to be a marked change for you. If you are doing simple actions such as re-loading a configuration file, you can use the signals functionality, especially the SIGHUP/HUP signal which is generally used for this purpose. If you require extended communication with your daemon, you can use a UNIX domain socket (think of it as a named pipe) or a network socket.
Another task you are going to need to accomplish is to daemonize your application. Generally this is done by first fork()ing your process, then redirecting the stdin/stdout pipes in the child. There are more details which can be answered by reading this document
See how-to-migrate-a-net-windows-service-application-to-linux-using-mono.
Under Linux, deamons are simple background processes. No special control methods (e.g start(), stop()) are used as in Windows. Build your service as a simple (console) application, and run it in the background. You can use a tool like daemonize to run a program as a Unix daemon.
I want to know the files a given process is reading/writing. Is there a program that shows this? On Windows XP. Thanks. I've tried Autohotkey Spy, Spy++, and Process Explorer. They show a lot of detail but not which files are being accessed.
Process Monitor
Process Monitor is an advanced
monitoring tool for Windows that shows
real-time file system, Registry and
process/thread activity. It combines
the features of two legacy
Sysinternals utilities, Filemon and
Regmon, and adds an extensive list of
enhancements
Filemon
How can I monitor a Windows process and start it up if it is not running? I'd like to have something that starts up as a Windows service and can handle multiple processes.
EDIT:
Hopefully there's a ready to use library/component I can use and just tweak or configure instead of having to implement it from scratch. I know in the *nix world of two popular packages: god and monit.
You can create a Windows Service that just watches the current process list.
EnumProcesses provides the means of seeing processes running currently. There are many APIs available to start a new process, including:
system()
_exec()
WinExec()
ShellExecute()/ShellExecuteEx()
CreateProcess()
CreateProcessAsUser()
CreateProcessWithLogonW()
If you're using other languages/frameworks, they often provide their own wrappers around the above.
Is there any library or software or any way of saving the state of a single process in Windows to a file, then restoring the running process to a running state with all the memory already loaded at a later time?
I am aware that open handles will have to be re-opened, threads may have to started, etc, but can the heap and a single thread stack at least be restored?
I saw this question, but the answers are all for linux and most of them say it can't be done.
I know I can make all of my data structures serializable and do it myself, but I'd like to know if it is possible without that.
Raymond Chen (who may even kick Jon Skeet's ass when it comes to obscure Windows knowledge) says it isn't possible.
Essentially, unless your process uses absolutely no system resources (e.g. handles of any kind), there's always going to be some OS state which you can't save and restore.
The most practical way of solving this problem is to create a VM running another instance of Windows and run your process inside that:
You can make the guest OS as lightweight as possible by using nLite.
You can then use the VMWare VIX API to suspend/resume the VM programmatically.
This of course suspends the guest OS, and your process with it, solving the OS state problem.
>> •You can make the guest OS as lightweight as possible by using nLite.
To add to the above statement - The official lightweight version of Windows XP is "XP Embedded" or "Windows Embedded Standard". It is a heavily componentized version of XP that lets you slim down the XP image as small as 40 MB.
The "light weight" version of Windows 7 is Windows Embedded Standard 2011 , which is currently in Beta and available for download (connect.microsoft.com/windowsembedded)
Of course , it is not a freeware unlike NLite.
Thanks,
Srikanth