I downgraded my WIN7 machine to work on only a single screen. Ever since then, my programs are acting strange. The biggest example is my QB64 basic program that puts up a scrollable DOS screen. Before, I could expand the screen as big as I want in both horizontal or vertical modes.

But now, I can only expand the DOS screen vertically. No dice horizontally.

I'm running version 1.4, but it makes no difference.

FYI-- I can copy this same exe program to my WIN10 Machine and it is fine.

An exe program compiled on my WIN10 machine is horizontally locket on my WIN7 machine.

So this is a system thing, not a QB64 thing.   Any suggestions?

Based on what you guys are telling me, I traced the problem to the COMMAND$ function.

The command data given: "C:\folder1\folder2\bigname_flat.LST"

A print command at the start of the program shows: C:\folder1\folder2\bignam~3"

The first code line used as test: Print "command$--->";COMMAND$

This used to work on my old WIN7 machine.

That small program worked great.

I moved the three screen format statements below my DIM and shared statements and my screen now is scrollable.

Thanks for all the help guys.

Thanks for the replies.

Well I tried the $console lines and it had no effect. I couldn't scroll up to see what scrolled off the upper part of the string.

How could I screw up two lines?

Any thoughts?

Well, it passed your test. My problem is not an issue of an early EOF.

The passed result on your test forces me to look into the program for an error.

And I think I found the problem.
This is why the program was terminating early -- the line number went from 09999 to 10000 and failed the first conditional INSTR -- there was no ASCII "0" in position #1.
At first I fixed it by replacing "= 1" to "> 0". But that would limit the line number to less than 11111.

So I used the VAL statement and that allows  the number to be larger.

Thanks for the help guys.

Opps.  I was using an integer to count.  Using a long integer I get better line counts:

As far as I can tell, I'm getting an early End Of File. And always at the same spot. I'm processing 53,313 lines and that is it.

Using a different input file, I can process 51,770 lines and have good results.  The entire file is processed.

I've backed up to qb64-1.1-20160902.48 and got the same results, although this version doesn't like tab characters in the Basic language.

Do you guys have any ideas for me to try?

The REV0p0 file uses the macro file and is not a flattened file. It simply reverses the listing process and regurgitates the pre-combo file.

Look at the file "J13Gps4G0p0.ASM"

It terminates too early. There is more in the LST file to process, but nothing comes out.

The file you pointed out "include "c:\...\macros_j13_c.asm"" is a file that was a macro file that was included and is no longer needed.  That line is commented out for the output file.