Normal quotes

09-05.md

@@ -2,15 +2,15 @@
   [Previous](09-04.html)   [Table of Contents](index.html)   [Next](09-06.html)
   ------------------------ --------------------------------- --------------------
 
-You’ll notice that in Listing 9.2 I didn’t use a table of character
+You'll notice that in Listing 9.2 I didn't use a table of character
 frequencies in English text to determine the character for which to
 scan, but rather let the caller make that choice. Each buffer of bytes
 has unique characteristics, and English-letter frequency could well be
 inappropriate. What if the buffer is filled with French text? Cyrillic?
-What if it isn’t text that’s being searched? It might be worthwhile for
+What if it isn't text that's being searched? It might be worthwhile for
 an application to build a dynamic frequency table for each buffer so
 that the best scan character could be chosen for each search. Or perhaps
-not, if the search isn’t time-critical or the buffer is small.
+not, if the search isn't time-critical or the buffer is small.
 
 The point is that you can improve performance dramatically by
 understanding the nature of the data with which you work. (This is
@@ -23,14 +23,14 @@ heads.
 #### Short Sorts {#Heading7}
 
 David Stafford (recently of Borland and Borland Japan) who happens to be
-one of the best assembly language programmers I’ve ever met, has written
+one of the best assembly language programmers I've ever met, has written
 a C-callable routine that sorts an array of integers in ascending order.
-That wouldn’t be particularly noteworthy, except that David’s routine,
+That wouldn't be particularly noteworthy, except that David's routine,
 shown in Listing 9.4, is exactly *25 bytes* long. Look at the code;
-you’ll keep saying to yourself, “But this doesn’t work...oh, yes, I
-guess it does.” As they say in the Prego spaghetti sauce ads, *it’s in
+you'll keep saying to yourself, "But this doesn't work...oh, yes, I
+guess it does." As they say in the Prego spaghetti sauce ads, *it's in
 there*—and what a job of packing. Anyway, David says that a 24-byte sort
-routine eludes him, and he’d like to know if anyone can come up with
+routine eludes him, and he'd like to know if anyone can come up with
 one.
 
 **LISTING 9.4 L9-4.ASM**
@@ -72,18 +72,18 @@ one.
 
 One of the most annoying limitations of the x86 is that while the
 dividend operand to the **DIV** instruction can be 32 bits in size, both
-the divisor and the result must be 16 bits. That’s particularly annoying
-in regards to the result because sometimes you just don’t know whether
+the divisor and the result must be 16 bits. That's particularly annoying
+in regards to the result because sometimes you just don't know whether
 the ratio of the dividend to the divisor is greater than 64K-1 or
 not—and if you guess wrong, you get that godawful Divide By Zero
 interrupt. So, what is one to do when the result might not fit in 16
 bits, or when the dividend is larger than 32 bits? Fall back to a
 software division approach? That will work—but oh so slowly.
 
-There’s another technique that’s much faster than a pure software
+There's another technique that's much faster than a pure software
 approach, albeit not so flexible. This technique allows arbitrarily
 large dividends and results, but the divisor is still limited to16 bits.
-That’s not perfect, but it does solve a number of problems, in
+That's not perfect, but it does solve a number of problems, in
 particular eliminating the possibility of a Divide By Zero interrupt
 from a too-large result.