Re: profile.c (kernel32): API broken

[Claudio Fontana]

On Thu, Aug 6, 2009 at 11:47 AM, Paul Vriens wrote:
> Claudio Fontana wrote:
> > On Thu, Aug 6, 2009 at 9:38 AM, Paul Vriens
> > wrote:
> > > Claudio Fontana wrote:
> > > > Just a reminder to everyone involved with profile.c:
> > > >
> > > > I have watched the git log of the somewhat recent changes to
> > > > kernel32/profile.c.
> > > >
> > > > The profile API does not work that way.
> > > >
> > > > The current situation is even worse than before, when the undocumented
> > > > empty string section and empty keys were not implemented at all.
> > > > The current situation leads to consistent INI file corruption when the
> > > > applications use the undocumented empty string section and empty keys.
> > > >
> > > > I tried to explain how the API works under Windows many times. This is
> > > > another casual attempt at giving you a reality check.
> > > > If you are interested, you can contact me for further details, or look
> > > > at the testcases in my last patch (search for profile.c / Claudio
> > > > Fontana).
> > >
> > > Found your patch from 2006 and tested on some Windows boxes.
> >
> > The testcases are more interesting than the functionality of the patch
> > itself.
> > I did the patch just to bring an application into running, it is not a
> > stable solution.
> >
> > The testcases are the interesting thing.
> > > The WritePrivateProfileStringA crashes on Windows 2003 for both added
> > > tests.
> > > Windows 98 doesn't crash btw.
> > >
> > > Both your fixes to the implementation seem to be for reading the ini
> > > file.
> >
> > The writing is affected too.
> > > Could you rewrite the test case so it succeeds on all platforms?
> >
> > I will try as soon as I get some time. However, I have no Windows 2003
> > to test on.
> > > So, for example creating the ini file with the empty section/key
> > > 'manually'
> > > and then trying to read (again on several platforms).
> >
> > Does Windows 2003 crash on _just_ the testcase? Or did you apply the
> > whole patch?
> > Also, the patch might not be compatible with the latest changes in
> > profile.c.
> >
> > I'll try to make the patch a little bit better, but in the meantime it
> > would be interesting
> > to know if Windows 2003 behaves differently in this situation from the
> > API point of view.
> >
> > Can you try just the testcase on Windows 2003 (with no other changes
> > added besides the new tests)?
>
> I only added the test cases (what else for a Windows box?). Both crash on
> Windows 2003.
>
> I will check later (if time permits) with that newer patch you mentioned:
> http://bugs2.winehq.org/attachment.cgi?id=6495

Should it crash again, could you define 'crash' a little bit better for me?
Maybe running under the windows debugger (windbg) or other debugger
to understand where exactly the crash happens?

I logged again the call pattern of the application with latest wine, along with
the generated INIs which show the corruption.

The attachments (@2009) show the first run, the generated INIs, and then the
second run (where the information is NOT found again as it should) and the
resulting (corrupted) INIs.

Looking for "firstload" in the traces allows to skip the first part
which is unrelated
to the application-specific INI files.

http://bugs.winehq.org/show_bug.cgi?id=8036