SYSTEMQQ and PATH

[greldak]

I am trying to run a small DOS program from a third party using a command shell with either the SYSTEM or SYSTEMQQ routines, however I cannot persuade the program to run ( the command returns success though) I have traced the problem to the PATH environment variable that the shell is picking up being different to that picked up when I start a command prompt from outside of the program. Can anyone enlighten me as to how to either pick up the same PATH variable or point me to which one the SYSTEMQQ routine uses.

I am running CVF 6.6B on Windows XP Pro

[ssragunath]

Hi,

I am not an expert user, but I have successfully run a program using RUNQQ. The syntax is result = RUNQQ (filename, commandline). Example result = RUNQQ('myprog', '-c -r'). In this case you just need to keep 'myprog' in the same directory as your DSW file. Hope this helps.

Thanks.

[greldak]

Unfortunately in this case I cannot rely on the program being run residing in the same folder as the fortran executable or indeed in any particular location which is why I need my program to pick up the PATH correctly.

[Jugoslav_Dujic]

But have you tried just RUNQQ instead?

Environment variables, including PATH, set by SETENVQQ (or SetEnvirnomentVariable api)are local to a command shell process. When you call SYSTEMQQ, you spawn another instance of command shell, which -- I think -- does not inherit the environment from the launching process. RUNQQ should not have that effect.

However, one thing is puzzling me -- you appear to know the directory where the .exe in question resides. Why don't you just launch it with the full path string instead of fiddling with PATH? Or is PATH set by something else?

Jugoslav

[greldak]

I'll try RUNQQ and see if that solves the problem.

I know where the program resides on my development machine, unfortunately I cannot guarantee it will be located in the same folder on the machines this is to be deployed on, indeed this may even vary with future versions of the third party software.

[tbwright]

I have the same problem, waiting Steve to get round to it. I find that reloading the directory DOES work, but the execution of I4=SYSTEM('program-route and name') does NOT work in Windows 2000; It gives error return code 255 and "stack overflow" on the Command-line screen opened, But it DOES work for a parameter which is 'dir" etc. ( any an internal DOS command) or a text editor in DOS like EDIT or 'C:WSWS' for wordstar as an example of other working programs. No problem with these! But it won't load and run a fortran-compiled console mode program, or a Fortran DOS program as a child process, from what in my case is the main menu program. This hurts, since the menu program is at least 15 years old and works fine in every platform including MAC DOS emulation.

[tbwright]

See the other topic on this same subject.
I have made extensive tests, with specially written test programs, and have even reloaded Windows 2000 and downloaded all patches and the result is the same.
SYSTEM (and probably SYSTEMQQ), will not run any .exe excutables. It will run any systems command, any batch file until it hits an executable, and runs correctly any .com file I tried. One single exception: Wordstar.exe actually runs when called, which program has its own stack within the body of the program, I believe.

Suspicion falls on one Microsoft security patch number KB835732, since all persons reporting this failure of SYSTEM (and in other Fortran compilers!!) say this is the last thing they did. What the relation is I don't know.

[greldak]

I have read through your postings and feel that your problem may be related but it is not identical

I had originally written the program on a win 98 machine and then migrated to a win2k one - in both cases it would run the executable without problem. Over the new year period we moved to a win XP environment with the result that the program could not find the executable within the path. It generated the black command prompt, gave an error cannot find command or program and exited. No stack overflow was generated though. It appeared to me than XP was propogating the machine environment wheras win2k propogated the user environment.

I think RUNQQ avoided the problem but as it has been several months I can't be totally certain.

[anthonyrichards]

Ihave been trying to apprehend what your exact problem is. What exactly do you mean by a 'FORTRAN DOS' program? What compiler was used to generate it (them)? You imply that NO .EXE programs can be started within a DOS prompt window except Wordstar.exe. What is Wordstar? What are the .EXE programs that fail? Are they game programs? Have you tried running in MS DOS mode? In my experience, programs originally written for DOS will quite easily fail to run in a DOS console window in Windows, for various quite understandable reasons. Do you have access to the FORTRAN code for the .EXEs you want to run?

[greldak]

Anthony

Did you intend to post this in the other thread

Calling a command file from within Visual Fortran[ 1 2 ]

your questions seem to apply more to the issues raised there than those I had found back in April.

However I can tell you what Wordstar is (is it still available?). It wastheindustry standardwordprocessor originally produced in the late '70s and seemed very tolerant of the operating system it would run on - I have even managed to run it under CDOS on a DRS 300 system. I think it may have been originally developed to run under CP/M. You will find several of the key shortcuts were made available in MS Word when that was first produced.

[Steven_L_Intel1]

I can believe that 16-bit DOS executables, such as WordStar, may not operate properky on Windows NT and derivatives, depending on the context from which they are run. I would not expect a "stack overflow" message, though - either they should run normally or give a clear error message.

[tbwright]

A little explanation.
There are two ways of executing DOS programs under Windows.
One is CMD.exe and the other command.exe.
They behave differently.
One can have its environment changed, the other not.
One remembers which directory it started in and returns to that directory after a batch file terminates; the other stays in the last directory set by CD directory.
Neither functions like DOS did, but both together have the same features, but not individually.

This is where the use of requesting the PATH is needed.
I find setting the path works in all systems.
.
I find that calling 16-bit DOS programs (.com or .exe type) or batch files or commands from the command line or from a DOS-compiled Fortran program using SPAWN for programs and SYSTEM for commands, works in all Windows versions 95,98,NT, 2000 and XP.
But calling the SAME programs, batch files commands and so on, from the SAME F77 program source, compiled under DVF with SPAWN replaced by SYSTEM or SYSTEMQQ, will NOT work for just the .exe type 16-bit DOS programs on Windows 2000. We do not have DVF on another other system type.
These 16-bit DOS programas are NOT games, but long-time commercial programs. We used dwbug to make a test programa and try all the mentioned uses of SYSTEM. The debudg program could even call itself, (an .exe file) but no other .exe files except Wordstar which seems to have an internal stack.
The error is number 255 (positive!!) and the message is "stack overflow" on the command line window opened.
By the way, the spell checker hates "com" as part of any word, anywhere!
.

[tbwright]

Steve. Your last posting #10523 suggests to me that my description was not clear. You aided us two years ago in setting up DVF and we communicated about a Text User Interface we developed for DVF and gave to Compaq.

Repeat; after updating Windows 2000 with security patches, many users worldwide have reported the same thing with respect to the use of SYSTEM. I am requesting copies from contacts and different Forums; They are coming in now.

Wordstar (WS.exe) is the ONLY 16-bit DOS program that executes if called by SYSTEM in our Windows 2000. 32-bit DVF-programs also seem to execute (I only tested the single working one I have). We reloaded Windows; no change.

When using SYSTEM from within a DVF-compiled program in updated Windows 2000 ONLY as far as I can test:-

What does NOT work is calling 16-bit type .exe DOS-compiled executables (ours compiled with MS V3.31, compiled dates 1985 to today), from a DVF compiled calling program. The failure is always "Stack overflow" and error code 255.

With Windoes 2000, all these 16-bit programs execute normally under DOS and under Windows (command line). All can be CALLED and executed using SPAWN in a 16 bit DOS-compiled program to call them, But not if called by SYSTEM in a DFV console program. So if the calling program is DOS compiled (SPAWN),the called programs run. If the calling program is compiled by DVF and uses SYSTEM or SYSTEMQQ, they DO NOT RUN (if they are .exe type executables).

What DOES work, is calling type .com executables, batch files and system commands. I can supply the test program.

[tbwright]

Here is the solution to the problem (supplied by members of Lahey Forum). The problem started when a MS security patch seems to do something needing the called program stack.

1) SYSTEM as used, expects the called program to provide its own stack for loading, instead of the normal DOS loader. This reduces its available stack size a lot under windows environments, to the point where it might not even load..

2) The workaround is to use the linker to change the stack to 5000 (suggested); Use exe2mod.exe to find what stack is assigned and up it a LOT.

Then the modified DOS-compiled program will load and execute, called from a Windows compiled DFV program. The reverse is reported to not need any changes.

I can confirm that DVF-compiled programs can call DVF-compiled programa and DOS programs can call DOS-compiled programs started in a Console command Window.

I don't like it because not all DOS programs are available as object modules that can be modified at the link moment.
So no third-party software is going to work unless called directly.

[tbwright]

I confirm that modifying the stack size in the executables to be called by SYSTEM and SYSTEMQQ resolves the problem.

It seems SYSTEM is using the called modules own stack to complete the loading, whereas a DOS window loads the exectable withiut doing that (just an interpretation).

I used a modifed exemod.exe (stack extended) to first modify LIB.exe (I could updae my library on Windows 2000), and then all the executables we wanted to called in Windows 200 through another program by SYSTEM.
It works. I have only seen this problem in Windows 2000, not in XP and not in 95 and 98.