Docs: Make our AsciiDoc markup more compatible with AsciiDoctor.
authorGerald Combs <gerald@wireshark.org>
Sun, 4 Feb 2018 19:39:56 +0000 (11:39 -0800)
committerGerald Combs <gerald@wireshark.org>
Sun, 4 Feb 2018 22:46:20 +0000 (22:46 +0000)
Start using markup that is preferred by Asciidoctor but compatible with
both generators.

Add a missing "cpp" attribute and set a couple of Asciidoctor-specific
compatibility attributes.

Change-Id: Iff4c31362e4493b97a85f46db2c39b18c336536f
Reviewed-on: https://code.wireshark.org/review/25600
Reviewed-by: Gerald Combs <gerald@wireshark.org>
24 files changed:
docbook/asciidoctor-asciidoc.conf
docbook/attributes.asciidoc
docbook/common_src/typographic_conventions.asciidoc
docbook/developer-guide.asciidoc
docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc
docbook/wsdg_src/WSDG_chapter_capture.asciidoc
docbook/wsdg_src/WSDG_chapter_dissection.asciidoc
docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc
docbook/wsdg_src/WSDG_chapter_libraries.asciidoc
docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc
docbook/wsdg_src/WSDG_chapter_sources.asciidoc
docbook/wsdg_src/WSDG_chapter_tools.asciidoc
docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc
docbook/wsdg_src/WSDG_chapter_works.asciidoc
docbook/wsluarm.asciidoc
docbook/wsug_src/WSUG_app_files.asciidoc
docbook/wsug_src/WSUG_app_howitworks.asciidoc
docbook/wsug_src/WSUG_app_tools.asciidoc
docbook/wsug_src/WSUG_chapter_build_install.asciidoc
docbook/wsug_src/WSUG_chapter_customize.asciidoc
docbook/wsug_src/WSUG_chapter_introduction.asciidoc
docbook/wsug_src/WSUG_chapter_io.asciidoc
docbook/wsug_src/WSUG_chapter_use.asciidoc
docbook/wsug_src/WSUG_chapter_work.asciidoc

index 95140e1985e9ddec232335521ea61cc7772154e0..5d6c754c01bd8fee68ac463f4b0931feb0de5f14 100644 (file)
@@ -22,6 +22,7 @@ caret=^
 plus=&#43;
 space=" "
 tilde=~
+cpp=C++
 user-home={eval:os.path.expanduser('~')}
 vbar=|
 # NOTE use -a no-inline-literal to set compat-mode to default when using AsciiDoc Python
index 5bd2862edc6257f1b295da6a65314cd762b3a784..f0b2cbcf45b344b60bad8095b30e5980fc0dc21b 100644 (file)
@@ -1,6 +1,10 @@
 // Common attributes
 
 :wireshark-version: 2.5.0
+// We're migrating from AsciiDoc.
+:compat-mode:
+// Required for btn, kbd:, and menu: macros.
+:experimental:
 
 //
 // URLs
index 90078b94f92b330dd986a8b9ff3f81fdd4f825ef..5b568f25c285d59ed560959525910d869ad6c3db 100644 (file)
@@ -6,11 +6,18 @@ The following table shows the typographic conventions that are used in this guid
 
 // https://github.com/oreillymedia/orm_book_samples/blob/master/asciidoc_only/preface.asciidoc
 
+// AsciiDoc allows alternative markup for some styles, specifially
+// 'single quotes' and _underlines_ for italics and +plus signs+ and
+// `backticks` for monospaces.
+// Asciidoctor's modern mode is more strict, and only allows _underline_
+// italics and `backtick` monospaces.
+// http://asciidoctor.org/docs/migration/
+
 .Typographic Conventions
 [options="header",cols="1,3,3"]
 |===============
 |Style|Description|Example
-|'Italic'             |File names, folder names, and extensions |'C:\Development\wireshark'.
+|_Italic_             |File names, folder names, and extensions |_C:\Development\wireshark_.
 |`Monospace`          |Commands, flags, and environment variables|CMake's `-G` option.
 |**`Bold Monospace`** |Commands that should be run by the user|Run **`cmake -G Ninja ..`**.
 |btn:[Button]         |Dialog and window buttons |Press btn:[Launch] to go to the Moon.
index e80439480352b9d44d74cd290316f14edccf6be2..78fe7c4928a8cb428eea9a7e94d872d369ad4b56 100644 (file)
@@ -3,6 +3,11 @@
 :doctype: book
 include::attributes.asciidoc[]
 
+// Convenience attribute.
+// XXX This should be surrounded by single quotes in the text. It's
+// currently surrounded by plus signs for AsciiDoc compatibility.
+:dlt-glob: DLT_*
+
 [[Preface]]
 ["preface",id="Preface"]
 == Preface
index 96437463617854880a98c157c278025fa1fb7b92..8162d6cbb9248e60ec8c79383dab140ac9a38d3d 100644 (file)
 
 Wireshark consists of the following major parts:
 
-* Packet dissection - in the '/epan/dissector' and '/plugin/*' directories
+* Packet dissection - in the _/epan/dissector_ and _/plugin/\*_ directories
 
 * File I/O - using Wireshark's own wiretap library
 
-* Capture - using the libpcap/winpcap library, in '/wiretap'
+* Capture - using the libpcap/winpcap library, in _/wiretap_
 
 * User interface - using the Qt or $$GTK+$$ and associated libraries
 
@@ -29,7 +29,7 @@ Wireshark consists of the following major parts:
 === Coding Style
 
 The coding style guides for Wireshark can be found in the "Code style"
-section of the file 'doc/README.developer'.
+section of the file _doc/README.developer_.
 
 [[ChCodeGLib]]
 
index a6cd4dc93071a1f7a382404f941516f1ea2fd90d..ccae1815dada421ea9dab6c47fd9f5ef923f315b 100644 (file)
@@ -1,7 +1,7 @@
 ++++++++++++++++++++++++++++++++++++++
 <!-- WSDG Chapter Capture -->
 ++++++++++++++++++++++++++++++++++++++
-    
+
 [[ChapterCapture]]
 
 == Packet capturing
@@ -17,12 +17,12 @@ 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_*$$+ values
+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_*$$+ value, unless the
+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
-+$$DLT_*$$+ values.
++{dlt-glob}+ values.
 
 For the rest of the libpcap discussion, I'll assume you're working with libpcap
 1.0 or later and that this is on a UN*X platform. You probably don't want to
@@ -30,45 +30,45 @@ 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.
 
-See, for example, the +#ifdef HAVE_DAG_API+ code in 'pcap-linux.c' and
-'pcap-bpf.c'.
+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+,
-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_*$$+ values, and set the +selectable_fd+ member to
-the same value as the +fd+ member. It should also set the +dlt_count+ member to
-the number of +$$DLT_*$$+ 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_*$$+ values.
+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
+the same value as the `fd` member. It should also set the `dlt_count` member to
+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+
+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
+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
-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+.
+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_*$$+ 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_*$$+ 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
+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
 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
-+dissector_add_uint()+.
+protocols and have them register themselves with the `wtap_encap` dissector
+table, with the appropriate _WTAP_ENCAP_ values by calling
+`dissector_add_uint()`.
 
 ++++++++++++++++++++++++++++++++++++
 <!-- End of WSDG Chapter Capture -->
-++++++++++++++++++++++++++++++++++++
\ No newline at end of file
+++++++++++++++++++++++++++++++++++++
index 0070bbc59b0d156472e24b23ebe98bc71d1e1c81..6ecf36a95b17800559ad8e40a4053d3272c2bb3e 100644 (file)
@@ -36,7 +36,7 @@ the finished code may make more sense as a built-in dissector.
 [NOTE]
 .Read README.dissector
 ====
-The file 'doc/README.dissector' contains detailed information about implementing
+The file _doc/README.dissector_ contains detailed information about implementing
 a dissector. In many cases it is more up to date than this document.
 ====
 
@@ -93,18 +93,18 @@ proto_register_foo(void)
 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.
+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
 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.
 
-Then a +#define+ for the UDP port that carries _foo_ traffic.
+Then a `#define` for the UDP port that carries _foo_ traffic.
 
 Now that we have the basics in place to interact with the main program, we'll
 start with two protocol dissector setup functions.
 
-First we'll call +proto_register_protocol()+ which registers the protocol. We
+First we'll call `proto_register_protocol()` which registers the protocol. 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
@@ -132,8 +132,8 @@ 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
 traffic on that port.
 
-The standard Wireshark dissector convention is to put +proto_register_foo()+ and
-+proto_reg_handoff_foo()+ as the last two functions in the dissector source.
+The standard Wireshark dissector convention is to put `proto_register_foo()` and
+`proto_reg_handoff_foo()` as the last two functions in the dissector source.
 
 Now at last we get to write some dissecting code. For the moment we'll
 leave it as a basic placeholder.
@@ -168,19 +168,19 @@ At this point we should have a basic dissector ready to compile and install.
 It doesn't do much at present, other than identify the protocol and label it.
 
 In order to compile this dissector and create a plugin a couple of support files
-are required, besides the dissector source in 'packet-foo.c':
+are required, besides the dissector source in _packet-foo.c_:
 
-* 'Makefile.am' - The UNIX/Linux makefile template.
+* _Makefile.am_ - The UNIX/Linux makefile template.
 
-* 'CMakeLists.txt' - Contains the CMake file and version info for this plugin.
+* _CMakeLists.txt_ - Contains the CMake file and version info for this plugin.
 
-* 'packet-foo.c' - Your dissector source.
+* _packet-foo.c_ - Your dissector source.
 
-* 'plugin.rc.in' - Contains the DLL resource template for Windows. (optional)
+* _plugin.rc.in_ - Contains the DLL resource template for Windows. (optional)
 
 You can find a good example for these files in the gryphon plugin directory.
-'Makefile.am' has to be modified to reflect the relevant files and dissector
-name. 'CMakeLists.txt' has to be modified with the correct
+_Makefile.am_ has to be modified to reflect the relevant files and dissector
+name. _CMakeLists.txt_ has to be modified with the correct
 plugin name and version info, along with the relevant files to compile.
 In the main top-level source directory, copy CMakeListsCustom.txt.example to
 CMakeListsCustom.txt and add the path of your plugin to the list in
@@ -226,7 +226,7 @@ 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
 this protocol does not encapsulate another.
-Therefore, we add the new tree node with +proto_tree_add_item()+,
+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
 tvb buffer as the data, and consume from 0 to the end (-1) of this data.
 ENC_NA ("not applicable") is specified as the "encoding" parameter.
@@ -236,11 +236,11 @@ 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
 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.
+some additions to the `proto_register_foo()` function shown previously.
 
 Two statically allocated arrays are added at the beginning of
-+proto_register_foo()+. The arrays are then registered after the call to
-+proto_register_protocol()+.
+`proto_register_foo()`. The arrays are then registered after the call to
+`proto_register_protocol()`.
 
 .Registering data structures.
 ====
@@ -274,7 +274,7 @@ proto_register_foo(void)
 ----
 ====
 
-The variables +hf_foo_pdu_type+ and +ett_foo+ also need to be declared somewhere near the top of the file.
+The variables `hf_foo_pdu_type` and `ett_foo` also need to be declared somewhere near the top of the file.
 
 .Dissector data structure globals.
 ====
@@ -300,34 +300,34 @@ Now the dissection is starting to look more interesting. We have picked apart
 our first bit of the protocol. One byte of data at the start of the packet
 that defines the packet type for foo protocol.
 
-The +proto_item_add_subtree()+ call has added a child node
+The `proto_item_add_subtree()` call has added a child node
 to the protocol tree which is where we will do our detail dissection.
-The expansion of this node is controlled by the +ett_foo+
+The expansion of this node is controlled by the `ett_foo`
 variable. This remembers if the node should be expanded or not as you move
 between packets. All subsequent dissection will be added to this tree,
 as you can see from the next call.
-A call to +proto_tree_add_item()+ in the foo_tree,
-this time using the +hf_foo_pdu_type+ to control the formatting
+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 (also called big endian), so that is why we use +ENC_BIG_ENDIAN+.
+in network order (also called big endian), so that is why we use `ENC_BIG_ENDIAN`.
 For a 1-byte quantity, there is no order issue, but it is good practice to
 make this the same as any multibyte fields that may be present, and as we will
 see in the next section, this particular protocol uses network order.
 
-If we look in detail at the +hf_foo_pdu_type+ declaration in
+If we look in detail at the `hf_foo_pdu_type` declaration in
 the static array we can see the details of the definition.
 
-* 'hf_foo_pdu_type' - The index for this node.
+* _hf_foo_pdu_type_ - The index for this node.
 
-* 'FOO PDU Type' - The label for this item.
+* _FOO PDU Type_ - The label for this item.
 
-* 'foo.type' - This is the filter string. It enables us to type constructs such
-as +foo.type=1+ into the filter box.
+* _foo.type_ - This is the filter string. It enables us to type constructs such
+as `foo.type=1` into the filter box.
 
-* 'FT_UINT8' - This specifies this item is an 8bit unsigned integer.
+* _FT_UINT8_ - This specifies this item is an 8bit unsigned integer.
 This tallies with our call above where we tell it to only look at one byte.
 
-* 'BASE_DEC' - For an integer type, this tells it to be printed as a decimal
+* _BASE_DEC_ - For an integer type, this tells it to be printed as a decimal
 number. It could be hexadecimal (BASE_HEX) or octal (BASE_OCT) if that made more sense.
 
 We'll ignore the rest of the structure for now.
@@ -425,7 +425,7 @@ static const value_string packettypenames[] = {
 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 the data, using the +VALS+ macro.
+these details to the appropriate part of the data, using the `VALS` macro.
 
 .Adding Names to the protocol.
 ====
@@ -498,7 +498,7 @@ proto_register_foo(void) {
 ====
 
 Some things to note here. For the flags, as each bit is a different flag, we use
-the type +FT_BOOLEAN+, as the flag is either on or off. Second, we include the flag
+the type `FT_BOOLEAN`, as the flag is either on or off. Second, we include the flag
 mask in the 7th field of the data, which allows the system to mask the relevant bit.
 We've also changed the 5th field to 8, to indicate that we are looking at an 8 bit
 quantity when the flags are extracted. Then finally we add the extra constructs
@@ -509,7 +509,7 @@ 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
 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
+`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 PDU it is - which is extremely helpful when looking at
 protocol traces. Second, we can also display this information in the dissection
@@ -543,7 +543,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
+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
 similarly we append this data to the base of our dissecting tree.
@@ -598,16 +598,16 @@ 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
-using +wmem_alloc()+ in pinfo->pool memory, and the packet is decompressed into
-it. The +tvb_get_ptr()+ function is useful to get a pointer to the raw data of
+using `wmem_alloc()` in pinfo->pool memory, and the packet is decompressed into
+it. The `tvb_get_ptr()` function is useful to get a pointer to the raw data of
 the packet from the offset onwards. In this case the decompression routine also
 needs to know the length, which is given by the
-+tvb_captured_length_remaining()+ function.
+`tvb_captured_length_remaining()` function.
 
 Next we build a new tvb buffer from this data, using the
-+tvb_new_child_real_data()+ call. This data is a child of our original data, so
+`tvb_new_child_real_data()` call. This data is a child of our original data, so
 calling this function also acknowledges that. No need to call
-+tvb_set_free_cb()+ as the pinfo->pool was used (the memory block will be
+`tvb_set_free_cb()` as the pinfo->pool was used (the memory block will be
 automatically freed when the pinfo pool lifetime expires). Finally we add this
 tvb as a new data source, so that the detailed display can show the
 decompressed bytes as well as the original.
@@ -616,7 +616,7 @@ 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
 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
+signaled, we use `tvb_new_subset_remaining()` to deliver us a new buffer based
 on the old one but starting at the current offset, and extending to the end.
 This makes dissecting the packet from this point on exactly the same regardless
 of compression.
@@ -634,7 +634,7 @@ arrived and then start the dissection.
 
 The following sections will guide you through two common cases. For a
 description of all possible functions, structures and parameters, see
-'epan/reassemble.h'.
+_epan/reassemble.h_.
 
 [[ChDissectReassembleUdp]]
 
@@ -694,10 +694,10 @@ 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
-+fragment_add_seq_check()+ do its work. We need to provide this with a certain
+`fragment_add_seq_check()` do its work. We need to provide this with a certain
 amount of parameters:
 
-* The +msg_reassembly_table+ table is for bookkeeping and is described later.
+* The `msg_reassembly_table` table is for bookkeeping and is described later.
 
 * The tvb buffer we are dissecting.
 
@@ -709,7 +709,7 @@ amount of parameters:
   fragments in flight, and this is used to key the relevant one to be used for
   reassembly.
 
-* Optional additional data for identifying the fragment. Can be set to +NULL+
+* Optional additional data for identifying the fragment. Can be set to `NULL`
   (as is done in the example) for most dissectors.
 
 * msg_num is the packet number within the sequence.
@@ -760,7 +760,7 @@ unless the fragments have been reassembled as there won't be much to find.
 Sometimes the first packet in the sequence can be partially decoded though if
 you wish.
 
-Now the mysterious data we passed into the +fragment_add_seq_check()+.
+Now the mysterious data we passed into the `fragment_add_seq_check()`.
 
 .Reassembling fragments - Initialisation
 ====
@@ -776,14 +776,14 @@ proto_register_msg(void)
 ----
 ====
 
-First a +reassembly_table+ structure is declared and initialised in the protocol
+First a `reassembly_table` structure is declared and initialised in the protocol
 initialisation routine. The second parameter specifies the functions that should
 be used for identifying fragments. We will use
-+addresses_ports_reassembly_table_functions+ in order to identify fragments by
-the given sequence number (+msg_seqid+), the source and destination addresses
+`addresses_ports_reassembly_table_functions` in order to identify fragments by
+the given sequence number (`msg_seqid`), the source and destination addresses
 and ports from the packet.
 
-Following that, a +fragment_items+ structure is allocated and filled in with a
+Following that, a `fragment_items` structure is allocated and filled in with a
 series of ett items, hf data items, and a string tag. The ett and hf values
 should be included in the relevant tables like all the other variables your
 protocol may use. The hf variables need to be placed in the structure something
@@ -883,7 +883,7 @@ from the reassembled one. The other variables are used for flagging up errors.
 
 ==== How to reassemble split TCP Packets
 
-A dissector gets a +tvbuff_t+ pointer which holds the payload
+A dissector gets a `tvbuff_t` pointer which holds the payload
 of a TCP packet. This payload contains the header and data
 of your application layer protocol.
 
@@ -897,8 +897,8 @@ More than one messages can be transmitted in one TCP packet,
 so that a message can start at an arbitrary position.
 
 This sounds complicated, but there is a simple solution.
-+tcp_dissect_pdus()+ does all this tcp packet reassembling for you.
-This function is implemented in 'epan/dissectors/packet-tcp.h'.
+`tcp_dissect_pdus()` does all this tcp packet reassembling for you.
+This function is implemented in _epan/dissectors/packet-tcp.h_.
 
 .Reassembling TCP fragments
 ====
@@ -942,12 +942,12 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data)
 ----
 ====
 
-As you can see this is really simple. Just call +tcp_dissect_pdus()+ in your
+As you can see this is really simple. Just call `tcp_dissect_pdus()` in your
 main dissection routine and move you message parsing code into another function.
 This function gets called whenever a message has been reassembled.
 
 The parameters tvb, pinfo, tree and data are just handed over to
-+tcp_dissect_pdus()+. The 4th parameter is a flag to indicate if the data should
+`tcp_dissect_pdus()`. The 4th parameter is a flag to indicate if the data should
 be reassembled or not. This could be set according to a dissector preference as
 well. Parameter 5 indicates how much data has at least to be available to be
 able to determine the length of the foo message. Parameter 6 is a function
@@ -973,7 +973,7 @@ then called on each dissection. Some arbitrary protocol specific data
 is provided with the routine that can be used.
 
 To create a tap, you first need to register a tap. A tap is registered with an
-integer handle, and registered with the routine +register_tap()+. This takes a
+integer handle, and registered with the routine `register_tap()`. This takes a
 string name with which to find it again.
 
 .Initialising a tap
@@ -1007,7 +1007,7 @@ 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
-specific structure and then calling +tap_queue_packet+, probably as the last part
+specific structure and then calling `tap_queue_packet`, probably as the last part
 of the dissector.
 
 .Calling a protocol tap
@@ -1063,17 +1063,17 @@ WS_DLL_PUBLIC_DEF void plugin_register_tap_listener(void)
 ====
 
 Working from the bottom up, first the plugin interface entry point is defined,
-+plugin_register_tap_listener()+. This simply calls the initialisation function
-+register_foo_stat_trees()+.
+`plugin_register_tap_listener()`. This simply calls the initialisation function
+`register_foo_stat_trees()`.
 
-This in turn calls the +stats_tree_register_plugin()+ function, which takes three
+This in turn calls the `stats_tree_register_plugin()` function, which takes three
 strings, an integer, and three callback functions.
 
 . This is the tap name that is registered.
 
 . 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
 
@@ -1121,8 +1121,8 @@ static int foo_stats_tree_packet(stats_tree* st, packet_info* pinfo, epan_dissec
 ====
 
 In this case the processing of the stats is quite simple. First we call the
-+tick_stat_node+ for the +st_str_packets+ packet node, to count packets. Then a
-call to +stats_tree_tick_pivot()+ on the +st_node_packet_types+ subtree allows
+`tick_stat_node` for the `st_str_packets` packet node, to count packets. Then a
+call to `stats_tree_tick_pivot()` on the `st_node_packet_types` subtree allows
 us to record statistics by packet type.
 
 [[ChDissectConversation]]
@@ -1130,7 +1130,7 @@ us to record statistics by packet type.
 === How to use conversations
 
 Some info about how to use conversations in a dissector can be found in the file
-'doc/README.dissector', chapter 2.2.
+_doc/README.dissector_, chapter 2.2.
 
 [[ChDissectIdl2wrs]]
 
@@ -1146,7 +1146,7 @@ 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
 dissector.
 
-+idl2wrs+ parses the data struct given to it by the `omniidl` compiler,
+`idl2wrs` parses the data struct given to it by the `omniidl` compiler,
 and using the GIOP API available in packet-giop.[ch], generates get_CDR_xxx
 calls to decode the CORBA traffic on the wire.
 
@@ -1183,9 +1183,9 @@ It is also COOL to work on a great Open Source project such as the case with
 
 To use the idl2wrs to generate Wireshark dissectors, you need the following:
 
-* Python must be installed.  See link:$$http://python.org/$$[]
+* Python must be installed.  See link:http://python.org/[]
 
-* +omniidl+ from the omniORB package must be available. See link:$$http://omniorb.sourceforge.net/$$[]
+* `omniidl` from the omniORB package must be available. See link:http://omniorb.sourceforge.net/[]
 
 * Of course you need Wireshark installed to compile the code and tweak it if
 required. idl2wrs is part of the standard Wireshark distribution
index 74b6ee060174dcab8bb7c6769b274e32870a96c4..1e76ae80a25852d81693b2091bcda030c850e048 100644 (file)
@@ -128,7 +128,7 @@ Wireshark mailing lists available.
 ==== Programming languages used
 
 Most of Wireshark is implemented in plain ANSI C. A notable exception is
-the code in 'ui/qt', which is written in $$C++$$.
+the code in _ui/qt_, which is written in {cpp}.
 
 The typical task for a new Wireshark developer is to extend an existing,
 or write a new dissector for a specific network protocol. As (almost) any
@@ -375,15 +375,15 @@ typically more up to date and the HTML format is easier to use.
 If you don't find the information you need inside this book, there are
 various other sources of information:
 
-* The file 'doc/README.developer' and all the other README.xxx files in the
+* The file _doc/README.developer_ and all the other README.xxx files in the
   source code. These are various documentation files on different topics
 
 [NOTE]
 .Read the README
 ====
-'README.developer' is packed full with all kinds of details relevant
+_README.developer_ is packed full with all kinds of details relevant
 to the developer of Wireshark source code. Its companion file
-'README.dissector' advises you around common
+_README.dissector_ advises you around common
 pitfalls, shows you basic layout of dissector code, shows details of the
 APIs available to the dissector developer, etc.
 ====
@@ -538,7 +538,7 @@ echoed. The ^D
 (Control-D, that is, press the Control key and the D key
 together) will cause `gdb` to exit. This will
 leave you with a file called
-'bt.txt' in the current directory.
+_bt.txt_ in the current directory.
 Include the file with your bug report.
 
 If you do not have `gdb` available, you
index dbfaa1c8333a30a7c3b0cff2ef9cc2a014d48529..0cc3d3987cf97c96e4eed33e072f0cfcab99f387 100644 (file)
 Several libraries are needed to build and run Wireshark. Most of them
 are split into three packages:
 
-. 'Runtime'. System and third party libraries such as 'MSVCR110.dll' and 'libglib-2.0-0.dll'.
+. _Runtime_. System and third party libraries such as _MSVCR110.dll_ and _libglib-2.0-0.dll_.
 
-. 'Developer'. Documentation, header files, import libraries, and other files needed for compilation.
+. _Developer_. Documentation, header files, import libraries, and other files needed for compilation.
 
-. 'Source'. Library sources, which are usually not required to
+. _Source_. Library sources, which are usually not required to
 build Wireshark.
 
 [TIP]
@@ -99,8 +99,8 @@ For more information on the Qt libraries, see <<ChUIQt>>.
 
 Most Linux distributions provide Qt and its development libraries as standard packages.
 The required libraries and tools will likely be split across several packages. For example,
-building on Ubuntu requires 'qttools5-dev', 'qttools5-dev-tools', 'libqt5svg5-dev,
-'qtmultimedia5-dev', and possibly others.
+building on Ubuntu requires _qttools5-dev_, _qttools5-dev-tools_, _libqt5svg5-dev_,
+_qtmultimedia5-dev_, and possibly others.
 
 The Qt Project provides an installation tool for macOS, similar to Windows.
 It is available at https://www.qt.io/download-open-source/#section-2[].
@@ -243,7 +243,7 @@ platform, you can get it at {tcpdump-main-url}.
 
 ==== Win32 MSVC: WinPcap
 
-You can get the "Windows packet capture library" at:
+You can get the ``Windows packet capture library'' at:
 https://www.winpcap.org/install/[]
 
 [[ChLibsGNUTLS]]
index 36cd714166641169d05f5638619d35c7a78e3eea..218785eb5ba6cc8f32b0ed080a15c2ae79d167c9 100644 (file)
@@ -65,7 +65,7 @@ You need to install, in exactly this order:
 
 . C compiler:
 https://go.microsoft.com/fwlink/?LinkId=532606&clcid=0x409[Download]
-and install "Microsoft Visual Studio 2015 Community Edition." This is a small
+and install ``Microsoft Visual Studio 2015 Community Edition.'' This is a small
 download that then downloads all the other required parts (which are quite large).
 
 Select the "Custom" install and then uncheck all the optional components other
@@ -120,9 +120,9 @@ Note that installation of separate Qt components are required for 32 bit
 and 64 bit builds, e.g. ``msvc2015 32-bit'' and ``msvc2015 64-bit''. The
 environment variable `QT5_BASE_DIR` should be set as appropriate for your
 environment and should point to the Qt directory that contains the bin
-directory, e.g. 'C:\Qt\5.9.1\msvc2015_64'
+directory, e.g. _C:\Qt\5.9.1\msvc2015_64_
 
-The Qt maintenance tool ('C:\Qt\MaintenanceTool.exe') can be used to
+The Qt maintenance tool (_C:\Qt\MaintenanceTool.exe_) can be used to
 upgrade Qt to newer versions.
 
 [[ChSetupCygwin]]
@@ -177,7 +177,7 @@ PS$>choco install cyg-get
 ----
 //PS$>choco install sed asciidoc [...] -source cygwin
 
-Chocolatey installs Cygwin in 'C:\tools\cygwin' by default.
+Chocolatey installs Cygwin in _C:\tools\cygwin_ by default.
 
 You can directly download packages via `cyg-get`
 
@@ -197,9 +197,9 @@ PS$>choco install winflexbison
 ==== Install Python
 
 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').
+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.
 
@@ -215,7 +215,7 @@ or
 PS$>choco install python2
 ----
 
-Chocolatey installs Python in 'C:\tools\python3' and 'C:\tools\python2' by default.
+Chocolatey installs Python in _C:\tools\python3_ and _C:\tools\python2_ by default.
 
 [[ChSetupGit]]
 
@@ -235,9 +235,9 @@ available at the URLs below or via https://chocolatey.org/[Chocolatey].
 Note that many of the GUI interfaces depend on the command line version.
 
 If installing the Windows version of git select the
-'Use Git from the Windows Command Prompt' (in chocolatey the '/GitOnlyOnPath'
-option).  Do *not* select the 'Use Git and optional Unix tools from the Windows Command Prompt'
-option (in chocolatey the '/GitAndUnixToolsOnPath' option).
+_Use Git from the Windows Command Prompt_ (in chocolatey the _/GitOnlyOnPath_
+option).  Do *not* select the _Use Git and optional Unix tools from the Windows Command Prompt_
+option (in chocolatey the _/GitAndUnixToolsOnPath_ option).
 
 ===== The Official Windows Installer
 
@@ -296,7 +296,7 @@ Git Extensions but any other Git client should work as well.
 // XXX -
 
 *Download sources* Download Wireshark sources into
-'C:\Development\wireshark' using either the command line or Git Extensions:
+_C:\Development\wireshark_ using either the command line or Git Extensions:
 
 Using the command line:
 
@@ -316,9 +316,9 @@ Using Git extensions:
 +
 Repository to clone: *`https://code.wireshark.org/review/wireshark`*
 +
-Destination: Your top-level development directory, e.g. 'C:\Development'.
+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
@@ -478,7 +478,7 @@ to build Wireshark.
 version, e.g.: Version {wireshark-version}-myprotocol123
 congratulations! You have compiled your own version of Wireshark!
 
-You may also open the Wireshark solution file ('Wireshark.sln') in the Visual Studio IDE and build there.
+You may also open the Wireshark solution file (_Wireshark.sln_) in the Visual Studio IDE and build there.
 
 TIP: If compilation fails for suspicious reasons after you changed some source
 files try to clean the build files by running *`msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln /t:Clean`*
@@ -494,7 +494,7 @@ on using the <<ChToolsDebugger, Debugger Tools>>.
 ==== 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.
+_docbook\README.txt_ in the Wireshark sources.
 
 ==== Optional: Create a Wireshark Installer
 
@@ -502,7 +502,7 @@ Note: You should have successfully built Wireshark
 before doing the following.
 
 If you want to build your own
-'Wireshark-win32-{wireshark-version}-myprotocol123.exe',
+_Wireshark-win32-{wireshark-version}-myprotocol123.exe_,
 you'll need NSIS.
 
 . NSIS:
@@ -512,13 +512,13 @@ Note that the 32-bit version of NSIS will work for both 32-bit and
 64-bit versions of Wireshark. NSIS v3 is recommended and may be required
 in the future.
 
-Note: If you do not yet have a copy of vcredist_x86.exe or vcredist_x64.exe in './wireshark-win**XX**-libs' (where *'XX'* is 32 or 64) you will need to download the appropriate file and place it in './wireshark-win**XX**-libs' before starting this step.
+Note: If you do not yet have a copy of vcredist_x86.exe or vcredist_x64.exe in _./wireshark-win**XX**-libs_ (where *_XX_* is 32 or 64) you will need to download the appropriate file and place it in _./wireshark-win**XX**-libs_ before starting this step.
 
-If building an x86 version using a Visual Studio "Express" edition or an x64 version with any edition, then you must have the appropriate vcredist file for your compiler in the support libraries directory ('vcredist_x86.exe' in 'wireshark-32-libs' or 'vcredist_x64.exe' in 'wireshark-win64-libs').
+If building an x86 version using a Visual Studio "Express" edition or an x64 version with any edition, then you must have the appropriate vcredist file for your compiler in the support libraries directory (_vcredist_x86.exe_ in _wireshark-32-libs_ or _vcredist_x64.exe_ in _wireshark-win64-libs_).
 
 The files can be located in the Visual Studio install directory for non-Express edition builds, or downloaded from Microsoft for Expresss edition builds.
 
-Note you must use the correct version of vcredist for your compiler, unfortunately they all have the same name ('vcredist_x86.exe' or 'vcredist_x64.exe').  You can use Windows Explorer and examine the `Properties -> Details' tab for a vcredist file to determine which compiler version the file is for use with.
+Note you must use the correct version of vcredist for your compiler, unfortunately they all have the same name (_vcredist_x86.exe_ or _vcredist_x64.exe_).  You can use Windows Explorer and examine the `Properties -> Details' tab for a vcredist file to determine which compiler version the file is for use with.
 
 . If you've closed the Visual Studio Command Prompt <<ChSetupPrepareCommandCom,prepare>> it again.
 
index 2177c445ed54c09d51c31e7390dfaacf842314de..01b2a5977833cb1011b5b2ddc50fc3c0f1d20df6 100644 (file)
@@ -84,8 +84,8 @@ http://en.wikipedia.org/wiki/Branching_%28revision_control%29[branching] to
 manage different copies of the source code and allow parallel development.
 Wireshark uses the following branches for official releases:
 
-* 'master': Main feature development and odd-numbered "feature" releases.
-* 'master-x.y': Stable release maintenance. For example, master-1.10 is used
+* _master_: Main feature development and odd-numbered "feature" releases.
+* _master-x.y_: Stable release maintenance. For example, master-1.10 is used
   to manage the 1.10.x official releases.
 
 [[ChSrcObtain]]
@@ -155,7 +155,7 @@ select _Settings_.
 
 . Under _Profile_ set a username. This will be the username that
 you use for SSH access. For the steps below we'll assume that your
-username is +henry.perry+.
+username is `henry.perry`.
 
 . Select _SSH Public Keys_ and add one or more keys. You will typically
 upload a key for each computer that you use.
@@ -361,7 +361,7 @@ error-prone than using Git.
 
 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
+to look at is _doc/README.developer_. Inside you will find the latest
 information for Wireshark development for all supported platforms.
 
 .Build Wireshark before changing anything
@@ -731,15 +731,15 @@ 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>>.
 
-* 'Update your sources just before making a patch.' For the same reasons as the
+* _Update your sources just before making a patch._ For the same reasons as the
   previous point.
 
-* 'Inspect your patch carefully.' Run `git diff` and make sure you aren't
+* _Inspect your patch carefully._ Run `git diff` and make sure you aren't
   adding, removing, or omitting anything you shouldn't.
 
 // * 'Do a "make clean" before generating the patch.' This removes a lot of
@@ -748,11 +748,11 @@ Some tips that will make the merging of your changes into Git much more likely
 //   the patch again.
 
 // XXX - What *are* good topic names?
-* 'Find a good descriptive topic name for your patch.' Short, specific
-  names are preferred. 'snowcone-machine-protocol' is good, your name or
+* _Find a good descriptive topic name for your patch._ Short, specific
+  names are preferred. _snowcone-machine-protocol_ is good, your name or
   your company name isn't.
 
-* 'Don't put unrelated things into one large patch.' A few smaller patches are
+* _Don't put unrelated things into one large patch._ A few smaller patches are
   usually easier to apply (but also don't put every changed line into a separate
   patch.
 
@@ -785,13 +785,13 @@ Ignoring the code requirements will make it very likely that your patch will
 be rejected.
 ====
 
-* 'Follow the Wireshark source code style guide.' Just because something
+* _Follow the Wireshark source code style guide._ Just because something
   compiles on your platform, that doesn't mean it'll compile on all of the other
   platforms for which Wireshark is built. Wireshark runs on many platforms, and
   can be compiled with a number of different compilers. See <<ChCodeStyle>>for
   details.
 
-* 'Submit dissectors as built-in whenever possible.' Developing a new dissector
+* _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
 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
@@ -802,7 +802,7 @@ can easily be put into "the big pile", while some are ASN.1 based which takes a
 different approach, and some multiple source file dissectors are more suitable to
 be placed separately as plugins.
 
-* 'Ensure Wireshark Git Pre-Commit Hook is in the repository.'  In your local
+* _Ensure Wireshark Git Pre-Commit Hook is in the repository._  In your local
 repository directory, there will be a .git/hooks/ directory, with sample git hooks
 for running automatic actions before and after git commands. You can also
 optionally install other hooks that you find useful.
@@ -823,7 +823,7 @@ change, you can run git commit --no-verify to skip running the hooks. Warning: u
 Change-ID to your commit. In case you are not updating an existing patch you may generate
 a Change-ID by running git review -i (or git commit --amend if don't use git review).
 
-* 'Fuzz test your changes!' Fuzz testing is a very
+* _Fuzz test your changes!_ Fuzz testing is a very
 effective way to automatically find a lot of dissector related bugs.
 You'll take a capture file containing packets affecting your dissector
 and the fuzz test will randomly change bytes in this file, so that unusual
@@ -943,11 +943,11 @@ of the patch and your source files match.
 
 ==== Using patch
 
-Given the file 'new.diff' containing a unified diff,
+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.
+_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
@@ -955,24 +955,24 @@ $ patch -p0 < new.diff
 
 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.orig/prefs.c_ and
+_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`.
+If they're relative to a _subdirectory_ of the top-level
+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
-have a patch file with patches to 'Makefile.am' and
-'wiretap/Makefile.am',
+have a patch file with patches to _Makefile.am_ and
+_wiretap/Makefile.am_,
 it'll try to apply the first patch to the top-level
-'Makefile.am' and then apply the
-'wiretap/Makefile.am' patch to the top-level
-'Makefile.am' as well.
+_Makefile.am_ and then apply the
+_wiretap/Makefile.am_ patch to the top-level
+_Makefile.am_ as well.
 
 At which position in the filesystem should the patch tool be called?
 
@@ -981,11 +981,11 @@ 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.
+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.
 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'.
+directories such as _Makefile.am_.
 
 [[ChSrcBinary]]
 
@@ -1073,7 +1073,7 @@ installing the _qt-devel_ package.
 ==== macOS: .dmg packages
 
 The macOS Package is built using macOS packaging tools, based on information
-found in the source tree under 'packaging/macosx'. It must be built using
+found in the source tree under _packaging/macosx_. It must be built using
 CMake. In your build directory, type:
 
 ----
@@ -1089,10 +1089,10 @@ to build the macOS Package.
 The _Nullsoft Install System_ is a free installer generator for Windows
 systems. Instructions on installing it can be found in <<ChToolsNSIS>>.
 NSIS is script based. You can find the main Wireshark installer
-generation script at 'packaging/nsis/wireshark.nsi'.
+generation script at _packaging/nsis/wireshark.nsi_.
 
-When building with CMake you must first build the 'nsis_package_prep' target,
-followed by the 'nsis_package' target, e.g.
+When building with CMake you must first build the _nsis_package_prep_ target,
+followed by the _nsis_package_ target, e.g.
 
 ----
 > msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj
@@ -1109,8 +1109,8 @@ It might take some time, even on fast machines.
 ====
 
 If everything went well, you will now find something like:
-'wireshark-setup-{wireshark-version}.exe' in
-the 'packaging/nsis' directory in the source tree.
+_wireshark-setup-{wireshark-version}.exe_ in
+the _packaging/nsis_ directory in the source tree.
 
 [[ChSrcPortableApps]]
 
@@ -1119,7 +1119,7 @@ the 'packaging/nsis' directory in the source tree.
 _PortableApps.com_ is an environment that lets users run popular applications
 from portable media such as flash drives and cloud drive services.
 
-Install the 'PortableApps.com Platform'. Install for ``all users``, which
+Install the _PortableApps.com Platform_. Install for ``all users'', which
 will place it in `C:\PortableApps`. Add the following apps:
 
 - NSIS Portable (Unicode)
@@ -1127,9 +1127,9 @@ will place it in `C:\PortableApps`. Add the following apps:
 - PortableApps.com Launcher
 - PortableApps.com AppCompactor
 
-When building with CMake you must first build the 'nsis_package_prep' target
+When building with CMake you must first build the _nsis_package_prep_ target
 (which takes care of general packaging dependencies), followed by the
-'portableapps_package' target, e.g.
+_portableapps_package_ target, e.g.
 
 ----
 > msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj
@@ -1144,8 +1144,8 @@ It might take some time, even on fast machines.
 ====
 
 If everything went well, you will now find something like:
-'WiresharkPortable_{wireshark-version}.paf.exe' in
-the 'packaging/portableapps' directory.
+_WiresharkPortable_{wireshark-version}.paf.exe_ in
+the _packaging/portableapps_ directory.
 
 ++++++++++++++++++++++++++++++++++++++
 <!-- End of WSDG Chapter Sources -->
index 211d896e442eb83493aba9f62f95b067fd3ee53f..906359205fd38d771212bcfbb23dfd1560a2aa4f 100644 (file)
@@ -55,18 +55,18 @@ many of the packages required for Wireshark development. Chocolatey can be
 obtained from the http://chocolatey.org[website] or from a Command Prompt:
 
 ----
-C:\>@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
+C:\>@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString(_https://chocolatey.org/install.ps1_))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
 ----
 
 or a Powershell prompt:
 
 ----
-PS:\>iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))
+PS:\>iex ((new-object net.webclient).DownloadString(_https://chocolatey.org/install.ps1_))
 ----
 
 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
-('C:\cygwin' or 'C:\cygwin64').
+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]]
 
@@ -75,29 +75,29 @@ example -- recent versions of the Cygwin package are installed in 'C:\ProgramDat
 Cygwin provides a lot of UNIX based tools on the Windows platform. It uses a UNIX
 emulation layer which might be a bit slower compared to the native Windows tools,
 but at an acceptable level. The installation and update is pretty easy and done
-through a single utility, 'setup-x86.exe' for 32-bit Windows and
-'setup-x86_64.exe' for 64-bit Windows.
+through a single utility, _setup-x86.exe_ for 32-bit Windows and
+_setup-x86_64.exe_ for 64-bit Windows.
 
 Over time the Wireshark development toolchain has been migrating away from Cygwin
 toward native tools and we hope to eliminate it as a requirement someday.
 
 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.
+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
 in the previous section.
 
 ==== Installing Cygwin using the Cygwin installer
 
-You will find 'setup-x86.exe', for 32-bit systems, and
-'setup-x86_64.exe', for 64-bit systems, at
+You will find _setup-x86.exe_, for 32-bit systems, and
+_setup-x86_64.exe_, for 64-bit systems, at
 http://www.cygwin.com/install.html[]. Click on the link for the
 appropriate setup utility to download it. After the download completes,
 run it.
 
 All tools will be installed into one base folder. The default is
-'C:\cygwin' for the 32-bit installer and 'C:\cygwin64' for the 64-bit
+_C:\cygwin_ for the 32-bit installer and _C:\cygwin64_ for the 64-bit
 installer.
 
 The setup utility will ask you for some settings. The defaults
@@ -134,15 +134,15 @@ number will be displayed, so it will be automatically updated.  You can
 change the current setting by simply clicking at it, it will change
 between:
 
-* 'A specific version number.' This specific package version will be installed.
+* _A specific version number._ This specific package version will be installed.
 
-* 'Skip.' Not installed, no changes.
+* _Skip._ Not installed, no changes.
 
-* 'Keep.' Already installed, no changes.
+* _Keep._ Already installed, no changes.
 
-* 'Uninstall.' Uninstall this package.
+* _Uninstall._ Uninstall this package.
 
-* 'Reinstall.' Reinstall this package.
+* _Reinstall._ Reinstall this package.
 
 ==== Installing Cygwin using Chocolatey
 
@@ -155,7 +155,7 @@ PS$>choco install cygwin
 PS$>choco install cyg-get
 ----
 
-Chocolatey installs Cygwin in 'C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin' by default.
+Chocolatey installs Cygwin in _C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin_ by default.
 
 One or more Cygwin packages can be installed using `cyg-get`:
 
@@ -208,7 +208,7 @@ In particular, the macOS and Windows packages are built using CMake.
 
 Building with CMake typically includes creating a build directory and
 specifying a *generator*, aka a build tool. For example, to build
-Wireshark using Ninja in the directory 'wireshark-ninja' you might
+Wireshark using Ninja in the directory _wireshark-ninja_ you might
 run the following commands:
 
 ----
@@ -235,7 +235,7 @@ using the `-D` flag. Useful variables and generators include the following:
 
 -DENABLE_HTML_GUIDES=ON -DENABLE_PDF_GUIDES=ON:: Build documentation
 
--DCMAKE_C_FLAGS='-Qunused-arguments':: Make ccache and clang work together
++++-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.
 
@@ -364,52 +364,52 @@ Your version string may vary, of course.
 
 === Microsoft compiler toolchain (Windows native)
 
-To compile Wireshark on Windows using the Microsoft C/$$C++$$
+To compile Wireshark on Windows using the Microsoft C/{cpp}
 compiler, you'll need:
 
-. C compiler ('cl.exe')
+. C compiler (_cl.exe_)
 
-. Assembler ('ml.exe' for 32-bit targets and 'ml64.exe' for 64-bit targets)
+. Assembler (_ml.exe_ for 32-bit targets and _ml64.exe_ for 64-bit targets)
 
-. Linker ('link.exe')
+. Linker (_link.exe_)
 
-. Resource Compiler ('rc.exe')
+. Resource Compiler (_rc.exe_)
 
-. C runtime headers and libraries (e.g. 'stdio.h', 'msvcrt.lib')
+. C runtime headers and libraries (e.g. _stdio.h_, _msvcrt.lib_)
 
 . Windows platform headers and libraries (e.g.
-'windows.h', 'WSock32.lib')
+_windows.h_, _WSock32.lib_)
 +
 // Can we drop support for CHM?
-. HTML help headers and libraries ('htmlhelp.h', 'htmlhelp.lib')
+. HTML help headers and libraries (_htmlhelp.h_, _htmlhelp.lib_)
 
 ==== Official Toolchain Packages And Alternatives
 
-The official Wireshark 2.4.x releases are compiled using Microsoft Visual $$C++$$ 2015.
-The Wireshark 2.2.x and 2.0.x releases are compiled using Microsoft Visual $$C++$$ 2013.
+The official Wireshark 2.4.x releases are compiled using Microsoft Visual {cpp} 2015.
+The Wireshark 2.2.x and 2.0.x releases are compiled using Microsoft Visual {cpp} 2013.
 The Wireshark 1.12.x and 1.10.x releases were compiled using
-Microsoft Visual $$C++$$ 2010 SP1.
+Microsoft Visual {cpp} 2010 SP1.
 The 1.8 releases were compiled using
-Microsoft Visual $$C++$$ 2010 SP1 as well.
+Microsoft Visual {cpp} 2010 SP1 as well.
 The 1.6, 1.4, and 1.2 releases were compiled using
-Microsoft Visual $$C++$$ 2008 SP1.
+Microsoft Visual {cpp} 2008 SP1.
 Other past releases, including the 1.0 branch,
-were compiled using Microsoft Visual $$C++$$ 6.0.
+were compiled using Microsoft Visual {cpp} 6.0.
 
 Using the release compilers is recommended for Wireshark development work.
 
 The older "Express
-Edition" compilers such as Visual $$C++$$ 2010 Express Edition SP1 can be
+Edition" compilers such as Visual {cpp} 2010 Express Edition SP1 can be
 used but any PortableApps packages you create with them
-will require the installation of a separate Visual $$C++$$
+will require the installation of a separate Visual {cpp}
 Redistributable package on any machine on which the PortableApps
 package is to be used. See
 <<msvc-runtime-redistributable>> below for more details.
 
-However, you might already have a different Microsoft $$C++$$ compiler
+However, you might already have a different Microsoft {cpp} compiler
 installed. It should be possible to use any of the following with the considerations listed:
 
-.Visual $$C++$$ 2013 Community Edition
+.Visual {cpp} 2013 Community Edition
 
 IDE + Debugger?:: Yes
 
@@ -419,7 +419,7 @@ SDK required for 64-bit builds?:: No
 
 CMake Generator: *`Visual Studio 12`*
 
-.Visual $$C++$$ 2010 Express Edition
+.Visual {cpp} 2010 Express Edition
 
 IDE + Debugger?:: Yes
 
@@ -429,13 +429,13 @@ SDK required for 64-bit builds?:: Yes.
 
 CMake Generator: *`Visual Studio 10`*
 
-Remarks:: Installers created using express editions require a $$C++$$ redistributable
-'$$vcredist_x86.exe$$' (3MB free
+Remarks:: Installers created using express editions require a {cpp} redistributable
+_vcredist_x86.exe_ (3MB free
 download) is required to build
 Wireshark-win32-{wireshark-version}.exe, and
-'$$vcredist_x64.exe$$' is required to build
+_vcredist_x64.exe_ is required to build
 Wireshark-win64-{wireshark-version}.exe. The version of
-'$$vcredist_x86.exe$$' or '$$vcredist_x64.exe$$' _must_ match the version for your
+_vcredist_x86.exe_ or _vcredist_x64.exe_ _must_ match the version for your
 compiler including any service packs installed for the compiler.]
 
 .Visual Studio 2010
@@ -449,8 +449,8 @@ SDK required for 64-bit builds?:: No
 CMake Generator: *`Visual Studio 10`*
 
 Remarks:: Building a 64-bit installer
-requires a a $$C++$$ redistributable
-('$$vcredist_x86.exe$$').footnoteref[vcredist]
+requires a a {cpp} redistributable
+(_vcredist_x86.exe_).footnoteref[vcredist]
 
 You can use Chocolatey to install Visual Studio, e.g:
 
@@ -482,7 +482,7 @@ at the Visual Studio Command line prompt (cmd.exe):
 should result in something like:
 
 ----
-Microsoft (R) C/$$C++$$ Optimizing Compiler Version 18.00.31101 for x86
+Microsoft (R) C/{cpp} Optimizing Compiler Version 18.00.31101 for x86
 Copyright (C) Microsoft Corporation.  All rights reserved.
 
 usage: cl [ option... ] filename... [ /link linkoption...
@@ -531,12 +531,12 @@ they are available - but they might not be available on a user machine!
 
 This is especially true for the C runtime DLL (msvcr*.dll), which contains the
 implementation of ANSI and alike functions, e.g.: fopen(), malloc(). The DLL is
-named like: msvcr'version'.dll, an abbreviation for "MicroSoft Visual C
+named like: _msvcr**version**.dll_, an abbreviation for "Microsoft Visual C
 Runtime". For Wireshark to work, this DLL must be available on the users
 machine.
 
 Starting with MSVC7, it is necessary to ship the C runtime DLL
-(msvcr'version'.dll) together with the application installer somehow, as that
+(_msvcr**version**.dll_) together with the application installer somehow, as that
 DLL is possibly not available on the target system.
 
 
@@ -554,7 +554,7 @@ interested reader:
 
 * http://msdn.microsoft.com/en-us/library/ms235299.aspx[Redistributing Visual C++ Files]
 
-In all cases where '$$vcredist_x86.exe$$' or '$$vcredist_x64.exe$$' is
+In all cases where _vcredist_x86.exe_ or _vcredist_x64.exe_ is
 downloaded it should be downloaded to the directory into which the support
 libraries for Wireshark have been downloaded and installed. This directory is
 specified by the WIRESHARK_BASE_DIR or WIRESHARK_LIB_DIR environment variables.
@@ -566,42 +566,42 @@ There are three redistribution methods that MSDN
 mentions for MSVC 2013 (see:
 http://msdn.microsoft.com/en-us/library/vstudio/ms235316(v=vs.120).aspx["Choosing a Deployment Method"]):
 
-. 'Using Visual $$C++$$ Redistributable Package'.
+. _Using Visual {cpp} Redistributable Package._
 The Microsoft libraries are installed by copying
-'$$vcredist_x64.exe$$' or
-'$$vcredist_x86.exe$$' to the target
+_vcredist_x64.exe_ or
+_vcredist_x86.exe_ to the target
 machine and executing it on that machine (MSDN recommends
 this for applications built with Visual Studio 2013)
 
-. 'Using Visual $$C++$$ Redistributable Merge Modules'.
+. _Using Visual {cpp} Redistributable Merge Modules._
 (Loadable modules for building msi installers.
 Not suitable for Wireshark's NSIS based installer)
 
-. 'Install a particular Visual $$C++$$ assembly as a
-private assembly for the application'. The
+. _Install a particular Visual {cpp} assembly as a
+private assembly for the application._ The
 Microsoft libraries are installed by copying the folder
-content of 'Microsoft.VC120.CRT' to
-the target directory (e.g. 'C:\Program Files\Wireshark')
+content of _Microsoft.VC120.CRT_ to
+the target directory (e.g. _C:\Program Files\Wireshark_)
 
 To save installer size, and to make a portable
 version of Wireshark (which must be completely self-contained,
 on a medium such as a flash drive, and not require that an
 installer be run to install anything on the target machine)
 possible, when building 32-bit Wireshark with MSVC2013, method
-3 (copying the content of 'Microsoft.VC120.CRT')
+3 (copying the content of _Microsoft.VC120.CRT_)
 is used (this produces the smallest package).
 
 ==== Windows (Platform) SDK
 
 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
+libraries (e.g. _windows.h_, _WSock32.lib_, etc.). As new Windows
 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
 include an SDK. The free Express (as in beer) downloadable C compiler
-versions (V$$C++$$ 2012 Express, V$$C++$$ 2012 Express, etc.) do not
+versions (V{cpp} 2012 Express, V{cpp} 2012 Express, etc.) do not
 contain an SDK -- you'll need to download a PSDK in order to
 have the required C header files and libraries.
 
@@ -628,7 +628,7 @@ have a look at the HHC_DIR setting in the file docbook/Makefile.
 
 ===== HTML Help Build Files (htmlhelp.c / htmlhelp.lib)
 
-The files 'htmlhelp.c' and 'htmlhelp.lib' are required to
+The files _htmlhelp.c_ and _htmlhelp.lib_ are required to
 be able to open .chm files from Wireshark and show the
 online help. Both files are part of the SDK (standalone (P)SDK or MSVC
 since 2002).
@@ -759,7 +759,7 @@ Python 2.5 or later (including Python 3) should work fine and Python 3.5 and
 
 Python is either included or available as a package on most UNIX-like platforms.
 Windows packages and source are available at http://python.org/download/[].
-The Cygwin Python package is *not* recommended since '/usr/bin/python' is
+The Cygwin Python package is *not* recommended since _/usr/bin/python_ is
 a symbolic link, which causes confusion outside Cygwin.
 
 You can also use Chocolatey to install Python:
@@ -774,7 +774,7 @@ or
 PS:\> choco install Python2
 ----
 
-Chocolatey installs Python into 'C:\tools\python3' or 'C:\tools\python2' by
+Chocolatey installs Python into _C:\tools\python3_ or _C:\tools\python2_ by
 default. You can verify your Python version by running
 
 ----
@@ -934,7 +934,7 @@ Your version string may vary.
 
 A native Windows version of bison is available in the _winflexbison_
 https://chocolatey.org/[Chocolatey] package. Note that the executable is named
-'win_bison'.
+_win_bison_.
 
 Native packages are available from other sources such as
 http://gnuwin32.sourceforge.net/packages/bison.htm[GnuWin]. They aren't
@@ -977,7 +977,7 @@ Your version string may vary.
 
 A native Windows version of flex is available in the _winflexbison_
 https://chocolatey.org/[Chocolatey] package. Note that the executable is named
-'win_flex'.
+_win_flex_.
 
 ----
 PS:\>choco install winflexbison
@@ -1141,7 +1141,7 @@ installation should be straightforward.
 === Windows: NSIS (optional)
 
 The NSIS (Nullsoft Scriptable Install System) is used to generate
-'Wireshark-win32-{wireshark-version}.exe' from all the files
+_Wireshark-win32-{wireshark-version}.exe_ from all the files
 needed to be installed, including all required DLLs, plugins, and supporting
 files.
 
@@ -1158,7 +1158,7 @@ You can find more instructions on using NSIS in <<ChSrcNSIS>>.
 === Windows: PortableApps (optional)
 
 The PortableApps.com Installer is used to generate
-'WiresharkPortable-{wireshark-version}.paf.exe' from all the files
+_WiresharkPortable-{wireshark-version}.paf.exe_ from all the files
 needed to be installed, including all required DLLs, plugins, and supporting
 files.
 
index ce2a070a63e5c4bef4ffc5a50ac82aae22505fde..b97fe763fbf709250c551a9250fcdcff30ff1963 100644 (file)
@@ -80,12 +80,12 @@ 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.
 
 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
+_CMakeLists.txt_ within Qt Creator. It should ask you to choose a build
 location. Do so. It should then ask you to run CMake. Fill in any
 desired build arguments (e.g. "-D CMAKE_BUILD_TYPE=Debug" or "-D
 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.
+sure _wireshark_ is selected.
 
 Note that Qt Creator uses output created by CMake's *CodeBlocks*
 generator. If you run CMake outside of Qt Creator you should use the
@@ -94,19 +94,19 @@ 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.
 
-The main window along with the rest of the application resides in 'ui/qt'. Due
-to its size the main window code is split into two modules, 'main_window.cpp'
-and 'main_window_slots.cpp'.
+The main window along with the rest of the application resides in _ui/qt_. Due
+to its size the main window code is split into two modules, _main_window.cpp_
+and _main_window_slots.cpp_.
 
-Most of the modules in 'ui/qt' are dialogs. Although we follow Qt naming
+Most of the modules in _ui/qt_ are dialogs. Although we follow Qt naming
 conventions for class names, we follow our own conventions by separating file
 name components with underscores. For example, ColoringRulesDialog is defined in
-'coloring_rules_dialog.cpp', 'coloring_rules_dialog.h', and
-'coloring_rules_dialog.ui'.
+_coloring_rules_dialog.cpp_, _coloring_rules_dialog.h_, and
+_coloring_rules_dialog.ui_.
 
 General-purpose dialogs are subclasses of `QDialog`. Dialogs that rely on the
 current capture file can subclass `WiresharkDialog`, which provides methods and
@@ -117,7 +117,7 @@ open when the capture file closes.
 
 ===== Names
 
-The code in 'ui/qt' directory uses three APIs: Qt (which uses
+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
 code uses InterCapConvention for class names, interCapConvention for methods,
@@ -175,18 +175,18 @@ QStrings are generally *much* safer and easier to use. They also make
 translations easier.
 
 If you need to pass strings between Qt and GLib you can use a number
-of convenience routines which are defined in 'ui/qt/qt_ui_utils.h'.
+of convenience routines which are defined in _ui/qt/qt_ui_utils.h_.
 
 If you're calling a function that returns wmem-allocated memory it might make
-more sense to add a wrapper function to 'qt_ui_utils' than to call wmem_free in
+more sense to add a wrapper function to _qt_ui_utils_ than to call wmem_free in
 your code.
 
-===== Mixing C and $$C++$$
+===== Mixing C and {cpp}
 
-Sometimes we have to call $$C++$$ functions from one of
-Wireshark's C callbacks and pass $$C++$$ objects to or from C. Tap
-listeners are a common example. The $$C++$$ FAQ link:$$http://www.
-parashift.com/c++-faq/mixing-c-and-cpp.html$$:[describes how to do this
+Sometimes we have to call {cpp} functions from one of
+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].
 
 Tapping usually involves declaring static methods for callbacks, passing `this`
@@ -197,10 +197,10 @@ as the tap data.
 Qt provides a convenient method for translating text: `Qobject::tr()`,
 usually available as `tr()`.
 
-However, please avoid using `tr()` for static strings and define them in '*.ui'
+However, please avoid using `tr()` for static strings and define them in _*.ui_
 files instead. `tr()` on manually created objects like `QMenu` are not
 automatically retranslated and must instead be manually translated using
-`changeEvent()` and `retranslateUi()`. See 'summary_dialog.[ch]' for an example
+`changeEvent()` and `retranslateUi()`. See _summary_dialog.[ch]_ for an example
 of this.
 
 NOTE: If your object life is short and your components are (re)created
@@ -212,16 +212,16 @@ In most cases you should handle the changeEvent in order to catch
 Qt makes translating the Wireshark UI into different languages easy. To add a new
 translation, do the following:
 
-- Add your translation ('ui/qt/wireshark_XX.ts') to 'ui/qt/Makefile.am' and 'ui/qt/CMakeLists.txt'
-- (Recommended) Add a flag image for your language in 'images/languages/XX.svg'. Update 'image/languages/languages.qrc' accordingly.
+- Add your translation (_ui/qt/wireshark_XX.ts_) to _ui/qt/Makefile.am_ and _ui/qt/CMakeLists.txt_
+- (Recommended) Add a flag image for your language in _images/languages/XX.svg_. Update _image/languages/languages.qrc_ accordingly.
 - Run `lupdate ui/qt -ts ui/qt/wireshark_XX.ts` to generate/update your translation file.
 - Translate with Qt Linguist: `linguist ui/qt/wireshark_XX.ts`.
-- Do a test build and make sure the generated 'wireshark_XX.qm' binary file is included.
+- Do a test build and make sure the generated _wireshark_XX.qm_ binary file is included.
 - Push your translation to Gerrit for review. See <<ChSrcContribute>> for details.
 
-Alternatively you can put your QM and flag files in the 'languages'
+Alternatively you can put your QM and flag files in the _languages_
 directory in the Wireshark user configuration directory
-('$XDG_CONFIG_HOME/wireshark/languages/' or '$HOME/.wireshark/languages/' on
+(_$XDG_CONFIG_HOME/wireshark/languages/_ or _$HOME/.wireshark/languages/_ on
 UNIX).
 
 For more information about Qt Linguist see
@@ -254,7 +254,7 @@ doesn't meet your needs.
 ==== Other Issues and Information
 
 The main window has many QActions which are shared with child widgets. See
-'ui/qt/proto_tree.cpp' for an example of this.
+_ui/qt/proto_tree.cpp_ for an example of this.
 
 http://www.kdab.com/kdab-products/gammaray/[GammaRay] lets you inspect
 the internals of a running Qt application similar to $$Spy++$$ on Windows.
@@ -335,7 +335,7 @@ GTK 3.x depends on the following libraries:
 ==== Compatibility GTK versions
 
 The GTK library itself defines some values which makes it easy to distinguish
-between the versions, e.g. +GTK_MAJOR_VERSION+ and +GTK_MINOR_VERSION+ will be
+between the versions, e.g. `GTK_MAJOR_VERSION` and `GTK_MINOR_VERSION` will be
 set to the GTK version at compile time inside the gtkversion.h header.
 
 [[ChUIGTKWeb]]
index 712063c0230c7b161e7a5b90022f3bb184018956..07adfec2bd65b3be55fbf8fa60e36196175b278a 100644 (file)
@@ -26,29 +26,29 @@ image::wsdg_graphics/ws-function-blocks.png[{pdf-scaledwidth}]
 The function blocks in more detail:
 
 GUI:: Handling of all user input/output (all windows, dialogs and such).
-Source code can be found in the 'ui/qt' and 'ui/gtk' directory.
+Source code can be found in the _ui/qt_ and _ui/gtk_ directory.
 
 Core:: Main "glue code" that holds the other blocks together. Source
 code can be found in the root directory.
 
 Epan:: Ethereal Packet ANalyzer -- the packet analyzing engine.
-Source code can be found in the 'epan' directory. Epan provides
+Source code can be found in the _epan_ directory. Epan provides
 the following APIs:
 
 * Protocol Tree. Dissection information for an individual packet.
 
 * Dissectors. The various protocol dissectors in
-'epan/dissectors'.
+_epan/dissectors_.
 
 * Dissector Plugins - Support for implementing dissectors as separate modules.
-Source code can be found in 'plugins'.
+Source code can be found in _plugins_.
 
 * Display Filters - The display filter engine at
-'epan/dfilter'.
+_epan/dfilter_.
 
 Wiretap:: The wiretap library is used to read and write capture files in libpcap,
 pcapng, and many other file formats. Source code is in the
-'wiretap' directory.
+_wiretap_ directory.
 
 Capture:: The interface with the capture engine. Source code is in the
 root directory.
index af8708b5d458b1a8ba68c2df6ce715e5c1ab7b0e..175a70103cb3a761683ab83b272bf29da913e5fc 100644 (file)
@@ -174,19 +174,19 @@ This Part of the User Guide describes the Wireshark specific functions in the em
 Classes group certain functionality, the following notational conventions are
 used:
 
-* 'Class.function()' represents a class method (named 'function') on class
-  'Class', taking no arguments.
+* _Class.function()_ represents a class method (named _function_) on class
+  _Class_, taking no arguments.
 
-* 'Class.function(a)' represents a class method taking one argument.
+* _Class.function(a)_ represents a class method taking one argument.
 
-* 'Class.function(...)' represents a class method taking a variable number of
+* _Class.function(...)_ represents a class method taking a variable number of
   arguments.
 
-* 'class:method()' represents an instance method (named 'method') on an instance
-  of class 'Class', taking no arguments. Note the lowercase notation in the
+* _class:method()_ represents an instance method (named _method_) on an instance
+  of class _Class_, taking no arguments. Note the lowercase notation in the
   documentation to clarify an instance.
 
-* 'class.prop' represents a property 'prop' on the instance of class 'Class'.
+* _class.prop_ represents a property _prop_ on the instance of class _Class_.
 
 Trying to access a non-existing property, function or method currently gives an
 error, but do not rely on it as the behavior may change in the future.
@@ -210,7 +210,7 @@ include::{build_dir}/wsluarm_src/wslua_struct.asciidoc[]
 
 === GLib Regular Expressions
 
-Lua has its own native 'pattern' syntax in the string library, but sometimes a
+Lua has its own native _pattern_ syntax in the string library, but sometimes a
 real regex engine is more useful. Wireshark comes with GLib's Regex
 implementation, which itself is based on Perl Compatible Regular Expressions
 (PCRE). This engine is exposed into Wireshark's Lua engine through the
@@ -219,23 +219,23 @@ Lrexlib PCRE implementation, with a few differences as follows:
 
 * There is no support for using custom locale/chartables
 
-* 'dfa_exec()' doesn't take 'ovecsize' nor 'wscount' arguments
+* _dfa_exec()_ doesn't take _ovecsize_ nor _wscount_ arguments
 
-* 'dfa_exec()' returns boolean true for partial match, without subcapture info
+* _dfa_exec()_ returns boolean true for partial match, without subcapture info
 
 * Named subgroups do not return name-keyed entries in the return table (i.e., in
   match/tfind/exec)
 
-* The 'flags()' function still works, returning all flags, but two new functions
-  'compile_flags()' and 'match_flags()' return just their respective flags,
+* The _flags()_ function still works, returning all flags, but two new functions
+  _compile_flags()_ and _match_flags()_ return just their respective flags,
   since GLib has a different and smaller set of such flags, for regex compile
   vs. match functions
 
 * Using some assertions and POSIX character classes against strings with
   non-ASCII characters might match high-order characters, because glib always
-  sets PCRE_UCP even if G_REGEX_RAW is set. For example, '[:alpha;]' matches
-  certain non-ASCII bytes. The following assertions have this issue: '\b', '\B',
-  '\s', '\S', '\w', '\W'. The following character classes have this issue:
+  sets PCRE_UCP even if G_REGEX_RAW is set. For example, _[:alpha;]_ matches
+  certain non-ASCII bytes. The following assertions have this issue: _\b_, _\B_,
+  _\s_, _\S_, _\w_, _\W_. The following character classes have this issue:
   [:alpha:], [:alnum:], [:lower:], [:upper:], [:space:], [:word:], and
   [:graph:].
 
@@ -272,15 +272,15 @@ All functions that take a string-type regex argument accept a compiled regex
 too. In this case, the compile flags argument is ignored (should be either
 supplied as nils or omitted).
 
-The capture flag argument 'cf' may also be supplied as a string, whose
+The capture flag argument _cf_ may also be supplied as a string, whose
 characters stand for compilation flags. Combinations of the following characters
 (case sensitive) are supported:
 
-* '__i__' = G_REGEX_CASELESS - Letters in the pattern match both upper- and
+* _i_ = G_REGEX_CASELESS - Letters in the pattern match both upper- and
   lowercase letters. This option can be changed within a pattern by a ``(?i)''
   option setting.
 
-* '__m__' = G_REGEX_MULTILINE - By default, GRegex treats the strings as
+* _m_ = G_REGEX_MULTILINE - By default, GRegex treats the strings as
   consisting of a single line of characters (even if it actually contains
   newlines). The ``start of line'' metacharacter (``^'') matches only at the start
   of the string, while the ``end of line'' metacharacter (``$'') matches only at
@@ -291,18 +291,18 @@ characters stand for compilation flags. Combinations of the following characters
   very start and end. This can be changed within a pattern by a ``(?m)'' option
   setting.
 
-* '__s__' = G_REGEX_DOTALL - A dot metacharater (``.'') in the pattern matches
+* _s_ = G_REGEX_DOTALL - A dot metacharater (``.'') in the pattern matches
   all characters, including newlines. Without it, newlines are excluded. This
   option can be changed within a pattern by a ("?s") option setting.
 
-* '__x__' = G_REGEX_EXTENDED - Whitespace data characters in the pattern are
+* _x_ = G_REGEX_EXTENDED - Whitespace data characters in the pattern are
   totally ignored except when escaped or inside a character class. Whitespace
   does not include the VT character (code 11). In addition, characters between
   an unescaped ``$$#$$'' outside a character class and the next newline character,
   inclusive, are also ignored. This can be changed within a pattern by a
   ``(?x)'' option setting.
 
-* '__U__' = G_REGEX_UNGREEDY - Inverts the ``greediness'' of the quantifiers so
+* _U_ = G_REGEX_UNGREEDY - Inverts the ``greediness'' of the quantifiers so
   that they are not greedy by default, but become greedy if followed by ``?''.
   It can also be set by a ``(?U)'' option setting within the pattern.
 
@@ -405,7 +405,7 @@ A table filled with the results.
 
 Searches for the first match of the regexp pattern in the string subject,
 starting from offset init, subject to flags cf and ef. The pattern is compiled
-each time this is called, unlike the class method 'match' function.
+each time this is called, unlike the class method _match_ function.
 
 Since: 1.11.3
 
@@ -436,7 +436,7 @@ is returned. On failure, returns nil.
 
 Searches for the first match of the regexp pattern in the string subject,
 starting from offset init, subject to flags ef. The pattern is compiled each
-time this is called, unlike the class method 'find' function.
+time this is called, unlike the class method _find_ function.
 
 Since: 1.11.3
 
index d86db8eb623332acb3e9b49b6ef05363719188fd..e849b11e3bf971910f0d5bab88f58be4f72a10e7 100644 (file)
@@ -98,28 +98,28 @@ menu.
 
 ==== Folders on Windows
 
-_APPDATA_ is the personal application data folder, e.g.:
-++C:\Users\++__username__++\AppData\Roaming\Wireshark++ (details can be
+_%APPDATA%_ is the personal application data folder, e.g.:
+_C:\Users{backslash}**username**\AppData\Roaming\Wireshark_ (details can be
 found at: <<ChWindowsProfiles>>).
 
-_WIRESHARK_ is the Wireshark program folder, e.g.: `C:\Program
-Files\Wireshark`.
+_WIRESHARK_ is the Wireshark program folder, e.g.: _C:\Program
+Files\Wireshark_.
 
 ==== Folders on Unix-like systems
 
-_XDG_CONFIG_HOME_ is the folder for user-specific configuration files.
-It's usually $HOME++/.config++, where $HOME is the user's home folder, which
-is usually something such as ++/home/++__username__, or
-++/Users/++__username__ on macOS.
+_$XDG_CONFIG_HOME_ is the folder for user-specific configuration files.
+It's usually _$HOME/.config_, where _$HOME_ is the user's home folder, which
+is usually something such as _$HOME/**username**_, or
+_/Users/**username**_ on macOS.
 
 If you are using macOS and you are running a copy of Wireshark
 installed as an application bundle, _APPDIR_ is the top-level directory
 of the Wireshark application bundle, which will typically be
-`/Applications/Wireshark.app`.  Otherwise, _INSTALLDIR_ is the top-level
+_/Applications/Wireshark.app_.  Otherwise, _INSTALLDIR_ is the top-level
 directory under which reside the subdirectories in which components of
 Wireshark are installed.  This will typically be `/usr` if Wireshark is
 bundled with the system (for example, provided as a package with a Linux
-distribution) and `/usr/local` if, for example, you've build Wireshark
+distribution) and _/usr/local_ if, for example, you've build Wireshark
 from source and installed it.
 
 [[ChAppFilesConfigurationSection]]
@@ -135,7 +135,7 @@ The content format of the configuration files is the same on all platforms.
 On Windows:
 
 * The personal configuration folder for Wireshark is the
-`Wireshark` sub-folder of that folder, i.e. _APPDATA_`\Wireshark`.
+_Wireshark_ sub-folder of that folder, i.e. _%APPDATA%\Wireshark_.
 
 * The global configuration folder for Wireshark is the Wireshark program
 folder and is also used as the system configuration folder.
@@ -143,20 +143,18 @@ folder and is also used as the system configuration folder.
 On Unix-like systems:
 
 * The personal configuration folder is
-__XDG_CONFIG_HOME__++/wireshark++.  For backwards compatibility with
-Wireshark before 2.2, if __XDG_CONFIG_HOME__++/wireshark++ does not
-exist and $HOME++/.wireshark++ is present, then the latter will be used.
+_$XDG_CONFIG_HOME/wireshark_.  For backwards compatibility with
+Wireshark before 2.2, if _$XDG_CONFIG_HOME/wireshark_ does not
+exist and _$HOME/.wireshark_ is present, then the latter will be used.
 
 * If you are using macOS and you are running a copy of Wireshark
 installed as an application bundle, the global configuration folder is
-__APPDIR__++/Contents/Resources/share/wireshark++.  Otherwise, the
-global configuration folder is __INSTALLDIR__++/share/wireshark++.
+_APPDIR/Contents/Resources/share/wireshark_.  Otherwise, the
+global configuration folder is _INSTALLDIR/share/wireshark_.
 
-* The `/etc` folder is the system configuration folder.  The folder
+* The _/etc_ folder is the system configuration folder.  The folder
 actually used on your system may vary, maybe something like:
-`/usr/local/etc`.
-
-[float]
+_/usr/local/etc_.
 
 [[AppFilesTabFolders]]
 .Configuration files overview
@@ -168,7 +166,7 @@ actually used on your system may vary, maybe something like:
 |_cfilters_|Capture filters.
 |_dfilters_|Display filters.
 |_colorfilters_|Coloring rules.
-|_$$disabled_protos$$_|Disabled protocols.
+|_+++disabled_protos+++_|Disabled protocols.
 |_ethers_|Ethernet name resolution.
 |_manuf_|Ethernet name resolution.
 |_hosts_|IPv4 and IPv6 name resolution.
@@ -271,7 +269,7 @@ all the current color filters are written to the personal color filters
 file.
 --
 
-_$$disabled_protos$$_::
+_+++disabled_protos+++_::
 Each line in this file specifies a disabled protocol name. The following are
 some examples:
 +
@@ -281,9 +279,9 @@ tcp
 udp
 ----
 
-At program start, if there is a _$$disabled_protos$$_ file in the global
+At program start, if there is a _+++disabled_protos+++_ file in the global
 configuration folder, it is read first.  Then, if there is a
-_$$disabled_protos$$_ file in the personal configuration folder, that is
+_+++disabled_protos+++_ file in the personal configuration folder, that is
 read; if there is an entry for a protocol set in both files, the setting
 in the personal disabled protocols file overrides the setting in the
 global disabled protocols file.
@@ -344,7 +342,7 @@ given IP address in both files, the setting in the personal hosts file
 overrides the entry in the global hosts file.
 +
 --
-This file has the same format as the usual `/etc/hosts` file on Unix systems.
+This file has the same format as the usual _/etc/hosts_ file on Unix systems.
 
 An example is:
 
@@ -392,7 +390,7 @@ overrides the setting in the personal preference file.
 +
 --
 Each line in one of these files consists of an IPv4 address, a subnet
-mask length separated only by a '/' and a name separated by whitespace.
+mask length separated only by a ``/'' and a name separated by whitespace.
 While the address must be a full IPv4 address, any values beyond the
 mask length are subsequently ignored.
 
@@ -455,7 +453,7 @@ Wireshark.
 === Plugin folders
 
 Wireshark supports plugins for various purposes.  Plugins can either be
-scripts written in Lua or code written in C or C++ and compiled to
+scripts written in Lua or code written in C or {cpp} and compiled to
 machine code.
 
 Wireshark looks for plugins in both a personal plugin folder and a
@@ -464,33 +462,33 @@ compiled plugins are stored in subfolders of the plugin folders, with
 the subfolder name being the Wireshark minor version number (X.Y). There is
 another hierarchical level for each Wireshark library (libwireshark, libwscodecs
 and libwiretap). So for example the location for a libwireshark plugin
-++foo.so++ (++foo.dll++ on Windows) would be __PLUGINDIR__++/X.Y/epan++
-(libwireshark used to be called libepan; the other folder names are ++codecs++
-and ++wiretap++).
+_foo.so_ (_foo.dll_ on Windows) would be _PLUGINDIR/X.Y/epan_
+(libwireshark used to be called libepan; the other folder names are _codecs_
+and _wiretap_).
 
 On Windows:
 
-* The personal plugin folder is _APPDATA_`\Wireshark\plugins`.
+* The personal plugin folder is _%APPDATA%\Wireshark\plugins_.
 
-* The global plugin folder is _WIRESHARK_`\plugins`.
+* The global plugin folder is _WIRESHARK\plugins_.
 
 On Unix-like systems:
 
-* The personal plugin folder is ++~/.local/lib/wireshark/plugins++.
+* The personal plugin folder is _~/.local/lib/wireshark/plugins_.
 
 [NOTE]
 ====
 To provide better support for binary plugins this folder changed in Wireshark 2.5.
 It is recommended to use the new folder but *for lua scripts only* you may
-continue to use __XDG_CONFIG_HOME__++/wireshark/plugins++ for backward-compatibility.
+continue to use _$XDG_CONFIG_HOME/wireshark/plugins_ for backward-compatibility.
 This is useful to have older versions of Wireshark installed side-by-side. In case
 of duplicate file names between old and new the new folder wins.
 ====
 
 * If you are running on macOS and Wireshark is installed as an
 application bundle, the global plugin folder is
-_APPDIR_`/Contents/PlugIns/wireshark`, otherwise it's
-_INSTALLDIR_`/lib/wireshark/plugins`.
+_%APPDIR%/Contents/PlugIns/wireshark_, otherwise it's
+_INSTALLDIR/lib/wireshark/plugins_.
 
 [[ChWindowsFolder]]
 
@@ -499,8 +497,8 @@ _INSTALLDIR_`/lib/wireshark/plugins`.
 Here you will find some details about the folders used in Wireshark on different
 Windows versions.
 
-As already mentioned, you can find the currently used folders in the _About
-Wireshark_ dialog.
+As already mentioned, you can find the currently used folders in the ``About
+Wireshark'' dialog.
 
 [[ChWindowsProfiles]]
 
@@ -521,23 +519,23 @@ The following guides you to the right place where to look for Wireshark's
 profile data.
 
 Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Vista, and associated server editions::
-++C:\Users\++__username__++\AppData\Roaming\Wireshark++.
+_C:\Users{backslash}**username**\AppData\Roaming\Wireshark_.
 
 Windows XP, Windows Server 2003, and Windows 2000 footnoteref:[historical,No longer supported by Wireshark. For historical reference only.]::
-++C:\Documents and Settings\++__username__++\Application Data++. ``Documents and
+_C:\Documents and Settings{backslash}**username**\Application Data_. ``Documents and
 Settings'' and ``Application Data'' might be internationalized.
 
 Windows NT 4 footnoteref:[historical]::
-++C:\WINNT\Profiles\++__username__++\Application Data\Wireshark++
+_C:\WINNT\Profiles{backslash}**username**\Application Data\Wireshark_
 
 Windows ME, Windows 98 with user profiles footnoteref:[historical]::
 In Windows ME and 98 you could enable separate user profiles. In that case,
-something like ++C:\windows\Profiles\++__username__++\Application Data\Wireshark++
+something like _C:\windows\Profiles{backslash}**username**\Application Data\Wireshark_
 is used.
 
 Windows ME, Windows 98 without user profiles footnoteref:[historical]::
 Without user profiles enabled the default location for all users was
-++C:\windows\Application Data\Wireshark++.
+_C:\windows\Application Data\Wireshark_.
 
 [[ChWindowsRoamingProfiles]]
 
@@ -549,7 +547,7 @@ They will be stored on the domain server instead.
 
 Your settings will travel with you from computer to computer with one exception.
 The ``Local Settings'' folder in your profile data (typically something like:
-++C:\Documents and Settings\++__username__++\Local Settings++) will not be
+_C:\Documents and Settings{backslash}**username**\Local Settings_) will not be
 transferred to the domain server. This is the default for temporary capture
 files.
 
@@ -561,13 +559,13 @@ Wireshark uses the folder which is set by the TMPDIR or TEMP environment
 variable. This variable will be set by the Windows installer.
 
 Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Vista, and associated server editions::
-++C:\Users\++__username__++\AppData\Local\Temp++
+_C:\Users{backslash}**username**\AppData\Local\Temp_
 
 Windows XP, Windows Server 2003, Windows 2000 footnoteref:[historical]::
-++C:\Documents and Settings\++__username__++\Local Settings\Temp++
+_C:\Documents and Settings{backslash}**username**\Local Settings\Temp_
 
 Windows NT footnoteref:[historical]::
-++C:\TEMP++
+_C:\TEMP_
 
 ++++++++++++++++++++++++++++++++++++++
 <!-- End of WSUG Appendix Files -->
index 969598ecbab9d451c9ed56e3f1ba2eaffb0398b4..9db04fb3600d9dd7cb9b1b98e9a2b0fd17458587 100644 (file)
@@ -65,7 +65,7 @@ There are two ways for a dissector to register itself for packet data:
 
 Let's look at an example. We'll assume, Wireshark loads a TCP/IP/Ethernet
 packet. Wireshark will call the Ethernet dissector, which will dissect the
-Ethernet related data (usually the first 6+6+2 bytes). Then this dissector calls
+Ethernet related data (usually the first 6 + 6 + 2 bytes). Then this dissector calls
 back into Wireshark and will pass the rest of the data back to Wireshark.
 Wireshark in turn will call the next related dissector, in our case the IP
 dissector (because of the value 0x800 in the Ethernet type field). This game
@@ -77,4 +77,4 @@ You can control the way Wireshark calls its dissectors, see
 
 ++++++++++++++++++++++++++++++++++++++
 <!-- End of WSUG Appendix How it Works -->
-++++++++++++++++++++++++++++++++++++++
\ No newline at end of file
+++++++++++++++++++++++++++++++++++++++
index abdc40ce38fa7e281c9267a5041f9b67405f0d76..0511383eca4ab1702e8954b6541d022b6bbec6fe 100644 (file)
@@ -35,7 +35,7 @@ include::tshark-h.txt[]
 
 [[AppToolstcpdump]]
 
-=== __tcpdump__: Capturing with `tcpdump` for viewing with Wireshark
+=== __tcpdump__: Capturing with ``tcpdump'' for viewing with Wireshark
 
 It's often more useful to capture packets using `tcpdump` rather than
 `wireshark`. For example, you might want to do a remote capture and either don't
@@ -52,14 +52,14 @@ You will have to specify the correct _interface_ and the name of a _file_ to
 save into. In addition, you will have to terminate the capture with ^C when you
 believe you have captured enough packets.
 
-+tcpdump+ is not part of the Wireshark distribution. You can get it from
+`tcpdump` is not part of the Wireshark distribution. You can get it from
 {tcpdump-main-url} or as a standard package in most Linux distributions.
-For more information on +tcpdump+ consult your local manual page (`man
+For more information on `tcpdump` consult your local manual page (`man
 tcpdump`) or link:{tcpdump-man-page-url}[the online version].
 
 [[AppToolsdumpcap]]
 
-=== __dumpcap__: Capturing with `dumpcap` for viewing with Wireshark
+=== __dumpcap__: Capturing with ``dumpcap'' for viewing with Wireshark
 
 Dumpcap is a network traffic dump tool. It captures packet data from a live
 network and writes the packets to a file. Dumpcap's native capture file format
@@ -82,7 +82,7 @@ include::dumpcap-h.txt[]
 
 === __capinfos__: Print information about capture files
 
-+capinfos+ can print information about capture files including the file
+`capinfos` can print information about capture files including the file
 type, number of packets, date and time information, and file hashes.
 Information can be printed in human and machine readable formats. For
 more information on `capinfos` consult your local manual page (`man
@@ -115,7 +115,7 @@ include::rawshark-h.txt[]
 
 === __editcap__: Edit capture files
 
-+editcap+ is a general-purpose utility for modifying capture files. Its
+`editcap` is a general-purpose utility for modifying capture files. Its
 main function is to remove packets from capture files, but it can also
 be used to convert capture files from one format to another, as well as
 to print information about capture files. For more information on
@@ -155,7 +155,7 @@ HP-UX's nettl, and the dump output from Toshiba's ISDN routers. There is no need
 to tell Mergecap what type of file you are reading; it will determine the file
 type by itself. Mergecap is also capable of reading any of these file formats if
 they are compressed using `gzip`. Mergecap recognizes this directly from the
-file; the ``$$.gz$$'' extension is not required for this purpose.
+file; the ``.gz'' extension is not required for this purpose.
 
 By default, it writes the capture file in pcapng format, and writes all of the
 packets in the input capture files to the output file. The `-F` flag can be used
@@ -216,14 +216,14 @@ $ mergecap -w outfile.pcapng dhcp-capture.pcapng imap-1.pcapng
 There may be some occasions when you wish to convert a hex dump of some network
 traffic into a libpcap file.
 
-+text2pcap+ is a program that reads in an ASCII hex dump and writes the data
+`text2pcap` is a program that reads in an ASCII hex dump and writes the data
 described into a libpcap-style capture file. text2pcap can read hexdumps with
 multiple packets in them, and build a capture file of multiple packets.
 `text2pcap` is also capable of generating dummy Ethernet, IP and UDP headers, in
 order to build fully processable packet dumps from hexdumps of application-level
 data only.
 
-+text2pcap+ understands a hexdump of the form generated by `od -A x -t x1`. In
+`text2pcap` understands a hexdump of the form generated by `od -A x -t x1`. In
 other words, each byte is individually displayed and surrounded with a space.
 Each line begins with an offset describing the position in the file. The offset
 is a hex number (can also be octal - see `-o`), of more than two hex digits. Here
@@ -256,13 +256,13 @@ of mangled outputs (including being forwarded through email multiple times, with
 limited line wrap etc.)
 
 There are a couple of other special features to note. Any line where the first
-non-whitespace character is '#' will be ignored as a comment. Any line beginning
+non-whitespace character is `#' will be ignored as a comment. Any line beginning
 with #TEXT2PCAP is a directive and options can be inserted after this command to
 be processed by `text2pcap`. Currently there are no directives implemented; in the
 future, these may be used to give more fine grained control on the dump and the
 way it should be processed e.g. timestamps, encapsulation type etc.
 
-+text2pcap+ also allows the user to read in dumps of application-level data, by
+`text2pcap` also allows the user to read in dumps of application-level data, by
 inserting dummy L2, L3 and L4 headers before each packet. Possibilities include
 inserting headers such as Ethernet, Ethernet + IP, Ethernet + IP + UDP, or
 Ethernet + Ip + TCP before each packet. This allows Wireshark or any other
@@ -283,7 +283,7 @@ include::text2pcap-h.txt[]
 
 === __reordercap__: Reorder a capture file
 
-+reordercap+ lets you reorder a capture file according to the packets
+`reordercap` lets you reorder a capture file according to the packets
 timestamp. For more information on `reordercap` consult your local
 manual page (`man reordercap`) or
 link:{wireshark-man-page-url}reordercap.html[the online version].
index ae34211c160dab90a0b333a270b075193c208e1c..438bdef92a39e135d883d175ce13281286a480d6 100644 (file)
@@ -321,7 +321,7 @@ the installation methods used with your version of UNIX. For example, under AIX,
 you would use _smit_ to install the Wireshark binary package, while under Tru64
 UNIX (formerly Digital UNIX) you would use _setld_.
 
-==== Installing from RPM's under Red Hat and alike
+==== Installing from RPMs under Red Hat and alike
 
 Building RPMs from Wireshark's source code results in several packages (most
 distributions follow the same system):
@@ -353,7 +353,7 @@ rpm -ivh wireshark-2.0.0-1.x86_64.rpm wireshark-qt-2.0.0-1.x86_64.rpm
 If the above command fails because of missing dependencies, install the
 dependencies first, and then retry the step above.
 
-==== Installing from deb's under Debian, Ubuntu and other Debian derivatives
+==== Installing from debs under Debian, Ubuntu and other Debian derivatives
 
 If you can just install from the repository then use
 
@@ -363,7 +363,7 @@ $ aptitude install wireshark
 
 Aptitude should take care of all of the dependency issues for you.
 
-Use the following command to install downloaded Wireshark deb's under Debian:
+Use the following command to install downloaded Wireshark debs under Debian:
 
 ----
 $ dpkg -i wireshark-common_2.0.5.0-1_i386.deb wireshark_wireshark-2.0.5.0-1_i386.deb
index c1d660fd6fb5658c7917a58ef419215f27f4c268..a599547ef5073f1ef6d754755884f597cf310b79 100644 (file)
@@ -413,7 +413,7 @@ are seconds since epoch (Jan 1, 1970 00:00:00)
 
 -u <s | hms>::
 
-Show timesamps as seconds ('s', the default) or hours, minutes, and seconts ('hms')
+Show timesamps as seconds (`s', the default) or hours, minutes, and seconds (`hms')
 
 -v::
 
@@ -449,12 +449,12 @@ Tells Wireshark to load the given script in addition to the default Lua scripts.
 lua_script[num]:argument::
 
 Tells Wireshark to pass the given argument to the lua script identified by
-'num', which is the number indexed order of the 'lua_script' command. For
+_num_, which is the number indexed order of the _lua_script_ command. For
 example, if only one script was loaded with `-X lua_script:my.lua`, then `-X
-lua_script1:foo` will pass the string 'foo' to the 'my.lua' script. If two
+lua_script1:foo` will pass the string _foo_ to the _my.lua_ script. If two
 scripts were loaded, such as `-X lua_script:my.lua` and `-X
 lua_script:other.lua` in that order, then a `-X lua_script2:bar` would pass the
-string 'bar' to the second lua script, namely 'other.lua'.
+string _bar_ to the second lua script, namely _other.lua_.
 --
 
 -z <statistics-string>::
@@ -921,13 +921,13 @@ Responder's SPI::
 Responder's SPI of the IKE_SA. This field takes hexadecimal string without
 ``0x'' prefix and the length must be 16 hex chars (represents 8 octets).
 
-$$SK_ei$$::
+SK_ei::
 Key used to encrypt/decrypt IKEv2 packets from initiator to responder. This
 field takes hexadecimal string without ``0x'' prefix and its length must meet
 the requirement of the encryption algorithm selected.
 
 
-$$SK_er$$::
+SK_er::
 Key used to encrypt/decrypt IKEv2 packets from responder to initiator. This
 field takes hexadecimal string without ``0x'' prefix and its length must meet
 the requirement of the encryption algorithm selected.
@@ -973,7 +973,7 @@ The string representation of the Object Identifier e.g. ``2.5.4.6''.
 
 Name::
 The name that should be displayed by Wireshark when the Object Identifier is
-dissected e.g. ('c');
+dissected e.g. (``c'');
 
 Syntax::
 The syntax of the value associated with the Object Identifier. This must be one
@@ -1084,21 +1084,21 @@ Authentication model::
 Which auth model to use (either ``MD5'' or ``SHA1'').
 
 Password::
-The authentication password. Use '\xDD' for unprintable characters. An
-hexadecimal password must be entered as a sequence of '\xDD' characters. For
+The authentication password. Use _\xDD_ for unprintable characters. An
+hexadecimal password must be entered as a sequence of _\xDD_ characters. For
 example the hex password 010203040506 must be entered as
-'\x01\x02\x03\x04\x05\x06'. The '\' character must be treated as an unprintable
-character, i.e. it must be entered as '\x5C' or '\x5c'.
+_\x01\x02\x03\x04\x05\x06_. The _\_ character must be treated as an unprintable
+character, i.e. it must be entered as _\x5C_ or _\x5c_.
 
 Privacy protocol::
 Which encryption algorithm to use (either ``DES'' or ``AES").
 
 Privacy password::
-The privacy password. Use '\xDD' for unprintable characters. An hexadecimal
-password must be entered as a sequence of '\xDD' characters. For example the hex
-password 010203040506 must be entered as '\x01\x02\x03\x04\x05\x06'. The '\'
+The privacy password. Use _\xDD_ for unprintable characters. An hexadecimal
+password must be entered as a sequence of _\xDD_ characters. For example the hex
+password 010203040506 must be entered as _\x01\x02\x03\x04\x05\x06_. The _\_
 character must be treated as an unprintable character, i.e. it must be entered
-as '\x5C' or '\x5c'.
+as _\x5C_ or _\x5c_.
 
 [[ChK12ProtocolsSection]]
 
index e7f13a8a407ab04b4db32fca50fa18e2af958707..90ee42cea4444d6ac342a1a698d4fdeef80356f8 100644 (file)
@@ -431,7 +431,7 @@ When reporting problems with Wireshark please supply the following information:
 
 . The version number of Wireshark and the dependent libraries linked with it,
   such as Qt or GLib. You can obtain this from Wireshark's about box or the
-  command `wireshark -v`.
+  command _wireshark -v_.
 
 . Information about the platform you run Wireshark on.
 
@@ -473,9 +473,9 @@ backtrace
 ^D
 ----
 
-If you do not have `gdb` available, you will have to check out your operating system's debugger.
+If you do not have _gdb_ available, you will have to check out your operating system's debugger.
 
-Mail `backtrace.txt` to mailto:{wireshark-dev-list-email}[].
+Mail _backtrace.txt_ to mailto:{wireshark-dev-list-email}[].
 
 ==== Reporting Crashes on Windows platforms
 
index 7d4ba0592151176132a54365476102a3f749422a..c76c379fc1d4f6145c69d43b8cb9da332669a983 100644 (file)
@@ -440,7 +440,7 @@ Here is a sample dump that can be imported:
 There is no limit on the width or number of bytes per line. Also the text dump
 at the end of the line is ignored. Byte and hex numbers can be uppercase or
 lowercase. Any text before the offset is ignored, including email forwarding
-characters '&gt;'. Any lines of text between the bytestring lines are ignored.
+characters _&gt;_. Any lines of text between the bytestring lines are ignored.
 The offsets are used to track the bytes, so offsets must be correct. Any line
 which has only bytes without a leading offset is ignored. An offset is
 recognized as being a hex number longer than two characters. Any text after the
@@ -707,7 +707,7 @@ Export packet bytes into C arrays so you can import the stream data into your ow
 
 Export packet data into PSML. This is an XML based format including only the
 packet summary. The PSML file specification is available at:
-link:$$http://www.nbee.org/doku.php?id=netpdl:psml_specification$$[].
+link:http://www.nbee.org/doku.php?id=netpdl:psml_specification[].
 
 .The "Export as PSML File" dialog box
 image::wsug_graphics/ws-export-psml.png[{screenshot-attrs}]
@@ -725,7 +725,7 @@ format is defined by the PSML specification.
 
 Export packet data into PDML. This is an XML based format including the packet
 details. The PDML file specification is available at:
-link:$$http://www.nbee.org/doku.php?id=netpdl:pdml_specification$$[].
+link:http://www.nbee.org/doku.php?id=netpdl:pdml_specification[].
 
 [NOTE]
 ====
index 955b70d1c6e2f1ed9035a54c1ddf0252ba5aa3de..188b2fc189f0f656c2afa68f99f710967b3a1861 100644 (file)
@@ -670,11 +670,11 @@ image::wsug_graphics/ws-help-menu.png[{screenshot-attrs}]
 |menu:Contents[]|F1| This menu item brings up a basic help system.
 |menu:Manual Pages[...]|| This menu item starts a Web browser showing one of the locally installed html manual pages.
 |menu:Website[]|| This menu item starts a Web browser showing the webpage from: link:{wireshark-main-url}[].
-|menu:FAQ's[]|| This menu item starts a Web browser showing various FAQ's.
+|menu:FAQs[]|| This menu item starts a Web browser showing various FAQs.
 |menu:Downloads[]|| This menu item starts a Web browser showing the downloads from: link:{wireshark-download-url}[].
 |menu:Wiki[]|| This menu item starts a Web browser showing the front page from: link:{wireshark-wiki-url}[].
 |menu:Sample Captures[]|| This menu item starts a Web browser showing the sample captures from: link:{wireshark-wiki-url}SampleCaptures[].
-|menu:About Wireshark[]|| This menu item brings up an information window that provides various detailed information items on Wireshark, such as how it's build, the plugins loaded, the used folders, ...
+|menu:About Wireshark[]|| This menu item brings up an information window that provides various detailed information items on Wireshark, such as how it's built, the plugins loaded, the used folders, ...
 
 |===============
 
index ff15c423c3ce6c7c8a2256c700eae3d79ea44e25..1499ee8043693bf740022b116559bb19cc71962b 100644 (file)
@@ -319,13 +319,13 @@ Signed integer::
 
 Boolean::
   A boolean field is present in the protocol decode only if its value is true. For
-  example, +tcp.flags.syn+ is present, and thus true, only if the SYN flag is
+  example, `tcp.flags.syn` is present, and thus true, only if the SYN flag is
   present in a TCP segment header.
 
-  The filter expression  +tcp.flags.syn+ will select only  those packets for which
+  The filter expression  `tcp.flags.syn` will select only  those packets for which
   this flag exists, that is,  TCP segments where the segment header contains the
   SYN flag. Similarly, to find source-routed token ring packets, use a filter
-  expression of  +tr.sr+.
+  expression of  `tr.sr`.
 
 Ethernet address::
   6 bytes separated by a colon (:), dot (.) or dash (-) with one or two bytes between separators:
@@ -346,12 +346,12 @@ IPv4 address::
   ip.addr == 129.111.0.0/16
 
 IPv6 address::
-  +ipv6.addr == ::1+
+  `ipv6.addr == ::1`
 
   As with IPv4 addresses, IPv6 addresses can match a subnet.
 
 Text string::
-  +http.request.uri == "https://www.wireshark.org/"+
+  `http.request.uri == "https://www.wireshark.org/"`
 
 ----
 udp contains 81:60:03
@@ -368,7 +368,7 @@ http.host matches "acme\.(org|com|net)"
 ----
 The example above match HTTP packets where the HOST header contains acme.org or acme.com
 or acme.net. Comparisons are case-insensitive. Note: Wireshark needs to be built with
-libpcre in order to be able to use the +matches+ resp. +~+ operator.
+libpcre in order to be able to use the `matches` resp. `~`` operator.
 ----
 tcp.flags & 0x02
 ----
@@ -817,7 +817,7 @@ The available precisions (aka. the number of displayed decimal places) are:
   precision is larger, the remaining decimal places will be cut off.
 
 Precision example: If you have a timestamp and it's displayed using, ``Seconds
-Since Previous Packet'', : the value might be 1.123456. This will be displayed
+Since Previous Packet'' the value might be 1.123456. This will be displayed
 using the ``Automatic'' setting for libpcap files (which is microseconds). If
 you use Seconds it would show simply 1 and if you use Nanoseconds it shows
 1.123456000.
@@ -839,7 +839,7 @@ Time referencing will only be useful if the time display format is set to
 are used, time referencing will have no effect (and will make no sense either).
 
 To work with time references, choose one of the menu:Time Reference[] items in
-the menu:Edit[] menu or from the pop-up menu of the ``Packet List'' pane. See
+the menu:[Edit] menu or from the pop-up menu of the ``Packet List'' pane. See
 <<ChUseEditMenuSection>>.
 
 * _Set Time Reference (toggle)_ Toggles the time reference state of the