When migrating from FTN95 7.xx to FTN95 8.xx (32bit), I get problems with the call of START_PROCESS@. The return code is now -1, which means a problem with calling the new process.
How can I get more information about the reason of this problem?
Welcome to our forums
When migrating from FTN95 7.xx to FTN95 8.xx (32bit), I get problems with the call of START_PROCESS@. The return code is now -1, which means a problem with calling the new process.
How can I get more information about the reason of this problem?
START_PROCESS@ returns -1 when
the length of the command string is zero (i.e. only spaces in Fortran)
the resulting call to the API CreateProcess returns NULL.
Case (b) is far more likely but that's as far as I can go.
I have wondered what happens if you try to start up a 32 bit app from a 64 bit app.
I try to start up a 32 bit app from a 32 bit app.
When I reduce my project to a small example it is working, but in the complete project I get this problem. I can't see any relevant message when compiling and linking the app.
In answer to Paul's speculation, I'd expect it to just work, same as calling a 64 bit app from a 32 bit one on a 64 bit system. The question is, what return message do you get when calling a 64 bit app from a 32 bit one on a 32 bit system?
My money is on START_PPROCESS@ at best resorting to a Windows message, and START_PROCESS@ causing a mess/crash/hang. Or maybe both cause a mess etc. Or maybe pigs do fly.
Only experimentation will tell.
Eddie
Hi, Have you tried:
START_PROCESS_AND_WAIT@
This solved a recent problem I was having with START_PROCESS - might not help but might be worth a try.
Bill
Another one is START_PPROCESS@ (P is repeated). They probably all end up calling CreateProcess.
If the problem persists then I could look into recovering the API error report following the call to CreateProcess. Thinking about it, you might even be able to get this report directly in your Fortran code.
START_PROCESS_AND_WAIT@ returns also error code -1.
START_PPROCESS@ leads to a 'Floating point stack overflow' in __clearwin when executing the line with SDBG.
I called now GetLastError() immediate after START_PROCESS@ and got error code 740, which means: 'The requested operation requires elevation.'
I don't know the meaning of this error code?
Google does.
The message simply states that your code is attempting to do something such as changing an item in the Windows registry, etc., that requires 'elevated privilege'. When you attempt such actions in Windows Explorer, you get a pop-up that you have to accept with a click or by entering an Admin password.
No, it does not require you to take your laptop into the Kehlsteinhaus 😃 .
Mecej4,
According to Godwin's Law, even with such an oblique reference, your last post has to be declared unhelpful! 😉
Eddie
If the application is just for your own use then you can probably fix this by running the primary application under 'Run as administrator'.
Obviously when starting the second app with START_PROCESS@ Windows will give a User Account Control message.
This message does not appear when I start the second app directly and it does not appear when I compile with FTN95 7.xx.
I have also another app compiled with FTN95 8.10 which uses the same algorithms and the same second app and there is no such message. START_PROCESS@ works properly in this case.
Are you testing on more than one machine with different operating systems? If you are only using one machine then the behaviour is very strange. Can you construct a working sample for me to look at?
I'm just testing on one machine running Windows 10 Pro 64-bit.
I will try to build an example, but it will need some time.
I have done now further investigations on the problem with START_PROCESS@ and Error 740.
The app which should be started by START_PROCESS@ has an UAC symbol in its icon and the 'Properties' of the app have no 'Compability' tab. So I can't remove this administrator privilege.
Even if I delete the app and rebuild it, I get the same behaviour.
This appears only for the 32-bit release of my project. The 64-bit release is working without problems.
I am willing to do some testing if you can provide some code that illustrates the failure. I am assuming that you are using Windows 10.
Paul,
I have sent an example to your e-mail address.
Paul,
I have solved the problem by using ShellExecuteEx. I have build a small function START_MY_PROCESS which works like START_PROCESS@ and has no problem with my examples.
If you are interested in the solution, I can send the source code to you.
Thank you. That would be useful.