More AsciiDoc → Asciidoctor updates.

Switch from AsciiDoc's smart quotes markup to the quotes themselves. Use
double curly quotes in place of singles.

Switch from XML entities to their direct equivalents where we can.
Switch from hex entities to decimal entities where we can't or it's not
convenient. (Asciidoctor PDF doesn't yet handle hex entities).

Change-Id: Iaf5ec33249e1c91b3d50b5d96251763243b72836
Reviewed-on: https://code.wireshark.org/review/25606
Reviewed-by: Gerald Combs <gerald@wireshark.org>

11 files changed, 124 insertions, 124 deletions

diff --git a/docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc b/docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc
index 8162d6cbb9..7221306da7 100644
--- a/docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc
@@ -14,7 +14,7 @@ Wireshark consists of the following major parts:
 
 * Packet dissection - in the _/epan/dissector_ and _/plugin/\*_ directories
 
-* File I/O - using Wireshark's own wiretap library
+* File I/O - using Wireshark’s own wiretap library
 
 * Capture - using the libpcap/winpcap library, in _/wiretap_
 
diff --git a/docbook/wsdg_src/WSDG_chapter_capture.asciidoc b/docbook/wsdg_src/WSDG_chapter_capture.asciidoc
index ccae1815da..bc434677f9 100644
--- a/docbook/wsdg_src/WSDG_chapter_capture.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_capture.asciidoc
@@ -17,8 +17,8 @@ This chapter needs to be reviewed and extended.
 The following is an updated excerpt from a developer mailing list mail about
 adding ISO 9141 and 14230 (simple serial line card diagnostics) to Wireshark:
 
-For libpcap, the first thing you'd need to do would be to get +{dlt-glob}+ values
-for all the link-layer protocols you'd need. If ISO 9141 and 14230 use the same
+For libpcap, the first thing you’d need to do would be to get +{dlt-glob}+ values
+for all the link-layer protocols you’d need. If ISO 9141 and 14230 use the same
 link-layer protocol, they might be able to share a +{dlt-glob}+ value, unless the
 only way to know what protocols are running above the link layer is to know
 which link-layer protocol is being used, in which case you might want separate
@@ -30,7 +30,7 @@ work with a version older than 1.0, even if whatever OS you're using happens to
 include libpcap - older versions are not as friendly towards adding support for
 devices other than standard network interfaces.
 
-Then you'd probably add to the `pcap_open_live()` routine, for whatever
+Then you’d probably add to the `pcap_open_live()` routine, for whatever
 platform or platforms this code should work, something such as a check
 for device names that look like serial port names and, if the check
 succeeds, a call to a routine to open the serial port.
@@ -39,7 +39,7 @@ See, for example, the `#ifdef HAVE_DAG_API` code in _pcap-linux.c_ and
 _pcap-bpf.c_.
 
 The serial port open routine would open the serial port device, set the baud
-rate and do anything else needed to open the device. It'd allocate a `pcap_t`,
+rate and do anything else needed to open the device. It’d allocate a `pcap_t`,
 set its `fd` member to the file descriptor for the serial device, set the
 `snapshot` member to the argument passed to the open routine, set the `linktype`
 member to one of the +{dlt-glob}+ values, and set the `selectable_fd` member to
@@ -48,22 +48,22 @@ the number of +{dlt-glob}+ values to support, and allocate an array of
 `dlt_count` `u_int`s, assign it to the `dlt_list` member, and fill in that list
 with all the +{dlt-glob}+ values.
 
-You'd then set the various `_*_op` fields to routines to handle the operations in
-question. `read_op` is the routine that'd read packets from the device. `inject_op`
-would be for sending packets; if you don't care about that, you'd set it to a
+You’d then set the various `_*_op` fields to routines to handle the operations in
+question. `read_op` is the routine that’d read packets from the device. `inject_op`
+would be for sending packets; if you don't care about that, you’d set it to a
 routine that returns an error indication. `setfilter_op` can probably just be set
 to `install_bpf_program`. `set_datalink` would just set the `linktype` member to the
-specified value if it's one of the values for OBD, otherwise it should return an
+specified value if it’s one of the values for OBD, otherwise it should return an
 error. `getnonblock_op` can probably be set to `pcap_getnonblock_fd`. `setnonblock_op`
 can probably be set to `pcap_setnonblock_fd`. `stats_op` would be set to a routine
 that reports statistics. `close_op` can probably be set to `pcap_close_common`.
 
-If there's more than one +{dlt-glob}+ value, you definitely want a `set_datalink`
+If there’s more than one +{dlt-glob}+ value, you definitely want a `set_datalink`
 routine so that the user can select the appropriate link-layer type.
 
-For Wireshark, you'd add support for those +{dlt-glob}+ values to
+For Wireshark, you’d add support for those +{dlt-glob}+ values to
 _wiretap/libpcap.c_, which might mean adding one or more _WTAP_ENCAP_ types to
-_wtap.h_ and to the `encap_table[]` table in _wiretap/wtap.c_. You'd then
+_wtap.h_ and to the `encap_table[]` table in _wiretap/wtap.c_. You’d then
 have to write a dissector or dissectors for the link-layer protocols or
 protocols and have them register themselves with the `wtap_encap` dissector
 table, with the appropriate _WTAP_ENCAP_ values by calling
diff --git a/docbook/wsdg_src/WSDG_chapter_dissection.asciidoc b/docbook/wsdg_src/WSDG_chapter_dissection.asciidoc
index 6ecf36a95b..56e9f607a3 100644
--- a/docbook/wsdg_src/WSDG_chapter_dissection.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_dissection.asciidoc
@@ -21,7 +21,7 @@ IP) and so on. At each stage, details of the packet will be decoded and
 displayed.
 
 Dissection can be implemented in two possible ways. One is to have a dissector
-module compiled into the main program, which means it's always available.
+module compiled into the main program, which means it’s always available.
 Another way is to make a plugin (a shared library or DLL) that registers itself
 to handle dissection.
 
@@ -44,7 +44,7 @@ a dissector. In many cases it is more up to date than this document.
 
 === Adding a basic dissector
 
-Let's step through adding a basic dissector. We'll start with the made up "foo"
+Let’s step through adding a basic dissector. We'll start with the made up "foo"
 protocol. It consists of the following basic items.
 
 * A packet type - 8 bits, possible values: 1 - initialisation, 2 - terminate, 3 - data.
@@ -62,7 +62,7 @@ protocol. It consists of the following basic items.
 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.
 
-Plugins are the easiest to write initially, so let's start with that.
+Plugins are the easiest to write initially, 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.
 
@@ -90,12 +90,12 @@ proto_register_foo(void)
 ----
 ====
 
-Let's go through this a bit at a time. First we have some boilerplate
+Let’s go through this a bit at a time. First we have some boilerplate
 include files. These will be pretty constant to start with.
 
 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.
-It's 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.
 
@@ -126,7 +126,7 @@ proto_reg_handoff_foo(void)
 ----
 ====
 
-What's happening here? We are initialising the dissector. First we create a
+What’s happening here? We are initialising the dissector. First we create a
 dissector handle; It is associated with the foo protocol and with a routine to
 be called to do the actual dissecting. Then we associate the handle with a UDP
 port number so that the main program will know to call us when it gets UDP
@@ -160,8 +160,8 @@ info structure contains general data about the protocol, and we can update
 information here. The tree parameter is where the detail dissection takes place.
 
 For now we'll do the minimum we can get away with. In the first line we set the
-text of this to our protocol, so everyone can see it's being recognised. The
-only other thing we do is to clear out any data in the INFO column if it's being
+text of this to our protocol, so everyone can see it’s being recognised. The
+only other thing we do is to clear out any data in the INFO column if it’s being
 displayed.
 
 At this point we should have a basic dissector ready to compile and install.
@@ -194,7 +194,7 @@ binary into the plugin directory of your Wireshark installation and run that.
 
 ==== Dissecting the details of the protocol
 
-Now that we have our basic dissector up and running, let's 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.
 
@@ -224,7 +224,7 @@ This subtree will hold all the details of this protocol and so not clutter
 up the display when not required.
 
 We are also marking the area of data that is being consumed by this
-protocol. In our case it's 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
@@ -234,7 +234,7 @@ ENC_NA ("not applicable") is specified as the "encoding" parameter.
 After this change, there should be a label in the detailed display for the protocol,
 and selecting this will highlight the remaining contents of the packet.
 
-Now let's go to the next step and add some protocol dissection. For this step
+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 additions to the `proto_register_foo()` function shown previously.
 
@@ -335,7 +335,7 @@ We'll ignore the rest of the structure for now.
 If you install this plugin and try it out, you'll see something that begins to look
 useful.
 
-Now let's 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 hfarray, and a couple more procedure calls.
 
 .Wrapping up the packet dissection.
@@ -405,7 +405,7 @@ now dissected.
 ==== Improving the dissection information
 
 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
+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.
 
@@ -507,7 +507,7 @@ to the dissection routine. Note we keep the same offset for each of the flags.
 This is starting to look fairly full featured now, but there are a couple of
 other 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, let's
+uninformative. We can enhance this by adding a little more detail. 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
@@ -545,7 +545,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_)
 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 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 it's displayed, and
+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.
 
 [[ChDissectTransformed]]
@@ -557,7 +557,7 @@ encrypt the data, or compress data, or part of it. If you know
 how these steps are taken it is possible to reverse them within the
 dissector.
 
-As encryption can be tricky, let's 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.
 
@@ -594,7 +594,7 @@ effect.
 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 it's not, it may be part of the compression routine to
+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.
 
 So armed with the size, a buffer is allocated to receive the uncompressed data
@@ -613,7 +613,7 @@ tvb as a new data source, so that the detailed display can show the
 decompressed bytes as well as the original.
 
 After this has been set up the remainder of the dissector can dissect the buffer
-next_tvb, as it's a new buffer the offset needs to be 0 as we start again from
+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 `tvb_new_subset_remaining()` to deliver us a new buffer based
@@ -640,7 +640,7 @@ _epan/reassemble.h_.
 
 ==== How to reassemble split UDP packets
 
-As an example, let's examine a protocol that is layered on top of UDP that
+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.
 
@@ -693,7 +693,7 @@ if (flags & FL_FRAGMENT) { /* fragmented */
 
 We start by saving the fragmented state of this packet, so we can restore it
 later. Next comes some protocol specific stuff, to dig the fragment data out of
-the stream if it's present. Having decided it is present, we let the function
+the stream if it’s present. Having decided it is present, we let the function
 `fragment_add_seq_check()` do its work. We need to provide this with a certain
 amount of parameters:
 
@@ -967,7 +967,7 @@ exception.
 Adding a Tap interface to a protocol allows it to do some useful things.
 In particular you can produce protocol statistics from the tap interface.
 
-A tap is basically a way of allowing other items to see what's happening as
+A tap is basically a way of allowing other items to see what’s happening as
 a protocol is dissected. A tap is registered with the main program, and
 then called on each dissection. Some arbitrary protocol specific data
 is provided with the routine that can be used.
@@ -998,15 +998,15 @@ void proto_register_foo(void)
 ====
 
 Whilst you can program a tap without protocol specific data, it is generally not
-very useful. Therefore it's a good idea to declare a structure that can be
+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. It's generally best to pick out some
+after the dissection routine has returned. It’s generally best to pick out some
 generic parts of the protocol you are dissecting into the tap data. A packet
 type, a priority or a status code maybe. The structure really needs to be
 included in a header file so that it can be included by other components that
 want to listen in to the tap.
 
-Once you have these defined, it's simply a case of populating the protocol
+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.
 
@@ -1073,7 +1073,7 @@ strings, an integer, and three callback functions.
 
 . An abbreviation of the stats name.
 
-. The name of the stats module. A `/' character can be used to make sub menus.
+. The name of the stats module. A “/” character can be used to make sub menus.
 
 . Flags for per-packet callback
 
@@ -1136,14 +1136,14 @@ _doc/README.dissector_, chapter 2.2.
 
 === __idl2wrs__: Creating dissectors from CORBA IDL files
 
-Many of Wireshark's dissectors are automatically generated. This section shows
+Many of Wireshark’s dissectors are automatically generated. This section shows
 how to generate one from a CORBA IDL file.
 
 ==== What is it?
 
 As you have probably guessed from the name, `idl2wrs` takes a user specified IDL
 file and attempts to build a dissector that can decode the IDL traffic over
-GIOP. The resulting file is ``C'' code, that should compile okay as a Wireshark
+GIOP. The resulting file is “C” code, that should compile okay as a Wireshark
 dissector.
 
 `idl2wrs` parses the data struct given to it by the `omniidl` compiler,
@@ -1176,7 +1176,7 @@ I have also had comments/feedback that this tool would be good for say a CORBA
 class when teaching students what CORBA traffic looks like ``on the wire''.
 
 It is also COOL to work on a great Open Source project such as the case with
-``Wireshark'' ({wireshark-main-url})
+“Wireshark” ({wireshark-main-url})
 
 
 ==== How to use idl2wrs
diff --git a/docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc b/docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc
index 1e76ae80a2..af713bb169 100644
--- a/docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc
@@ -19,7 +19,7 @@ development in general.
 
 Well, if you want to start Wireshark development, you might already
 know what Wireshark is doing. If not, please have a look at the
-link:{wireshark-users-guide-url}[Wireshark User's Guide],
+link:{wireshark-users-guide-url}[Wireshark User’s Guide],
 which will provide a lot of general information about it.
 
 [[ChIntroPlatforms]]
@@ -32,7 +32,7 @@ order to run.
 
 As Wireshark is developed in a platform independent way and uses libraries (such
 as the Qt GUI library) which are available for many different platforms,
-it's thus available on a wide variety of platforms.
+it’s thus available on a wide variety of platforms.
 
 If a binary package is not available for your platform, you should
 download the source and try to build it. Please report your experiences
@@ -84,7 +84,7 @@ others:
 Wireshark supports Windows natively via the
 https://en.wikipedia.org/wiki/Windows_API[Windows API]. Note that in
 this documentation and elsewhere we tend to use the terms
-``Win32'', ``Win'', and ``Windows'' interchangeably to refer to the
+“Win32”, “Win”, and “Windows” interchangeably to refer to the
 Windows API. Wireshark runs on and can be compiled on the following
 platforms:
 
@@ -168,7 +168,7 @@ community:
   will know that you have helped people in the same way that the developers of
   Wireshark have helped you and other people.
 
-* The developers of Wireshark might improve your changes even more, as there's
+* The developers of Wireshark might improve your changes even more, as there’s
   always room for improvement. Or they may implement some advanced things on top
   of your code, which can be useful for yourself too.
 
@@ -235,10 +235,10 @@ e.g. if you need a distribution for a special audience, see
 
 ==== Source code distributions
 
-It's still common for UNIX developers to give the end user a source
+It’s still common for UNIX developers to give the end user a source
 tarball and let the user compile it on their target machine (configure,
 make, make install). However, for different UNIX (Linux) distributions
-it's becoming more common to release binary packages (e.g. .deb or .rpm
+it’s becoming more common to release binary packages (e.g. .deb or .rpm
 files) these days.
 
 You should use the released sources if you want to build Wireshark from
@@ -340,7 +340,7 @@ You will find lots of useful information on the Wireshark homepage at
 
 The Wireshark Wiki at {wireshark-wiki-url} provides a wide range
 of information related to Wireshark and packet capturing in general.
-You will find a lot of information not part of this developer's guide. For
+You will find a lot of information not part of this developer’s guide. For
 example, there is an explanation how to capture on a switched network,
 an ongoing effort to build a protocol reference and a lot more.
 
@@ -365,7 +365,7 @@ You will find the FAQ inside Wireshark by clicking the menu item
 Help/Contents and selecting the FAQ page in the upcoming dialog.
 
 An online version is available at the Wireshark website:
-{wireshark-faq-url}. You might prefer this online version as it's
+{wireshark-faq-url}. You might prefer this online version as it’s
 typically more up to date and the HTML format is easier to use.
 
 [[ChIntroOtherSources]]
@@ -495,7 +495,7 @@ as this won't give any direction to look at.
 [NOTE]
 .Don't send large files
 ====
-Do not send large files (>100KB) to the mailing lists, just place a note
+Do not send large files (>100KB) to the mailing lists, just place a note
 that further data is available on request. Large files will only annoy a
 lot of people on the list who are not interested in your specific problem.
 If required, you will be asked for further data by the persons who really
@@ -542,7 +542,7 @@ _bt.txt_ in the current directory.
 Include the file with your bug report.
 
 If you do not have `gdb` available, you
-will have to check out your operating system's debugger.
+will have to check out your operating system’s debugger.
 ====
 
 You should mail the traceback to mailto:{wireshark-dev-list-email}[] or attach it
diff --git a/docbook/wsdg_src/WSDG_chapter_libraries.asciidoc b/docbook/wsdg_src/WSDG_chapter_libraries.asciidoc
index 0cc3d3987c..ef825fb482 100644
--- a/docbook/wsdg_src/WSDG_chapter_libraries.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_libraries.asciidoc
@@ -63,7 +63,7 @@ format. You will recognize MSVC libraries by the .lib/.dll file extension.
 ==== Win32: cygwin gcc
 
 Cygwin provides most of the required libraries (with file extension .a or .lib)
-for Wireshark suitable for cygwin's gcc compiler.
+for Wireshark suitable for cygwin’s gcc compiler.
 
 
 [[ChLibsSetup]]
@@ -120,7 +120,7 @@ bin directory, e.g. C:\Qt\Qt5.6.2\5.6\msvc2013
 
 === GTK+ / GLib / GDK / Pango / ATK / GNU gettext / GNU libiconv
 
-The Glib library is used as a basic platform abstraction library, it's
+The Glib library is used as a basic platform abstraction library, it’s
 not related to graphical user interface (GUI) things. For a detailed
 description about GLib, see <<ChCodeGLib>>.
 
@@ -172,7 +172,7 @@ http://www.ibr.cs.tu-bs.de/projects/libsmi/[].
 
 Wireshark uses the source libSMI distribution at
 http://www.ibr.cs.tu-bs.de/projects/libsmi/[].
-LibSMI is cross-compiled using MinGW32. It's stored in the libsmi zip archive at
+LibSMI is cross-compiled using MinGW32. It’s stored in the libsmi zip archive at
 https://anonsvn.wireshark.org/wireshark-win32-libs/trunk/packages/[].
 
 [[ChLibsCares]]
@@ -230,7 +230,7 @@ locally.
 === libpcap/WinPcap (optional)
 
 Libpcap and WinPcap provide that packet capture capabilities that are central
-to Wireshark's core functionality.
+to Wireshark’s core functionality.
 
 [[ChLibsLibpcap]]
 
diff --git a/docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc b/docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc
index 218785eb5b..8ad0c6fc28 100644
--- a/docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc
@@ -16,7 +16,7 @@ If a tool is not already installed on your system, you can usually install it
 using the package in your distribution: aptitude, yum, Synaptic, etc.
 
 If an install package is not available or you have a
-reason not to use it (maybe because it's simply too old), you
+reason not to use it (maybe because it’s simply too old), you
 can install that tool from source code. The following sections
 will provide you with the webpage addresses where you can get
 these sources.
@@ -81,7 +81,7 @@ PS$>choco install VisualStudio2015Community --timeout 0 -package-parameters "--A
 ----
 
 You can use other Microsoft C compiler variants, but VS2015 is used to
-build the development releases and is the preferred option. It's
+build the development releases and is the preferred option. It’s
 possible to compile Wireshark with a wide range of Microsoft C compiler
 variants. For details see <<ChToolsMSChain>>.
 
@@ -185,7 +185,7 @@ You can directly download packages via `cyg-get`
 PS$>cyg-get asciidoc patch docbook-xml45 [...]
 ----
 
-You can use Chocolatey's Win flex-bison packages rather than the Cygwin
+You can use Chocolatey’s Win flex-bison packages rather than the Cygwin
 Bison and Flex package:
 
 ----
@@ -199,7 +199,7 @@ PS$>choco install winflexbison
 Get the Python 3.5 or 2.7 installer from http://python.org/download/[] and
 install Python into the default location (_C:\Python35_ or _C:\Python27_).
 
-Why is this recommended? Cygwin's _/usr/bin/python_ is a Cygwin-specific
+Why is this recommended? Cygwin’s _/usr/bin/python_ is a Cygwin-specific
 symbolic link which cannot be run from Windows. The native package is faster
 as well.
 
@@ -288,7 +288,7 @@ Chocolatey ensures cmake.exe is on your path.
 [TIP]
 .Make sure everything works
 ====
-It's a good idea to make sure Wireshark compiles and runs at least once before
+It’s a good idea to make sure Wireshark compiles and runs at least once before
 you start hacking the Wireshark sources for your own project. This example uses
 Git Extensions but any other Git client should work as well.
 ====
@@ -318,7 +318,7 @@ Repository to clone: *`https://code.wireshark.org/review/wireshark`*
 +
 Destination: Your top-level development directory, e.g. _C:\Development_.
 +
-Subdirectory to create: Anything you'd like. Usually _wireshark_.
+Subdirectory to create: Anything you’d like. Usually _wireshark_.
 +
 [TIP]
 .Check your paths
@@ -457,7 +457,7 @@ the environment variables `WIRESHARK_BASE_DIR` and `QT5_BASE_DIR`.
 
 ==== Build Wireshark
 
-Now it's time to build Wireshark!
+Now it’s time to build Wireshark!
 
 . If you've closed the Visual Studio Command Prompt <<ChSetupPrepareCommandCom,prepare>> it again.
 
@@ -491,7 +491,7 @@ The build files produced by CMake will regenerate themselves if required by chan
 You can debug using the Visual Studio Debugger or WinDbg.  See the section
 on using the <<ChToolsDebugger, Debugger Tools>>.
 
-==== Optional: Create User's and Developer's Guide
+==== Optional: Create User’s and Developer’s Guide
 
 Detailed information to build these guides can be found in the file
 _docbook\README.txt_ in the Wireshark sources.
@@ -538,6 +538,6 @@ to build a Wireshark installer.
 ----
 > C:\Development\wireshark\packaging\nsis\wireshark-win32-{wireshark-version}-myprotocol123.exe
 ----
-to test your new installer. It's a good idea to test on a different machine
+to test your new installer. It’s a good idea to test on a different machine
 than the developer machine. Note that if you've built an x64 version, the installer will be named accordingly.
 --
diff --git a/docbook/wsdg_src/WSDG_chapter_sources.asciidoc b/docbook/wsdg_src/WSDG_chapter_sources.asciidoc
index 01b2a59778..e39e916764 100644
--- a/docbook/wsdg_src/WSDG_chapter_sources.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_sources.asciidoc
@@ -28,7 +28,7 @@ such as where to find specific functionality. This is done in
 === The Wireshark Git repository
 
 http://git-scm.com/[Git] is used to keep track of the changes made to the
-Wireshark source code. The code is stored inside Wireshark project's Git
+Wireshark source code. The code is stored inside Wireshark project’s Git
 repository located at a server at the wireshark.org domain.
 
 Changes to the official repository are managed using the
@@ -46,7 +46,7 @@ scale distributed development and ensures data integrity.
 .Why Gerrit?
 
 Gerrit makes it easy to contribute. You can sign in with any OpenID
-provider and push your changes. It's usable from both the web and
+provider and push your changes. It’s usable from both the web and
 command line and is integrated with many popular tools.
 
 .Git is our *third* revision control system
@@ -57,7 +57,7 @@ Wireshark originally used http://www.nongnu.org/cvs/[Concurrent Versions System]
 The Subversion repository was subsequently migrated to Git in January 2014.
 ====
 
-Using Wireshark's Git repository you can:
+Using Wireshark’s Git repository you can:
 
 * Keep your private sources up to date with very little effort
 * Get a mail notification when the official source code changes
@@ -92,7 +92,7 @@ Wireshark uses the following branches for official releases:
 
 === Obtain the Wireshark sources
 
-There are several ways to obtain the sources from Wireshark's Git
+There are several ways to obtain the sources from Wireshark’s Git
 repository.
 
 [TIP]
@@ -109,7 +109,7 @@ source tree several times a day without much effort.
 ====
 The following ways to retrieve the Wireshark sources are sorted in
 decreasing source timeliness.  If you plan to commit changes you've
-made to the sources, it's a good idea to keep your private source
+made to the sources, it’s a good idea to keep your private source
 tree as current as possible.
 ====
 
@@ -126,7 +126,7 @@ Recommended for development purposes.
 
 Age: a few minutes.
 
-You can use a Git client to download the source code from Wireshark's code
+You can use a Git client to download the source code from Wireshark’s code
 review system. Anyone can clone from the anonymous git URL:
 
 * {wireshark-git-anonhttp-url}
@@ -141,7 +141,7 @@ https://code.wireshark.org/review/Documentation/cmd-index.html#_server[command l
 HTTP lets you access the repository in environments that block the Gerrit SSH
 port (29418). At the time of this writing (early 2014) we recommend that
 you use the SSH interface. However, this may change as more tools take
-advantage of Gerrit's HTTP REST API.
+advantage of Gerrit’s HTTP REST API.
 
 The following example shows how to get up and running on the command
 line. See <<ChToolsGit>> for information on installing and configuring
@@ -258,14 +258,14 @@ possible (e.g. because of a restrictive firewall).
 Age: some number of minutes (a bit older than the Git access).
 
 The Buildbot server will automatically start to generate a snapshot of
-Wireshark's source tree after a source code change is committed. These
+Wireshark’s source tree after a source code change is committed. These
 snapshots can be found at {wireshark-snapshots-url}.
 
 If Git access isn't possible, e.g. if the connection to the server
 isn't possible because of a corporate firewall, the sources can be
 obtained by downloading the Buildbot snapshots. However, if you are
 going to maintain your sources in parallel to the "official" sources
-for some time, it's recommended to use the anonymous (or authenticated)
+for some time, it’s recommended to use the anonymous (or authenticated)
 Git access if possible (believe it, it will save you a lot of time).
 
 [[ChSrcReleased]]
@@ -310,7 +310,7 @@ sure the builds are in good shape.
 
 ==== Update Using Git
 
-After you clone Wireshark's Git repository you can update
+After you clone Wireshark’s Git repository you can update
 by running
 
 ----
@@ -359,7 +359,7 @@ error-prone than using Git.
 
 === Build Wireshark
 
-The sources contain several documentation files. It's a good idea to read these
+The sources contain several documentation files. It’s a good idea to read these
 files first. After obtaining the sources, tools and libraries, the first place
 to look at is _doc/README.developer_. Inside you will find the latest
 information for Wireshark development for all supported platforms.
@@ -420,7 +420,7 @@ installed version first.
 ==== Unix/Linux
 
 After a successful build you can run Wireshark right from the build
-directory. Still the program would need to know that it's being run from
+directory. Still the program would need to know that it’s being run from
 the build directory and not from its install location. This has an impact
 on the directories where the program can find the other parts and
 relevant data files.
@@ -436,7 +436,7 @@ command line to launch Wireshark would be:
 $ WIRESHARK_RUN_FROM_BUILD_DIRECTORY=1 ./wireshark
 ----
 
-There's no need to run Wireshark as root user, you just won't be able to
+There’s no need to run Wireshark as root user, you just won't be able to
 capture. When you opt to run Wireshark this way, your terminal output can
 be informative when things don't work as expected.
 
@@ -501,7 +501,7 @@ on using the <<ChToolsDebugger, Debugger Tools>>.
 
 As the Wireshark developers are working on many different platforms, a lot of
 editors are used to develop Wireshark (emacs, vi, Microsoft Visual Studio
-and many, many others). There's no "standard" or "default" development
+and many, many others). There’s no "standard" or "default" development
 environment.
 
 There are several reasons why you might want to change the Wireshark
@@ -521,7 +521,7 @@ The internal structure of the Wireshark sources will be described in
 .Ask the _wireshark-dev_ mailing list before you start a new development task.
 [TIP]
 ====
-If you have an idea what you want to add or change it's a good idea to
+If you have an idea what you want to add or change it’s a good idea to
 contact the developer mailing list
 (see <<ChIntroMailingLists>>)
 and explain your idea. Someone else might already be working on the same
@@ -541,12 +541,12 @@ If you have finished changing the Wireshark sources to suit your needs, you
 might want to contribute your changes back to the Wireshark community. You gain
 the following benefits by contributing your improvements:
 
-* _It's the right thing to do._ Other people who find your contributions useful
+* _It’s the right thing to do._ Other people who find your contributions useful
   will appreciate them, and you will know that you have helped people in the
   same way that the developers of Wireshark have helped you.
 
 * _You get free enhancements._ By making your code public, other developers have
-  a chance to make improvements, as there's always room for improvements. In
+  a chance to make improvements, as there’s always room for improvements. In
   addition someone may implement advanced features on top of your code, which
   can be useful for yourself too.
 
@@ -557,7 +557,7 @@ the following benefits by contributing your improvements:
   version from the website and your changes will already be included without any
   effort for you.
 
-There's no direct way to push changes to the Git repository. Only a few people
+There’s no direct way to push changes to the Git repository. Only a few people
 are authorised to actually make changes to the source code (check-in changed
 files). If you want to submit your changes, you should upload them to the code
 review system at {wireshark-code-review-url}. This requires you to set up git
@@ -696,7 +696,7 @@ as described at <<ChSrcGit>>.
 // $ diff -N -r -u --strip-trailing-cr ./svn-dir ./working-dir > foo.diff
 // ----
 //
-// It's a good idea to run `make distclean` before the
+// It’s a good idea to run `make distclean` before the
 // actual diff call, as this will remove a lot
 // of temporary files which might be otherwise included in the diff. After
 // doing the diff, you should edit the _foo.diff_ file and remove unnecessary
@@ -731,7 +731,7 @@ as described at <<ChSrcGit>>.
 Some tips that will make the merging of your changes into Git much more likely
 (and you want exactly that, don't you?):
 
-* _Use the latest Git sources._ It's a good idea to work with the same
+* _Use the latest Git sources._ It’s a good idea to work with the same
   sources that are used by the other developers. This usually makes it much
   easier to apply your patch. For information about the different ways to get
   the sources, see <<ChSrcObtain>>.
@@ -774,7 +774,7 @@ and integrated.
 The core maintainers have done a lot of work fixing bugs and making code
 compile on the various platforms Wireshark supports.
 
-To ensure Wireshark's source code quality, and to reduce the workload of the
+To ensure Wireshark’s source code quality, and to reduce the workload of the
 core maintainers, there are some things you should think about _before_
 submitting a patch.
 
@@ -792,7 +792,7 @@ be rejected.
   details.
 
 * _Submit dissectors as built-in whenever possible._ Developing a new dissector
-as a plugin is a good idea because compiling and testing is quicker, but it's
+as a plugin is a good idea because compiling and testing is quicker, but it’s
 best to convert dissectors to the built-in style before submitting for check in.
 This reduces the number of files that must be installed with Wireshark and
 ensures your dissector will be available on all platforms.
@@ -882,7 +882,7 @@ You might get one of the following responses to your patch request:
   your patch is in the review system it won't get lost.
 
 If you're concerned, feel free to add a comment to the patch or send an email
-to the developer's list asking for status. But please be patient: most if not
+to the developer’s list asking for status. But please be patient: most if not
 all of us do this in our spare time.
 
 [[ChSrcBackport]]
@@ -947,23 +947,23 @@ Given the file _new.diff_ containing a unified diff,
 the right way to call the patch tool depends on what the pathnames in
 _new.diff_ look like.
 If they're relative to the top-level source directory (for example, if a
-patch to _prefs.c_ just has _prefs.c_ as the file name) you'd run it as:
+patch to _prefs.c_ just has _prefs.c_ as the file name) you’d run it as:
 
 ----
 $ patch -p0 < new.diff
 ----
 
-If they're relative to a higher-level directory, you'd replace 0 with the
+If they're relative to a higher-level directory, you’d replace 0 with the
 number of higher-level directories in the path, e.g. if the names are
 _wireshark.orig/prefs.c_ and
-_wireshark.mine/prefs.c_, you'd run it with:
+_wireshark.mine/prefs.c_, you’d run it with:
 
 ----
 $ patch -p1 < new.diff
 ----
 
 If they're relative to a _subdirectory_ of the top-level
-directory, you'd run `patch` in _that_ directory and run it with `-p0`.
+directory, you’d run `patch` in _that_ directory and run it with `-p0`.
 
 If you run it without `-pat` all, the patch tool
 flattens path names, so that if you
@@ -977,12 +977,12 @@ _Makefile.am_ as well.
 At which position in the filesystem should the patch tool be called?
 
 If the pathnames are relative to the top-level source directory, or to a
-directory above that directory, you'd run it in the top-level source
+directory above that directory, you’d run it in the top-level source
 directory.
 
 If they're relative to a *subdirectory* -- for example,
 if somebody did a patch to _packet-ip.c_ and ran `diff` or `git diff` in
-the _epan/dissectors_ directory -- you'd run it in that subdirectory.
+the _epan/dissectors_ directory -- you’d run it in that subdirectory.
 It is preferred that people *not* submit patches like
 that, especially if they're only patching files that exist in multiple
 directories such as _Makefile.am_.
diff --git a/docbook/wsdg_src/WSDG_chapter_tools.asciidoc b/docbook/wsdg_src/WSDG_chapter_tools.asciidoc
index 906359205f..5f55f7ae06 100644
--- a/docbook/wsdg_src/WSDG_chapter_tools.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_tools.asciidoc
@@ -65,7 +65,7 @@ PS:\>iex ((new-object net.webclient).DownloadString(_https://chocolatey.org/inst
 ----
 
 Chocolatey sometimes installs packages in unexpected locations. Cygwin is a notable
-example -- recent versions of the Cygwin package are installed in _C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin_ instead of Cygwin's default location
+example -- recent versions of the Cygwin package are installed in _C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin_ instead of Cygwin’s default location
 (_C:\cygwin_ or _C:\cygwin64_).
 
 [[ChToolsCygwin]]
@@ -85,7 +85,7 @@ Although Cygwin consists of several separate packages, the installation
 and update is done through a single utility, _setup-x86.exe_ or
 _setup-x86_64.exe_, which acts similarly to other web based installers.
 You can install Cygwin and its packages using Chocolatey, but this is not
-recommended due to Chocolatey's default installation location, described
+recommended due to Chocolatey’s default installation location, described
 in the previous section.
 
 ==== Installing Cygwin using the Cygwin installer
@@ -198,7 +198,7 @@ Your version string may vary, of course.
 
 [[ChToolsCMake]]
 
-Wireshark's build environment can be configured using CMake on Windows
+Wireshark’s build environment can be configured using CMake on Windows
 and either CMake or Autotools on Linux, macOS, and UNIX. CMake is designed
 to support out of tree builds. So much so, that in tree builds do not work
 properly in all cases. Along with being cross-platform, CMake supports
@@ -237,7 +237,7 @@ using the `-D` flag. Useful variables and generators include the following:
 
 +++-DCMAKE_C_FLAGS='-Qunused-arguments'+++:: Make ccache and clang work together
 
--DPYTHON_EXECUTABLE=c:/Python27/python:: Force the Python path. Useful on Windows since Cygwin's /usrbin/python is a symlink.
+-DPYTHON_EXECUTABLE=c:/Python27/python:: Force the Python path. Useful on Windows since Cygwin’s /usrbin/python is a symlink.
 
 -DENABLE_APPLICATION_BUNDLE=OFF:: Disable building an application bundle (Wireshark.app) on macOS
 
@@ -522,7 +522,7 @@ http://msdn.microsoft.com/en-us/library/t2fck18t.aspx[Microsoft MSDN]
 ==== C-Runtime "Redistributable" Files
 
 Please note: The following is not legal advice - ask your preferred lawyer
-instead. It's the authors view and this view might be wrong.
+instead. It’s the authors view and this view might be wrong.
 
 Depending on the Microsoft compiler version you use, some binary files coming
 from Microsoft might be required to be installed on Windows machine to run
@@ -575,7 +575,7 @@ this for applications built with Visual Studio 2013)
 
 . _Using Visual {cpp} Redistributable Merge Modules._
 (Loadable modules for building msi installers.
-Not suitable for Wireshark's NSIS based installer)
+Not suitable for Wireshark’s NSIS based installer)
 
 . _Install a particular Visual {cpp} assembly as a
 private assembly for the application._ The
@@ -596,7 +596,7 @@ is used (this produces the smallest package).
 The Windows Platform SDK (PSDK) or Windows SDK is a free
 (as in beer) download and contains platform specific headers and
 libraries (e.g. _windows.h_, _WSock32.lib_, etc.). As new Windows
-features evolve in time, updated SDK's become available that
+features evolve in time, updated SDK’s become available that
 include new and updated APIs.
 
 When you purchase a commercial Visual Studio or use the Community Edition, it will
@@ -611,15 +611,15 @@ search for SetEnv.* in the SDK directory.
 
 ==== HTML Help
 
-HTML Help is used to create the User's and Developer's Guide in .chm format and
-to show the User's Guide as the Wireshark "Online Help".
+HTML Help is used to create the User’s and Developer’s Guide in .chm format and
+to show the User’s Guide as the Wireshark "Online Help".
 
 Both features are currently optional, and might be removed in future versions.
 
 ===== HTML Help Compiler (hhc.exe)
 
 This compiler is used to generate a .chm file from a bunch of HTML files -- in
-our case to generate the User's and Developer's Guide in .chm format.
+our case to generate the User’s and Developer’s Guide in .chm format.
 
 The compiler is only available as the free (as in beer) "HTML Help Workshop"
 download. If you want to compile the guides yourself, you need to download and
@@ -688,7 +688,7 @@ If you require a non-optimised version, then build using a debug configuration.
 ===== Debugging Tools for Windows
 
 You can also use the Microsoft Debugging Tools for Windows toolkit, which is a
-standalone GUI debugger. Although it's not that comfortable compared to
+standalone GUI debugger. Although it’s not that comfortable compared to
 debugging with the Visual Studio integrated debugger it can be helpful if you
 have to debug on a machine where an integrated debugger is not available.
 
@@ -897,7 +897,7 @@ However, the version string may vary.
 
 === Bison
 
-Bison is a parser generator used for some of Wireshark's file format support.
+Bison is a parser generator used for some of Wireshark’s file format support.
 
 [[ChToolsUnixBison]]
 
@@ -944,7 +944,7 @@ officially supported but _should_ work.
 
 === Flex
 
-Flex is a lexical analyzer generator used for Wireshark's display filters, some
+Flex is a lexical analyzer generator used for Wireshark’s display filters, some
 file formats, and other features.
 
 [[ChToolsUnixFlex]]
diff --git a/docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc b/docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc
index b97fe763fb..75e9e4c9df 100644
--- a/docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc
@@ -66,7 +66,7 @@ instead of requiring that options be specified.
 documentation and instead prefer to learn an application as they use it.
 Providing feedback increases your sense of control and awareness, and
 makes the application more enjoyable to use. Most of the Qt dialogs
-provide a ``hint'' area near the bottom which shows useful information.
+provide a “hint” area near the bottom which shows useful information.
 For example, the ``Follow Stream'' dialog shows the packet corresponding
 to the text under the mouse. The profile management dialog shows a
 clickable path to the current profile. The main welcome screen shows
@@ -77,7 +77,7 @@ keyboard shortcuts.
 
 Qt Creator is a full-featured IDE and user interface editor. It makes
 adding new UI features much easier. It doesn't work well on Windows at
-the present time, so it's recommended that you use it on macOS or Linux.
+the present time, so it’s recommended that you use it on macOS or Linux.
 
 To edit and build Wireshark using Qt Cretor, open the top-level
 _CMakeLists.txt_ within Qt Creator. It should ask you to choose a build
@@ -87,14 +87,14 @@ ENABLE_GTK3=OFF") and click the ``Run CMake'' button. When that
 completes select ``Build → Open Build and Run Kit Selector...'' and make
 sure _wireshark_ is selected.
 
-Note that Qt Creator uses output created by CMake's *CodeBlocks*
+Note that Qt Creator uses output created by CMake’s *CodeBlocks*
 generator. If you run CMake outside of Qt Creator you should use the
 ``CodeBlocks - Unix Makefiles'' generator, otherwise Qt Creator will
 prompt you to re-run CMake.
 
 ==== Source Code Overview
 
-Wireshark's `main` entry point is in _wireshark-qt.cpp_. Command-line arguments
+Wireshark’s `main` entry point is in _wireshark-qt.cpp_. Command-line arguments
 are processed there and the main application class (`WiresharkApplication`)
 instance is created there along with the main window.
 
@@ -119,7 +119,7 @@ open when the capture file closes.
 
 The code in _ui/qt_ directory uses three APIs: Qt (which uses
 InterCapConvention), GLib (which uses underscore_convention), and the Wireshark
-API (which also uses underscore_convention). As a general rule Wireshark's Qt
+API (which also uses underscore_convention). As a general rule Wireshark’s Qt
 code uses InterCapConvention for class names, interCapConvention for methods,
 and underscore_convention for variables, with a trailing_underscore_ for member
 variables.
@@ -130,9 +130,9 @@ Dialogs that work with capture file information shouldn't close just because the
 capture file closes. Subclassing `WiresharkDialog` as described above can make
 it easier to persist across capture files.
 
-When you create a window with a row of standard ``OK'' and ``Close'' buttons at
+When you create a window with a row of standard “OK” and “Close” buttons at
 the bottom using Qt Creator you will end up with a subclass of QDialog. This is
-fine for traditional modal dialogs, but many times the ``dialog'' needs to behave
+fine for traditional modal dialogs, but many times the “dialog” needs to behave
 like a QWindow instead.
 
 Modal dialogs should be constructed with `QDialog(parent)`. Modeless dialogs
@@ -143,7 +143,7 @@ this for you.
 
 Most of the dialogs in ui/qt share many similarities, including method names,
 widget names, and behavior. Most dialogs should have the following, although
-it's not strictly required:
+it’s not strictly required:
 
 - An `updateWidgets()` method, which enables and disables widgets depending on
   the current state and constraints of the dialog. For example, the Coloring
@@ -163,7 +163,7 @@ it's not strictly required:
 
 ===== Strings
 
-Wireshark's C code and GLib use UTF-8 encoded character arrays. Qt
+Wireshark’s C code and GLib use UTF-8 encoded character arrays. Qt
 (specifically QString) uses UTF-16. You can convert a `char *` to a
 `QString` using simple assignment. You can convert a `QString` to a
 `const char *` using `qUtf8Printable`.
@@ -184,7 +184,7 @@ your code.
 ===== Mixing C and {cpp}
 
 Sometimes we have to call {cpp} functions from one of
-Wireshark's C callbacks and pass {cpp} objects to or from C. Tap
+Wireshark’s C callbacks and pass {cpp} objects to or from C. Tap
 listeners are a common example. The {cpp} FAQ link:http://www.
 parashift.com/c++-faq/mixing-c-and-cpp.html:[describes how to do this
 safely].
@@ -266,7 +266,7 @@ the internals of a running Qt application similar to $$Spy++$$ on Windows.
 .We have switched to Qt
 [NOTE]
 ====
-Wireshark's default interface uses Qt. If you would like to add a new
+Wireshark’s default interface uses Qt. If you would like to add a new
 interface feature you should use it and not GTK{plus}.
 The documentation below is primarily historical.
 ====
@@ -278,13 +278,13 @@ intended to be a multiplatform tool, there are some drawbacks, as the
 result is a somewhat "non native" look and feel.
 
 GTK{plus} is available for many different platforms including, but not limited to:
-Unix/Linux, macOS and Win32. It's the foundation of the famous GNOME desktop,
+Unix/Linux, macOS and Win32. It’s the foundation of the famous GNOME desktop,
 so the future development of GTK should be certain. GTK is implemented in plain
 C (as is Wireshark itself), and available under the LGPL (Lesser General Public
 License), making it free to used by commercial and noncommercial applications.
 
 There are other similar toolkits like wxWidgets which could also be used for
-Wireshark. There's no "one and only" reason for or against any of these
+Wireshark. There’s no "one and only" reason for or against any of these
 toolkits. However, the decision towards GTK was made a long time ago :-)
 
 There are two major GTK versions available:
@@ -353,7 +353,7 @@ Several mailing lists are available about GTK development, see
 http://mail.gnome.org/mailman/listinfo[], the gtk-app-devel-list may be your
 friend.
 
-As it's often done wrong: You should post a mail to *help* the developers
+As it’s often done wrong: You should post a mail to *help* the developers
 there instead of only complaining. Posting such a thing like "I don't like
 your dialog, it looks ugly" won't be of much help. You might think about
 what you dislike and describe why you dislike it and provide a suggestion
diff --git a/docbook/wsdg_src/WSDG_chapter_works.asciidoc b/docbook/wsdg_src/WSDG_chapter_works.asciidoc
index 07adfec2bd..6ba6c53e15 100644
--- a/docbook/wsdg_src/WSDG_chapter_works.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_works.asciidoc
@@ -16,7 +16,7 @@ This chapter will give you a short overview of how Wireshark works.
 
 === Overview
 
-The following will give you a simplified overview of Wireshark's function blocks:
+The following will give you a simplified overview of Wireshark’s function blocks:
 
 [[ChWorksFigOverview]]
 
@@ -58,8 +58,8 @@ with elevated privileges. Source code is in the root directory.
 
 WinPcap and libpcap:: These are separate libraries that provide packet capture
 and filtering support on different platforms. The filtering WinPcap and libpcap
-works at a much lower level than Wireshark's display filters and uses a
-significantly different mechanism. That's why we have different display and
+works at a much lower level than Wireshark’s display filters and uses a
+significantly different mechanism. That’s why we have different display and
 capture filter syntaxes.
 
 
@@ -71,7 +71,7 @@ Capturing takes packets from a network adapter and saves them to a file
 on your hard disk.
 
 Since raw network adapter access requires elevated privileges these functions
-are isolated into the `dumpcap` program. It's only this program that needs these
+are isolated into the `dumpcap` program. It’s only this program that needs these
 privileges, allowing the main part of the code (dissectors, user interface,
 etc) to run with normal user privileges.
 
diff --git a/docbook/wsdg_src/WSDG_preface.asciidoc b/docbook/wsdg_src/WSDG_preface.asciidoc
index c3f62c4b67..92cd596e05 100644
--- a/docbook/wsdg_src/WSDG_preface.asciidoc
+++ b/docbook/wsdg_src/WSDG_preface.asciidoc
@@ -32,7 +32,7 @@ Wireshark.
 
 This book is not intended to explain the usage of Wireshark in general.
 Please refer the
-{wireshark-users-guide-url}[Wireshark User's Guide] about Wireshark usage.
+{wireshark-users-guide-url}[Wireshark User’s Guide] about Wireshark usage.
 
 By reading this book, you will learn how to develop Wireshark. It will
 hopefully guide you around some common problems that frequently appear for