dosbox version?

I'm using the latest version, #0.73

Can you recompile the fortran app?

Yes, I can recompile since I wrote the program and have the source code. Would simply recompiling help, or should I change something in the code ?
I should add that this program worked fine, under WinXP/SP3, until recently. I suspect that the problem was caused by my having to install the .NET Framework in order to operate another program. The evidence for this is that the old Fortran program continues to work on the one machine I have which does not have the .NET Framework installed. When I try to run with .NET Framework installed I get a "Stack OverFlow" error which can't be fixed even by setting Stacks=64,512 (the maximum allowed) in Config.NT. I'm hoping that DOSBox will let me get around this problem. I know that none of this .NET sutff has anything to do with DOSBox. I mention it only because it might provide a clue of some kind.
Thanks !

Would simply recompiling help, or should I change something in the code ?

No, but maybe you can produce a simple test case (short fortran app that
just reads/processes one keyboard input) that shows the problem and you
can upload here.

I should add that this program worked fine, under WinXP/SP3, until recently.

Does it work under DOS? If it doesn't, chances are quite low that it works
in dosbox as-is.

What compiler are you using?

Yes, the program works under DOS. I've been using it - under DOS, Win95, Win98 and until recently, WinXP - for >20 years, so this problem is really something very recent. I'm using an old MS Fortran 77 compiler, vers. 3.3 I believe. This is the same compiler I've been using all this time. Yes, I could try a newer compiler, but, given the history here, this would probably be just a diversion. You've made a good suggestion. I'll try writing something very simple, something that just reads in a single response from the keyboard and see what happens.

One thing you could try is setting machine=cga in the dosbox.conf file. DOSBox uses enhanced keyboard functions for some things with EGA/VGA machine types, and standard keyboard functions for non-EGA/VGA. Might not help, but I know of some old games where it does, and it's easy to check. However, considering that you describe the problem as happening after you press enter, it might not be a keyboard problem anyway.

You could try to set core=dynamic and cycles=max in your dosbox configuration file.

I tried

config -set "dosbox machine=cga"
config -set "cpu core=dynamic"
config -set "cpu cycles=max"

but this didn't help. Strangely, after entering these commands, I still had what looked like a VGA, not a CGA, screen. On the other hand, if I enter

dosbox -machine cga

from the Command.com prompt I get a CGA-looking screen.

In any case, I followed up on the previous suggestion and wrote a very simple test program, which ends up having the same problem as described previously. I'm attaching the source code and the .EXE file. The source code has some non-standard Fortran 77 commands, like "CLS" and "LOCATE". I've included these to duplicate as much as possible the actual program I'm trying to run. These commands just clear the screen and put the cursor in the upper left corner. These are included in an add-on subroutine library that gets Link-ed to the object file to build the .EXE. The $STORAGE:2 and $NOFLOATCALLS are MS Fortran meta-commands, again included to duplicate lines in my real code.

Again, this is all stuff that I've been using for >20 years until the recent unpleasantness.

The problem is that the app reads from the console device with INT 21/3F and DOSBox uses the byte count in the CX register to control how many bytes are read, but real DOS doesn't pay attention to CX when reading from CON and only returns after a carriage return (documented in the interrupt list). CX is 1 when the read function is called, so DOSBox only returns the first key pressed, not everything entered and ended with a CR.

DOSBox is intended for games, and support for applications is often a secondary concern. If games relied on the specific behavior involved, it would probably be supported in DOSBox already. One thing you can do is boot real DOS in DOSBox, but then there are several virtualizers you could use if you go that far.

well we could support it. Testing for CON is doable

OK, it looks like the end of the line here. Thanks for your attempts to help. At least now I know why my program doesn't work in DOSBox. I'll search around for another solution. Thanks again !

I have the same input problem with an old DOS software I need to use today on my Windows 7 computer. The software seems to run properly into the DOSBox shell, but when I respond to a request for input I type a character, it appears on the monitor but when I hit Enter nothing happens.
Did you succeeded in solving the problem?

TEST.EXE 263 downloads?!

Same story: when I hit Enter nothing happens (the phrase "THE ANSWER IS..." doesn't appear on the screen)!