Did INI files work in a different way on Windows 3.x than today?

Question

I am dealing with an application that still uses INI files for configuration. I wanted to make a temporary change to an INI file, but the result was not what I expected.

Let's say the original INI file is

[mysection]
mykey=myvalue

and I wanted to make a revertable change for testing purposes. From my (maybe incomplete or wrong) memories, I recalled that a lot of programs used batch files to modify INI files like so:

echo [mysection]>>test.ini
echo mykey=anothervalue>>test.ini

resulting in an INI file like

[mysection]
mykey=myvalue
[mysection]
mykey=anothervalue

The "revertable" part of this would be that I could simply delete the last 2 lines.

I don't recall any utilities which would have taken care about duplicate sections or keys. Obviously, "echoing" the section is needed to make sure that the section exists in case it did not exist before.

For the last 30 years or so, I believed that the last entry of an INI file wins, exactly for the reason to support these "echoing" changes.

Now, as I said, this change did not work out for the application I am using today. My first thought was that they used an incompatible INI file parser. So I conducted the following test myself, just relying on the Windows API:

// C#
static void Main()
{
    var sb = new StringBuilder(500);
    GetPrivateProfileString(
        "mysection", "mykey","", sb, (uint)sb.Capacity, "e:\\test.ini");
    if (sb.ToString() != "anothervalue")
        throw new ApplicationException("Not what I expected");
}

Guess what: the result is not what I expected.

Could someone confirm (or disprove) that I was wrong for 30 years? Did Windows 3.x and Windows 95 consider the first section and first key of INI files only?

(I am only interested in the "official" way of reading INI files using the Windows API GetPrivateProfileString())

Answer 1

You have been wrong for 30 years.

I wrote the test program below and compiled it with Borland Pascal 7:

uses WinTypes, WinProcs, WinCrt;

var
  buffer: string;
  len: Integer;
begin
  len := GetPrivateProfileString(
    'mysection', 'mykey', '', @buffer[1], 255, 'C:\TEST.INI');
  buffer[0] := Chr(len);
  WriteLn(buffer);
end.

Then I ran it with the INI file from the question saved to C:\TEST.INI. It output myvalue both in Windows 3.10:

and in Windows 95:

Whatever INI-modifying utilities you were speaking of were simply not doing their job right. Sorry, old software was made of duct tape, smoke and mirrors, just like today. Where did you think we inherited this from?

Answer 2

Note that this - embedding multiple apparently-valid entries in a configuration file - is an awful approach to troubleshooting for a whole bunch of reasons, hence the need for INI files to allow comments or, as Microsoft themselves put it,

"You can include comments in initialization files. You must begin each line of a comment with a semicolon (;)."

I took this quote from the embedded documentation already present in WfW 3.11:

 64128  11-01-1993 03:11   WIN311/SYSINI.WRI
 22272  11-01-1993 03:11   WIN311/WININI.WRI
 76400  11-11-1993 03:11   WIN311/SYSTEM/KRNL386.EXE