Strange behavior of an EXE from PB 3.5 under XP

[Gunther Ilzig]

Hallo

I've done some experimental code in the last few days. That has to do with out of order execution of the modern processors etc. To use this features, one has to make some streamlining "by hand" to break for example dependency chains.

So, my program is written as DOS application with PB 3.5 and runs under XP with SP 2 on an old AMD Sempron with 1.6 GHz. It is blended code, PowerBASIC mixed with Assembler. I used TASM 4.0, because the PB Inline Assembler doesn't support FPU instructions.

The heart of the program are 2 functions; both calculate the sum of a double vector in BASIC or Assembler. The results are the same, of course. I've added 2 FOR-loops for time measurement, in which the functions are called.

And here the trouble started. All worked well with 1330 loop iterations, but at 1350 iterations the program in the DOS box falls back to the command line - in the PB IDE as well as the EXE. It is clear: the resulting times are not very accurate under Windows (multitasking etc.), but it should work. It is also clear that the DOS emulation under Windows was always a tragedy.

I assume, that the error is in XP and not in PB, but I haven't any clue. Does anyone know what happens here? I'll test the program next weekend under other Operating Systems and post the results.

Best wishes
Gunther

[Michael Mattias]

but at 1350 iterations the program in the DOS box falls back to the command line - in the PB IDE as well as the EXE

With a PB-DOS program, it "should" be exiting ("falling back to the command line") with an error code and program offset. You can use Compile/Find Error to relate that offset to a specific line of source code.

[Gunther Ilzig]

With a PB-DOS program, it "should" be exiting ("falling back to the command line") with an error code and program offset. You can use Compile/Find Error to relate that offset to a specific line of source code.

Michael, yes and no. You're right, if the error comes from the application, but it worked well with less loop iterations. The only error report comes sometimes from the Windows VDM-CPU, mostly not. I haven't a good ring 0 debugger to check the instructions step by step - that's the problem.

My first impression was, that the behavior has to do with the TIMER statement. But that isn't true; also the same problem without time measuring.

On the other hand: a number of 1350 loop iterations can't cause an integer overflow. I've changed the loop counter to long integer and 1350 is always the end of the line.

Gunther

[Michael Mattias]

>a number of 1350 loop iterations can't cause an integer overflow.

You didn't have to tell me that. I could see that plainly in your code.

BTW, a have three bucks says you DON'T need a "ring 0 debugger" to find your problem. The fact your program executes correctly up to some number of iterations tells you that.

Is is possible that "iterations" is wrong word, and really is "recursions," intended or not?

Overflowing the stack would explain a lot, especially the part where the number of iterations/recursions to the failure point remains constant, and that you don't get an applications error code on exit (when the stack is overflowed or corrupted, lots of stuff does not work as expected).

But "iterations" versus "recursions" can't tell from your posted code. I guess I need a bit more experience to do that. (Experience reading minds, that is.)


MCM

[Donald Darden]

No one can adequately judge what might be happening on your PC, and your observations only serve to tell us the impressions you have formed, and do not seem to pinpoint any specific problem that could relate to what you are trying to do.

i have PB 3.5, and other than a few minor cosmetic changes needed for the console window as opposed to the DOS screen, I have found no real problems writing or adapting earlier code to work with Windows. I haven't tried everything, but even code written that goes directly to serial and parallel ports has worked. However, they are different environments, and both PB/CC and PB/Win are better suited to work with Windows.

What Michael is saying is, that if your program is abruptly terminating rather than running to completion, there should be a error code being returned by the system. Even if there is no error, a code of 0 is a normal termination. So what is the code being returned by your program? You can assign it to an environmental variable, but Windows does not maintain a child environment once the child process terminates. Efforts to modify variables in the parent environment are involved. Usually, you perform a task in the child process that carries over to the parent after the child process ends. For instance, creating or writing to a text file with words like "count = 1330", then "count = 1331". If the program terminates, you can check the text file to see how far it got. You can even use TRACE sometimes as a way to log what sequence a program runs though and how far it got. A Ring 0 debugger is certainly not required for what you are trying to do here.

[Geoffrey Voeth]

Have You Tried making a WinXPsp2 PIF FILE

I have found if you use virtual anything you must make a PIF file under WINDOWS XP SP2 and if you want things to run fast you must set the idle time to minimum and EMS memory to whatever. Are you using any virtual arrays ?

[Knuth Konrad]

It might also be worth trying the compatibility mode: http://support.microsoft.com/?scid=k...2533&x=16&y=13

[Gunther Ilzig]

It might also be worth trying the compatibility mode: http://support.microsoft.com/?scid=k...2533&x=16&y=13

Thank you Knuth,

an excellent hint. I fixed the problem and now the entire program works fine. I have to do some documentation, adding comments etc. If that's done, I'll try to publish the material. It is written with PB 3.5, but should be easily portable to PB CC. It shows how to use out of order execution, breaking dependency chains etc. with modern processors. It might be that this is interesting and can help other programmers.

Gunther

[Michael Mattias]

> I fixed the problem

Which was....???

[Gunther Ilzig]

>
Which was....???

Two problems:

1. I used virtual arrays. As this was changed and
2. the application has now 4 KB of stack memory,

it runs fine.

Gunther

[Michael Mattias]

Thank you for posting that.

Now there is a 'fix' to try for anyone else who has a similar problem in the future.

I think it only fair that when one asks here, and others contribute suggestions, making the time post "what worked" is a very very small price to pay for the quantity and quality of otherwise free support received.

MCM

[Gunther Ilzig]

Michael,

you're right. It seems to me, that the entire trouble had to do with the poorly realization of the DOS emulation under XP.

Gunther