Re: [PATCH] rpcrt4: compare networkoptions correctly (Coverity) (adjusted)
2009/11/8 Marcus Meissner meiss...@suse.de:
@@ -84,6 +84,17 @@ static RPC_STATUS RpcAssoc_Alloc(LPCSTR Protseq, LPCSTR
NetworkAddr,
return RPC_S_OK;
}
+static BOOL compare_networkoptions(LPCWSTR opts1, LPCWSTR opts2)
+{
+ if ((opts1 == NULL) (opts2 == NULL))
+ return TRUE;
+ if ((opts1 == NULL) (opts2 != NULL))
+ return FALSE;
+ if ((opts1 != NULL) (opts2 == NULL))
+ return FALSE;
+ return !strcmpW(opts1, opts2);
+}
+
RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr,
LPCSTR Endpoint, LPCWSTR NetworkOptions,
RpcAssoc **assoc_out)
@@ -97,8 +108,8 @@ RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR
NetworkAddr,
if (!strcmp(Protseq, assoc-Protseq)
!strcmp(NetworkAddr, assoc-NetworkAddr)
!strcmp(Endpoint, assoc-Endpoint)
- ((!assoc-NetworkOptions !NetworkOptions) ||
!strcmpW(NetworkOptions, assoc-NetworkOptions)))
- {
+ compare_networkoptions(NetworkOptions, assoc-NetworkOptions)
+ ) {
Looks good functionally, but please don't change the style.
assoc-refs++;
*assoc_out = assoc;
LeaveCriticalSection(assoc_list_cs);
Thanks,
--
Rob Shearman
Re: Another article that makes me want Wine to run in a sandbox
2009/11/8 Dan Kegel d...@kegel.com: I expect that people will do utterly stupid things, there's no two ways around that, it's human nature. That being the case, I think there are still opportunities for providing a safe computing experience without compromising the user's convenience. Case in point: the sandbox used by the Chromium web browser. It provides a modicum of security without getting in the way. I can easily imagine classes of windows apps, say, games, fitting nicely into a sandboxed wine environment. Sure, getting the networking right would be a challenge, but for at least casual games, it ought to be quite doable. The key is to require no user choices -- just do the right thing by default. Then the user's level of education or computer skills don't matter. You'd get good sandboxing running Wine apps as another user. Main problem then is integration with the user's desktop. Doable, but a nuisance. - d.
The user32/win test crashes X on Intel cards
I hit this issue while trying to run winetest for WineConf. I looked into it and the crash is caused by this line in dlls/user32/tests/win.c: SetWindowPos(hwnd, 0, 32768, 4, 32768, 4, SWP_NOMOVE); More precisely it's the setting of the window width and height to 32768 x 4 that causes the crash. Looking at the .xsession-errors file I see the window manager reporting the following X server error: Anomalie dans le gestionnaire de fenêtres : Unexpected X error: BadAlloc (insufficient resources for operation) serial 11940 error_code 11 request_code 53 minor_code 0) Is it possible that this is just an out of memory issue caused by the huge window size? According to my tests 32000x32000 (a tad 3GB) works but 32767x32767 (a tad 3GB) cause the crash. Here's my configuration: * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 * VideoRAM: 256MB (according to /var/log/Xorg.0.log) * xserver-xorg-video-intel 2:2.9.0-1 Latest from Debian Testing. Debian Unstable does not seem to have a more recent driver. Marcus got the same issue and he had an Intel card too and we were the only two with this issue. So apparently this is Intel-specific. Does any one have an Intel card where this does not happen? What's your driver version? -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Lotto: A tax on people who are bad at math. -- unknown Windows: Microsoft's tax on computer illiterates. -- WE7U
Re: Another article that makes me want Wine to run in a sandbox
2009/11/8 David Gerard dger...@gmail.com: You'd get good sandboxing running Wine apps as another user. Main problem then is integration with the user's desktop. Doable, but a nuisance. Not really. A separate Wine user wouldn't prevent people from running Wine as root incorrectly, and if you integrate it with the normal user's home directory, it's no longer sandboxed (or at least, no more than separated wineprefixes). I believe the type of sandboxing being discussed includes things like preventing Win32 apps from breaking out into native calls using the infamous interrupt trick. Correct me if I'm wrong though :)
Re: d3d9: quiet a few very noisy fixme's
On Sun, Nov 8, 2009 at 6:14 AM, Louis Lenders xerox_xerox2...@yahoo.co.uk wrote: These are spawned at huge rate in World in Conflict demo (http://bugs.winehq.org/show_bug.cgi?id=4) It'd be quicker/cleaner to just change them to warn's instead, IMHO. -- -Austin
Re: d3d9: quiet a few very noisy fixme's
Am 08.11.2009 um 13:28 schrieb Austin English: On Sun, Nov 8, 2009 at 6:14 AM, Louis Lenders xerox_xerox2...@yahoo.co.uk wrote: These are spawned at huge rate in World in Conflict demo (http://bugs.winehq.org/show_bug.cgi?id=4) It'd be quicker/cleaner to just change them to warn's instead, IMHO. I think BeginEvent / EndEvent can be changed to TRACE's. They're tools for Microsoft's debugger and profile apps - so the main purpose of them is to help debugging. The shader validator one should probably be a one-time FIXME
Re: The user32/win test crashes X on Intel cards
On Sun, 8 Nov 2009, Francois Gouget wrote: [...] Here's my configuration: * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 * VideoRAM: 256MB (according to /var/log/Xorg.0.log) * xserver-xorg-video-intel 2:2.9.0-1 Latest from Debian Testing. Debian Unstable does not seem to have a more recent driver. More data: * Marcus is running version 2.9.1 of the Intel driver (and gets the crash). * Michael Stefaniuc does not have the problem. He is using FC11's 2.8.0 version of the driver. * I tried Michael's FC11 intel_drv.so file on my system and I still get a crash. I also tried the 2.8.1 Ubuntu driver and got the same result. So the problem comes from some other part of Xorg or the kernel. * Michael is running the 2.6.32 kernel and I'm running the 2.6.30 one. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Lotto: A tax on people who are bad at math. -- unknown Windows: Microsoft's tax on computer illiterates. -- WE7U
Re: Another article that makes me want Wine to run in a sandbox
On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein shackl...@gmail.com wrote: I believe the type of sandboxing being discussed includes things like preventing Win32 apps from breaking out into native calls using the infamous interrupt trick. Correct me if I'm wrong though :) No, I was thinking of native sandboxing, so even if they did manage to make native calls, they couldn't do any harm. Running as another uid is a fine example of a native sandboxing technique. (So, on a single user system, you could have a uid dedicated to running sandboxed apps, and it would be unable to affect the regular user's data.) This would only be useful for apps that don't need to load or save user data (probably), for example, for casual games.
What to do when un-nominating bugs for 1.2
In the gcc world, when a bug is targeted for release X and doesn't make it in time, it is retargeted for release X+1. So when 1.0 rolled around, I retargeted the leftover 1.0-targeted bugs at 1.2. Can we do the same this time, and retarget 1.2 bugs for 1.4 if they're not going to be fixed for 1.2? The only time one should simply remove the 1.2 target is if we decide the bug really isn't even a candidate for 1.4 (or was nominated for 1.2 in error).
Re: Another article that makes me want Wine to run in a sandbox
2009/11/8 Dan Kegel d...@kegel.com: On Sun, Nov 8, 2009 at 3:25 AM, Ben Klein shackl...@gmail.com wrote: I believe the type of sandboxing being discussed includes things like preventing Win32 apps from breaking out into native calls using the infamous interrupt trick. Correct me if I'm wrong though :) No, I was thinking of native sandboxing, so even if they did manage to make native calls, they couldn't do any harm. Running as another uid is a fine example of a native sandboxing technique. (So, on a single user system, you could have a uid dedicated to running sandboxed apps, and it would be unable to affect the regular user's data.) This would only be useful for apps that don't need to load or save user data (probably), for example, for casual games. Yes, Unix comes with pretty good sandboxing built-in in the form of separate user names. Then one could explicity open communication channels between the Unix environment and the Wine user, rather than trying to close off open-everything. Fairly obviously, it'll take some pretty substantial real-world need for this to get anywhere near the winehq tree! But it's an interesting idea. Imagine, successfully securiing Win32 ... - d.
Re: What to do when un-nominating bugs for 1.2
Hey Dan, Dan Kegel wrote: In the gcc world, when a bug is targeted for release X and doesn't make it in time, it is retargeted for release X+1. So when 1.0 rolled around, I retargeted the leftover 1.0-targeted bugs at 1.2. Can we do the same this time, and retarget 1.2 bugs for 1.4 if they're not going to be fixed for 1.2? Alexandre expressed a preference that the bugs not be auto rolled to 1.4; he'd rather we deliberately chose bugs to go into 1.4. So when we un-nominated, we were intentionally returning bugs to the larger pool. If that proves to have been a mistake (which it may yet), please blame me; I made Austin make each change. We were trying an experiment - a bug council to review the bugs. I'm not sure if it was successful; the bugs have a great richness of information that is hard to digest and then discuss thoughtfully in a relatively small (2 hours) period of time. Cheers, Jeremy
Re: What to do when un-nominating bugs for 1.2
On Sun, Nov 8, 2009 at 8:46 AM, Jeremy White jwh...@codeweavers.com wrote: Alexandre expressed a preference that the bugs not be auto rolled to 1.4; he'd rather we deliberately chose bugs to go into 1.4. So when we un-nominated, we were intentionally returning bugs to the larger pool. OK. We were trying an experiment - a bug council to review the bugs. I'm not sure if it was successful; the bugs have a great richness of information that is hard to digest and then discuss thoughtfully in a relatively small (2 hours) period of time. Judging from the bugzilla activity, it looked pretty successful. - Dan
Re: Another article that makes me want Wine to run in a sandbox
On Sun, Nov 8, 2009 at 03:55, Dan Kegel d...@kegel.com wrote: On Sat, Nov 7, 2009 at 3:40 PM, James McKenzie jjmckenzi...@earthlink.net wrote: You really underestimate the stupidity of people. I expect that people will do utterly stupid things, there's no two ways around that, it's human nature. That being the case, I think there are still opportunities for providing a safe computing experience without compromising the user's convenience. Convincing packagers to recommend (not sure if anything but clam supports this...) / have clamav as a dependency might help (Although it would probably help if Wine uses libclamav to scan all files before running/load even if the clamav daemon is not running and libclam is present...) (No idea what infrastructure that would require, but it sould need a way to turn it of, etc... Also not sure if that is something Wine is supposed to do...) Gert
Re: What to do when un-nominating bugs for 1.2
Dan Kegel wrote: Can we do the same this time, and retarget 1.2 bugs for 1.4 if they're not going to be fixed for 1.2? At least simple explanation for why bugs were un-nominated from 1.2 would have been great. Half of bugs had no explanation whatsoever. Vitaliy.
re: Remove NoAppDBEntry keyword?
Jerome Leclanche wrote: Austin English austinenglish at gmail.com wrote: Anyone opposed to removing that keyword? +1 on removing it. It would be nice to have a bugzilla filter to replace it, too. Are we keeping tasklist and tasklet keywords as well? theres barely a dozen very old bugs for both of them. I think it'd be fine to remove noappdbentry, tasklist, and tasklet. If there are no objections by next weekend, let's go ahead and do it. - Dan
