December 2003 - Wine-Devel - list.winehq.org

Happy 2004

by Ivan Leo Murray-Smith

Happy New Year from the Central European Time Zone! Ivan.

Dec. 31, 2003

Re: Simple arguments check

by Dimitrie O. Paun

On December 31, 2003 03:29 pm, Mike Hearn wrote: > > Maybe because crashing is the right thing to do in many cases, > > Why? I'd have thought failing the API call would be more sensible, or Because it's bad policy: it's better to fail early and as close as possible to the error point, rather then let the program limp along. In general, MS made a bad policy call by trying to help badly written apps to crawl along. This results in the long term in a lot of hard to track bugs, slower/bloated code, etc. Remember that the road to hell is paved with good intentions... -- Dimi.

Dec. 31, 2003

Re: Simple arguments check

by Mike Hearn

n Wed, 2003-12-31 at 17:36, Dimitrie O. Paun wrote: > Maybe because crashing is the right thing to do in many cases, Why? I'd have thought failing the API call would be more sensible, or doing what GTK does and printing assertion failures. But hey. Crashing is what Win32 does, so it's what we do. I know the answer really :) > but it > looks like MS really likes defensive programming and does all sort of > checks it shouldn't do (and catching all sort of exceptions it shouldn't > catch). Some APIs even correct mistakes you make for you!

Dec. 31, 2003

Re: Renaming registry keys...

by Dimitrie O. Paun

On December 31, 2003 08:00 am, Robert van Herk wrote: > I need such a thing for winecfg, but Win32 doesn't seem to have a > RegKeyRename api-call... Why do you need the rename a key in winecfg? -- Dimi.

Dec. 31, 2003

Re: MCI #4: Add support for many MCIWNDM_ messages and some MCI_ commands

by Dimitrie O. Paun

On December 30, 2003 12:06 pm, Dmitry Timoshkov wrote: > Moreover, I've created an explicit list of unimplemented messages/ > commands in the switch statement, so it should be fairly easy to > figure out what should be done. Well, I've looked at it (the switch statement in MCIWndProc() from dlls/msvideo/mciwnd.c) to compose the list myself, but to be honest it's not obvious to me at all what are the outstanding MC_ cmds and MCIWNDM_ messages... Any hints would be much appreciated. BTW: what would you reckon is the completion status for this beast? (so that I can update the status) -- Dimi.

Dec. 31, 2003

Re: New registry key adding patch

by Zimler Attila

Dimitrie O. Paun wrote: >On December 31, 2003 11:18 am, Zimler Attila wrote: > >Cool, here are a few comments on the patch: > > > >>+ /* Modified by Attila ZIMLER <hijaszu(a)hlfslinux.hu> on 28th of dec 2003. >>+ - New key adding is now supported. >>+ */ >> >> > >Please don't add such stuff in the headers, this goes automatically in >the CVS log, where it belongs. Otherwise we risk cluttering up the files. > > > >>+ /* try to find out a name for the newly create key */ >>+ /* TODO: warning is issued because asprintf's implicit declaration, >>+ I tried to declare it as >>+ extern "C" ssize_t asprintf(char**, const char**, ...) >>+ which is the format of this function, but it seems not helping. >>+ Don't know why :( >>+ */ >>+ asprintf(&keyName, "new key"); >> >> > >Please don't use GNU extensions like asprintf. We can with a >local variable: > TCHAR keyName[32]; > > > >>+ lRet = RegOpenKey(hKey, keyName, &retKey); >>+ while (lRet == ERROR_SUCCESS) { >>+ asprintf(&keyName, "new key %u", ++keyNum); >>+ lRet = RegOpenKey(hKey, keyName, &retKey); >>+ } >> >> > >I'd add a counter to the loop, and exit after, say, 100 tries. > > > >>+ case ID_EDIT_NEW_KEY: >>+ if (CreateKey(hKey)) >>+ RefreshListView(g_pChildWnd->hListWnd, hKeyRoot, keyPath); >>+ break; >> >> > >As I said, no need to refresh the ListView here. Maybe you should just >create a dummy RefreshTreeView() function that just prints a warning >for now. > > > ok, I will replace the code marked bad :) but I will send code only in next year ;) Attila

Dec. 31, 2003

Re: New registry key adding patch

by Dimitrie O. Paun

On December 31, 2003 11:18 am, Zimler Attila wrote: Cool, here are a few comments on the patch: > + /* Modified by Attila ZIMLER <hijaszu(a)hlfslinux.hu> on 28th of dec 2003. > + - New key adding is now supported. > + */ Please don't add such stuff in the headers, this goes automatically in the CVS log, where it belongs. Otherwise we risk cluttering up the files. > + /* try to find out a name for the newly create key */ > + /* TODO: warning is issued because asprintf's implicit declaration, > + I tried to declare it as > + extern "C" ssize_t asprintf(char**, const char**, ...) > + which is the format of this function, but it seems not helping. > + Don't know why :( > + */ > + asprintf(&keyName, "new key"); Please don't use GNU extensions like asprintf. We can with a local variable: TCHAR keyName[32]; > + lRet = RegOpenKey(hKey, keyName, &retKey); > + while (lRet == ERROR_SUCCESS) { > + asprintf(&keyName, "new key %u", ++keyNum); > + lRet = RegOpenKey(hKey, keyName, &retKey); > + } I'd add a counter to the loop, and exit after, say, 100 tries. > + case ID_EDIT_NEW_KEY: > + if (CreateKey(hKey)) > + RefreshListView(g_pChildWnd->hListWnd, hKeyRoot, keyPath); > + break; As I said, no need to refresh the ListView here. Maybe you should just create a dummy RefreshTreeView() function that just prints a warning for now. -- Dimi.

Dec. 31, 2003

Re: Congradulations - windef.h

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On December 31, 2003 04:38 am, Boaz Harrosh wrote: >> they were/are protected, but I think it should be removed from winegcc >> because they don't do the Job. > > Maybe, I'm not sure. I'll let Alexandre comment on the ms-extensions.h > idea. In general, he does not like non-standard headers... No, I don't. Boaz, could you please explain a bit more why the definitions in winegcc don't work for you? -- Alexandre Julliard julliard(a)winehq.com

Dec. 31, 2003

Re: unknwn.h: unknwn.idl

by Ove Kaaven

ons, 31.12.2003 kl. 15.55 skrev Boaz Harrosh: > 2) In order for ATL to compile I need below code in my unknwn.h file. I > could not fined a way to do it with WIDL. > I have looked in Microsoft (vc6) header/idl and it looks they had the > same problem. And below code was added by hand. If Microsoft couldn't solve it in their IDL compiler, I don't think widl could either, since it's meant to have MIDL-compatible syntax. If MIDL syntax can't do it, then widl isn't designed to handle it any better. I guess it might still be possible to design some widl extension to do it, but that won't be straightforward, and perhaps not a good idea either (having Wine's IDL files remain MIDL-compatible could be seen as a good thing). If you must add a method this way, the only idea I have is to let this "make idl" thing patch the output of widl. Like, the Wine tree could contain a .diff file that adds your template thing, and after running widl, the makefile applies that patch to the generated .h file.

Dec. 31, 2003

Re: Simple arguments check

by Dimitrie O. Paun

On December 31, 2003 12:14 pm, Mike Hearn wrote: > I guess the reason we need to crash when windows does is for apps that > trap the fault and rely on it? Or is it just about being as correct as > possible? Maybe because crashing is the right thing to do in many cases, but it looks like MS really likes defensive programming and does all sort of checks it shouldn't do (and catching all sort of exceptions it shouldn't catch). However, this is no reason to the wrong thing and go down the path of defensive programming where even MS didn't go. In other words, many of these checks should be done only where MS does them (since obviously apps will depend on them). -- Dimi.

Dec. 31, 2003