Re: CreateProcess SW_HIDE not working

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Sorry I missed seeing this code...
On Mon, 1 Dec 2008 16:32:05 -0800 (PST), Bob <jeep@xxxxxxxxx> wrote:

Ive been reading many many other articles on this issue and playing
with variations of
my code to get it working and cannot seem to get it to work. I have a
thread that is launched
withing a MFC GUI application which Im trying to silently do work in.
Im using wget.exe which
works fine. In fact all the code works great except the stupid window
keeps popping up everytime
it launches my wget. I even tried to reduce the size of the window to
1 x 1 pixels and that
doesnt even work!

Can someone tell me why? Ive looked at the microsoft pages on article
Q150956 and anything
else I could see with no luck.

I appreciate it!

Relevant code here:

DWORD WINAPI myThreadFunc(LPVOID lpParam )
{
char cmd[255];
char ipfile[255];
char buf[25];
BOOL m_run = true;

while (m_run)
{
sprintf(ipfile, "C:\\bin\\myip.txt");
****
Why sprintf? THere are so many things wrong with this one statement it is mind-boggling!

First, why 'char' as the datatype. 'char' is dead. It should not be used in ordinary
programs. There is no bounds checking to see that the buffer is not overrun, just trust
that the string is short enough. There is a presumption that the file is located on a
specific drive, in a specific directory. The buffer into which it is written has the
random number 255 as its limit, instead of _MAX_PATH, which is the longest path possible.
Note that _MAX_PATH is *not* 255, it is LONGER and therefore a buffer overrun can occur.

Note that this could all have been solved by
LPTSTR ipfile = _T("c:\\bin\myip.txt:);
which suffers from the problem of binding to a specific drive and directory, but
eliminates all other problems.

Or, in a sane world,
CString ipfile(_T("c:\\bin\myip.txt"));

since there is no reason to use fixed-size char buffers in modern programming. If you
don't like CString, use std::string. But generally forget that fixed-size buffers exist.
****
****
sprintf(cmd, "C:\\bin\\wget -q -nv http://10.10.10.1/cgi-bin/getip.cgi
-O %s", ipfile);
*****
CString cmd;
cmd.Fomat(_T("c:\\bin\wget -q -nv http://10.10.10.1/cgi-bin/getip.cgi -O %s"),
ipfile);

Note there is no possibility of buffer overrun here because there is no preallocated
buffer. The buffer here should be AT LEAST 2*_MAX_PATH but why bother when you don't need
to pre-allocate at all!

Now this assumes a specific IP address. It runs some kind of script with some option.
This presumably is going to write a file somewhere on the host machine's disk drive. What
good is this going to do? Why not just retrieve the data you want using HTTP? It doesn't
take that much effort to write this code (I've done it several times, and it is a small
number of lines of code, even though I have to look them up every time).

What I'm curious about is why a hardwired file name in what should nominally be a
write-protected directory of executables is being used. Generally, you should be using
GetTempName to generate a guaranteed-unique name, and it should written in the GetTempPath
directory, not into critical system directories. In any sane installation, the bin
directories are all read-only to protect against virus infestation.
****

STARTUPINFO si;
ZeroMemory(&si, sizeof(si));
//GetStartupInfo(&si);
si.dwFlags = STARTF_USESHOWWINDOW | STARTF_USESIZE;
****
As pointed out, only if your app honors the wShowWIndow option will it have any effect.
But wget.exe appears to be a non-GUI program, so this flag only applies to GUI programs.

You would want to reroute stdout and use the option that said to not display a console
window.
****
si.wShowWindow = SW_HIDE;
si.dwXSize = 1;
si.dwYSize = 1;

si.cb = sizeof(si); // Must set the size of structure
PROCESS_INFORMATION pi;
BOOL ret = CreateProcess(NULL, cmd, NULL, NULL, FALSE,
CREATE_NO_WINDOW, // | DETACHED_PROCESS,
NULL, NULL, &si, &pi);
if (ret)
{
WaitForSingleObject(pi.hProcess, 1000 * 2); // wait 2 seconds
****
Any time a line like this appears, you can assume the design is flawed beyond redemption.
Why do you think that 2 seconds means anything whatsoever? If the process hasn't
finished, you're going to wait another 5 seconds for some inexplicable reason anyway. What
is going on here? Either it is going to terminate, in which case you want INFINITE, or it
is going to hang, in which case, just closing the handle, crossing your fingers, and
hoping is somewhat misplaced.
****
CloseHandle(pi.hProcess);
}
Sleep(1000 * 5);
}
return 0;
****
You are spending more effort to set up a bad solution than it would take to write a good
solution. If you want the page contents (yes, I looked up wget), just read them using the
HTTP APIs.
joe
****
}
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages