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

Re: #3 - shell32/systray.c

by Steven Edwards

Hello Mike, --- Mike Hearn <mike(a)theoretic.com> wrote: > I have a pretty big patch against the system tray code, and it's > going > to get bigger. Cool. > Hopefully in the next few days I will get time to properly reverse > engineer (if it's not already documented) the interaction between > shell32 and explorer, so we can implement this using a separate > wineshell executable. > > Is there anything you need from us for ReactOS? If the message > protocol > is documented I guess you guys can just implement server support in > your > explorer for it, am I right? I am not 100% sure but I think your patch will be enough. We already have some systray support in our Explorer when running on Windows. Take a look at running explorer under WINE and see if it will help any. Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 2, 2004

Re: #3 - shell32/systray.c

by Mike Hearn

Hi Steven, I have a pretty big patch against the system tray code, and it's going to get bigger. Hopefully in the next few days I will get time to properly reverse engineer (if it's not already documented) the interaction between shell32 and explorer, so we can implement this using a separate wineshell executable. Is there anything you need from us for ReactOS? If the message protocol is documented I guess you guys can just implement server support in your explorer for it, am I right? thanks -mike On Fri, 2004-01-02 at 15:37, Steven Edwards wrote: > When playing around with a app that uses the systray under ReactOS I > noticed that the comment in Wine is out of date. > > Changelog: > Update the notes in shell32 on how WINE uses the Systray under KDE. > > > > __________________________________ > Do you Yahoo!? > Find out what made the Top Yahoo! Searches of 2003 > http://search.yahoo.com/top2003

Jan. 2, 2004

Re: lParam of WM_CREATE for MDI children

by Steven Edwards

Hello Dmitry, --- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > No offence intended, but I don't see anything useful in the diff: No offence taken. I didnt know if there would be anything useful in there or not. We have been doing a bit of work on MDI because Martin's explorer clone depends on it so I thought we might have already fixed some of the bugs. Quite a few of our developers also use MDI text editors though I dont understand why..... > 1. lots of useless #ifdef __REACTOS__/#endif I agree. We need to better split the Win16/32 stuff in some of the sources we are adopting and abstract some of the code better so Wine and ReactOS can share it without needing these. I will send a patch for this today. > 2. MDICLIENTINFO is allocated twice: in WM_NCCREATE and WM_CREATE. Yes this is a problem too. > 3. again, as everywhere in the ReactOS I see complete misuse of > ansi/unicode > macros vs. real win32 API names. You guys really want to disable use > of macros > based on the UNICODE preprocessor define, like it's done in Wine. > Otherwise > you will get *a lot* of mess and headache in the long run. > > For instance > > SetWindowLongPtr(hwnd, 0, (LONG_PTR) ci); > > what version A or W of SetWindowLongPtr is intended to be used in > this > particular case and in this particular place of the code? Your right. We have the same problem in the controls and I think this causes a good bit of problems for us. Well sorry for the noise, Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 2, 2004

Re: Printing bugfixes

by Mike Hearn

On Fri, 2004-01-02 at 12:35, Huw D M Davies wrote: > Actually I don't see why we need a different name and devname we > should just use devname for both entries instead. I think it's a > hangover from some old code OK. I'll resend just using devname. > Your patch however looks wrong, you're adding a default printer with > port LPR:LPT1, the spooler will try to print with the command > lpr -PLPT1 which won't work. You really want to set the port to LPT1: You mean in this line? WINSPOOL_SetDefaultPrinter("LPT1","Wine PostScript Driver", FALSE); I don't really understand, sorry. You mean it should be like this? WINSPOOL_SetDefaultPrinter("LPT1:","Wine PostScript Driver", FALSE); Or that this line: sprintf(buf,"%s,WINEPS,LPR:%s",name,devname); should be sprintf(buf,"%s,WINEPS,%s",devname,devname); thanks -mike

Jan. 2, 2004

Re: Printing bugfixes

by Huw D M Davies

On Thu, Jan 01, 2004 at 08:23:20PM +0000, Mike Hearn wrote: > ChangeLog: > - Write out default printer name in the order used by WinME > - Support PRINTER_ENUM_DEFAULT > - Add FIXME for enumerating print providers > > I'd appreciate somebody with a CUPs and lpr setup ensuring the order > change doesn't cause regressions. It appears correct to me, but as the > code worked before even though it looked like it shouldn't I might be > wrong. Actually I don't see why we need a different name and devname we should just use devname for both entries instead. I think it's a hangover from some old code Your patch however looks wrong, you're adding a default printer with port LPR:LPT1, the spooler will try to print with the command lpr -PLPT1 which won't work. You really want to set the port to LPT1: Huw.

Jan. 2, 2004

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. 1, 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. 1, 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

Re: Missing exports?

by Lionel Ulmer

> I guess it's a matter of long term vs short term thinking, but in that > case why do we build MSHTML when we have no implementation for it, and > probably won't for some time? Well, creating the stubs is often the easiest part of working on a DLL.. So if nobody wants to work on a DLL, what would it gain us to have the stubs (as the people who are competent to work on it will also know how to create the stubs themselves). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 1, 2004

Re: Congradulations - windef.h

by Ivan Leo Murray-Smith

>You cannot use KDevelop 2.1 release with wine. Too many files to deep. >It will crash trying to import that project. (After 10 minuets of a >progress bar) Sucessfully imported, configured, currently building in KDevelop 2.1 shipped with Mandrake Linux 9.2 Ivan.

Jan. 1, 2004

Docs

by Ivan Leo Murray-Smith

Hi list, I've noticed this  in getting.sgml, I've recently changed a few things in it, but there isn't a cvs.sgml file, should this warning go? Ivan.

Jan. 1, 2004

Re: Congradulations - windef.h

by Dimitrie O. Paun

On January 1, 2004 07:42 am, Boaz Harrosh wrote: > In short __declspec( selectany ) && __declspec( thread ) These are supported just fine by winegcc, what's wrong with it? AFACT, it's supported exactly the same way as in your patch... -- Dimi.

Jan. 1, 2004

Re: Renaming registry keys...

by Dimitrie O. Paun

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... -- Dimi.

Jan. 1, 2004

Re: New registry key adding patch

by Dimitrie O. Paun

On January 1, 2004 08:16 am, Zimler Attila wrote: > I don't understand this. Probably because I don't understand how we > translate the "key name" string, to the localized version, and because > this I have no idea how big memory should we allocate. 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). > cvs diff -u is ok? (This is how I did it at this time) Yes, this is perfect. > Hope everything is ok (except localization) at this time. It looks like it. Please send it to wine-patches for inclusion in the tree. -- Dimi.

Jan. 1, 2004

Re: event.c freezes on XFilterEvent

by Joshua Walker

<snip> > I often hit shift+space by accident > (while typing in English) and > brings the application to a halt. <snip> In my .xinitrc... ------------------ export LANG="ja_JP.UTF-8" export XMODIFIERS="@im=kinput2" xmodmap -e 'keycode 115 = Kanji' kinput2 -xim -kinput -canna & ---------------------------- The xmodmap command will map the kanji key to the Windows key, then you have to dump the shift-space combo edit this file... /usr/X11R6/lib/X11/app-defaults/Kinput2 and comment out the following lines with bangs... ------------------------- *ConversionStartKeys: \ Shift<Key>space \n\ Ctrl<Key>Kanji -------------------------- That would solve your shift-space problem.

Jan. 1, 2004

Re: Congradulations - windef.h

by Boaz Harrosh

Mike Hearn wrote: >On Wed, 2003-12-31 at 17:26, Dimitrie O. Paun wrote: > > >>Are you using KDevelop to work on Wine? Is it OK? I'm a vim guy >>myself, and I've never used KDevelop, but I could maybe use some >>autocompletion :) >> >> > >If vim has something like emacs tag completion then you could use that - >I know etags works pretty well for me. I'm not saying you should use >emacs obviously, but I expect there is an equivalent or vimscript you >can use. > >Briefly, you can do "make etags" in the wine source root, wait a bit, >then two very useful features are available: > >M-. (find-tag) lets you locate any definition in the wine source tree >complete-tag lets you perform completion based upon those same tags. > >I typically just use dabbrev-expand though which searches files you have >open in the background for expansions. > > > Personally I use KDevelop for the debugger. Nothing like it save across the border at windows MSVC++. Well I guess I like the other stuff too. I'm originally a Macintosh person so anything GUI for me. KDevelop will let you feel more at home if you come from windows. You cannot use KDevelop 2.1 release with wine. Too many files to deep. It will crash trying to import that project. (After 10 minuets of a progress bar) here you have been warned. KDevelop 3 beta does not do any of that. It Just runs the makefile no Q asked. 3 seconds done. But be careful do not use the official beta release (or RPMs or DEBs) use only the latest snapshot. You'll have to compile it from source. and thanks for the "make etags" KDevelop likes that too ...

Jan. 1, 2004

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

by Joshua Walker

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? On second thought, this is more of a functionallity question. Here's more on documentation... I wanted to say this after I finished documenting the API of a DLL, but it's more releivent here. Many people program open source for many reasons. I simply want to learn the Win32 API. I have no idea why, I guess I'm just cerious about how it works. As I am sitting here placing comments into code I am reminded of a short story in "The Hitchhiker's Guide to the Galaxy" In the story there was an alien who had immortility accidently placed upon him by way of a particle accelorator, a rubber band, and I think some tea... But I'm not too sure about that bit. Anyway he had a grand old time simply outliving the hell out of everyone. After a while he became biter an jaded, he needed something to do to bide his time and so he decided to insult the universe. The worst bit, and the part that he fought so hard to maintain, is that he decided to do it *Alphabectally* I feel much like this guy, I'm starting in advapi32.dll and methotcally working my way through it. At first I wanted to do an end-to-end API documentaion, but I'm hampered by things that arn't implmented yet. That's fine, I'll just do an end-to-end Wine API documentation instead. I do not have the skills to fill in code myself. I don't even have a test suite (Read:windows computer) to check myself against anyway. I have found that when I document the APIs, that the subs tend to stand out between the hyperlinks. It almost feels like they are saying "Look at me! Not only do I not fuction, but I can't get a lousy hyperlink either!" And so I think I have found another motivtion to do Open Source programming. Guilt. Yes, I am now panning to guilt people into impmentation. All those entries look soooo pretty it it wasn't for those ugly, black stubs in there. I would like to have the entire API in there, stubbed out, to simply enhance the guilt. But I shall just "do what's there" I just dispuse going through what I've written when I have an eppifiny of some sort. I have to do it again anyway as I need to link up some advapi32 calls to some ntdll calls. I just learnd that one was a front end to another... Anyway, I guess this is a rounds about way of saying this, but I'll just do what's there, and hopefully guilt others into implemtation ^_^ -Joshua P.S. If I find someone who has implemented something after I've gon through the DLL, only to find they didn't bother to make a simple documentation header for it.... Well, then I'd just be really sore....

Jan. 1, 2004

Re: Renaming registry keys...

by Mike Hearn

On Thu, 2004-01-01 at 13:38, 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. Oh, I see.... I was intending to simply not support that :) What you want is a deep tree copy function. You can then do renaming by copying the contents of a key to a new key, and deleting the old one. Here's one I just knocked up. Total pain in the ass isn't it! Hopefully when we get a standard config system on Linux it will be a bit better designed.... /* Copy the values and subkeys of the registry key source to dest recursively. * Returns NO_ERROR if the copy completed OK, otherwise it propagates the error. */ LONG copytree(HKEY source, HKEY dest) { int i = 0; LONG res; /* first of all, copy the values */ while (1) { char valname[MAX_VALUE_NAME]; DWORD valname_size = sizeof(valname); DWORD size; DWORD typecode; char *value; /* determine size of the buffer we'll need */ res = RegEnumValue(source, i, valname, &valname_size, NULL, &typecode, NULL, &size); if (res == ERROR_NO_MORE_ITEMS) break; if (res != NO_ERROR) return res; value = HeapAlloc(GetProcessHeap(), 0, size); if (!value) return ERROR_OUTOFMEMORY; valname_size = sizeof(valname); /* RegEnumValue blasts this even though it doesn't need to */ res = RegEnumValue(source, i, valname, &valname_size, NULL, &typecode, value, &size); if (res != NO_ERROR) return res; res = RegSetValueEx(dest, valname, 0, typecode, value, size); if (res != NO_ERROR) return res; HeapFree(GetProcessHeap(), 0, value); i++; } /* for each subkey, create an equivalent under dest then recurse into ourselves to complete the copy */ i = 0; while (1) { HKEY subkey_src, subkey_dest; char name[MAX_KEY_LENGTH]; DWORD size = sizeof(name); FILETIME time; res = RegEnumKeyEx(source, i, name, &size, NULL, NULL, NULL, &time); if (res == ERROR_NO_MORE_ITEMS) break; if (res != NO_ERROR) return res; /* create the destination subkey */ res = RegCreateKey(dest, name, &subkey_dest); if (res != NO_ERROR) return res; /* open the source subkey */ res = RegOpenKey(source, name, &subkey_src); if (res != NO_ERROR) return res; /* perform the recursive copy */ res = copytree(subkey_src, subkey_dest); if (res != NO_ERROR) return res; i++; } return NO_ERROR; } Hope that helps! thanks -mike

Jan. 1, 2004