Home Acknowledgements Bible Copyright Out of Copyright Copyright info Fonts History Concept Innovations Vowel pointing & Accents Tregelles Text BHS Oxford User Guide Displaying Bibles Separate Lexicon Button Bible and Lexicon Searches Automatic Concordances Search Results and History Screen Shots Greek Grammar System Hebrew Grammar System Lexicon Enhancements Microsoft Bugs BL Bugs & Tips Stem - Lexicon Matches Strong's Abbreviations Thayer's info Gesenius' Lexicon Middle Liddell Emphatic Diaglott Codex Sinaiticus Codex Vaticanus B

Microsoft bugs and failings discovered whilst writing Bible Linguistics

To be fair to Microsoft, which is more than they are to their competition, we did use their software. We used Word 2000, Access 2000, Excel 2000, Windows XP and character map. Here are some of the disasters that befell us as a result!

1. We tried Word 2010 and it was 60x slower in loading a 50 MB 10,000 page word document and 60x slower in converting said document to html than Word 2000. Word 2000 opened our 50 MB document in 20 seconds and converted it to html in 30 seconds. Word 2010 achieved the same results, but in minutes. Also a 4MB word 2000 file becomes a 28MB Word 2010 file. So in short unless you absolutely have to 'upgrade', stick with the far more powerful Word 2000.

2. If you import a large text file into Microsoft Access 2000 it will scramble the order of the records in the text file (whether you permit Access to add an index or not). It is better to copy the file to the clipboard and then paste append it into an Access table. Pasting into Access does not work with large files. Paste Appending does - very well.

3. If you export a table from Microsoft Access 2000, it will scramble the record order yet again. So give the table an index, then copy paste that index into a text file and compare it with the scrambled index of the exported file using a text file compare program such as the excellent and free WinMerge. Then manually unscramble it according to the shuffle order that WinMerge reveals. 

4. If you do quite a lot of work in one Access database it grows at an absurd rate until it reaches 2GB when it stops working. But Microsoft Access does not tell you it has stopped working. Instead it gives you a series of errors that it represents you have made when in fact it is Access itself that is at fault. It will say 'invalid command' for example when you have made a perfectly valid command. The fix is to compact the database which in our case then shrank from 2GB to 24MB! It shrank by 99%. We therefore recommend compacting Access databases as soon as they reach 250MB.

5. If you search for a paragraph marker in Microsoft Word 2000, then you use the code ^p in the find box. Word then finds all of the paragraph markers in your document (normally). But actually there are some paragraphs markers in some documents that it does not find. These seem to arise when large tables are used. These can be found not with ^p but with ^13. 

6. When you search for a character in a font which uses an extended character set as most of them do, Microsoft Word will sometimes mistake a character at or above alt 0128, i.e. in the extended character set, with a similar character in the keyboard character set (below alt 0128). We found this with alt 0039 and alt 0145 and alt 0146 with the Bwhebb font. Word kept sticking Qamets vowels where they shouldn't be. It was in fact mistaking an acute accent (0145, 0146 latin) for an apostrophe (0039 latin). The fix was to de-accent the Hebrew before we started doing find replace operations upon it.

7. Word by default assumes that you are an illiterate moron and edits your document proactively by capitalising or decapitalizing and autocorrecting your text as it sees fit. This will totally corrupt a file in a foreign character set. The fix is to turn off all the auto correction functions in Word. In other word treat Microsoft like the moron.

8. When you dedupe a file (remove duplicate entries from it) in Microsoft Access, the dedupe process is not case sensitive and there is no option to make it case sensitive. The fix we found was to use this great website www.textmechanic.com. Just copy paste your data into his data box and check the case sensitive box and hit the 'remove duplicate lines' button and count to 5 and your 500,000 record file is deduped in a case sensitive way. Just imagine what these sorts of people could do if they had 1% of the funding of Microsoft!

9. If you highlight a table in Microsoft word by clicking on the top of the column so that the whole column goes black indicating that it has been selected then you are being deceived. If you do a find and replace supposedly in that column you will corrupt your entire table. Instead you have to use the table menu and choose select and then column. That highlights the column in precisely the same way but only finds and replaces in that column - most of the time. Also you must choose to search down only to keep things localized to one column.

10. If you do a lot of find replace operations in a Microsoft Word document (more than 250,000) word will run out of memory which is being used to store these edits in order to enable you to undo them. At this point it will suddenly become unable to save your work which means you lose all the edits that it was remembering! So make sure that you save the document after 250,000 edits and close it and re-open it to reset the undo store.