tags:

views:

21

answers:

2

After intensive searching why certain workstations wouldn't perform a certain action when just being started up in the morning (...) I've discovered that GetPrivateProfileInt just returns the default value and doesn't bother to set GetLastError to something non-zero when the network-subsystem hasn't activated yet (e.g. because the DHCP client is still trying to get hold of an IP address to use.)

Does this sound familiar to someone? Does anybody happen to know what I should/could do about it?

For now I'll correct by using an alternate default value, and stalling a bit while I get my default value.

+1  A: 

I would check if the file exists and sleep for a few seconds until the file is there. After some number of tries either use the default value or take an appropriate action.

Hugh Brackett
+1  A: 

GetPrivateProfileInt() is one of those innocent looking Windows API functions that has a ton of code behind it. There's a mass of appcompat code, designed to allow Win3 programs to run on modern versions of Windows. One of the side-effects is that it is incredibly slow, it took about 50 msec the last time I profiled it.

Looks like you found a flaw in it. For all I know, it might actually be designed appcompat behavior. Emulating the way this API worked 18 years ago. I have no clue of course if that's accurate.

The very best thing you can do is stop using it. A possible workaround is to open the file first so that your program blocks until the service is up and running.

Hans Passant
I agree completely, I too found out that it's one of the slowest methods to retrieve settings; you may switch to boost::Program_options, or, if you just use one section of the INI file, you may use GetPrivateProfileSection to retrieve all the data and parse it in memory (once I wrote a class that incapsulates all this mess and provides generic method to read/write any type easily (http://code.google.com/p/irfanpaint/source/browse/trunk/irfanpaint/INISection.h)).
Matteo Italia
By the way, it's so slow also because it has to reparse the whole file at each call.
Matteo Italia
@matteo: I don't think so. Parsing text is cheap, microseconds, not milliseconds. It also matters little how large the ini file is or where in the file the param is located. The file data should also come out of the file system cache. But *that* doesn't seem to happen, it appears to hit the disk again to open the file. Weird.
Hans Passant