This is what I get from the console:

-1
27
Press any key to continue ...

I don't wana scream bug, but this seems kind of fishy.

Try using "wb" and "rb" instead of "w" and "r".

I tested it and yes, that was the problem.

I wonder if Allegro should do that for you. I'm never using Windows but still always use "wb" and "rb" since I know that Windows will possibly garble every byte <= ascii 32 otherwise. But for the Allegro file operations we could just specify that they are always in binary mode and fix the windows drivers accordingly. I can't see any problems with that, unless someone knows of an actual use for the standard libc behavior with "w" and "r".

Thanks alot, You wouldn't believe how long I've spent trying to figure out my problem.

That would also keep things the same as the File I/O routines in A4, which also doesn't differentiate between text and binary mode.

As far as I understand it, it's standard C behaviour : A portable piece of code that writes "ABC\nDEF" as a text file should read back "ABC\nDEF".

(This is an answer to "an actual use for the standard libc behavior with "w" and "r".")

Unfortunately not. Only if you use "rb" and "wb" in fopen. [edit:] Otherwise it only applies for ASCII files and if you don't care that line endings get mangled on disk.

My meaning was for portable C code that reads and writes in text file: The code opens the file in TEXT mode, fwrite() the single '\n' character, and the libc implementation will do whatever is required to produce a Newline character on the platform. Similarly, open back the file in TEXT mode, fread(), and you should get the single '\n' character.
This is straight-from-the-book implementation of the C standard... And it means the same piece of source code will produce similar-behaving programs on platforms that handle text files differently at the byte level.

Yes. And Allegro 5 works like that as well now. I think it would be better if it didn't.

For future reference, I just remembered: character 26 is ctrl-z, so it marks end-of-file. When you read a file in text mode, encountering this character should stop the reading as if the physical end-of-file was reached, it explains the "-1" returned by al_fread32le().

I remember some file formats used this trick, they started by a human-readable string,then ctrl-z, then the binary data started. Opening such file in a basic text editor should only show the string - though nowadays many programmer's editors can show the hidden content.