General cleanup; Update 'Win32 Automated library download' section slightly;

Cleanup: 
   - relatively minor wording changes
   - spelling 
   - typos
   - minor formatting changes 

svn path=/trunk/; revision=22836

1 files changed, 35 insertions, 35 deletions

diff --git a/docbook/wsdg_src/WSDG_chapter_dissection.xml b/docbook/wsdg_src/WSDG_chapter_dissection.xml
index da7ce25a3d..ae0c502e1f 100644
--- a/docbook/wsdg_src/WSDG_chapter_dissection.xml
+++ b/docbook/wsdg_src/WSDG_chapter_dissection.xml
@@ -7,7 +7,7 @@
   <section id="ChDissectWorks">
 	<title>How it works</title>
 	<para>
-	Each dissector decodes it's part of the protocol, and then hand off
+	Each dissector decodes its part of the protocol, and then hands off
 	decoding to subsequent dissectors for an encapsulated protocol.
 	</para>
 	<para>
@@ -19,7 +19,7 @@
 	</para>
 	<para>
 	Dissection can be implemented in two possible ways. One is to have a dissector
-	module compiled into the main program, which means its always available.
+	module compiled into the main program, which means it's always available.
 	Another way is to make a plugin (a shared library/DLL) that registers itself
 	to handle dissection. - XXX add a special explanation section for this?
 	</para>
@@ -28,7 +28,7 @@
   <section id="ChDissectAdd">
 	<title>Adding a basic dissector</title>
 	<para>
-	Lets step through adding a basic dissector. We'll start with the made up
+	Let's step through adding a basic dissector. We'll start with the made up
 	"foo" protocol. It consists of the following basic items.
 	</para>
 	<itemizedlist>
@@ -49,12 +49,12 @@
 	<title>Setting up the dissector</title>
 	   <para>
 	   	The first decision you need to make is if this dissector will be a 
-	   	built in dissector, included in the main program, or a plugin.
+	   	built-in dissector, included in the main program, or a plugin.
 	   </para>
 	   <para>
 	   	Plugins are the easiest to write initially as they don't need
-	   	write permission on the main code base. So lets start with that.
-	   	With a little care, the plugin can be made to run as a built in
+	   	write permission on the main code base. So let's start with that.
+	   	With a little care, the plugin can be made to run as a built-in
 	   	easily too - so we haven't lost anything.
 	   </para>
 	   <example><title>Dissector Initialisation.</title>
@@ -89,7 +89,7 @@ proto_register_foo(void)
 }]]>
    </programlisting></example>
 	<para>
-	Lets go through this a bit at a time. First we have some boiler plate
+	Let's go through this a bit at a time. First we have some boiler plate
 	include files. These will be pretty constant to start with. Here we also
 	pre-declare some functions that we'll be writing shortly.
 	</para>
@@ -97,7 +97,7 @@ proto_register_foo(void)
 	Next we have an int that is initialised to -1 that records our protocol.
 	This will get updated when we register this dissector with the main program.
 	We can use this as a handy way to detect if we've been initialised yet.
-	Its good practice to make all variables and functions that aren't exported
+	It's good practice to make all variables and functions that aren't exported
 	static to keep name space pollution down. Normally this isn't a problem unless your
 	dissector gets so big it has to span multiple files.
 	</para>
@@ -109,14 +109,14 @@ proto_register_foo(void)
 	</para>
 	<para>
 	Now we have the basics in place to interact with the main program, we had
-	better fill in those missing functions. Lets start with register function.
+	better fill in those missing functions. Let's start with register function.
 	</para>
 	<para>
 	First a call to proto_register_protocol that registers the protocol. 
-	We can give it three names that	will be used in various places to display it.
-	The full and short name are used in the eg. the "Preferences" and "Enabled protocols" 
+	We can give it three names that	will be used for display in various places.
+	The full and short name are used in e.g. the "Preferences" and "Enabled protocols" 
 	dialogs as well as the generated field name list in the documentation.
-	The abbreviation is used as display filter name. 
+	The abbreviation is used as the display filter name. 
 	</para>
 	<para>
 	Next we need a handoff routine.
@@ -173,9 +173,9 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 	For now we'll do the minimum we can get away with. 
 	The first two lines check to see if the Protocol column is being displayed in
 	the UI. If it is, we set the text of this to our protocol, so everyone
-	can see its been recognised.
+	can see it's been recognised.
 	The only other thing we do is to clear out any data in the INFO column
-	if its being displayed. 
+	if it's being displayed. 
 	</para>
 	<para>
 	At this point we should have a basic dissector ready to compile and install.
@@ -218,7 +218,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 	<section id="ChDissectDetails">
 	<title>Dissecting the details of the protocol</title>
 	   <para>
-	   Now we have our basic dissector up and running, lets do something with it.
+	   Now that we have our basic dissector up and running, let's do something with it.
 	   The simplest thing to do to start with is to just label the payload.
 	   This will allow us to set up some of the parts we will need.
 	   </para>
@@ -230,7 +230,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 	   called to look into details of the packet. These two cases can be
 	   distinguished by the tree pointer. If the tree pointer is NULL, then
 	   we are being asked for a summary. If it is non null, we can pick apart
-	   the protocol for display. So with that in mind, lets enhance our dissector.
+	   the protocol for display. So with that in mind, let's enhance our dissector.
 	   </para>
 	   <example><title>Plugin Packet Dissection.</title>
    <programlisting>
@@ -258,7 +258,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 	</para>
 	<para>
 	We are also marking the area of data that is being consumed by this
-	protocol. In our cases its all that has been passed to us, as we're assuming
+	protocol. In our case it's all that has been passed to us, as we're assuming
 	this protocol does not encapsulate another.
 	Therefore, we add the new tree node with proto_tree_add_item, adding
 	it to the passed in tree, label it with the protocol, use the passed in
@@ -270,7 +270,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 	and selecting this will highlight the remaining contents of the packet.
 	</para>
 	<para>
-	Now lets go to the next step and add some protocol dissection.
+	Now let's go to the next step and add some protocol dissection.
 	For this step we'll need to construct a couple of tables that help with dissection.
 	This needs some changes to proto_register_foo. First a couple of statically
 	declare arrays.
@@ -339,8 +339,8 @@ static gint ett_foo = -1;
 	A call to proto_tree_add_item in the foo_tree, this time using the 
 	hf_foo_pdu_type to control the formatting of the item. The pdu type
 	is one byte of data, starting at 0. We assume it is in network order,
-	so that is why we use FALSE. Although for 1 byte there is no order issues
-	its best to keep right.
+	so that is why we use FALSE. Although for 1 byte there is no order issue
+	it's best to keep this correct.
 	</para>
 	<para>
 	If we look in detail at the hf_foo_pdu_type declaration in the static array
@@ -374,7 +374,7 @@ static gint ett_foo = -1;
 	useful. 
 	</para>
 	<para>
-	Now lets finish off dissecting the simple protocol. We need to add a few
+	Now let's finish off dissecting the simple protocol. We need to add a few
 	more variables to the hf array, and a couple more procedure calls.
 	</para>
 	   <example><title>Wrapping up the packet dissection.</title>
@@ -419,8 +419,8 @@ static int hf_foo_initialip = -1;
    </section>
    <section><title>Improving the dissection information</title>
    <para>
-   We can certainly improve the display of the proto with a bit of extra data.
-   The first step is to add some text labels. Lets start by labelling the packet types.
+   We can certainly improve the display of the protocol with a bit of extra data.
+   The first step is to add some text labels. Let's start by labeling the packet types.
    There is some useful support for this sort of thing by adding a couple of extra things.
    First we add a simple table of type to name.
    </para>
@@ -434,10 +434,10 @@ static int hf_foo_initialip = -1;
 };]]>	
    </programlisting></example>
    <para>
-   This is a handy data structure that can be used to look up value to names.
+   This is a handy data structure that can be used to look up a name for a value.
    There are routines to directly access this lookup table, but we don't need to
    do that, as the support code already has that added in. We just have to give 
-   these details to the appropriate part of data, using the VALS macro.
+   these details to the appropriate part of the data, using the VALS macro.
    </para>
 	   <example><title>Adding Names to the protocol.</title>
    <programlisting>
@@ -499,7 +499,7 @@ static int hf_foo_priorityflag = -1;
    things we can do to make things look even more pretty. At the moment our dissection
    shows the packets as "Foo Protocol" which whilst correct is a little uninformative.
    We can enhance this by adding a little more detail.
-   First, lets get hold of the actual value of the protocol type. We can use the handy
+   First, let's get hold of the actual value of the protocol type. We can use the handy
    function tvb_get_guint8 to do this.
    With this value in hand, there are a couple of things we can do.
    First we can set the INFO column of the non-detailed view to show what sort of 
@@ -538,9 +538,9 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
    </programlisting></example>
    <para>
    So here, after grabbing the value of the first 8 bits, we use it with one of the
-   built in utility routines val_to_str, to lookup the value. If the value isn't 
+   built-in utility routines val_to_str, to lookup the value. If the value isn't 
    found we provide a fallback which just prints the value in hex. 
-   We use this twice, once in the INFO field of the columns - if its displayed, and
+   We use this twice, once in the INFO field of the columns - if it's displayed, and
    similarly we append this data to the base of our dissecting tree.
    </para>
 
@@ -556,7 +556,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 	dissector. 
 	</para>
 	<para> 
-	As encryption can be tricky, lets consider the case of compression.
+	As encryption can be tricky, let's consider the case of compression.
 	These techniques can also work for other transformations of data,
 	where some step is required before the data can be examined.
 	</para>
@@ -596,7 +596,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
    	The first steps here are to recognise the compression. In this case
    	a flag byte alerts us to the fact the remainder of the packet is compressed.
    	Next we retrieve the original size of the packet, which in this case
-   	is conveniently within the protocol. If its not, it may be part of the 
+   	is conveniently within the protocol. If it's not, it may be part of the 
    	compression routine to work it out for you, in which case the logic would
    	be different.
    	</para>
@@ -614,13 +614,13 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
    	in the next call to tvb_set_child_real_data_tvbuff. 
    	Finally we add this data as a new data source, so that
    	the detailed display can show the decompressed bytes as well as the original.
-   	One procedural step is to add a handler to free the data when its no longer needed.
+   	One procedural step is to add a handler to free the data when it's no longer needed.
    	In this case as g_malloc was used to allocate the memory, g_free is the appropriate
    	function.
    	</para>
 	<para> 
 	After this has been set up the remainder of the dissector can dissect the
-	buffer next_tvb, as its a new buffer the offset needs to be 0 as we start
+	buffer next_tvb, as it's a new buffer the offset needs to be 0 as we start
 	again from the beginning of this buffer. To make the rest of the dissector
 	work regardless of whether compression was involved or not, in the case that
 	compression was not signaled, we use the tvb_new_subset to deliver us
@@ -642,7 +642,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 	  <section id="ChDissectReassembleUdp">
 		<title>How to reassemble split UDP packets</title>
 		<para>
-		As an example, lets examine a protocol that is layered on
+		As an example, let's examine a protocol that is layered on
 		top of UDP that splits up its own data stream.
 		If a packet is bigger than some given size, it will be split into
 		chunks, and somehow signaled within its protocol.
@@ -995,7 +995,7 @@ struct FooTap {
    </programlisting></example>
 	<para>
 	Whilst you can program a tap without protocol specific data, it
-	is generally not very useful. Therefore its a good idea
+	is generally not very useful. Therefore it's a good idea
 	to declare a structure that can be passed through the tap.
 	This needs to be a static structure as it will be used after the
 	dissection routine has returned. Its generally best to pick out some
@@ -1006,7 +1006,7 @@ struct FooTap {
 	to the tap.
 	</para>
 	<para>
-	Once you have these defined, its simply a case of populating the
+	Once you have these defined, it's simply a case of populating the
 	protocol specific structure and then calling tap_queue_packet probably
 	as the last part of the dissector.
 	</para>