Calling a command file from within Visual Fortran

Calling a command file from within Visual Fortran

I just came over to Windows FORTRAN from the UNIX side where we could call a text file with UNIX system commandsfrom within the FORTRAN code, e.g.,

istatus = system('sedfile')

where 'sedfile' would be a text file of UNIX commands (rm, ls, etc.) of the type we would enter from the screen prompt line. Is there an equivalent capability within Windows FORTRAN (using BASIC commands instead of UNIX, of course) to use system commands (e.g., dir) ? I can't track down the equivalent capability wihtin Compaq's Language Reference Manual but would think it a pretty standard tool for all flavors of FORTRAN.

Thanks much!

Carl

26 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Yes, if you open up the developer studio and check the CVF help menu, you should find this. The commands available are those which go with the shell from which the program was started, not BASIC.

It's not in the Language Reference because it's not a language routine. However, as Tim says, SYSTEM is a library routine which is available and you can see it in the on-disk documentation.

Steve - Intel Developer Support

I can not get CALL SYSTEM() or CALL SYSTEMQQ() to work on Windows 2000 - all references are to console mode applications.
For some parameters in the brackets (program name in the same directory as the calling program) some work and some do not.They all work on 95,98, NT and XP machines
All true system commands (like IDR etc) work and some executions of text editors (like EDIT and Wordstar, and batch files), but the working fortran-compiled programs aboort with "stack overflow". These are not big programs, (smaller than the text editors).
Example
CALL SYSTEM ('C:directorymyprogram ')
I've tried adding binary zeros to the end of the string without result. (Not needed in 95,98,NT,XP).
Anybody know why SYSTEM fails on 2000?
The same programs work from the command line.

I have not heard of this symptom before, and can't see how a program that runs from the command line would get stack overflow this way...

What compiler version are you using?

Steve - Intel Developer Support

Steve: I am using using version 6.6; and yesterday tried udpating to 6.6c with same result.
Laheye Forum has reported the same problem so it's probably related to MS and how Microsoft handles the API. Someone said it was due to a particular recent MS security update. Then several came back with confirmations. All say the same: "stack overflow". I used debug to find the 255 return code.
The console screen is actually formed, black, no text; but some failing called called programs actually say "stack overflow" on line 23, others put a small white square in screen centre; others just hang. These are LONGTIME working programs that run on all platforms to date. It's the recompiled F77 menu code, using the same function call to code, except as an Integer*4 and not an Integer*2 as in DOS. What I don't understand is why EDIT and Wordstar and Vedit all run when called.
Another problem, PERHAPS related is that some dos programs with a parameter need an extra non-blank caharacter in the command line to run now, not before.
Example:
FM myfile is a binary dump program from Caltech.
It runs on Windows 200o only as
FM Xmyfile where X is ANY non-blank.

Bizarre. I have never heard of this problem before. Do you have any online references I can look at? One of my systems runs Windows 2000 with all the updates and I have not seen any issues.

Steve - Intel Developer Support

I could not find on-line references. I tried my old list of Lahey contributions and find all the trouble started about 23-25/05/2004, when suddenly a lot of people who had updated Windows 2000 started to crash on some uses of the jret=SYSTEM(parameters). I was pontificating on the Forum that it didn't happen, but then it happened to me after applying the level 4 general Windows update.
Here is the information from myself:

"My reported "computer slow-down", occurring after installing the Windows KB835732 security fix, went away after I installed the whole huge group 4 update for Windows 2000 from Microsoft (it took 20 minutes with broadband connections)".

That is the offender others persons mentioned. I thought I had avoided it. I ran Norton on the windows system and it cleaned up a lot of bad things from the group 4, and the computer speeded up. But since then SYSTEM has not worked for every case called from the same menu program.

What I need is ANOTHER way to call the execution of an external program. My DVF is on the Windows 2000 machine. My programs actually work on a Dell XP (un"fixed", untouched).

The DOS-compiled versions (MS Fortran V3.31) also work in DOS and command line on the same XP machine. Only DOS-compiled versions mode work on my 2000 machine, and there is that occasional odd quirk of command-line mis-reading of parameters by ignoring the next character after the blank between program name and file name parameter in SOME dos programs. Probably these programs assume only certain delimiters (blank or comma), and maybe Windows is supplying hex zero instead of blank through the SYSTEM call, as it actually does in SPAWN.

I ran a small test program directly in DVF 6.6c, running on Windows 2000.

It shows EDIT (really a command) works as does DIR (not here).

The FM.com (a .com file) works ONLY if you put a dummy letter before the program name.

Any commercial type .EXE dos program that runs alone in a command line cannot be called by SYSTEM.

The debug version of TESTSYST.EXE runs itself!

And type .exe executables don't work and give "stack overflow":

program testsyst
implicit none
!
integer*4 :: jret,system
character :: cx
jret=system('EDIT c:progra~1Micros~2CommonMSDev98Myproj~1 estsystTESTSYST.F90')
print *, 'After call EDIT'
read(*,901) cx
! THIS RUNS. Uses Alt-X to quit
!
jret=system('c:fm Xc:fm.com')
print *, 'after call FM binary display called with dummy X'
read(*,901) cx
! THIS RUNS BUT NEEDS DUMMY "X" before filename. Program is DOS FM.com and is displaying itself in binary!
! uses Escape to quit
!
jret=system('c:saprunsapdoc')
print *, 'after call sapdoc'
read(*,901) cx
! THIS CALLS A (ANY) COMMERCIAL WORKING DOS PROGRAM AND GIVES "STACK OVERFLOW".
! Change the name for something you have.
! AND DOES THIS for any DOS .EXE file, but not .COM files - a clue?

jret=system('c:progra~1Micros~2CommonMSDev98Myproj~1 estsystdebug estsyst.exe')
print *, 'after call execute'
read(*,901) cx
! THIS RUNS ITSELF, WHICH WILL LOOP ON ITSELF (OK, expected) and has to be aborted.

901 format(A1)
end program testsyst

So we have a situation where DFV-compiled programs can be called by DVF-compiled programs. Commands can be executed and type .COM programs can be executed.
But DOS-compiled programs of type .EXE cannot be called to execute by SYSTEM under this DVF and Windows 2000 as a combination. Does this help find what is happening?

I am a bit confused - in your example, you changed the name of the folder, not the executable. Is that right?

Have you tried SYSTEMQQ or RUNQQ?

Steve - Intel Developer Support

No (or I don't understand the question). All the programs called by SYSTEM in the testsyst.exe DVF program are in different directories, except testsyst.exe itself, in the debug folder, used to call and be called as a test.
All my attempts with SYSTEM (or SYSTEMQQ with a different USE library) fail the same way. All the .exe programs I am interested in calling, apart from user-chosen editors DO reside in one directory.

ALL the SYSTEM functions called, commands, batch files, DOS .com and DOS .exe files are called the same way in the test program, with full path. In the case of EDIT, Windows knows where to find it; The FM.com program was in the root directory; Wordstar was in its own WS directory (example not in test program but these two DO work from the menu program I'm trying to get working on Windows 2000); SAPDOC.exe (a DOS-compiled Fortran program in this case) is just one of 60 similar programs in the SAPRUN directory; all of which 60 modules failed on being called; about half actually showing "Stack overflow" on line 23 of a black screen, the rest hanging in a black screen, I tried all 60 under debug, The calling menu program DOES allow for getting find code -2 ("program not found") and so reporting, but all returning error numbers are 255 (and positive).

The Wordstar program is 78208 byte. Almost all the other .exe programs tested that give stack overflow are EXEPACK-packed fortran-compiled executables of SMALLER size (about 40 to 60k byte). They are all about 1 to 5 years only in the present compilations and work on all DOS and Windows platforms, either alone or being called from a SPAWN call in DOS. In DVF, the documention essentially says that SYSTEM performs the same function as both SPAWN and SYSTEM in the Microsoft DOS compilers for Fortran (wheras DOS SPAWN uses hex zero delimiters). So the only difference is that where I had SPAWN in DOS I now have SYSTEM in the DFV version; the rest is sill F77 code with IMPLICIT NONE instead of (I-N). And the tests with FM.com and WS.exe show that SYSTEM DOES work taht way, but for me, only for some programs.

Further.
Just tried uncompacted executables, executables in many other directories, tiny executables that just read the keyboard and report the character struck, and so on.
ALL fail on being called by SYSTEM, with "stack overflow".. But WS.exe does not, and runs!
I then tried calling batch files.
A batch file starts to execute correctly but cannot find the first program to execute, even though the full path (actually the same path n the same directory) is specified.
Then tried FM.exe (a .exe version of FM.com, which runs as do any .com file tried); FM.exe also gives "stack overflow". I am now convinced SYSTEM does not work on .EXE files that need resources of any kind under Windows 2000. Succesful Wordstar probably assigns its own stack internally to the program space.

Is there ANY other way of loading and executing a program as a child process? (SYSTEMQQ gives the same result as SYSTEM)

Somnething is very odd on your system... The stack overflow puzzles me.

Try ShellExecute for grins.

Steve - Intel Developer Support

Shell Execute? I find no refence in the DVF Reference Manual nor Etzel/Dickinson's "DVF programmer's Guide".
I also find, with a new program, that I can Open and Read an unformatted "binary" file, but not open as NEW, output, one that exists (this is under debug). I thought it SHOULD simply overwrite the old one, I have to externally delete the old one before I can write a new file with the same name!
Other than these comments the computer seems to work fine.
Is reloading all the Windows 2000 patches a good idea, or NOT?
Should I try RUNQQ?

I can open a DOS shell within my DVF-compiled Menu test programs (I have a shell entry) and YES, anything works, EXCEPT any DOS .exe program other than Wordstar. I tried a lot or programs!
They all give "stack overflow". But all run alone directly.
Under debug a DVF program can call itself and execute, but not another different one!
And as before, any batch files called start to run but on hitting any executable - "stack overflow"!

ShellExecute is a Win32 API routine. See http://h18009.www1.hp.com/fortran/visual/vfn08/index.html#win32

Steve - Intel Developer Support

New.
Have now reloaded Window 2000 and applied all Microsoft Upgrade patches offered after MS "inspected" my computer; Group 4, Group 6 and miscellaneous others. Took a long time and I ran Norton (find windows problems) after each of the three sessions meed. No problems found.

STILL SYSTEM does not load and execute .exe files.
Code returned is 255; Message is "stack overflow".

Have not tried SYSTEMQQ again.
Where do I go from here? Use the API suggested (and I downloaded your article and the source code).

But there is something in W2000 that does not run with SYSTEM when executing executables. The fact it runs batch files, .com files and systems commands indicate the main part of SYSTEM works, But there is some resource (stack?) that is being strangled during this call.
I'm the squeaky wheel. many others have reported this in other sites.

Can you give references to the other reports? I haven't seen it myself.

Steve - Intel Developer Support

I've had stack overflow programs running some of my old DOS executables
under windows XP. My solution is to increase the stack size using the
exemod program (Microsoft EXE File Header Utility Version 3.0). Ironically, I had to run it on itself on an old win 95 machine to get a version that
would run on XP. If you'd like to try that on one of your executables, e-mail
me at japarsly@tva.gov. To send me an executable, you'll have to put it
into a .zip file.

The reports on this theme are all under "stack overflow after Miscrosoft update", referring to a failure with SYSTEM in the Lahey Frum dates 23/5/2004 through 28/5/2004.
Obviously the same API is used by Lahey as DVF. I am NOT a Lahey user, but a DVF user and a Microsoft DOS Fortran V3.31 user. I haven't seen more references but I can ask around. One person SOLVED the problem by removeing the patch I mentioned above. It didn't work for me.
See comments in thread on PATH and SYSTEMQQ.

Credit J.A. Parsley with the solution posted in the SSYTEMQQ AND PATH thread. Lahey Forum supplied about 50 reports on the same problem of failures after patching Windoes 2000. Some say SYSTEM simpley does not work at all in XP; I wouldn't know.

I need to use "system" command for linking a FORTRAN code with another one. But I have a problem. I have attached a simple example in which It seems the command line "call system ('discrete2.f90')" does not run the other code at all. What shoud I do?

Attachments: 

AttachmentSize
Downloadapplication/octet-stream discrete2.f90361 bytes
Downloadapplication/octet-stream system.f9068 bytes

What do you expect this to do? You're asking Windows to "run" a Fortran source file.

Steve - Intel Developer Support

oh ok I thought "system" is doing the same as "runqq". so that I should not use "system" for the same purpose. thanks.

 

It is very similar, but the same issue applies. You can't "run" a .f90 file.

Steve - Intel Developer Support

Thanks so much for your reply. The problem I was concerned about is now solved. 

Leave a Comment

Please sign in to add a comment. Not a member? Join today