<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Beware of what you get when locking DirectX Resources Buffers</title>
	<atom:link href="http://entland.homelinux.com/blog/2006/01/30/beware-of-what-you-get-when-locking-directx-resources-buffers/feed/" rel="self" type="application/rss+xml" />
	<link>http://entland.homelinux.com/blog/2006/01/30/beware-of-what-you-get-when-locking-directx-resources-buffers/</link>
	<description>Code, 3D, Games, Linux and much more...</description>
	<lastBuildDate>Mon, 09 Nov 2009 03:12:38 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: chanka</title>
		<link>http://entland.homelinux.com/blog/2006/01/30/beware-of-what-you-get-when-locking-directx-resources-buffers/comment-page-1/#comment-23</link>
		<dc:creator>chanka</dc:creator>
		<pubDate>Wed, 01 Feb 2006 06:19:21 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/?p=49#comment-23</guid>
		<description>Yes ninja 8)</description>
		<content:encoded><![CDATA[<p>Yes ninja <img src='http://entland.homelinux.com/blog/wp-includes/images/smilies/icon_cool.gif' alt='8)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ent</title>
		<link>http://entland.homelinux.com/blog/2006/01/30/beware-of-what-you-get-when-locking-directx-resources-buffers/comment-page-1/#comment-22</link>
		<dc:creator>ent</dc:creator>
		<pubDate>Wed, 01 Feb 2006 01:18:45 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/?p=49#comment-22</guid>
		<description>Hmmm, yes. You are right, both fourth and second solution have the same problem. try...catch seems to be the only real solution to this problem. :-\</description>
		<content:encoded><![CDATA[<p>Hmmm, yes. You are right, both fourth and second solution have the same problem. try&#8230;catch seems to be the only real solution to this problem. :-\</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: chanka</title>
		<link>http://entland.homelinux.com/blog/2006/01/30/beware-of-what-you-get-when-locking-directx-resources-buffers/comment-page-1/#comment-21</link>
		<dc:creator>chanka</dc:creator>
		<pubDate>Tue, 31 Jan 2006 14:13:43 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/?p=49#comment-21</guid>
		<description>I mean, if the IsBadWritePtr() return true, and after the call the memory is invalidated.</description>
		<content:encoded><![CDATA[<p>I mean, if the IsBadWritePtr() return true, and after the call the memory is invalidated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ent</title>
		<link>http://entland.homelinux.com/blog/2006/01/30/beware-of-what-you-get-when-locking-directx-resources-buffers/comment-page-1/#comment-20</link>
		<dc:creator>ent</dc:creator>
		<pubDate>Tue, 31 Jan 2006 09:55:12 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/?p=49#comment-20</guid>
		<description>IsBadWritePtr() won&#039;t return you a pointer. It returns a bool indicating if the memory pointer is writable or not.


BOOL IsBadWritePtr(LPVOID lp, UINT_PTR ucb);</description>
		<content:encoded><![CDATA[<p>IsBadWritePtr() won&#8217;t return you a pointer. It returns a bool indicating if the memory pointer is writable or not.</p>
<p>BOOL IsBadWritePtr(LPVOID lp, UINT_PTR ucb);</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: chanka</title>
		<link>http://entland.homelinux.com/blog/2006/01/30/beware-of-what-you-get-when-locking-directx-resources-buffers/comment-page-1/#comment-18</link>
		<dc:creator>chanka</dc:creator>
		<pubDate>Tue, 31 Jan 2006 09:16:25 +0000</pubDate>
		<guid isPermaLink="false">http://entland.homelinux.com/blog/?p=49#comment-18</guid>
		<description>&gt;&gt; Use the IsBadWritePtr function against the pointers returned by the DirectX API and if you get a bad pointer return a pointer to a dummy memory block internally allocated by you. To me, this is the cleanest and safest option. You should return a memory block long enough to hold the size requested by the Lock.


What if the pointer is invalid after the call to IsBadWritePtr?</description>
		<content:encoded><![CDATA[<p>&gt;&gt; Use the IsBadWritePtr function against the pointers returned by the DirectX API and if you get a bad pointer return a pointer to a dummy memory block internally allocated by you. To me, this is the cleanest and safest option. You should return a memory block long enough to hold the size requested by the Lock.</p>
<p>What if the pointer is invalid after the call to IsBadWritePtr?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
