Re: [RESENT]: Fixed winedbg example configuration
"BiGgUn" <fbiggun(a)hotmail.com> writes:
Changelog: Reorder lines for a typical winedbg configuration.
Your patch is wrapped; but anyway I don't see any reason to change that, keys are sorted when registry files are saved so the order doesn't matter. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
"BiGgUn" <fbiggun(a)hotmail.com> writes:
Changelog: Reorder lines for a typical winedbg configuration.
Your patch is wrapped; but anyway I don't see any reason to change that, keys are sorted when registry files are saved so the order doesn't matter.
This needs to change, though - for example, the tool palettes in C++Builder appear in the wrong order because of this. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com
Hi, BiGgUn wrote:
This needs to change, though - for example, the tool palettes in C++Builder appear in the wrong order because of this.
Can you send a patch that fix it ? :)
It's on my list of things to look into, but I don't have time to fix it right now - I just wanted to make the point :-) -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com
Changelog: Fixed winedbg example configuration Index: documentation/debugger.sgml =================================================================== RCS file: /home/wine/wine/documentation/debugger.sgml,v retrieving revision 1.23 diff -u -r1.23 debugger.sgml --- documentation/debugger.sgml 9 Jul 2003 19:50:14 -0000 1.23 +++ documentation/debugger.sgml 15 Jul 2003 15:38:52 -0000 @@ -1009,8 +1009,8 @@ </para> <programlisting> [MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 957636538 -"Auto"=dword:00000001 "Debugger"="winedbg --debugmsg -all %ld %ld" +"Auto"=dword:00000001 </programlisting> <note>
"BiGgUn" == BiGgUn <fbiggun(a)hotmail.com> writes:
BiGgUn> Changelog: Fixed winedbg example configuration BiGgUn> Index: documentation/debugger.sgml BiGgUn> =================================================================== BiGgUn> RCS file: /home/wine/wine/documentation/debugger.sgml,v BiGgUn> retrieving revision 1.23 diff -u -r1.23 debugger.sgml --- BiGgUn> documentation/debugger.sgml 9 Jul 2003 19:50:14 -0000 1.23 +++ BiGgUn> documentation/debugger.sgml 15 Jul 2003 15:38:52 -0000 @@ BiGgUn> -1009,8 +1009,8 @@ </para> <programlisting> BiGgUn> [MACHINE\\Software\\Microsoft\\Windows BiGgUn> NT\\CurrentVersion\\AeDebug] 957636538 -"Auto"=dword:00000001 BiGgUn> "Debugger"="winedbg --debugmsg -all %ld %ld" BiGgUn> +"Auto"=dword:00000001 </programlisting> Your patch seems a NOP (No-Operation) to me. Only the order of items is changed, nothing else. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Jon Bright wrote:
Alexandre Julliard wrote:
"BiGgUn" <fbiggun(a)hotmail.com> writes:
Changelog: Reorder lines for a typical winedbg configuration.
Your patch is wrapped; but anyway I don't see any reason to change that, keys are sorted when registry files are saved so the order doesn't matter.
This needs to change, though - for example, the tool palettes in C++Builder appear in the wrong order because of this. I really don't see how changing the configuration (in a no op way) of the debugger would fix some window related issue elsewhere and if it's the case, it means something is severely broken in some other place => this is not the correct fix A+
-- Eric Pouech
Eric Pouech wrote:
Jon Bright wrote:
Alexandre Julliard wrote:
"BiGgUn" <fbiggun(a)hotmail.com> writes:
Changelog: Reorder lines for a typical winedbg configuration.
Your patch is wrapped; but anyway I don't see any reason to change that, keys are sorted when registry files are saved so the order doesn't matter.
This needs to change, though - for example, the tool palettes in C++Builder appear in the wrong order because of this.
I really don't see how changing the configuration (in a no op way) of the debugger would fix some window related issue elsewhere and if it's the case, it means something is severely broken in some other place => this is not the correct fix A+
These are two separate changes: a) Wine's registry needs to preserve ordering (c++ builder, presumably among others) b) BiGgUn wants to reorder the winedbg lines for some reason. I'm not saying he's right (I don't understand why he wants to reorder things like that), but I am saying that if he is wrong, it's not because this would be reordered anyway. Basically, I'm not supporting his patch, I'm saying Alexandre's reason for rejection is wrong. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com
These are two separate changes:
a) Wine's registry needs to preserve ordering (c++ builder, presumably among others) b) BiGgUn wants to reorder the winedbg lines for some reason. I'm not saying he's right (I don't understand why he wants to reorder things like that), but I am saying that if he is wrong, it's not because this would be reordered anyway. Basically, I'm not supporting his patch, I'm saying Alexandre's reason for rejection is wrong. I still agree with Alexandre here. Order of keys in registry doesn't matter when loading, moreover, next time wine exits, the keys get automatically reordered (and saved), so I don't understand the need of the key reordering.
A+ -- Eric Pouech
I still agree with Alexandre here. Order of keys in registry doesn't matter when loading, moreover, next time wine exits, the keys get automatically reordered (and saved),
How do you explain that keys stay in the same order i typed them ?
BiGgUn wrote:
I still agree with Alexandre here. Order of keys in registry doesn't matter when loading, moreover, next time wine exits, the keys get automatically reordered (and saved),
How do you explain that keys stay in the same order i typed them ?
did you wait for wineserver to terminate before checking they have not changed ? A+ -- Eric Pouech
Eric Pouech wrote:
These are two separate changes:
a) Wine's registry needs to preserve ordering (c++ builder, presumably among others) b) BiGgUn wants to reorder the winedbg lines for some reason. I'm not saying he's right (I don't understand why he wants to reorder things like that), but I am saying that if he is wrong, it's not because this would be reordered anyway. Basically, I'm not supporting his patch, I'm saying Alexandre's reason for rejection is wrong.
I still agree with Alexandre here. Order of keys in registry doesn't matter when loading, moreover, next time wine exits, the keys get automatically reordered (and saved), so I don't understand the need of the key reordering.
A+
It appears that several Windows programs expect the order of the keys to remain the same as the order of creation. One such program is modern Explorer, which reorders menus by rewriting the registry. I believe we will eventually have to support that. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Eric Pouech wrote:
These are two separate changes:
a) Wine's registry needs to preserve ordering (c++ builder, presumably among others) b) BiGgUn wants to reorder the winedbg lines for some reason. I'm not saying he's right (I don't understand why he wants to reorder things like that), but I am saying that if he is wrong, it's not because this would be reordered anyway. Basically, I'm not supporting his patch, I'm saying Alexandre's reason for rejection is wrong.
I still agree with Alexandre here. Order of keys in registry doesn't matter when loading, moreover, next time wine exits, the keys get automatically reordered (and saved), so I don't understand the need of the key reordering.
The point is that the automatic reordering should go away because it's causing at least one bug that I know of. Keys should be read out of the registry in the same order they were written to it. Thus, saying "this is a no-op because keys are reordered" isn't a valid argument against BiGgUn's patch. You could equally say "This patch seems completely pointless, key re-ordering or not", though and I'd be quite happy. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com
On Fri, Jul 18, 2003 at 08:09:58AM +0200, Jon Bright wrote: ...
The point is that the automatic reordering should go away because it's causing at least one bug that I know of. Keys should be read out of the registry in the same order they were written to it. Thus, saying "this is a no-op because keys are reordered" isn't a valid argument against BiGgUn's patch. You could equally say "This patch seems completely pointless, key re-ordering or not", though and I'd be quite happy.
Please give more details on that bug. Ciao, Marcus
Marcus Meissner wrote:
Please give more details on that bug.
I'll go one better. Attached is a test case. In Windows, RegEnumValue returns the keys in the order they were created in. Wine will, of course, reorder them. Shachar mentions newer versions of Explorer depend on Windows behaviour - I don't know about that, but I do know that the Tool palette in Borland C++Builder 5 appears in the wrong order because it depends on the keys not being reordered. The test case runs on WinXP without error. Since apps depend on this behaviour, I'm assuming it's not windows-version dependent. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com //--------------------------------------------------------------------------- #include <windows.h> #include <stdio.h> #pragma hdrstop //--------------------------------------------------------------------------- int fail(char *stage) { printf("FAILED: %s\n",stage); return -1; } #pragma argsused int main(int argc, char* argv[]) { HKEY software, wine, regorder; char name[2]; DWORD i,nsize,type,ri,risize,disp; if (RegCreateKeyEx(HKEY_CURRENT_USER,"Software",0,NULL,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&software,&disp)!=ERROR_SUCCESS) return fail("Create-Software"); if (RegCreateKeyEx(software,"Wine",0,NULL,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&wine,&disp)!=ERROR_SUCCESS) return fail("Create-Wine"); if (RegCreateKeyEx(wine,"TestRegOrder",0,NULL,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,®order,&disp)!=ERROR_SUCCESS) return fail("Create-TestRegOrder"); name[1]='\0'; for (i=26; i; i--) { name[0]='A'+i-1; if (RegSetValueEx(regorder,name,0,REG_DWORD,(BYTE*)&i,sizeof(i))!=ERROR_SUCCESS) return fail("SetValueEx"); } for (i=0; i<26; i++) { nsize = 2; risize = sizeof(ri); if (RegEnumValue(regorder,i,name,&nsize,NULL,&type,(BYTE*)&ri,&risize)!=ERROR_SUCCESS) return fail("EnumValue"); printf("%s = %d\n",name,ri); if (ri!=26-i) return fail("Comparison"); } if (RegCloseKey(regorder)!=ERROR_SUCCESS) return fail("CloseKey"); if (RegDeleteKey(wine,"TestRegOrder")!=ERROR_SUCCESS) return fail("DeleteKey"); return 0; } //---------------------------------------------------------------------------
I wouldn't have believed it, except I saw it with my own eyes. Sure enough, Windows 2000 retains the creation order. I even modified the code to leave the keys over a cold boot, and it still retained the creation order. I had always assumed regedit was displaying items in the order it got from RegEnumValue. Well, today was a good day, I learned something new. Does anyone know if the same is true of key ordering? -- Jeff Smith --- Jon Bright <jon(a)siliconcircus.com> wrote:
Marcus Meissner wrote:
Please give more details on that bug.
I'll go one better. Attached is a test case. In Windows, RegEnumValue returns the keys in the order they were created in. Wine will, of course, reorder them. Shachar mentions newer versions of Explorer depend on Windows behaviour - I don't know about that, but I do know that the Tool palette in Borland C++Builder 5 appears in the wrong order because it depends on the keys not being reordered.
The test case runs on WinXP without error. Since apps depend on this behaviour, I'm assuming it's not windows-version dependent.
-- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Jeff Smith wrote:
Does anyone know if the same is true of key ordering?
No immediate clue, but I'll add some stuff to the test for that. From the comments on MSDN, I'd guess so. I'd also guess that a sequence of create-val "Z", create-val "Y", create-val "X", delete-val "Y", create-val "W" will, in enum, return "Z", "W", "X". But again, I'm guessing. Updated testcase underway. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com
Hi, Attached, a better test. The conclusion: - Values are enumerated in the order they were created, even if a value's been deleted in the meantime. - Key are enumerated alphabetically, irrespective of the order in which they were created. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com //--------------------------------------------------------------------------- #include <windows.h> #include <stdio.h> #pragma hdrstop //--------------------------------------------------------------------------- int fail(char *stage) { printf("FAILED: %s\n",stage); return -1; } #pragma argsused int main(int argc, char* argv[]) { HKEY software, wine, valorder, keyorder, k; char name[2]; DWORD i,nsize,type,ri,risize,disp; FILETIME ft; if (RegCreateKeyEx(HKEY_CURRENT_USER,"Software",0,NULL,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&software,&disp)!=ERROR_SUCCESS) return fail("Create-Software"); if (RegCreateKeyEx(software,"Wine",0,NULL,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&wine,&disp)!=ERROR_SUCCESS) return fail("Create-Wine"); if (RegCreateKeyEx(wine,"TestValOrder",0,NULL,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&valorder,&disp)!=ERROR_SUCCESS) return fail("Create-TestValOrder"); name[1]='\0'; for (i=26; i; i--) { name[0]='A'+i-1; if (RegSetValueEx(valorder,name,0,REG_DWORD,(BYTE*)&i,sizeof(i))!=ERROR_SUCCESS) return fail("SetValueEx"); } for (i=0; i<26; i++) { nsize = 2; risize = sizeof(ri); if (RegEnumValue(valorder,i,name,&nsize,NULL,&type,(BYTE*)&ri,&risize)!=ERROR_SUCCESS) return fail("EnumValue"); printf("%2d. %s = %d\n",i,name,ri); if (ri!=26-i) return fail("Comparison"); } if (RegDeleteValue(valorder,"C")) return fail("DeleteValue"); i = 1000; if (RegSetValueEx(valorder,"1",0,REG_DWORD,(BYTE*)&i,sizeof(i))!=ERROR_SUCCESS) return fail("SetValueEx"); for (i=0; i<26; i++) { nsize = 2; risize = sizeof(ri); if (RegEnumValue(valorder,i,name,&nsize,NULL,&type,(BYTE*)&ri,&risize)!=ERROR_SUCCESS) return fail("EnumValue"); printf("%2d. %s = %d\n",i,name,ri); if ((i<23 && ri!=26-i) || ((i==23 || i==24) && ri!=25-i) || (i==25 && ri!=1000)) return fail("Comparison"); } if (RegCloseKey(valorder)!=ERROR_SUCCESS) return fail("CloseKey"); if (RegDeleteKey(wine,"TestValOrder")!=ERROR_SUCCESS) return fail("DeleteKey-Val"); if (RegCreateKeyEx(wine,"TestKeyOrder",0,NULL,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&keyorder,&disp)!=ERROR_SUCCESS) return fail("Create-TestKeyOrder"); name[1]='\0'; for (i=26; i; i--) { name[0]='A'+i-1; if (RegCreateKeyEx(keyorder,name,0,NULL,REG_OPTION_NON_VOLATILE,KEY_ALL_ACCESS,NULL,&k,&disp)!=ERROR_SUCCESS) return fail("Create-KeyLoop"); if (RegCloseKey(k)!=ERROR_SUCCESS) return fail("Close-KeyLoop"); } for (i=0; i<26; i++) { nsize = 2; if (RegEnumKeyEx(keyorder,i,name,&nsize,NULL,NULL,NULL,&ft)!=ERROR_SUCCESS) return fail("EnumKey"); printf("%2d. %s\n",i,name); if (name[0]!=(char)('A'+i)) return fail("Comparison"); } for (i=0; i<26; i++) { name[0]='A'+i; if (RegDeleteKey(keyorder,name)!=ERROR_SUCCESS) return fail("Delete-KeyLoop"); } if (RegCloseKey(keyorder)!=ERROR_SUCCESS) return fail("Close-KeyOrder"); if (RegDeleteKey(wine,"TestKeyOrder")!=ERROR_SUCCESS) return fail("DeleteKey-Key"); return 0; } //---------------------------------------------------------------------------
participants (8)
-
Alexandre Julliard -
BiGgUn -
Eric Pouech -
Jeff Smith -
Jon Bright -
Marcus Meissner -
Shachar Shemesh -
Uwe Bonnes