Bugs in Word 6, 97 and 2000
Bugs in Word 2000 that weren't there in Word 97
A problem in Word 6 that gets worse with every new version
Annoying behaviour in Win95, which is worse in Win98
Annoying behaviour in Win95, which is still in Win98
In July 2000 I bought a new
Gateway 2000
computer (European headquarters),
with Win98 and Word2000 pre-installed.
To me this meant an upgrade from the Win95 and Word6&97 that I was used to.
It turned out to be a bit of a disappointment. Many of the bugs and much of the clumsiness
in the old software is still present in the new, and there are new bugs too.
One of them
impeded my work so much that I had to uninstall Word2000 and re-install Win97.
On the other hand I want to stress that bugs are always more conspicuous than features.
I don't discuss the things about Windows and Word I am satisfied about, and especially
in Word, there are many. I also knowingly don't discuss some improvements in newer
versions. But now for the bugs:
Many of the problems I am going to describe here have to do with tables. So to make myself clear, we need an example. It looks like the table below. But to get the table on your screen in such a way that it fits my description, you will have to adjust the windows width of your browser. The last words of the three lines in the right cell of the last row should ideally be "one", "to" and "word".
| Left cell, first row | Right cell, first row |
| Left cell, second row | Here is rather long text in a single table cell. It consists of several lines, more than one sentence, and the whole thing is paragraph. Here is a very long non-existent word to complete the : abacadabralilopozodozovivinabupunonbreaking word. |
| Left cell, third row | Right cell, third row |
You can also view or download the example table as a Word document (stored in RTF, Rich Text Format, so it works in versions 6, (probably also 95), 97 and 2000 of Word for Windows.
Marking text with the cursor keys (Shift plus arrows, End, Home) doesn't work the same in a table as it does in a non-table paragraph:
Place the cursor on the second word of the last line of the second row,
"and".
Hold the Shift key and press End.
The whole table cell is marked, instead of the right portion of the line, from
cursor to the end of the line. This is inconsistent with the behaviour outside
a table cell. The situation can be remedied though, by pressing arrow left.
When the purpose of marking this text is to delete the remainders of the
source text, after having inserted a translation for example, forgetting this
extra key stroke deletes not only the source text, but also the
translation I just typed. Thank you, program, for not cooperating with me.
Still in the second table row, place the cursor on the beginning of the second
word in the second line, "and". Hold Shift, and press arrow-down. This correctly
marks the right part of the second line and the left part of the third line.
Now press arrow-down again (still holding Shift), with the intention to mark
also the rest of the last line. But this doesn't mark up to the last line,
but also the next row! Because in the previous situation an arrow left
corrected the situation, there is a tendency to try that in this case too.
But it makes things worse: now four cells are marked, instead of the rightmost
text in that single cell being added to the selection.
This sort of program behaviour causes a lot of extra and unnecessary keystrokes
when quickly translating text in a two-column table, source text left, source
language text to be overwritten by target language text right.
It is difficult to get used to this and adapt to it, because it is so
different from how it works outside table cells.
I think a paragraph in a table cell should simply behave exactly the same
as a non-table paragraph. I remember Windows being presented as an environment
with a uniform and consistent user interface across applications. In practice,
even in a single application, made by Windows' creator, there are such
inconsistenties.
Put the cursor on the colon in the third line
of the second right cell. Make sure that insert mode is on, and
insert the word which was clearly forgotten: "paragraph".
Now decide to delete the following nonsense word, by holding Shift,
pressing End, and the correcting arrow left. I’d now expect that
text from the cursor position to the end of the line would be
marked: the nonsense word, the word "word" and the full stop.
But instead, the word "paragraph" is also included in the selection.
This means that when text was marked meaning to delete it, the missing
word that was inserted is also deleted!
Again this is very annoying when doing translation work or editing text.
While the previous two points may still be debatable, bugs that might
have been intended as features, this third point looks more like a
programming error to me: an internal program variable that holds
the original cursor position is not updated when clearly it should be.
Yet, three versions Word (6, 97, 2000) work like this. Feature,
bug, of insufficient testing? Testing that concentrates too much
on novice users, and not enough on high-speed production work?
Styles (Dutch: opmaakprofielen) are a useful way to define sets of formatting properties.
You define the style's properties in one place, you assign a style to each paragraph,
and then the properties apply to all those paragraphs. When formatting properties
need to be changed, you change them once, and the change becomes effective for all
paragraphs that have that style.
This concept is similar to subroutines or functions in programming languages, and
to CSS (cascading style sheets) in HTML.
A very smart idea. The strange thing though, is that in RTF (Rich Text Format) styles are not stored in a way that the concept suggests: The style's properties are stored, there is a reference to the style with the paragraph that have that style, but the style's properties are also stored with every paragraph.. This is true in RTF generated by Word 6, Word 97 and Word 2000. It wastes space, and defies the idea behind styles.
Word's designer are very much aware of the fact that nowadays, disk storage is cheap. But to them, screen resolution seems to be a different matter:
Again consider a document with a table like this example, except that it is now a lot larger. For example, the document I discovered this problem with had 127444 text characters (but required an awful lot more bytes to store it on disk).
There is a left column with reference numbers (irrelevant for this
discussion), a second column with source language text, and
a third language that should eventually contain fully translated
target language text. Some cells have fully or partially pre-translated
text from a translation memory system, some cells are almost done but
require editing, and many still need full translation.
Now it is convenient, to save on typing effort and for consistency,
to start by searching and replacing some often occurring terms.
(The translation memory might have done some of that work, but that
isn't the point of this discussion).
Only the rightmost column may be changed, the other two should
remain unaffected.
If normally do this by splitting the screen horizontally, marking
the rightmost column in the upper screen half (so changes will be
restricted to that column), and then looking for candidates while
perusing the lower screen half. Once I see a candidate, I switch
back to the upper half using function key F6. In Word 97, this can
be done in less than half a second. In Word 2000 (version 9.0.2812),
this takes 45 (forty-five!). This was measured on a laptop computer with a
Celeron 500 MHz processorand 64 MB of memory. (45 seconds times 500 MHz
means 22.5 billion clock pulses).
This makes Word 2000 completely unusable for me, so I uninstalled
it and reverted to Word 97.
A file that contained a mere 49326 bytes of text (including spaces and newlines), without fancy formatting (except that the text was in tables, as explained above), required the following amounts of disk-space (in bytes) in various Word versions:
| Word 6 | Word 97 | Word 2000 | |||
| RTF | Word | RTF | Word | RTF | Word |
| 272 688 | 92 160 | 347 955 | 181 248 | 837 386 | 333 824 |
The same figures expressed in percentages of overhead:
| Word 6 | Word 97 | Word 2000 | |||
| RTF | Word | RTF | Word | RTF | Word |
| 453 % | 87 % | 605 % | 267 % | 1598 % | 578 % |
I also compressed the files using PkZip, which gives an idea of the real information content of the files, versus redundancy. (The plain text file compressed to 15784 bytes).
| Word 6 | Word 97 | Word 2000 | |||
| RTF | Word | RTF | Word | RTF | Word |
| 23 965 | 25 851 | 26 206 | 28 709 | 31 714 | 38 320 |
Now Microsoft might argue that this file size expansion is because the newer
word processors are so much more powerful, and that all those features need to
be stored. But I don't want those new features. I’d still use Word 6 if I could
put it on my new computer. I can't, because some floppies are bad. I wondered
why I never made backup copies. But in fact, you can't because they contain
a non-standard number of bytes.
Also, when I don't use new features in a file, they need not be stored, and
they shouldn't require any space. A well designed file format should have kept
room for future expansions in the first place.
The size of the zipped files shows there isn't really much extra information
in the larger files, but most of it is just wasted space.
Also, now that hard-disks are so cheap, space isn't an issue. But with larger disks,
more documents tend to be kept online, and then it does become a problem. For example,
I have five years of translation documents and invoices on my disks.
I suspect this file expansion is due to lack of programming skills, possibly combined
with ill will, and a tasteless attempt to boost hard-disk sales.
In the MacIntosh world too, newer Word versions aren't always better. Read here what Cathy Flick has to say about Word 5.1 and 98 for the Mac.
Starting up the computer takes an unreasonably long time with Win95. With Win98, despite a faster computer it takes even longer. Another example of a big problem, which Microsoft doesn't seem to consider one, otherwise I’d expect them to improve the situation. Instead, they made it worse.
| OS | Processor | Clock speed | Time from power on till desktop | Time from power on vanished hour glass / quiet disk |
| Win95 | Pentium I | 133 MHz | 0m55s | 1m08s |
| Win95 | Pentium II | 233 MHz | 0m45s | 0m55s |
| Win98 | Pentium Celeron | 500 MHz | 1m25s | 1m40s |
The measured times are not including checking the disk (scandisk), logging in to Windows or connecting to network drives. Also, there was only a minimum of applications starting at boot-time.
The table shows that the newer operating system with a faster processor starts slowlier. Now the Celeron certainly isn't the fastest Pentium, but it is actually faster than the earlier models I tested on, as shown by the following measurements:
| Processor | Clock speed | Long integer additions per second | Floating point multiplications per second |
| Pentium I | 133 MHz | 21 million | 6 million |
| Pentium II | 233 MHz | 58 million | 30 million |
| Pentium Celeron | 500 MHz | 70 million | 32 million |
OnNow (ACPI - Advanced Configuration Power Interface) is not the right approach to solve this problem, because it means the hardware stays on in standby-mode. This is a waste of energy and adds to the greenhouse effect, by encouraging people to keep their computers on all the time. Even if stand-by power is minimal, with many millions of computers worldwide it is an important factor.
The real solution is to avoid unnecessary actions during start-up. I have no idea what Windows is doing in all this time, but considering that it equals the time needed for 7 billion integer additions, there must be something very wrong. Possible explanations (just speculations, I don't actually know what's going on):
A reasonable start-up time, for BIOS and OS together, I’d find 6 seconds on an old 468, and 3 seconds on a Pentium. If it's longer it's probably a design error.
Under Windows 95 and 98, network drives are not connected on demand. That means Windows usually tries to connect them when failure is likely or even certain, and does not connect them when you need them! Moreover, it doesn't keep track of which letters are used with what type of connexion.
Consider this example set-up: two computers in a connected in a LAN, one that you normally work on, with drives c: and d:, and a backup computer with drives or partitions c:, d: and e:, which are mapped to l:, m: and n: on the work computer. Moreover, there is a remote computer, whose drive is sometimes mapped to drive g: over a dial-up connexion.
Connexions are made in Windows Explorer (Dutch: Verkenner)
(not to be confused with Internet Explorer,
which is also called Explorer in the Dutch version).
No two Windows Explorers look the same for some strange reason, but via menu "Tools"
(Dutch: "Extra") or by using a button,
you should be able to access the feature "Map network drive"
(Dutch: "Netwerkverbinding maken").
You tick the option "Reconnect at logon" (Dutch: 'Opnieuw verbinden bij
aanmelden"). If you don't, Windows doesn't initially make the connexion, so you'll
have to do it manually when you need it.
This can only be done in Windows Explorer, not directly where you need it.
If you do tick the option, Windows automatically makes the connexion when
starting the computer, because then you log on to the network. This is fine.
There are two problems though:
The only point where the drive connexion is made on demand is in the
left window of Windows Explorer, when you click on a collapsed drive
letter to expand it. It is not automatically connected when entered
in a path in the Open File dialog of an application, and not when
trying to go to that drive in the Windows console (formerly known
as "MSDOS box").
Then when I go to Explorer to connect via "Map network drive", it
has the audacity to warn me that drive x: is already connected to
path xxxx, (it isn't, why else do you think I'm connecting it?) and
whether I want to connect to the (exact same!) path xxxx instead?
Yes, but why didn’t you already do it yourself instead of bothering
me with it?
Now you might argue, why do you use these stupid drive letters in the first place? I agree that they're clumsy, because what is m: as seen from one computer is d: from another, so you can't use the same reference to such a drive from any computer in the network without change.
The way Linux and other Unixes handle this is much better: there you mount a disk drive or partition into a point in the existing tree, so what is a drive letter in Windows becomes a directory, and thereby a part of the path name, in those systems. For example, in Windows, I could have a drive c: for operating system and applications, and a data drive d: for my own documents. In a Unix system, c:\ would be /, and I could mount the other disk to /data (or any other path I choose), so d:\mydir in Windows corresponds to /data/mydir in Unix. The only disadvantage is you get longer pathnames, but BSD-like Unixes can use symbolic links to overcome that.
Windows and Internet offer something similar to mounting a disk into the directory tree: virtual machine names, preceded with two backslashes (slashes on Internet) instead of one. The clear advantage is that such names are the same, regardless of the network computer you are on. But unfortunately, this only works in Windows GUI programs. In the Windows Console (which is no longer a 640 kB MSDOS, and which I still regularly use, because many program simply don't need a fancy GUI interface), you cannot cd (chdir; change directory) to \\machine\rootdir\somedir. That is, the system lets you wait for several seconds, apparently looking for something, but it never finds anything, not even with a valid name.
Copyright © 2000-2001 by R. Harmsen.
Updated 28 January 2001.
20 January 2012: removed donation link.