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).
A good fix in profile.c is difficult because of the unfortunate use of the empty string as sentinel in the implementation. Probably rewriting the module would be a better idea.
In short again: empty string section is just another (valid) section under Windows. Depending on the windows version the section is represented in the saved file after []\r\n at the beginning of the INI file or with no header at all.
The empty key can be requested and saved in a named section. The empty key in a named section is just another (valid) key under Windows. The empty key value is represented in the saved file after the header of the appropriate section in this way, just as logic would suggest:
[header] =value
Those "empty string" sections and "empty string" keys should be found when querying using the profile API. Currently it does not happen, leading to INI corruption (multiple repeated empty sections' values, none of which are found by the API).
Regards,
Claudio Fontana
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 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. Could you rewrite the test case so it succeeds on all platforms?
So, for example creating the ini file with the empty section/key 'manually' and then trying to read (again on several platforms).
On Thu, Aug 6, 2009 at 9:38 AM, Paul Vrienspaul.vriens.wine@gmail.com 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)?
CF
Claudio Fontana wrote:
On Thu, Aug 6, 2009 at 9:38 AM, Paul Vrienspaul.vriens.wine@gmail.com 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
On Thu, Aug 6, 2009 at 11:47 AM, Paul Vrienspaul.vriens.wine@gmail.com wrote:
Claudio Fontana wrote:
On Thu, Aug 6, 2009 at 9:38 AM, Paul Vrienspaul.vriens.wine@gmail.com 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.
Claudio Fontana wrote:
On Thu, Aug 6, 2009 at 11:47 AM, Paul Vrienspaul.vriens.wine@gmail.com wrote:
Claudio Fontana wrote:
On Thu, Aug 6, 2009 at 9:38 AM, Paul Vrienspaul.vriens.wine@gmail.com 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 don't have the time to pursue this in great depth. The test crash means I get a drwtsn32 when running the tests.
I've installed the application successfully under Windows XP but your tests crash. This either means the app is not writing the ini-files with the help of WritePrivateProfileStringA or it has a crash handler.
Interestingly enough doing the same tests with WritePrivateProfileStringW don't crash!?
Paul Vriens wrote:
Claudio Fontana wrote:
On Thu, Aug 6, 2009 at 11:47 AM, Paul Vrienspaul.vriens.wine@gmail.com wrote:
Claudio Fontana wrote:
On Thu, Aug 6, 2009 at 9:38 AM, Paul Vrienspaul.vriens.wine@gmail.com 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 don't have the time to pursue this in great depth. The test crash means I get a drwtsn32 when running the tests.
That is unfortunate. Not knowing what exactly happens means I am blind and therefore less likely to be able to fix it.
I've installed the application successfully under Windows XP
You say you have installed the application successfully under Windows XP. By application you mean "The Spirit Engine"? The problem does not happen on installation, but on running. To be precise, the second run is most problematic.
On the first run the application writes the new INIs with WritePrivateProfileString. They look ok.
On the second run the application tries to read the values again, and here the wine implementation fails. The values are not found, and instead the INIs are corrupted, ie the values are appended again.
but your tests crash.
This is I think the focal point, and the reason nobody cared. The problem is, something in the test crashes under Windows > 98. Not having access to such a system makes it hard for me to debug.
This either means the app is not writing the ini-files with the help of WritePrivateProfileStringA or it has a crash handler.
I cannot say about the "crash handler" part.
You can find the trace of the application in the bug report, showing that indeed it is WritePrivateProfileStringW that is called (not A).
It seems that this windows API is even fishier as I thought before. IE, the W version of the API does not really unconditionally behave in the UTF-16 way. So I might have assumed wrongly, and a replace of
WritePrivateProfileStringA with WritePrivateProfileStringW is at least needed in the test, but probably the rest of the code should be checked/changed in order to match the odd windows behaviour.
http://www.google.com/search?q=WritePrivateProfileStringW
shows an interesting result:
http://www.ureader.com/msg/147342.aspx
It seems that the function behaves in the Unicode way if the file is already unicode, and in the A way otherwise. This is indeed documented in
http://msdn.microsoft.com/en-us/library/ms725501%28VS.85%29.aspx
I never noticed, and I think this is currently not handled in wine.
See http://bugs2.winehq.org/attachment.cgi?id=5806 for the trace of the application calls to WritePrivateProfileStringW.
Interestingly enough doing the same tests with WritePrivateProfileStringW don't crash!?
The tests ran successfully under Windows > 98? IE by replacing A with W we get the correct behaviour? We might be on to something.
CF
I tried to work on the patch again, but it does not apply anymore. I am slowly going through what happened in profile.c, to find out which changes should be kept, and which go in a wrong direction.
I stumbled already @the first entry:
commit 9a10234ef2b5212ba44b82a797c478f190b4dad1 Author: Paul Vriens Paul.Vriens.Wine@gmail.com Date: Thu Apr 2 12:16:11 2009 +0200
The change is good and bad at the same time, in that the change depends on the windows version AFAIR. This change takes the []\r\n away for empty sections, but some windows versions do put those characters there.
See http://bugs2.winehq.org/attachment.cgi?id=6182 for a file generated under Windows XP, showing the []\r\n at the beginning for the empty string section.
There seems to be a situation where this gets changed back and forth depending on who is committing the change (and thus probably depending on which windows version is tested).
If someone is interested in fixing this confusion and has access to different windows versions, the whole history of
git log -p dlls/kernel32/profile.c
would be a good starting point, together with the experimental results of XP and 98 which respectively do and do not put the '[]\r\n' there.
-
Claudio Fontana -
Paul Vriens