January 2004 - Wine-Devel - list.winehq.org

Re: Congradulations - windef.h

by Alexandre Julliard

Boaz Harrosh <boaz(a)hishome.net> writes: > Conclusion: winegcc should stick to command-line switches and > translations of options. like include directories, extra libs and so > on. All code related and defines should go to an header file. If you > don't like the ms-extensions.h name than it can be winegcc.h. It's not the name, it's the fact that we add a header that doesn't exist on Windows. You still haven't answered the real question: why wouldn't it work to have them in winegcc? -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2004

Re: unknwn.h: unknwn.idl

by Alexandre Julliard

Boaz Harrosh <boaz(a)hishome.net> writes: > Exactly! > > Alexandre please permit me to remove unknwn.idl from idl list in > include/Makefile.in. And send a patch for unknwn.h. Of course not. Just add the needed code with cpp_quote in the .idl, adding #if 0 to disable the generated code. Check how Microsoft does it in the SDK headers. -- Alexandre Julliard julliard(a)winehq.com

Jan. 2, 2004

Re: Missing exports?

by Tom

Alexandre Julliard wrote: > No. As already explained a number of times, adding stubs for new > functions is just asking for trouble, since apps will now try to call > the functions and die. Stubs should only be added if there's an app > that requires them. Same thing with dlls, unless there is a reason to > have a stub dll it's much better to not have one at all so that the > native one gets used. > Okay, It has finally sunk into my hard head.. I won't ask again :-) Tom

Jan. 1, 2004

Re: New registry key adding patch

by Zimler Attila

Dimitrie O. Paun wrote: >You use LoadString() to load the string (look at how we load >error strings in edit.c even though there it's simple since >the buffer is fixed size for now). > > Am I loaded correctly the string? Could you verify it for me? If yes, I will send the patch for including in the CVS tree. If yes, could you tell me also, which is the next task, I could do? Attila Index: programs/regedit/En.rc =================================================================== RCS file: /home/wine/wine/programs/regedit/En.rc,v retrieving revision 1.3 diff -u -u -r1.3 En.rc --- programs/regedit/En.rc 3 Dec 2003 20:25:24 -0000 1.3 +++ programs/regedit/En.rc 1 Jan 2004 18:27:02 -0000 @@ -201,6 +201,7 @@ IDS_BAD_VALUE "Can't query value '%s'" IDS_UNSUPPORTED_TYPE "Can't edit keys of this type (%ld)" IDS_TOO_BIG_VALUE "Value is too big (%ld)" + IDS_NEWKEY "new key" END /*****************************************************************/ Index: programs/regedit/edit.c =================================================================== RCS file: /home/wine/wine/programs/regedit/edit.c,v retrieving revision 1.3 diff -u -u -r1.3 edit.c --- programs/regedit/edit.c 12 Dec 2003 04:08:59 -0000 1.3 +++ programs/regedit/edit.c 1 Jan 2004 18:27:02 -0000 @@ -91,6 +91,40 @@ return FALSE; } +BOOL CreateKey(HKEY hKey) +{ + LONG lRet; + HKEY retKey; + TCHAR keyName[32]; + static TCHAR newKey[28] = ""; /* should be max keyName len - 4 */ + HINSTANCE hInstance; + unsigned int keyNum = 1; + + /* If we have illegal parameter return with operation failure */ + if (!hKey) return FALSE; + + /* Load localized "new key" string. -4 is because we need max 4 character + to numbering. */ + if (newKey[0] == 0) { + hInstance = GetModuleHandle(0); + if (!LoadString(hInstance, IDS_NEWKEY, newKey, COUNT_OF(newKey))) + lstrcpy(newKey, "new key"); + } + lstrcpy(keyName, newKey); + + /* try to find out a name for the newly create key. + We try it max 100 times. */ + lRet = RegOpenKey(hKey, keyName, &retKey); + while (lRet == ERROR_SUCCESS && keyNum < 100) { + sprintf(keyName, "%s %u", newKey, ++keyNum); + lRet = RegOpenKey(hKey, keyName, &retKey); + } + if (lRet == ERROR_SUCCESS) return FALSE; + + lRet = RegCreateKey(hKey, keyName, &retKey); + return lRet == ERROR_SUCCESS; +} + BOOL ModifyValue(HWND hwnd, HKEY hKey, LPCTSTR valueName) { DWORD valueDataLen; Index: programs/regedit/framewnd.c =================================================================== RCS file: /home/wine/wine/programs/regedit/framewnd.c,v retrieving revision 1.5 diff -u -u -r1.5 framewnd.c --- programs/regedit/framewnd.c 12 Dec 2003 04:08:59 -0000 1.5 +++ programs/regedit/framewnd.c 1 Jan 2004 18:27:02 -0000 @@ -469,6 +469,9 @@ case ID_EDIT_COPYKEYNAME: CopyKeyName(hWnd, _T("")); break; + case ID_EDIT_NEW_KEY: + CreateKey(hKey); + break; case ID_REGISTRY_PRINTERSETUP: /*PRINTDLG pd;*/ /*PrintDlg(&pd);*/ Index: programs/regedit/main.h =================================================================== RCS file: /home/wine/wine/programs/regedit/main.h,v retrieving revision 1.8 diff -u -u -r1.8 main.h --- programs/regedit/main.h 12 Dec 2003 04:08:59 -0000 1.8 +++ programs/regedit/main.h 1 Jan 2004 18:27:02 -0000 @@ -93,6 +93,7 @@ extern LPCTSTR GetItemPath(HWND hwndTV, HTREEITEM hItem, HKEY* phRootKey); /* edit.c */ +BOOL CreateKey(HKEY hKey); BOOL ModifyValue(HWND hwnd, HKEY hKey, LPCTSTR valueName); #endif /* __MAIN_H__ */ Index: programs/regedit/resource.h =================================================================== RCS file: /home/wine/wine/programs/regedit/resource.h,v retrieving revision 1.2 diff -u -u -r1.2 resource.h --- programs/regedit/resource.h 3 Dec 2003 20:25:24 -0000 1.2 +++ programs/regedit/resource.h 1 Jan 2004 18:27:02 -0000 @@ -106,6 +106,7 @@ #define IDS_BAD_VALUE 32837 #define IDS_UNSUPPORTED_TYPE 32838 #define IDS_TOO_BIG_VALUE 32839 +#define IDS_NEWKEY 32840 #define IDD_EDIT_STRING 2000 #define IDC_VALUE_NAME 2001

Jan. 1, 2004

Re: DMUSIC: my latest work

by Dimitrie O. Paun

On January 1, 2004 04:25 am, Rok Mandeljc wrote: > Hey everyone, > > I finally found some time to organise my dmusic work of last two months > in useful patch. Dmusic is now DX9 compatible, we have almost fully > implemented (but not working :( ) > IDirectMusicCollection/IDirectMusicInstrument, fully implemented > IDirectMusicContainer and almost completely (but fully working I believe > IDirectMusicLoader)... Nice! What would you say is the status of DMusic (70-80-90% complete?) > => oh and if somebody is interested in test programs I wrote & used and > some docs on dark sides of dmusic (written by myself ;)), mail me and > you'll get them in 24 hours ;) Shouldn't we get this into the tree somewhere? (either as comments in the code, or as documentation in the Devel Guide). Ditto for test program (not sure where it should go though...) > => and happy New Year everyone! Happy New Year to you too! -- Dimi.

Jan. 1, 2004

Re: New registry key adding patch

by Dimitrie O. Paun

On January 1, 2004 02:35 pm, Zimler Attila wrote: > Am I loaded correctly the string? Could you verify it for me? If yes, I > will send the patch for including in the CVS tree. It seems so, yes. However, I'd change the "new key" string to "New Key" to match the native one (it's also nicer). > If yes, could you tell me also, which is the next task, I could do? OK, I propose the following tasks (in this order): -- new value -- rename value -- rename key -- Dimi.

Jan. 1, 2004

Re: Renaming registry keys...

by Robert van Herk

Dimitrie O. Paun wrote: >On January 1, 2004 08:38 am, Robert van Herk wrote: > > >>When someone configures app1.exe, and later on decides that he actually >>meant app2.exe, he might want to rename app1.exe to app2.exe, and so >>migrate all the settings. >> >> > >I'd say don't support that. At least for now, it's not that important >a functionality to worry about it... > > Hm, maybe you're right. I will leave it for a moment then, and maybe include it in the future. Thanx though for all the help, guys. Grtz, Robert

Jan. 1, 2004

Debugger Woes

by Robert Shearman

Hi, After the automatic glibc detection changes the Wine debugger stopped loading symbols correctly, making it harder to debug programs. I only recently noticed this due to lack of disk space and not compiling and installing the whole tree on a cvs update. However, I have now spent some time looking at the problem. By applying the following patch to winedbg, I saw that the address for the ELF debugging section was not being found properly. Index: programs/winedbg/stabs.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/stabs.c,v retrieving revision 1.11 diff -u -r1.11 stabs.c --- programs/winedbg/stabs.c 15 Dec 2003 19:53:08 -0000 1.11 +++ programs/winedbg/stabs.c 1 Jan 2004 17:49:02 -0000 @@ -1625,6 +1625,7 @@ do { if (!DEBUG_READ_MEM_VERBOSE((void*)dyn_addr, &dyn, sizeof(dyn))) goto leave; + WINE_TRACE("dyn.d_tag is %d\n", dyn.d_tag); dyn_addr += sizeof(dyn); } while (dyn.d_tag != DT_DEBUG && dyn.d_tag != DT_NULL); if (dyn.d_tag == DT_NULL) goto leave; An example from loading "winedbg --debugmsg +winedbg notepad": trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1448084550 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is -997982209 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1457883477 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1455977869 ... trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 0 I believe these invalid values are being caused because we are mmap'ing "wine" and reading in the values from the .dynamic section, but the ".dynamic" section hasn't been intialized by the ELF loader. This previously wasn't as issue since "wine" would already have been loaded. However, now "wine" exec's "wine-kthread" or "wine-pthead" as appropriate and then exits and so is no longer in memory. This appears to have been anticipated with the check further up in the stabs.c file that examines the "WINELOADER" environment variable to find the file to mmap. If this is set to "wine-pthread", for example, then the problem goes away. Hence the attached patch. Perhaps the real fix should be made to programs/winedbg/stabs.c. We could either not use the ".dynamic" section somehow or use the dlsym rather than mmap so that we properly initialize the ".dynamic" section. Rob P.S. above trace with patch applied: trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 1 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 12 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 13 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 4 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 5 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 6 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 10 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 11 trace:winedbg:DEBUG_ReadExecutableDbgInfo dyn.d_tag is 21

Jan. 1, 2004

Re: Just adding an entry in the.spec file makes somethin build?

by Dimitrie O. Paun

On January 1, 2004 10:16 am, Joshua Walker wrote: > Are .spec files automahicly built? Adding an entry to > the .spec file does what exactly? From my standpoint > all it does is add an entry to the documentation thats > generated by c2man.pl, but it's undocumentabale, not > linked to anything, and just sits there. I'm assuming > you *MUST* have a function, or a declration, or > something the jive with the .spec file? Yes, essentially you need a function in the .c file to match the entry in the .spec file. From your point of view (doing documentation), I wouldn't worry about .spec files for now. -- Dimi.

Jan. 1, 2004

Re: Docs

by Dimitrie O. Paun

On January 1, 2004 12:20 pm, Ivan Leo Murray-Smith wrote: > in getting.sgml, I've recently changed a few things in it, but there isn't > a cvs.sgml file, should this warning go? Yes, it should, cvs.sgml is no longer. But there may be things on WineHQ that may need updating instead. -- Dimi.

Jan. 1, 2004