I'm working on a game where the game's settings in an INI file via a call to al_save_config_file(). Under Linux, where I do most of development, this works flawlessly. When I compile the game under Windows, the resulting INI file is all on one line, which is highly indicative of saving under binary mode rather than text mode (Many Windows programs require a CR+LF to register a newline).

Is there some sort of parameter that I'm missing, or is this an oversight?

It's not binary, it's just missing the CR\LF pair, using LF only (Linux style). You just need a better editor to interpret the LF's properly. Code Blocks works, and Notepad++ too.

I should say, that it may write different config files on different platforms, using the native path separators when saving. Or maybe it only saves in LF form, IDK.

Actually it is, remember fopen(filename,"wb"); ?

You're using al_save_config_file, right? I don't think that would save in binary, because then you couldn't hand edit it (easily).

Leaving out the \r is binary! Well, so is the other way, it's bits.

Indicating the file on Linux shows multiple lines, using LF. It could be in binary, but then you couldn't read the text! So I'm assuming it is not binary. See my reasoning?

The "binary" comes from Windows C compilers mangling files opened as text that can contain all values ("binary" files). The text is binary either way, look at it with a hex editor, see the bits?

http://www.delorie.com/djgpp/doc/libc/libc_337.html

[EDIT2]

"Text" is simply that range of binary values that our editors have been programmed to map to alphanumeric chars on the screen.

I'm confused. How do you know allegro is opening the file in binary mode? Wouldn't that defeat the purpose of an easily configurable config file?

Oh, and yeah, you're right the text is binary. But the rest of the file would be filled with 'garbage'.

"Binary" in this context just refers to the line ending convention, not how numbers are represented or anything else.

Edgar, you have debug.com somewhere on your disk, right? Try this:

debug.com edgar.txt
-e 100
 48 65 6c 6c 6f 2c 20 45  64 67 61 72 21 0a
ebx 10e
w
q
type edgar.txt

If that doesn't work, it's because my 10+ year old memory of debug.com is rusty.

Not here at school. I'm in class. Is it a DOS program?

debug.com only works on 32 bit versions of windows.

It should work (and works here with MinGW and Wine). al_save_config_file calls al_fopen with "w" (not "wb") which is passed through to _wfopen (unless you have overridden it). The C library should then translate \n to CRLF.

But if you save on Linux and try to open on Windows you'll have a problem? Is that what you're saying?

Nope. The file is being created from scratch under Windows.

I did some further testing and it appears that when I force the configuration file to be saved before physfs has been initialized, the file saves correctly and displays normally under Notepad. Could the problem be physfs?

Looks like it. I don't think this problem can be fixed in an efficient manner, so perhaps there should be a stern warning about this in the documentation?

Yuck. So I take it that the only way to circumvent this is to call al_set_standard_file_interface(), then save the file, and then call al_set_physfs_file_interface() again to turn it back on?

The warning should be about files written in Windows sometimes containing extra random 0x13 bytes. That cost me quite a few wasted hours at work, some parser would add the 0x13 byte to every value that happened to come last in a line

I think physfs actually made the most sane choice there and I'd wish Allegro would never write those extra bytes

Assuming it's about the Mingw-gcc port (instead of, say, the Visual Studio one), physfs must be setting one of the flags that alters the behavior of all future fopen() calls.
The following page lists several ways to do it:
http://oldwiki.mingw.org/index.php/binary

Now, if al_save_config_file() would call al_fopen() with an explicit "t" mode, and if al_fopen() relayed it to the underlying libc, I think it would work even if a lib (or user code) plays with these settings.

al_fopen() relays it to PhysFS in this case.