Problem with Turbo Pascal in Windows2000 cmd.exe/DOS-box

[cobo]

I use Borland Turbo Pascal 5.5
In Dos-box Windows98 no problem.
In cmd.exe/DOS-box Windows2000 following problem:

Program A works well, and after end of program I am still on the commandline in the DOS-box.

Program B works well, but after end of program exits cmd.exe/DOS-box and returns to desktop. DOS-box is closed.
Of course I want to be able to stay in the DOS-box after running the program.

Both in Window- or FullScreen-option the same result.

The main difference between program A and B is that I use BLAISE PowerToolsPlus in program B, especially the units which handle Direct File Access (like e.g. "__ROpenFil()" etc.) So I suppose that causes the problem.

Is anyone familliar with this problem, and even better: has a solution?

I would be greatful for it,
Cheers, CoBo.

 

[lionelhill]

I suspect this is nothing to do with pascal, but more a reflection on whether you have the "close on exit" box ticked in the appropriate program information section of windows. I suggest you make an icon for each program on the desk-top, right-click and select properties, and check the box as desired (I think that applies to Win2000; certainly does on NT and XP).

 

[cobo]

No, it must have to do with Pascal, because in the same DOS-box program-A does not lead to an exit, while program-B does. Program-A and program-B are very similar, and they are both used in the same DOS-box. The DOS-box cannot be the problem.

Further: program-B reads an ascii-file, and when I reduce the number of lines of that file, the DOS-box is not quit.

Program-A also reads a file, but not using the direct-access handles. The number of lines is not a problem here.
I suppose it has something to do with memory. Somehow the direct-access functions seem to interfere with that. But I am no expert on this matter, so I could be totally wrong.

Who can help?
Cheers, CoBo.

 

[JohnHPears]

I’ve had similar problems using Delphi apps written for console mode.
The problem nearly always turned out to be a runtime error that shut down the app with an error message and then closed the dos window, but this happens so quickly you miss the error message.
Instead of running the “program” from an icon, run a "bat file" from an icon e.g.

Rem file name: My_Run.bat
Myprogram.exe
Pause
Rem end of bat file.

This way the window stops open until you press a key, after reading any error messages.

 

[cobo]

I already did this. I even tried running from a batch-file in a batch-file.

I put a message + wait at the end of the Pascal program-B itself + a pause after the program.exe + one after the call batchfile,
The program comes at the end_of_program without error, and waits for keyin. After keyin the pause in the batch-file is skipped or - more likely - the cmd.exe/DOS-box is quit before that: the pause-line is never reached.
So "Pause-2"is never reached, let alone "Pause-1".

batch1:
call batch2.bat
pause Pause-1

batch2:
program-B.exe
pause Pause-2

The funny thing is, as I wrote before, when I reduce the input-file for the program (program-B) to 52 lines, there is no problem.
Just adding one line to this input-file, makes the program quit cdm.exe/DOS-box, althlough is finishes the program without error.

Reading the same file with program-A does not give any problems. There is no limit to the number of input-lines.
It must have to do with the direct access reading. That is the only difference between program-A and -B.

Bare in mind that both programs work proparly on Windows-98.
So the error cannot be in the Pascal-program itself.

This is a complicated matter I am afraid.
Would be obliged if someone could help.
Cheers, CoBo.

 

[JohnHPears]

Oops, I didn’t spot the 2000 bit.

I suspect that the program will fail on win NT4 as well as Win2000 ( NT5 ).
I have many 16 bit apps fail in the NT environment but work fine in win 95/98.
I strongly recommend getting Borland Delphi 6/7 personal edition FREE from

http://www.borland.com/products/downloads/download_delphi.html

and write a “console mode” app.
Delphi does not come with the CRT unit, but Will DeWitt Jr. wrote a free one. Get it from

http://threads.borland.com/codecentral/ccweb.exe/author?authorid=38901

or do a web search on
“crt unit for Delphi Will DeWitt”

the only modification you will have to make to existing code is add the line
{$APPTYPE CONSOLE}
after the line
program xxxx;
and change the main program name from xxxxx.pas to xxxxx.dpr.

I have used Delphi since ver 1. But always used good old turbo pascal for dos stuff… until I discovered the 32 bit crt unit for Delphi.
Believe me. You’ll never look back.

John Pears, Coventry, England.

 

[lionelhill]

(1) ... puzzled: turbo 5.5 is a dos program. It cannot write a program file called "program-B.exe" because that's not a valid dos name. I'd avoid long file names and long paths in turbo5.5 world.

(2) I don't know if it's possible for a pascal program to permanently change the source of keyboard input in a dos-box. It probably is. If you've done this, then perhaps the dos box could continue to get its input from a file or an un-emptied buffer, in which case it might be closing the window for you. Just a thought, might be rubbish.

(3) I have had no problems whatsoever running a wide range of dos programs in the dos boxes of win95, win2000, winNT, and winXP. There is nothing wrong with any of these dos boxes.

 

[cobo]

to lionellhill:

1)
You're right, it's not actually called "program-b.exe", I used this name just for this discussion.

2)
The actual program-B is quite big, but because of the problems I reduced it to just opening an ascii-file, displaying the number of lines of this file, closing the file and exit.

The batchfile is as follows:

prgm-b.exe file1.txt
pause Program-B

The TurboPascal-lines from opening (assuming the declarations):

string1 := paramstr(1);
assign(f1,string1);
reset(f1);
_ROpenFil(f1,file1,pointer1,linesize,linenum,error);
{ this is a PowerToolsPlus procedure }
{ "file1" = file, "pointer1" = pointer, "linesize" and "linenum" = longint, "error" = word }

gotoxy(1,8);
writeln('File=',string1,'Lines=',linenum);
char1 := readkey;

After this the file is closed and the program quit.

When linenum <= 52 the batchfile is terminated normally, so going to pause and after enter remaining in the DOS-box.

When linenum > 52 the batchfile is terminated before pause and the DOS-box is terminated.

3)
The TurboPascal-editor is not working. So I write my programs with a different editor and compile them directly from the commandline.

All my other DOS-programs work, only one has a mouse-problem. It's a music-editor (called "Score&quot which does show the arrow of the mouse, but does not react on it.

The mouse in the Dos-editor EDIT works okay.

Even stranger, a friend of mine uses the same program ("Score&quot, also in Windows-2000 Professional, but with him the mouse works normal. I tried different mousedrivers (of course also the one he is using), but even when the cat is out, my mouse won't dance. (I placed a question about this in the Windows-forum, but didn't get a reply.)

Why, why, why, why?

I have not yet looked into the Delphi-thing John Pears suggested. Maybe something comes out of that.
In the mean time, open to suggestions, often large problems are caused by a minor little stupid thing. You only have to know it.

Cheers, CoBo (Den Haag, Netherlands).

 

[lionelhill]

I'm a bit worried the turbo pascal editor isn't working. Mine does, in all the environments I listed.
I don't know anything about powertools plus, but I assume your pointer is pointing to a sufficiently large area of appropriately declared memory?

 

[cobo]

Your remark on the Turbo-editor made me puzzle:
it doesn't work under WIndows-98 (Windows-98 says that it only works when you restart under MS.DOS-only), so I never even tried it in Windows-2000.

Just now I did, and it works! Now comes the strange thing: When I run program-B from the Turbo-editor, after running it returns normally to the editor! So there is no early termination of the DOS-box. When I however run it from the DOS-commandline again, DOS is terminated again after end_of_program-B. So the same program runs OK from the Turbo-editor (which means more memory is taken, by the way!) but it does not from the commandline.
What does this learn us?

The PowerToolsPlus procedure is a unit that is called from my TP-program. I assume this unit takes care of everything. When I compile program-B (both from DOS-commandline and TURBO-editor) there are no error-messages. It works without problems under Windows-98, and apart from the early terminating DOS-box problem, all TP-programs work under Windows-2000.
But you could be right that there is a problem there with a pointer/memory-conflict between PT+ and cmd.exe. But why is it not a problem when running from the Turbo-editor?

I am not deep enough in this programming to find this out, but somehow I have the feeling it may have to do with somnething complete else. Often I experienced that when something didn't work well on my computer, that the cause of the problem could lie in a place where you did not expect it at all. You keep focussing on the problem and the area around it while the solution was way elsewhere, and always found by accident.

You know the joke of the man with the broken car?
It wouldn't start anymore, he checked everything, oil, batteries, gas, etc. Finally he ordered a man from car-repare-service and this man looked a few seconds at the car and then hit it hard on the hood. After that the car started fine again, so the repare-guy says: "that's $100,- please" The man of the car says "$100,- for one kick?"
"Yes," said the repare-guy, "you must know where to kick!".

Cheers, CoBo.

 

[Bertv100]

If the program works from within the IDE and not from DOS, this means that the program messes with interrupts. Before running a program the TP IDE saves all interrupt handlers, when the program has finished, the handlers are restored. Even during the run of a program it is not certain that a called interrupt is a system interrupt or one that is replaced by TP (this is the reason why you can't disable Ctrl-Break by redefining it's interrupt when running from within the IDE).
Maybe the powertools unit does some specialized memory/interrupt/port hacking. Try to replace your file routines by the standard ones and see if the problem persists.

Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com

http://student.vub.ac.be/~bvingerh/

Don't worry what people think about you. They're too busy wondering what you think about them.