per page, with , order by , clip by
Results of 1 - 1 of about 6 for backslashes (0.000 sec.)
What I dislike about Windows and Word
#score: 11698
@digest: 828daf7afc0a2e27194f26e2a8a48606
@id: 1441
@lang: en
@size: 26047
@type: text/html
content-type: text/html; charset=UTF-8
viewport: width=device-width, initial-scale=1
#keywords: pentium (58591), windows (55714), drive (50480), network (43487), hardware (38361), paragraph (37241), computer (34729), annoying (34535), connect (34297), cursor (32799), drives (32741), connexion (32621), properties (32195), seconds (30545), word (29815), cell (29801), win95 (27462), bugs (26027), table (25522), application (25454), behaviour (25204), versions (24609), applications (24510), memory (23109), million (22789), explorer (22005), connected (21532), disk (21003), worse (20986), features (20876), second (18838), files (18009)
What I dislike about Windows and Word Table of contents Introduction 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 Word 5.1 and 98 for the Mac Annoying behaviour in Win95, which is worse in Win98 Annoying behaviour in Win95, which is still in Win98 Introduction 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: Bugs in Word 6, 97 and 2000 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. The cursor and tables in Word 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? Storage of styles (opmaakprofielen) 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 and screen resolution 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: The number of remembered files opened earlier is 4 by default, and can be set to a maximum of 9. With modern graphics card and monitors, a resolution of 1024 by 768 is quite workable and usual, and that easily leaves room for over 20 remembered files. With intensive use, for many different projects at the same time, many files in various different directories, such a longer list is also needed and useful. If the path of a remembered file is rather long due to sub-directories, part of the path is abbreviated to three dots. When working with different versions of files with the same name in different directory (e.g. a file being translated, and a backed-up untouched original), the dots often hide the essential, distinguishing part of the path, making it impossible to see what is what. Modern screen resolutions leave plenty of room to show the full path, but Word's designer don't make use of it. A related problem: the screen heading shows the name of the currently edited document with the file name only, not with the full path. In a situation as referred to above (files with the same name, but different paths), files become indistinguishable, you can't see which file you're working on. For file identification I often have to rely on one file being read-only ... When I see things like this, I wonder: has this software really been tested with real and experienced users, or only with beginners? Note that novice users are quickly becoming extinct these days, so focusing on them is increasingly the wrong approach. Bugs in Word 2000 that weren't there in Word 97 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. File size: A problem in Word 6 that gets worse with every new version 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. Word 5.1 and 98 for the Mac 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. Annoying behaviour in Win95, which is worse in Win98 Slow start-up 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): Time-outs when checking non-existent hardware. Most hardware needn't be checked at start-up. Because modern hardware is fast, long time-outs aren't necessary. The hardware configuration doesn't usually change, so there's no need to look for new hardware (which Windows often doesn't even find anyway, even if it is there). The floppy disk for example need not be checked. Everybody normally boots from harddisk, the floppy drive is used about once a week nowadays, and if it fails, the moment when the user attempts to use it is a good moment to be told about it. The BIOS also checks hardware, and uses about 15 seconds to get started. That too is far too long. I have a suspicion that the registry is read into memory in its intirety. This wastes memory, and hardly makes applications faster (reading a small ini-file when it is needed is fast enough). The old procedure with ini-files, common in Windows 3.0/3.10/3.11, was much better: An application could keep its ini file(s) in the directory where it also had its executable file(s), dynamic load libraries (DLL), and data directory and files. An application depended on itself, and not on Windows. It read its ini files only when and if needed, on demand . The Registry was meant to be clearer than the ini-file. Instead, the registry contains no explanatory comments, and many many completely incomprehensible hexadecimal codes. In practice, the old ini-files were much easier to read and understand. The registry that is read into memory at start-up is probably also the reason why Windows has to be restarted so often when installing an application, protocol or hardware. With the ini file approach, that wasn't necessary, because programs could re-read them when they needed a value. With disk caching, that wasn't slow, and saved memory. 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. Annoying behaviour in Win95, which is still in Win98 Network drives 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: If the other computer is not switched on, Windows doesn't immediately detect that the computer is off, but instead keeps trying to establish a connexion for several seconds, again for every drive to be connected. Every time again it then asks me if I want to connect at logon next time. Yes I do, but only if and when it makes sense, that is, with that computer switched on. With two computers in the house or in a small office, when trying not to waste energy, there's at least a 50% chance that the one computer is off when starting up the other. And I want drives mapped in both directions. To make this procedure even more irritating, Windows isn't aware of how the connexion is usually made. Whenever a logon to a network occurs, it tries to reconnect to all drives to be mapped. It even tries to map a drive which is on a computer that can only be reached through dial-up, when starting up Windows. Failure is one hundred percent certain then, because that dial-up connexion can only be made after Windows has finished its annoyingly long boot procedure. 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. Menu Top menu ...
https://rudhar.com/sfreview/dislwinw.htm - [detail] - [similar]
PREV NEXT
Powered by Hyper Estraier 1.4.13, with 1747 documents and 81086 words.