Home/ Questions/Q 938147
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T21:35:41+00:00

I have a old command line based program (its fortran if that matters) that

  • 0

I have a old command line based program (its fortran if that matters) that is opened from a C# application when a user clicks a button. If the command line program is shut down while it is running data becomes corrupted. Is there any way to prevent people shutting it down while it is running? Like make the [x] not be available or somehow embed the program into mine?

 System.Diagnostics.Process pname =
 System.Diagnostics.Process.Start(Path.Combine(Application.StartUpPath,
"diag_main.exe"));

    pname.Exited += new EventHandler(pname_Exited);

Note: I want to still be able to see the application running and it closes on its own when it is finished, I just can’t have people killing it while it is in the process of running.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    A solution that will take a decent amount of programming but can be done:

    Write a separate program that intercepts the screen output of the program and sends it to your program somehow. Run this program in the hidden window, it turns around and runs the app and sends the output to your program.

    At least parts of the interceptor are almost certainly going to have to be in assembly.

    Edit: Redirecting stdout won’t do it even if the program only writes to it–he wants the output displayed.

    There are three things that might need to be intercepted:

    Int 21h filesystem writes. These are the things that could be intercepted by redirecting stdout. Beware that some programs may write to a different handle number that actually represents the stdout file–look up the handle that’s being written to in the program’s handle table and compare it to the stdout entry (IIRC the second entry)–if they match it’s actually screen output.

    The second level is IIRC int 10h. There are several sub-calls that must be intercepted.

    Finally, a program may do direct screen writes. Intercepting these would be a major pain, I wouldn’t even consider trying it (you would have to basically rewrite the dos box.) Instead, frequently compare the screen memory with a saved copy looking for changes.

    In all three cases at least parts of the routine are going to have to be written in assembly.

    I have done the first, played a bit with the second but then I found that I could get by without doing it. I’ve never attempted the third.

    • 0