CreateProcess question

[rahzan]

I am trying to emulate the function of the fiollowing command line:

start /b df.exe >dfout.tzt 2>&1

I have pared down th eprogram STARTP. the relevant portion is:

... 
integer,parameter::	SIZEOFSzArgs=100 
character(SIZEOFSzArgs) szArgs,args 
... 
dwCreate = IOR(HIGH_PRIORITY_CLASS,dwCreate)! /h 
dwCreate = IAND(NOT(CREATE_NEW_CONSOLE),dwCreate) 
... 
call zeromemory (LOC(szArgs), SIZEOFszArgs) 
args="df.exe"C// 	& 
          " >dfout.txt"C// 	& 
          " 2>&1"C 
res=  lstrcpy  (szArgs, args) 
 
fSuccess = CreateProcess(null_character,    &  ! image file name 
             szArgs,                        &  ! command line (including program name) 
             NULL_security_attributes,      &  ! security for process 
             NULL_security_attributes,      &  ! security for main thread 
             .FALSE.,                       &  ! new process inherits handles? 
             dwCreate,                      &  ! creation flags 
             NULL,                          &  ! environment 
             null_character,                &  ! new current DirName 
             si,                            &  ! STARTUPINFO structure 
             pi)                               ! PROCESSINFORMATION structure 

All this without really knowning what the heck is going on with several of these items (e.g. I canonly guess the ''C means the same as //char(0), etc)

Now this program works excpt it act as if it does NOT see ANY of the arguments to the df.exe (i.e. the redirection of the output or /nologo, etc)

I am either not setting dwcreate right or somthing wrong in setting the string szARG
Any help will be MUCH appreciated
Tim

p.s.

1.STARTP gives a mystery runtime error as it stands(only FYI)

2.Where does the settings like 68 for SIZEOFSTARTUPINFO come from?

3. Why is SIZESECURITYATTRIBUTES=12

4. the set of switches on the help routine do not match up with the win2k help files, for exmaple there is not option for /b but STARTP allows /c and /n so I can;t be sure what setting /b corresponds to.

[Jugoslav_Dujic]

Huh, one by one:

2) Use SIZEOF(si) to fill in corresponding field in SI before call. This is size of structure, in bytes (which is not always equal to sum of individual members, but that's another topic). Win32 API uses stuff like that where they felt there may be a need for future compatibility (i.e. if they add few members one day, they won't break up existing codes if they test size).


3) As above. Since you use NULL, no need to fill anything.


4) Based on a quick test -- I believe that redirection is property of command line processor, not of df.exe itself. So, you can do it by typing in command line, but not from your process. There are two workarounds, the simpler being invoking command-line processor instead:

 
'cmd.exe /k"df.exe > dfout.txt"'//CHAR(0) 

The second is to redirect output of child process to your process, but that's complicated; I can dig out a MS knowledge base article if you wish. Note that on Win2k/NT command line processor is cmd.exe, but on Win9x command.com. If you mean your code to be portable, use GetEnvironmentVariable("COMSPEC") to get the name of actual command line processor.

HTH
Jugoslav

[rahzan]

You are quite right and that redirect belongs to the cmd. Sorry about that + thanks.
My problem was I was inserting a char(0) after each arg the way startp seems to and it did not allow the args to be seen. this also maybe why startp does not work.

Also /k on cmd leaves a do nothing thread in the memory. one needs /c

HOWEVER, this leaves me after a whole day's work back where I was. I am trying to elliminate the appearence of the DOS screen when launching a program however, because I need to "redirect" I MUST use CMD and because of that the DOS screen STILL appears. Which is just the same as using SYSTEMQQ in about 50 lines less!

Any ideas on this will be appreciated.

Tim

[Jugoslav_Dujic]

This time, just a hint -- have a look on PROCESSINFO%wShowWindow (don't forget to set dwFlags to STARTF_USESHOWWINDOW also)

[Jugoslav_Dujic]

This time, just a hint -- have a look on STARTUPINFO%wShowWindow (don't forget to set dwFlags to STARTF_USESHOWWINDOW also)

[rahzan]

I think using your suggestion I got it to work. I had not even bothered looking the docs on it since I can't even understand 8/10 data types listed under win32.
Anyhow one last question (I hope). How to set the working directory.
I tried:

character(160):: szPath,path
...
call zeromemory (LOC(szPath), len(path))
call GETENVQQ('Whatever',path)
res= lstrcpy (szPath, path)
res=createprocess(.....,szPath,...)

But it returns a "bad starting directory" error. I;ve noticed that lpDirectory must be of type LPCSTR while e..g the Args are of type LPSTR. The difference is a mystery, but it may be the problem since the Path which comes out of getevqq looks ok.

Any ideas?
Thanks, Tim

[Jugoslav_Dujic]

All LP*STR's for practical use can be treated as C strings. Well, the problem might be in C-string/Fortran-string conversion... and all APIs require C strings on input so a Windows fortran program is usually full of conversions back and forth (which should be taken with care). My guess is that szPath didn't get zero-terminated; I'm not sure about behaviour of GETENVQQ -- you did ZeroMemory but maybe GETENVQQ overwrote it with blanks. Try explicit conversions:

C -> Fortran:

 
fString = szString(1:INDEX(szString, CHAR(0))-1)

Fortran -> C

 
szString = TRIM(fString) // CHAR(0)

Tip: C strings and Fortran strings look the same in the debugger; to really see what's in there open "Memory" debugger window and type in your variable name
(you'll see hex representation along).

Jugoslav

P.S. Why use lstrcpy when plain Fortran assignment will do it in a safer and simpler way?

[rahzan]

Darn!
My mistake again, sorry. Of course these are all C strings so I had forgotten about the null termination.

I was using the C-based gobldygook copy function since that was the way STARTP sample did it, and I did not want to make more trouble for myself. Plus the fact that the sdk-doc says these strings are supposed to be pointers and while I understand C pointers quite well, fortran pointers totally elude me (the sole instance of this occurence) but this is only because of the weakness of the cvf documentation on the topic of the pointers.

Anyway, Thanks a bundle for you help.
Tim