Re: wine menus
Damjan Jovanovic [EMAIL PROTECTED] writes: With FindFirstChangeNotification() and FindNextChangeNotification() you don't even have to poll, and those are implemented on wineserver using inotify, so it's very efficient. Except it doesn't work on many platforms, so it can't be the standard mechanism. -- Alexandre Julliard [EMAIL PROTECTED]
Re: RegOpenKeyExW() Question
Tom Spear wrote: At the risk of looking like an idiot, I'll take a stab at this.. If you RegCloseKey on env, and it is not initialized, then RegCloseKey will generate ERROR_INVALID_HANDLE, so I personally think that something like the first approach would be the better one to go with. env should only be initialized (according to what I have seen) if RegOpenKeyExW returns ERROR_SUCCESS. But I haven't seen every case, so there may be something that causes it to be initialized when the return is not ERROR_SUCCESS. Thanks, Tom. I think I might submit a patch to fix the violation that Coverity flags, which is prior to the RegOpenKeyW() call, and just insert a FIXME: comment where the return value of RegOpenKeyW() is tested, without changing the existing functionality. -- Andy.
Re: msi: Fix use of uninitialized variable (Coverity)
Andrew Talbot wrote: This patch should fix Coverity bug CID-562. Additionally, I have pinpointed another suspected use-before-initialization bug, for future consideration. -- Andy. --- Changelog: msi: Fix use of uninitialized variable (Coverity). Wouldn't it be easier to set env to NULL when declaring it and do a: if (env) RegCloseKey(env); Cheers, Paul.
Re: msi: Fix use of uninitialized variable (Coverity)
Paul Vriens wrote: Wouldn't it be easier to set env to NULL when declaring it and do a: if (env) RegCloseKey(env); Cheers, Paul. Indeed it would! I shall submit a vastly simplified retry, accordingly. :) -- Thanks, Andy.
Re: Making the wiki FAQ live
On 6/21/07, Ben Hodgetts (Enverex) [EMAIL PROTECTED] wrote: I've done some heavy modifications and additions to the Wiki FAQ and it's now the YOU MUST READ THIS NOW! document pointed to by the #winehq IRC channel so I agree. It's also impossible to edit the old FAQ easily anyway. Some users have been confused though finding two FAQs on the site, so the quicker the old one can be taken down the better. Ben H. In the interest of not breaking existing links, can the static FAQ be replaced with a redirect to the wiki version?
Re: Wine on SkyOS
On Fri, 2007-06-22 at 22:56 -0400, Tom Wickline wrote: Hello All, Looks as if SkyOS will soon support Wine! But I don't think it supports the graphical aspects of wine, just command line and the infrastructure, if I recall correctly. Internals - Many kernel updates like LDT support (required by Wine), updated signal handling, pthread support, and overall additional POSIX compatibility enhancements. http://www.skyos.org/?q=node/605 Tom signature.asc Description: This is a digitally signed message part
Re: Bugzilla mails and people replying to [EMAIL PROTECTED]
On 6/22/07, Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: Lørdag 23 juni 2007 01:13, skrev Tom Spear: Just curious how trivial it would be to add a note to the bugzilla mail template saying to post replies to comments in the bug? Something like the following: A bug you are watching, Bug #(bug number), has a new comment. To reply to this comment, click (bug link). Then the rest of the email as it currently appears. I'm asking because I have received several replies to the list recently, and once wine reaches 1.0, I'm sure many more people will join the list and do the same. I don't want comments to be lost due to them not being posted in the proper place, as everyone's input on a bug is important. That seems like a very good idea. For the AppDB we also use a reply bot since a lot of poeple don't seem to notice such information. Or how about adding some magic to the ML where any reply to wine-bugs gets added as a comment to the bug report? Web programming isn't my specialty, so I don't know if this if feasible or possible, but it seems like the best solution to the problem (we also have a message to attach logs and not paste, but most people don't read or follow that advice). -- James Hawkins
Re: msi: Fix use of uninitialized variable (Coverity) (Try 2)
On 6/23/07, Andrew Talbot [EMAIL PROTECTED] wrote:
This patch should fix Coverity bug CID-562.
-- Andy.
---
Changelog:
msi: Fix use of uninitialized variable (Coverity).
diff -urN a/dlls/msi/action.c b/dlls/msi/action.c
--- a/dlls/msi/action.c 2007-06-18 17:52:27.0 +0100
+++ b/dlls/msi/action.c 2007-06-23 17:08:55.0 +0100
@@ -4648,7 +4648,7 @@
LPWSTR deformatted, ptr;
DWORD flags, type, size;
LONG res;
-HKEY env, root = HKEY_CURRENT_USER;
+HKEY env = NULL, root = HKEY_CURRENT_USER;
static const WCHAR environment[] =
{'S','y','s','t','e','m','\\',
@@ -4759,7 +4759,7 @@
res = RegSetValueExW(env, name, 0, type, (LPVOID)newval, size);
done:
-RegCloseKey(env);
+if (env) RegCloseKey(env);
msi_free(deformatted);
msi_free(data);
msi_free(newval);
Please don't check env for NULL; RegCloseKey will just fail harmlessly
if env is NULL. We spent a lot of time removing such checks.
--
James Hawkins
Re: msi: Fix use of uninitialized variable (Coverity) (Try 2)
James Hawkins wrote: Please don't check env for NULL; RegCloseKey will just fail harmlessly if env is NULL. We spent a lot of time removing such checks. OK, I shall re-post my first effort as Try 3. -- Andy.
Re: Wine on SkyOS
On 6/23/07, Adam Petaccia [EMAIL PROTECTED] wrote: If there are any SkyOS developers lurking about, I know some people that developed a SkyOS to win32 wrapper that allowed you to run some simple SkyGI apps on Windows. It might be a good place to start if you want to take a look at what primitives are needed to do the reverse to implement a wine driver. Contact me off list and I will see if I can dig it up. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: wine menus
On 6/23/07, Alexandre Julliard [EMAIL PROTECTED] wrote: Damjan Jovanovic [EMAIL PROTECTED] writes: With FindFirstChangeNotification() and FindNextChangeNotification() you don't even have to poll, and those are implemented on wineserver using inotify, so it's very efficient. Except it doesn't work on many platforms, so it can't be the standard mechanism. Could we detect if it fails and then have a fallback case where it sync's the lnk's to xdg-menus on explorer shutdown? -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Bugzilla mails and people replying to [EMAIL PROTECTED]
On 6/23/07, James Hawkins [EMAIL PROTECTED] wrote: Or how about adding some magic to the ML where any reply to wine-bugs gets added as a comment to the bug report? Web programming isn't my specialty, so I don't know if this if feasible or possible, but it seems like the best solution to the problem That would be great (we also have a message to attach logs and not paste, but most people don't read or follow that advice). I think the problem with that is that it isn't in bold, it kind of blends in with the page. I know that it had been there a while before I finally noticed it, although I had been attaching logs prior to that message being put there. I think that a notice in the email at the very top right before the link would be noticable enough to where people would see it in 90% of the cases when they would have hit reply otherwise. Another solution I thought of would be to just set wine-bugs@ to either bounce messages back to the sender with undeliverable address, or redirect it to /dev/null, although neither of those would be as helpful as James' or my own ideas. Last solution, although I personally don't like it would be to have reply-to set to wine-devel@ -- Thanks Tom
Re: msi: Fix use of uninitialized variable (Coverity) (Try 2)
On 6/23/07, James Hawkins [EMAIL PROTECTED] wrote:
On 6/23/07, Andrew Talbot [EMAIL PROTECTED] wrote:
This patch should fix Coverity bug CID-562.
-- Andy.
---
Changelog:
msi: Fix use of uninitialized variable (Coverity).
diff -urN a/dlls/msi/action.c b/dlls/msi/action.c
--- a/dlls/msi/action.c 2007-06-18 17:52:27.0 +0100
+++ b/dlls/msi/action.c 2007-06-23 17:08:55.0 +0100
@@ -4648,7 +4648,7 @@
LPWSTR deformatted, ptr;
DWORD flags, type, size;
LONG res;
-HKEY env, root = HKEY_CURRENT_USER;
+HKEY env = NULL, root = HKEY_CURRENT_USER;
static const WCHAR environment[] =
{'S','y','s','t','e','m','\\',
@@ -4759,7 +4759,7 @@
res = RegSetValueExW(env, name, 0, type, (LPVOID)newval, size);
done:
-RegCloseKey(env);
+if (env) RegCloseKey(env);
msi_free(deformatted);
msi_free(data);
msi_free(newval);
Please don't check env for NULL; RegCloseKey will just fail harmlessly
if env is NULL. We spent a lot of time removing such checks.
Perhaps a conformance test is in order, because from what I have read,
RegCloseKey returns a nonzero error code on any error, including a
NULL variable being passed to it, which screws up obtaining the
original error if x program or api tries to use GetLastError. We
don't want bugs in wine, unless it is duplicating a windows bug, and
what I see if we don't check the way Andrew has, is a bug that I am
pretty sure does not exist in windows.
RegCloseKey documentation (our RegCloseKey function matches this):
http://msdn2.microsoft.com/en-us/library/ms724837.aspx
--
Thanks
Tom
