MFC or No MFC? (No .NET)

Hey folks:

I have a list of requirements, and I'd like to know if you folks think it would be better to be a MFC app or not:

1) Sit in the system tray 24/7
2) Run on every startup
3) Be able to exec other executables
4) Be able to change some display control panel settings
5) Be able to open a socket to an application server
6) Be able to upload and download data via the socket
7) Execute a set of instructions every hour
8) Know when to relaunch itself (if explorer.exe crashes)
9) Be able to create and delete files
10) Be able to detect if another process is running
11) Be able to change its tray icon to a different tray icon at certain times

Is there a good framework for this? If anyone knows anyway to accomplish any of these tasks, I'd love to hear how, or follow links to where they could be explained.

Just some keywords to guide you in the right direction:

1) Shell_NotifyIcon()
2) Registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
3) CreateProcess()
4) Dunno, probably registry
5+6) Windows Socket API (WinSock)
7) SetTimer()
8) Use second process which monitors app using process enumeration
9) CreateFile(), DeleteFile()
10) Process enumeration --> create Toolhelp 32 snapshot
11) see 1) + LoadImage()

BTW: if you don't need a GUI, MFC won't be useful here IMO.

You dont need MFC for anything, but you can choose it if you want. From your specs, it looks like you can do just fine without it. By the way, when explorer crashes, it doesnt take your program with it ;) You dont need to relaunch.

As a side not, most virus makers nowadays inject process into Explorer (by adding startup to a not-so-well-known Explorer/policies/run registry key) so when another virus process dies, the monitoring process (which is not seen in task manager, because it runs as part of explorer exe) reloads the virus image to memory. If you ever had a virus and wanted to remove it yourself, and killed the process in Taskmanager, it instantly reappers. If thats what you need, you can do the same, but i am not sure about the ethics of this :)

After Amn's comment I realized what you meant by "relaunch itself (if explorer.exe crashes).
You noticed that the system tray icons disappear in this case, right?
Well, Amn is right on this issue: You're program does not crash and is still running. Only the tray icon has been destroyed. So you can check for that from time to time (or you will get error when trying to change the icon) and setup a new if it is down. No need for a second monitor process in this case.

Quote:

---

Originally Posted by philkr

After Amn's comment I realized what you meant by "relaunch itself (if explorer.exe crashes).
You noticed that the system tray icons disappear in this case, right?
Well, Amn is right on this issue: You're program does not crash and is still running. Only the tray icon has been destroyed. So you can check for that from time to time (or you will get error when trying to change the icon) and setup a new if it is down. No need for a second monitor process in this case.

---

I believe Windows do send a message when the system tray is ready to accept icons when explorer.exe is run at startup or when it reboots. IIRC NoHero posted it... but i can't find his post :confused:

If you are interest only in NT generation systems (WinNT, Win2000, WinXP, Win2003 Server) you can make NT-service (allowing service interact with desctop) - then you will not depends from explorer.exe

Quote:

---

Originally Posted by philkr

After Amn's comment I realized what you meant by "relaunch itself (if explorer.exe crashes).
You noticed that the system tray icons disappear in this case, right?
Well, Amn is right on this issue: You're program does not crash and is still running. Only the tray icon has been destroyed. So you can check for that from time to time (or you will get error when trying to change the icon) and setup a new if it is down. No need for a second monitor process in this case.

---

Yes. When the icon is registered with the tray, after calling the ShellXXX function (dont remember which), the icon will get updates for redraw and such AS LONG as the process runs that called the function (actually the process owning window, getting the message for the icon) is running. That is why when you kill processes from Taskman, their own icons disappear as soon as you hover with the cursor over them. So if you want an UNDEAD icon, which cannot be killed, bind it to a process which is UNDEAD too ;) No process is truly invincible, but explorer loads images registered under explorer/policies/run as child processes, and IN THAT case actually killing explorer will kill the processes. Spawned processes DO NOT DIE when the spawning process is killed/terminated/finished. But BE SURE your icon will disappear if the process that owns the window which receives icon related messages is terminated.

As to the icon being completely independent, there is no such thing, at least not feasable without hacks and intrusions into native window processes, which again is not very ethical imho. THe reason that you see for example the volume and messenger icon reappearing when explorer restarts, is NOT BECAUSE there is some magix flag for the icon, but because in Windows XP additional messages are introduced which allow processes to visually reinstall their icons to the tray. Processes themselves were not killed, but explorer was, and so the visible tray area was unavailable for some time, but when it reappears, all processes have a chance to have their icons reappear ;)

Hope this clears up things. If anyone has more hands-on practical experience, lets discuss hehe.

In response to a 'framework' being available that would make such a thing easy, there really is no need to use MFC or anything other than the API.

If you want OOP design, there is a very simple solution to solving the window process having to be a static.

Code:

---

INT_PTR SomeWindow::WindowProcess(UINT message,WPARAM wParam,LPARAM lParam) throw()
{
    // do your message handling here
    return ::DefWindowProc(Handle,message,wParam,lParam);
}

// Below is the static window process method.
// Note the use of Window Properties with SetPropW and GetPropW

INT_PTR __stdcall SomeWindow::HandleWindowProcess(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam) throw()
{
    if (message == WM_NCCREATE)
    {
        LPCREATESTRUCT lpCreate = reinterpret_cast<LPCREATESTRUCT>(lpCreate);
        SomeWindow * pWindow = reinterpret_cast<SomeWindow *>(lpCreate->lpCreateParams);
        pWindow->Handle = hWnd;
        ::SetPropW(hWnd,L"WindowObject",reinterpret_cast<HANDLE>(pWindow));
        return pWindow->WindowProcess(message,wParam,lParam);
    }
    else
    {
        SomeWindow * pWindow = reinterpret_cast<SomeWindow *>(::GetPropW(hWnd,L"WindowObject"));
        if (pWindow != NULL)
        {
            return pWindow->WindowProcess(message,wParam,lParam);
        }
        else
        {
            return ::DefWindowProc(message,wParam,lParam);
        }
    }
}

---