aboutsummaryrefslogtreecommitdiffstats
path: root/docbook/wsdg_src
diff options
context:
space:
mode:
authorBill Meier <wmeier@newsguy.com>2010-04-16 17:26:47 +0000
committerBill Meier <wmeier@newsguy.com>2010-04-16 17:26:47 +0000
commit7ab0cfa8d6444f1b319ae40036b136ac197e41af (patch)
tree930358f94fe54ff236e56dd066f688fee0fc8529 /docbook/wsdg_src
parente740706aeb919cc7921ec0c7653876cd70e0ddff (diff)
(Trivial changes)
svn path=/trunk/; revision=32496
Diffstat (limited to 'docbook/wsdg_src')
-rw-r--r--docbook/wsdg_src/WSDG_chapter_dissection.xml6
-rw-r--r--docbook/wsdg_src/WSDG_chapter_sources.xml12
2 files changed, 9 insertions, 9 deletions
diff --git a/docbook/wsdg_src/WSDG_chapter_dissection.xml b/docbook/wsdg_src/WSDG_chapter_dissection.xml
index ec9909692b..eaf8b0c194 100644
--- a/docbook/wsdg_src/WSDG_chapter_dissection.xml
+++ b/docbook/wsdg_src/WSDG_chapter_dissection.xml
@@ -25,13 +25,13 @@
</para>
<para>
There is little difference in having your dissector as either a plugin
- or build-in. On the Win32 platform you have limited function access
+ or built-in. On the Win32 platform you have limited function access
through what's listed in libwireshark.def, but that is mostly complete.
</para>
<para>
The big plus is that your rebuild cycle for a plugin is much shorter
- than for a build-in one. So starting with a plugin makes initial development
- simpler, while deployment of the finished code may well be done as build-in
+ than for a built-in one. So starting with a plugin makes initial development
+ simpler, while deployment of the finished code may well be done as built-in
dissector.
</para>
<note><title>See also README.developer</title>
diff --git a/docbook/wsdg_src/WSDG_chapter_sources.xml b/docbook/wsdg_src/WSDG_chapter_sources.xml
index e4be5d1f3c..ee08080b36 100644
--- a/docbook/wsdg_src/WSDG_chapter_sources.xml
+++ b/docbook/wsdg_src/WSDG_chapter_sources.xml
@@ -850,9 +850,9 @@ Index: file.h
</para>
</listitem>
<listitem><para>
- <command>Submit dissectors as build-in whenever possible.</command>
+ <command>Submit dissectors as built-in whenever possible.</command>
Developing a new dissector as a plugin is a good idea because compiling is
- quicker, but it's best to convert dissectors to the build-in style before
+ quicker, but it's best to convert dissectors to the built-in style before
submitting for checkin. This reduces the number of files that must be installed
with Wireshark and ensures your dissector will be available on all platforms.
</para><para>
@@ -1074,7 +1074,7 @@ diff -c -r1.5 dlnames.c
<note><title>Note!</title>
<para>
This action is only possible/allowed by the Wireshark core developers who
- have write access to the Subversion repository. It is put in here, to have
+ have write access to the Subversion repository. It is put in here to have
all information in one place.
</para>
</note>
@@ -1089,7 +1089,7 @@ diff -c -r1.5 dlnames.c
</listitem>
<listitem>
<para>
- Add a line to each new file, containing the following text (case is
+ Add a line to each new file containing the following text (case is
important, so don't write ID or id or iD):
<programlisting>
$Id&#36;
@@ -1133,14 +1133,14 @@ $Id&#36;
</para>
</listitem>
</orderedlist>
- Don't forget a brief description of the reason for the commit, so other
+ Don't forget a brief description of the reason for the commit so other
developers don't need to read the diff in order to know what has changed.
</para>
</section>
<section id="ChSrcBinary">
<title>Binary packaging</title>
<para>
- Delivering binary packages, makes it much easier for the end-users to
+ Delivering binary packages makes it much easier for the end-users to
install Wireshark on their target system. This section will explain how
the binary packages are made.
</para>