First Edition CD-ROM was published by Oxford University Press [OUP], International Computaprint Corp.,
  Bowker, and Tri Star Publishing (Fort Washington, Pennsylvania) as The Oxford English Dictionary
  Computer File: the Original Oxford English Dictionary on Compact Disc in December 1987 and phased
  out in December 1992.  DOS only, marketed in the U.S.A.  2 CDs and a 5¼ inch floppy.  Did not
  include any material post-1933.  44 million words.  ISBN 0944674003  [I’ve never seen it.]

Second Edition CD-ROM versions:
1992 - v1  1 CD, 1 diskette <==the version primarily discussed here
			    59 million words
			    User’s Guide by Donna Lee Berg (ISBN of Guide only 0199617260):
			      Spiral binding, comprehensive instructions and examples, 118 pages
			    ISBN complete package Windows 0198612605, Macintosh 0199617279
	Software Releases (all v1 releases, both PC and Mac, use the same dictionary data CD):
	1992: v1.0x	<== hard disk installation PERMITTED
                            Buggy. Uses different fonts than later v1.1x versions. DDE interprocess
                            communication NOT enabled. Replace with v1.10+ (e.g. v1.10 or v1.14,
                            below, which are freely available)
	1994: v1.10	<== hard disk installation PERMITTED
                            Single-user version of the OED for Windows
                            Windows v1.10 software is available at abandonware sites, e.g. here (registration required)
	1995: v1.11*	<== hard disk installation PERMITTED
                            “Windows Network Version” of April 1995, for site-licenced users;
                            works equally well in single-user mode;
                            manual installation (no SETUP file)
                            An OUP brochure described this version’s features.
                            N.B. The asterisk “*” in v1.11* is OUP’s idea
	1996: v1.13	<== hard disk installation normally NOT ALLOWED
	1998: v1.14	<== hard disk installation normally NOT ALLOWED
                      	    Windows v1.14 software is still freely available from OUP:
                              http://global.oup.com/fdscontent/academic/zip/ep/oed1_14.zip
			    Macintosh v1.0d software is also freely available:
			      http://www.oup.co.uk/zip/ep/oedv1.0d.zip
1999 - v2  2 CDs	<== hard disk installation normally NOT ALLOWED;
			    requires CD to be in drive at all times
			    ISBN 0192687883
			    Patch for Windows 2000/XP (Patch for Windows ME)
			    (I don’t own this version — not tested)
2002 - v3  2 CDs	    User Manual: Booklet, 59 pages
	Software Releases:
	2002: v3.0	<== hard disk installation PERMITTED with 70-90 day
			    revalidation (i.e. insert CD in drive)
			    Full Version: ISBN 0195218884
			    Upgrade (v2 → v3) Version: ISBN 0195218892
	2004-2005: v3.1	<== hard disk installation PERMITTED with 70-90 day revalidation
			    Full European Version (“Release 1”) 21 October 2004: ISBN 0198610165
			    Full USA Version (“Release 1”) January 2005: ISBN 0195222172
			    Upgrade (“Release 2”) August 2005: ISBN 0195222164
			    According to OUP’s vague announcement, v3.1 “incorporates software
			    improvements together with copy protection and still retains the clear
			    interface and easy-to-use functionality of the Oxford English
			    Dictionary (Second Edition) on CD-ROM version 3.0 … [plus]
			    almost 2,000 new words and phrases from the OED’s ongoing
			    research programme, as well as the full text of the OED Second
			    Edition, published in 1989, the Oxford English Dictionary Addition
			    Series (Volumes 1-3), published in 1993 and 1997, the Bibliography
			    to the Second Edition, and other ancillary material”.
	2007: v3.1.1	<== hard disk installation PERMITTED (70-90 day revalidation
			    requirement ELIMINATED!) 
			    v3.1.1 is available, for disks dated “2004” (new “2004,2005,2007”
			    disks will be supplied), by contacting OUP Tech Support;
			    or for disks dated “2004,2005” via a software patch.
			    (Can you still swap “2004” disks for “2004,2005,2007” disks, now that v4 is released?)
			    The primary purpose of v3.1.1 was to enable operation under Vista
2009 - v4		<== hard disk installation PERMITTED. See Amazon’s description.
			    Release date 21 May 2009.
			    Full Version Windows|Mac (U.K.|U.S.) ISBN-13 9780199563838,
			    ISBN-10 0199563837. £169.57+VAT | $295.00 MSRP ($212.40 at Amazon, $198 at eLearnAid).
			    Upgrade (U.S.) Windows-only “available to registered users of Versions 2.0 upwards.”
			    ISBN-13 9780199565948 ISBN-10 0199565945 £78|$79.95 MSRP.
			    There are also ‘Official Import Versions’ in Japan (Full ¥40,000 Upgrade ¥15,000),
			    with “a user manual translated into Japanese, as well as a Japanese technical
			    support helpline.” Inter alia,
			    “Now available to Mac [OS X v10.4+ PPC G4 or Intel Core Duo] users;
			    “Flash-base;
			    “Smoother and faster performance providing instantaneous search results;
			    “New word-wheel which supports incremental letter-by-letter browsing;
			    “7,000 new words and meanings;
			    “local CD-ROM/DVD drive (for installation); runs from hard drive only”[!]
			    Note that you must pay full price for the Mac version (the Upgrade is
			    Windows-only), and you can no longer upgrade from Version 1!

Third Edition (circa 2018? 2037? different publication dates are mooted)

Windows 7:

Second Edition/Version 1 softwares for x86 processors are 16-bit programs, so they will also run under Windows v3.x and NT v3.5x. Moreover, Windows v3.x can be emulated by other operating systems, so OED version 1 can be installed under e.g. Win-OS/2, or Linux with Wine (which supports Win32 programs also). Note, however, that 16-bit programs will not work out-of-the-box with 64-bit versions of Vista. A freeware solution is Microsoft’s Virtual PC 2007: install Win98 (or even Win3.1) under VPC on a Vista 64-bit platform, and 16-bit programs like OED v1.1x will run.

There are no Windows Registry entries, so you can install Version 1 manually if you want (uninstall simply involves deleting the OED files, in their single dedicated subdirectory).

Oxford’s original “tip sheet” for v1.10 hard disk installation was basically accurate (those instructions were deleted long ago, together with the entire OUP-USA v1 website; however see the surviving OUP-UK OED v1 support site, which contains some misinformation about v1 hard disk installation).

You may install both the datafile and the executables on drives with any supported file system — FAT, FAT32, NTFS (it doesn’t matter).

For no good reason, OED v1.1x requires that a “printer” (or at least a printer driver) be installed. It’s easy to meet this requirement, even if you have no hardware printer — see General Protection Faults: Printer Driver Incompatibilities (and Fixes), below.

Note that on multi-user machines, it is necessary to “Share” the directory where the OED executable (OED.EXE) is located; otherwise only the Administrator (or other user who installed the program) will be able to use the OED.

COPY F:\OED2.DAT E:\

It may be necessary to write a contiguous (defragmented) OED2.DAT file to hard disk (although under Win2000 and WinXP — the only OSes specifically tested for this issue — v1.1x runs successfully despite fragmentation). If only for speed, you should consider defragmenting your target hard disk volume before (and maybe again after) copying OED2.DAT onto it. In Win32, find the built-in defragmenter at Start key → [All] Programs → Accessories → System Tools → Disk Defragmenter (or just Run dfrg.msc). Alternatively, on WinNT+ only, run SysInternals’ single-file defragmenter Contig.exe against OED2.DAT.

v1.10 and v1.11* are distributed with a simple two-line OED.INI:

[data]
Filename=E:\

[OED]
ExeName=OED.EXE
PathName=E:\OED
ServiceName=OED

Root directory \ — Data File:
OED2.DAT	635,400,192  <== Copy to hard disk per “Automatic installation”, above
	Checksums:
	CRC32:	0f2c6998
	MD4:	bc3b708bf4307548f109ff888e3af6be
	MD5:	f30d97b59d007600a2322466bb2214fd
	SHA1:	626fab18cc9a25feafcf4080901c834e3ca05af7
Subdirectory \OED — System Files:
OED.EXE	447,280  <== v1.10 Standalone Version (MD5: d1438ba83e3f16b470a14cbdfa48c895)
  or
OED.EXE	443,856  <== v1.11* Network Version (MD5: e05ce1fbd45cea33f86b30a8720824d9)
IPC.DLL	 20,436  <== needed for InterProcess Communication [DDE] (MD5: bd8f927673da3c86a6dbbf39a0563849)
OED.HLP	160,450  <== optional
OED_LOGO.BMP	140,680  <== the splash screen (MD5: 2e799e0416a7c2bb9d633b1d51e4cffb)
XWI321.DLL	211,285 (MD5: e21eb111b54216f4fe85f9b264891832)
XWI321TE.DLL	 58,759 (MD5: ffe09005e024b89004782137ca0d15b7)

ARIOUP.TTF	Arial OUP
ARIALSC.TTF	Arial Small Caps OUP Regular
ARIBIOUP.TTF	Arial OUP Bold Italic
ARIBOUP.TTF	Arial OUP Bold
ARITOUP.TTF	Arial OUP Italic
HADAS.TTF	Monotype Hadassah
IPA.TTF	Plantin Regular		[v1.11* only]
PI6OUP.TTF	Pi6OUP MT
PI7OUP.TTF	Pi7OUP MT
PI8OUP.TTF	Pi8OUP MT
PI9OUP.TTF	Pi9OUP MT
PI10OUP.TTF	Pi10OUP MT	[v1.11* only]
PLANOUP.TTF	Plantin OUP
PLANBOUP.TTF	Plantin OUP Bold
PLANIOUP.TTF	Plantin OUP Italic
PLANSC.TTF	Plantin OUP Small Caps
PLANZOUP.TTF	Plantin OUP Bold Italic
PORGRK.TTF	Porson OUP Greek One
PORGRK2.TTF	Porson OUP Greek Two
TNRPHON.TTF	Times New Roman Phonetic

Install the 18-20 fonts using Control Panel → Fonts → File → Install New Font (be sure to check the box “Copy fonts to Font folder” in the “Install New Font” [or “Add Font”] dialog).

You may now run “OEDXP.EXE /F” against your installation, to confirm that all Files and Fonts are correctly installed and recognized by the operating system.

If you are now tempted to remove the \OED\FONTS subdirectory, if it exists, to recover disk space, don’t do it! There’s a distinct possibility that someday you’ll need those backup copies of the fonts again (see various font problems that can arise, below). However, you may delete the *.FOT font descriptors, if any, in \OED\FONTS — they aren’t necessary.

You may need to implement one (or more) of the two general mechanisms, below, for “finding” the dictionary data file OED2.DAT; these are especially important if your computer has multiple removable drives, and/or unusual driveletter designations. In most cases, however, OED.EXE v1.1x will simply find OED2.DAT (no matter whether hard disk file or CD) as long as it is present in a root directory.

A Desktop “Shortcut” (PIF or LNK) which launches the OED may “Start in” either the directory of executable OED.EXE, or the root directory of OED2.DAT.

Note that there is no copy protection for either the original data CD or for the OED2.DAT dictionary data file; you can simply burn OED2.DAT to the root directory of any CD, and it will run happily — as long as OED2.DAT is on a CD. If however you want to run v1.13 or v1.14 off hard disk, you must make and mount an image file, perhaps using Mkisofs and a CD-ROM emulator like Virtual Clone Drive or Daemon Tools. An alternate, light-weight (8Kb device driver + 23Kb control panel) CD-ROM emulator is an unsupported freeware package from Microsoft(!) called winxpvirtualcdcontrolpanel_21.exe, which claims that it requires WinXP Pro or Home, but which works with Win2000 (and maybe other OSes) too. It supports OED v1.1x, and places very little load on your system (it lacks the robust features of Daemon Tools, but if emulation of an OED v1.1x Data CD is your only requirement, then this is an alternative choice). Beware that this last-named emulator can establish SUBST-like drives on every driveletter below the drive that you pick for your emulated “CD” — and because drives X: Y: or Z: fail due to a bug, this could involve the pointless allocation of precious resources. The Readme included in the self-extracting ZIPfile explains installation and image file mounting adequately, but fuller instructions are available here. In my opinion, Virtual Clone Drive is the better choice. Thanks to William Farrar for this tip.

OED v1.14 contains the same data and executable files as v1.10|1.11*, with these exceptions: IPC.DLL is no longer included; UNWISE.EXE is added (used to uninstall the OED application); and three different M$Word macros are also included. During SETUP.EXE installation, when offered the option to install a M$Word macro, skip it (the default action): a much more sophisticated macro is discussed below, and can be downloaded from this website.

The 18 True Type fonts of v1.14 (listed below) are different than in v1.10 or v1.11*, and they are automatically copied by SETUP.EXE to [BootDrive]:\WINDOWS[or WINNT]\SYSTEM (perhaps the right place for them under Win v3.x, but not the ideal location under Win32 — see further font information, below). As with v1.10 and v1.11*, install the 18 fonts using Control Panel → Fonts → File → Install New Font (and be sure to check the box “Copy fonts to Font folder” in the “Install New Font” [or “Add Font”] dialog).

You may now run “OEDXP.EXE /F” against your installation, to confirm that all Files and Fonts are correctly installed and recognized by the operating system.

ARBOUP97.TTF	Arial OUP Bold
ARCOUP97.TTF	Arial OUP Small Caps Regular
ARIOUP97.TTF	Arial OUP Italic
AROUP97.TTF	Arial OUP
ARZOUP97.TTF	Arial OUP Bold Italic
HADAS.TTF	Monotype Hadassah
PI6OUP.TTF	Pi6OUP MT
PI7OUP.TTF	Pi7OUP MT
PI8OUP.TTF	Pi8OUP MT
PI9OUP.TTF	Pi9OUP MT
PLBOUP97.TTF	Plantin OUP Bold
PLCOUP97.TTF	Plantin OUP Small Caps Regular
PLIOUP97.TTF	Plantin OUP Italic
PLOUP97.TTF	Plantin OUP
PLZOUP97.TTF	Plantin OUP Bold Italic
PORGRK.TTF	Porson Greek OUP One
PORGRK2.TTF	Porson Greek OUP Two
TNRPHON.TTF	Times New Roman Phonetic

Option 2: OED v1.1x under Crossover
The OED v1.1x runs under Crossover for Macintosh. (v1.13 and v1.14 require that you set up OED2.DAT as a CD drive, real or emulated). Crossover probably will not work with OED v3.x, due to C-Dilla/CD-Cops copy protection. One potential workaround might be to install OED v3.1 under true Windows on a dual-boot Mac machine, and then consult it under OS X.

See also two more descriptions (the second is very detailed) of successful v1.1x installations on SuSE 8.1, and Kanotix [Debian], platforms using Wine, as well as recipes for Kanotix (basically Debian Sid) and Wine 0.0.20050524-1 (among the “comments”); and Ubuntu v6.06 and v9.04 using Wine (very straightforward).

This is a watershed moment for many users. They never surmount this hurdle. They’ve already placed the OED data file on (for example) drive N: (or any drive lettered lower than our hypothetical CD drive F:) — which may be, variously, a second CD|DVD drive, or a local or remote hard disk. It would have been less problematic to put the OED on a drive lettered higher than F: (e.g. D: or E:). But they still have options:

• Hit “Cancel” (instead of “Abort”), and the OED.EXEcutable will continue to search for a drive with a root directory containing OED2.DAT. In the cases of v1.10 and v1.11*, both hard and CD drives are searched; in v1.13 and v1.14, only CD drives are searched.
• Reassign the driveletter of your CD from “F” to any letter after “N” (if you have Administrator rights under NT4/2000/XP/Vista, open Control Panel → Administrative Tools → Computer Management → Storage → Disk Management → right-click on drive F: → Change Drive Letter and Paths for F:)
• Or (simplest, best, recommended, and often the only effective solution) establish the OED environment variable “OED” (e.g. using the DOS command “SET OED=N:”; or — recommended! — to establish the variable globally under e.g. Win2000 or XP Pro, open Control Panel → System → Advanced → Environment Variables [in WinXP, this is a small box at the bottom of the Advanced tab] → in System Variables [so that all users have access to it, not just the current user], click New → under “Variable name”, add “OED” and under “Variable value”, add “N:”, click OK, and then Reboot.)

In formal terms, OED.EXE recognizes two general mechanisms to override the default behavior and “find” the dictionary data on a different drive than the first removable device, whether it be a CD or a hard drive volume. The most reliable pointer for v1.10 and v1.11* is the OED variable. In order of priority, OED.EXE v1.10|v1.11* will:

1) Consult the environment variable OED.  “SET OED=d:”, either (local)
   in an individual DOS session (e.g. “SET OED=N:”), or (global) in the
   System Environment, thus affecting all sessions.
2) Search local disks for a hard disk or CD labeled “OED2”.  Command
   at DOS “LABEL N:OED2”.  Because the original data CD was LABELed “OED2”, the
   hard disk where OED is relocated should also be LABELed “OED2”.  Hard disks
   should all be lettered higher than (i.e. above or before) the first CD drive on your machine.

v1.14 reverses the above priority; it cares more about the LABEL on the “CD” (real or virtual) than the OED variable.

The “Filename=N:\” spec in the “[data]” stanza of OED.INI is NOT consulted; it simply assists word processing macros, which obtain DDE (Dynamic Data Exchange) interprocess communication parameters from OED.INI. In other words, OED.INI is not required.

If you’re using the actual CD-ROM disk as your dictionary (not a copy on a hard disk), you probably don’t need either of these mechanisms, because OED.EXE will find the CD as long as it is in the first CD drive. (OED v1.10 and v1.11* will usually find OED2.DAT, either on hard disk or CD, if it is in any local root directory. No assistance from either of these mechanisms is usually required, but if OED generates a “Cannot read from drive d:” error, then set the OED environment variable [Method 1) above].)

With any OED v1.x version, employ the OED.INI format required by v1.14 of the software — this affords additional flexibility. Paste the lines below into file OED.INI, changing only the “Filename=” and the “PathName=” specs to point at your OED EXEcutable installation, and the “Wait=” value to represent the duration of OED initialization on your computer. Note that the “Wait=” duration is machine-dependent: longer for slow machines (5-9 seconds), shorter for fast machines (3-6 seconds). It should roughly correspond to the number of seconds that the blue Oxford shield is displayed when OED.EXE is not cached in machine memory, e.g. when you run it for the first time in a session (on subsequent launches it will start much faster):

[data]
Filename=E:\

[Macro]
ExeName=OED.EXE
PathName=E:\OED
ServiceName=OED
AppName=Oxford English Dictionary (Second Edition)
Wait=4

Note that OEDXP.EXE does not require OED.INI at all, unless OEDXP is used in conjunction with (called by) a word processing macro. OEDXP has its own runtime arguments, which replace those in OED.INI. OED.INI is only required by this website’s M$Word, OpenOffice, and WordPerfect word processing macros — otherwise it is not needed.

Note too that when v3.0 was first published, you needed to be logged on as Administrator just to run OED v3 under Win2000 or WinXP. This requirement has been dropped. According to OUP, “Local Administrator permissions are no longer required to run the OED as long as the latest version of the authentication process is installed. This can be downloaded from [OUP’s] Authentication Drivers page” (it amounts to an update to C-Dilla). Lots of other potential v3 snags and snafus are documented by OUP here.

Here’s how to overcome the 90 day revalidation requirement for v3.0 only (but not v3.1, which beefs up the copy protection by using CD-Cops):

E:\IMAGES\OED_CD_3.BWI  789,592,272  <== the data image
E:\IMAGES\OED_CD_3.BWS   32,228,256  <== the CD subcodes and disk parameter descriptors — possibly(?) optional
E:\IMAGES\OED_CD_3.BWT          630  <== the TOC (Table_Of_Contents) file

E:\IMAGES\OED_CD_3.B5T  789,592,272  <== the data image

[FILE_PATHS]
CD_PATH=N:\  <== change this driveletter to the Daemon Tools virtual “CD drive”
INSTALL_PATH=E:\OEDV3\  <== leave this spec (whatever it is) alone!

When quarterly revalidation time rolls around (the software demands that you insert the CD, but gives you a 20-day countdown warning), don’t insert anything — just push the “Finish” button. The software construes your image file to be the actual data CD, and revalidates for another 90 days. So you no longer need your CDs, because you’re fully installed on your hard drive.

v3.1 was initially released in 2004. In the words of one user, v3.1 added “about 9 new words [to v3.0] as window dressing, ironclad CD-Cops v1.65 copy protection (instead of C-Dilla a.k.a. ‘SafeCast 2’, which is no longer part of the product), and little else” [actually, OUP claims 2000 “new words and phrases”, although I suspect that most are probably modern jargon, i.e. not words that you ordinarily look up in the OED]. The v3.1 discs were reissued in 2005 as “Release 2”, reportedly to add a single word that had been inadvertently omitted from the 2004 discs. You can tell which discs you own, because the year of issue is stamped upon them. The most onerous aspect of these releases is the 70-90 day revalidation requirement, inherited from v3.0. CD-Cops completely frustrated revalidation from a CD emulator — you had to carry the data disc with you if you planned to travel for long. (Note that you can force revalidation, to obtain a fresh 90-day “lease”, by holding down Ctrl-Shift while clicking on the OED shortcut icon.) Release 1 was rife with revalidation errors; OUP had to issue a CD-Cops patch to fix them. Some users could never get it to work on certain hardware, or validation simply stopped functioning after a few reauthorizations. They'd reinstall their entire operating system trying to get it to load – a new definition of desperation. Kapersky and Norton AV sometimes blocked it. Customer reviews at Amazon convey the rich flavor of these experiences, along with the nightmare that OUP calls “Tech Support”.

Then, in early 2007, OUP issued a software patch called “v3.1.1”, which confers two big benefits: it eliminates the 70-90 day revalidation requirement under “Windows 98SE, ME, NT4, 2000, and XP”; and it enables v3.1 under both 32- and 64-bit versions of Vista and 64-bit versions of XP. Owners of Release 2 v3.1 discs dated “2004,2005” (not “2004”) with key numbers FT39P-9UFX-L92Q or URAP9-Z2M9-R6EH only (these two keys seem to apply to most, maybe even all, of these discs) may download the v3.1.1 patch (read the instructions before applying the patch, and authenticate with your key number translated to lower case and no hyphens, i.e. ft39p9ufxl92q or urap9z2m9r6eh); otherwise obtain v3.1.1 by contacting OUP Tech Support. Owners of v3.1 discs dated “2004” are (or were) invited to return them to OUP Tech Support, in exchange for “Full” Version 2005 discs, to which the patch can then be applied (after uninstalling the 2004 version, and performing a “Full”, not “Typical”, reinstallation), or for newly remastered 2007 discs. Briefly, in March 2007, the UK v3.1 tech support website said: “If your OED v3.1 CDs do not show the date 2005, then you can exchange them for the OED v3.1 Release II free of charge, on receipt of the old ones. Please send CDs to … Technical Support with your name and address and the reason why you are sending them.” You may need to reinstall from scratch: instructions that accompanied one early set of disks required that this patch be applied before first use, and before entering the authentication code (supplied in a letter from OUP — you must contact OUP directly to obtain the code unless your key number, a.k.a. authentication/validation code, is one of the two numbers mentioned above); however, the current online instructions suggest that the OED may already be installed and running, and therefore reinstallation should be unnecessary (indeed, a newer version of the patch has been posted). All this complication seemed to arise as an interim emergency measure under the pressure of frustrated Vista users. Remastered disks of v3.1.1 dated 2007 incorporated these changes and obviated the need to apply any patch. v3.1.1 also upgraded CD-Cops to v1.71.

Altogether, v3.1.1 represented a rebirth of trust & openness at OUP: v3.1.1 was the first version of the OED since v1.11* (anno 1995) that could be freely installed on a hard disk without further hindrance. It works as advertised. Kudos to OUP, for restoring some sanity to their marketing. OUP appeared to be endeavoring to repair a battered reputation, to be reaching out generously to its customers at real cost in time, trouble, and money. v3.1.1 presaged the U-turn in DRM policy that emerged more clearly (if not quite completely) in v4…

The net result of v3.1.1 is software that works without annoyance. It isn’t particularly fast, and the interface is clumsy. But it’s the OED nonetheless — and you can install it on your hard disk.

Note that v3 will crash and ask you to reinstall the software(!) for the trivial reason that OED.INI (which resides in %SYSTEMROOT% or %windir%, e.g. C:\WINDOWS) is missing. This might happen if you overwrite OED.INI because you also run other versions of the OED, or if you aren’t privileged to write to %SYSTEMROOT%. Just use a plain-vanilla generic OED.INI to avoid this herculean task, with its array of CDs, verification, and what-not, then fine-tune the various options after you’re up and running. Something like this will suffice (set both [FILE PATHS] specs to the uppermost OED directory):

[FILE_PATHS]
CD_PATH=C:\OEDV31\
INSTALL_PATH=C:\OEDV31\

[OPTIONS]
WOTD=OFF
AUTO_SEARCH=OFF
LAYOUT=ON
ENTRY_HISTORY=10
SEARCH_HISTORY=10
TIPS=OFF

[PREFERENCES]
PRONUNCIATION=ON
SPELLINGS=ON
ETYMOLOGY=ON
QUOTATIONS=ON
QUOTATION_DATES=ON
ADDITIONS=ON
RESULTS_PER_PAGE=10
SORT_ORDER=0
LIST_BY=1
HEIGHT=0
WIDTH=0
XPOS=0
YPOS=0

v3.1.1 uses 22 dedicated True Type fonts:

aribioup.ttf   66,520  1996/9/20  Arial OUP Bold Italic
ariboup.ttf    61,332  1996/9/20  Arial OUP Bold
arioup.ttf     64,548  1996/9/20  Arial OUP
aritoup.ttf    60,672  1996/9/20  Arial OUP Italic
hadas.ttf      45,028  1993/4/16  Monotype Hadassah
pi6oup.ttf     19,724  1996/9/20  Pi6OUP MT
pi7oup.ttf     28,756  1996/9/20  Pi7OUP MT
pi8oup.ttf     28,868  1996/9/20  Pi8OUP MT
pi9oup.ttf      3,840  1993/4/15  Pi9OUP MT
Pitenoup_.ttf  17,348  2001/4/26  PiTenOUP MT
PLAABI__.TTF   80,016  2001/8/15  Plantin for OUP Alt Bold Italic
PLAAB___.TTF   75,308  2001/3/15  Plantin for OUP Alt Bold
PLAAI___.TTF   81,036  2001/3/15  Plantin for OUP Alt Italic
PLAA____.TTF   74,552  2001/3/15  Plantin for OUP Alt
planboup.ttf   63,900  1996/9/20  Plantin OUP Bold
planioup.ttf   68,096  1996/9/20  Plantin OUP Italic
planoup.ttf    65,288  1996/9/20  Plantin OUP
planzoup.ttf   70,032  1996/9/20  Plantin OUP Bold Italic
plcoup97.ttf   27,192  1997/7/28  Plantin for OUP 97 Small Caps
porgrk.ttf     54,672  1996/9/20  Porson Greek OUP One
porgrk2.ttf    11,228  1996/9/20  Porson Greek OUP Two
tnrphon.ttf    29,024  1996/9/20  Times New Roman Phonetic
    Total:  1,096,980 bytes

An OSX user writes (11/2006): “I just installed v3.0 onto a MacBook Pro (via Daemon Tools [with] Safedisk emulation checked, after applying Safedisc2Cleaner v1.20 to the SCRfrsh.exe infection) running Windows XP on Parallels Desktop. It works well. A Windows ‘print to pdf’ program delivers results to my OSX desktop via the OED ‘Print’ command.”

Another OSX user writes (4/2007): “I installed v3.1 [Release 2 dated 2005] in Parallels Desktop on machines configured with Windows XP and Windows Vista, and immediately ran the new [2007 v3.1.1] OUP software patch. I was asked to enter my CD-ROM sticker number, and everything works. This is great. No need for dual boot.”

The same user also experimented with Apple’s Boot Camp. He installed OED v3.1 Release 2 (using 2005 disks) under Windows Vista, and then applied the 2007 v3.1.1 software patch. “Everything works, as expected.”

Another OSX user was upgraded for free from v3.0 after complaining to OUP-US Customer Service about authentication problems: “v3.1.1 (2007 disks) works very nicely … on my Apple Powerbook, running Windows XP Professional via BootCamp.”

A Linux user, who for five years(!) had been trying to get various iterations of v3.x to run under SuSE and openSuSE, finally succeeded (2/2008) with OED v3.1.1 and 32-bit openSuSE 10.3. “I just used the technique of exhaustion: if at first it doesn’t work, do it again (and again, and again) in a different order, and hope for the best. Eventually, it worked.” To no avail, he had tried “Win4Lin, VMWare, Xen, CrossOverOffice, and Wine, repeating with each new release of SuSE, plus Mandrake/Mandriva and other Linux flavours.” Success came at last with VirtualBox OSE (open-source edition), a free Innotek product installed with openSuSE’s built-in YaST installation tool, hosting a WinXP Pro virtual machine.

Technical Requirements (per OUP website)

Installation

• Macintosh users simply copy (drag) the two parts of a single “OED4” DMG disk image from OUP’s two installation CDs to a Tiger+ desktop (or to any storage medium, e.g. an external drive), double-click the parent OED4.dmg file, and voilà: “OED v4.0.app” is ready to run. Amazingly, the Mac software seems to have no copy protection or verification baggage whatsoever. It’s even portable: copy “OED v4.0.app” (655Mb) to a memory key, and hit the road. Notwithstanding OUP’s stipulation that v4 “runs from hard drive only”, in fact the OS X app runs perfectly well on a burned CD (albeit a tad slowly at first, but the dictionary is soon cached entirely in memory, and CD disk accesses are then limited to first-time routines); you won’t be able to save your Options or Bookmarks because CDs are read-only, so set the Options first in your read-write copy of “OED v4.0.app”, then make an ISO and/or burn it.

• Windows upgraders need to insert their old v2|v3 Data CD once, at the outset of installation. After installation, Full and Upgrade version users both must make sure that the v4 “Install” disk (not the “Data” disk) is back in the drive and recognized (spinning) before they launch the OED for the very first time, otherwise they will have a mystifying encounter with SecuROM, which “protects” the Windows installation from folks like you, the legitimate purchaser of the OED for probably the umpteenth time (you’ll recognize SecuROM by one of its signature vague messages, “A required security module can not be activated. This program can not be executed.”). Thereafter, you won’t need your CDs anymore. The Getting Started booklet says that “you must uninstall your previous version of the Dictionary before installing the new one”, but I have five versions installed on my machine, and they all run successfully (even concurrently), as long as you:
  • install the different versions in separate folders
  • swap version-specific copies of OED.INI into %SYSTEMROOT% (e.g. C:\WINDOWS) for v1.14, v2, and v3;  v4 does not generate an OED.INI in %SYSTEMROOT%
  
  Once you’ve successfully installed v4 on a machine, you can do just about anything with the liberated application’s “VM” or virtual machine (as distinct from the two installation CDs), e.g. make an ISO of the root OED4 folder and all installed subdirectories (=the OED VM), and run that in an emulator instead of the hard disk version. Or burn a CD of the app (the VM) and run that (launch “oed.exe” in the OED’s top-level directory). One virtue of this approach (installing|copying|running from an ISO) is that upgraders will never again require the old v2|v3 Data CD — essentially, they are creating an alternative installation method that is not subject to prior-version verification. An ISO (or a copy of it) runs perfectly, anywhere you locate it on the original installation machine; but after copying the ISO|CD of the VM to a different machine, you always need to insert the original v4 “Install” disc before the first use, to validate that you own it. You can only install a CD of the VM (the application) if you have two CD drives: on first use only, put the burned CD in the secondary CD drive, and the v4 Install disk in the primary CD drive.

  Obviously, something is written to your hard disk that enables it to “remember” that the OED is validated on that machine, without restricting its location (fixed disk, removable disk, virtual disk, CD) on the computer. That “something” is SecuROM, a particularly strong form of copy protection developed by Sony Digital Audio Disc Corporation (Sony DADC). SecuROM is notoriously difficult to expunge from computers (Registry entries and deeply buried files persist), and allegedly it writes to critical parts of the kernel (Ring 0). Gamers absolutely despise SecuROM, blame it for disabling unrelated programs, and accuse it of being a rootkit. Lawsuits pend against it. Although SecuROM denies many of the prevailing accusations and suspicions, SecuROM may be a v4 poison pill. The “Uninstal.exe” that is generated when you install v4 deletes the dictionary only, not SecuROM! (The v3.0 uninstall routine didn’t delete C-Dilla either, but C-Dilla created its own independent Uninstall, accessible from Control Panel → Add or Remove Programs.) You can try the ‘official’ Removal Tool available from a SecuROM website, but undeletable (because they contain null characters) Registry entries remain (at HKCU\Software\SecuROM) — apparently you’re supposed to be saddled with SecuROM for the life of your machine, which most tech-savvy users consider an outrage, magnified by Oxford’s failure to mention it or secure user consent (but see a solution, below). SecuROM has many optional capabilities that are activated by individual software publishers, e.g. limitations on the number of times an application can be installed, expiry dates, “online activation” (communicate encrypted data to “headquarters” surreptitiously — although you do not need to be online to install v4), blacklisted applications (apps that cannot be run concurrently with a SecuROM-protected app), even a “Postscribed ID (PID) technology … [that] add[s] unique ID codes or data … to produce individually identifiable discs.” Some of this sounds like intentionally-sown FUD (Fear Uncertainty and Doubt). The SecuROM capabilities applied to OED v4 are presently unknown. But sadly, OUP long ago passed that cross-roads where the dissemination of knowledge (once deemed to be Oxford University’s core mission, Dominus Illuminatio Mea) turned into the capitalization of knowledge. When OUP traffics with outfits like SecuROM, they stand in SecuROM’s many odors. Consider yourself warned.

  One small mercy of v4 is that it doesn’t balk when CD emulators (like Daemon Tools and Virtual Clone Drive) are installed and/or running. But it doesn’t like debuggers, at least during initialization — the OED simply won’t start (SecuROM error message). I use Microsoft’s (originally SysInternals’) superb Process Explorer as a replacement Task Manager, and I must kill it in order to launch v4 because SecuROM blacklists it. (One conjecture is that Sony is retaliating against Mark Russinovich, a co-author of Process Explorer, whose discovery in 2005 of the stealthy, uninstallable rootkit that Sony was putting on its audio CDs led to worldwide protest and a costly recall by Sony. Russinovich: “Not happy having underhanded and sloppily written software on my system… I checked the EULA and saw no mention of the fact that I was agreeing to have software put on my system that I couldn’t uninstall. Now I was mad.” That affair ended with a settlement in U.S. District Court for the Southern District of New York, and court-ordered supervision of Sony’s DRM development and EULAs. Later, Russinovich wrote a tool called RegDelNull that can either remove undeleteable Registry keys directly, or else replace nulls with asterisks and thereby make them deleteable by ordinary RegEdit means. If you uninstall OED v4 and you want to get rid of SecuROM too, there are two keys to delete (use RegDelNull first): HKEY_CURRENT_USER\Software\SecuROM and HKEY_USERS\<Computer specific key>\Software\SecuROM, where “<Computer specific key>” can be determined by searching the registry for the “SecuROM” directory key, under another key which looks similar to “S-1-5-21-3570084223-1426146163-3138021032-1005”, although your string will have different numbers — that’s your <Computer specific key>.)

• One way to avoid potential SecuROM complications is to bypass SecuROM entirely. Almost two years before the debut of OED v4, version 6 of the Shorter OED (SOED) was published on CD using open-source haXe/Neko/Screenweaver HX languages and libraries to compile a self-contained virtual machine (VM) for both Windows and Mac. It was an innovative concept, which delivered content to the screen via a bundled Flash player. However, OUP made a fatal error, more typical of novice programmers: they wrapped the finished application in a security shell, instead of putting security at the core and building the application around it (they’ve made this same mistake with virtually every program they’ve published on CD). SecuROM is so tough to defeat that OUP’s conceptual blunder shouldn’t have mattered; but OUP apparently also forgot that they compiled the Neko VM with open-source programs (largely unacknowledged, in apparent violation of the pertinent licenses:
  • No “prominent notices” of inclusion of GPL and LGPL software
  • Statically linking GPL code into the program but not providing the source code of the whole program under GPL
  • Statically linking LGPL code but not providing the source of the LGPL parts and the binary code of the non-LGPL parts to allow relinking with updated LGPL code
  • Placing restrictions on the use of the code outside of what GPL/LGPL allow, e.g. not “licensing at no charge to all third parties” under the LGPL and GPL (but note that this requirement is met, although oddly under Windows only, by the v4.0.0.3 update, below)
  ). The only mechanism that a Screenweaver HX virtual machine needs to launch is a generic boot loader, which haxe.org naturally supplies. In a final fit of folly, OUP merged SecuROM into the SOED boot loader as a single program, so customers who used the Screenweaver boot loader instead of the SOED boot loader quickly discovered that they could sideline the SecuROM wrapper and dive directly into the unsecured program under both Windows and (probably unnecessarily) OS X.

  One glance at the OED4 directory structure reveals that it too is an ordinary haXe/Neko/Screenweaver app, built precisely on the SOED6 model and containing all required libraries. Therefore, you can launch the OED without SecuROM by starting it with the standard Screenweaver boot loader, swhx.exe (144Kb) instead of the SecuROM-encumbered oed.exe loader (5032Kb; 6736Kb in v4.0.0.3). swhx.exe is freely downloadable from haxe.org: extract swhx.exe from the “swhx/tools/” subdirectory of swhx-1,2,0.zip ("unzip -j swhx-1,2,0.zip swhx/tools/swhx.exe"), and locate that one file in the base directory of your OED4 installation (where app.n also resides). The only thing swhx.exe doesn’t do is display a proper OED icon in shortcuts and toolbars (you see a Screenweaver icon instead — although you could use Resource Hacker to extract/replace it). One tech-savvy correspondent was simply unable to install v4; OUP customer service couldn’t resolve her problem despite a long struggle and many discouraging experiments, but the SecuROM-free Screenweaver boot loader/launcher overcame her bottleneck instantly. Customer service should keep a copy in their tool box. Consult your OUP (also haXe/Neko and Screenweaver [L]GPL + BSD) licences to determine whether they permit you to operate v4 in this manner. Note that this approach involves no modification of OUP files.

• SecuROM may protect the Mac installation in some obscure fashion, although it is difficult to see how it can be doing anything effective: the Mac boot loader “OED v4.0.app/Contents/MacOS/OED” is a bit-for-bit copy of Edwin van Rijkom’s “swhx” for screenweaver.org! Under Windows, SecuROM leaves clear traces of its presence, but I don’t know how to identify it under OS X.

• There are huge (640|617Mb) post-installation v4.0.0.3 updates for Macintosh | Windows (the latter a corrupt file, pursuant to OUP changes on 22 January 2013; use the OUP-USA Tech Support mirror instead). These refreshes of the code supply a new OED icon (a “carousel” of 20 books like the image on the CD case, except that one volume is open with a magnifying glass straddling the gutter – an amusing allusion to the generally-reviled two-volume “micrographic” Compact Version), and more importantly solve a few of the problems described below, albeit with a beefed-up SecuROM under Windows. Funny thing about this refresh: the Windows version calls itself “OED_update_4-0-3.exe” (655,401,876 bytes, MD5: 9fe0d6169a19738caf3fa8b99e76a632, downloaded 9 August 2010) but it doesn’t seem to require a previous installation, and it doesn’t seem to care whether you originally bought the full version or the upgrade — in fact, the freely-downloadable Windows update (but not the Mac update) is the complete v4 package (just as earlier SOED updates had been nearly complete save for a boot loader, pronunciation audio files, and some non-essential Help PDFs), and furthermore many correspondents confirm that if you use the SecuROM-free swhx.exe Screenweaver launcher described above, it doesn't ask that any disks be inserted to authenticate, and it functions pretty much like the Macintosh version: no copy protection or verification baggage, and no blacklisted apps either. OUP thus partially meets the licensing requirements of [L]GPL, which is no doubt gratifying to people committed to open source, but perhaps more important, a boon to the English-speaking world. Astonishing, actually, if you think about it... does OUP even fathom what they are doing here? Meeting a licensing requirement very very quietly (and thereby making the OED freely available), but in the subtlest possible fashion, recognizable only by technowhiz programmers... “If, on termination, [the OED_update_4-0-3.exe installer] tells you to reboot your machine, don’t do it. Instead, ... point your ‘OED v4.0’ shortcuts at swhx.exe instead of oed.exe, then test it. If you permit oed.exe to execute even once, you’re stuck with SecuROM forever” (or with the expunging rigmarole described above, which is no picnic – obviously, the smart thing to do is delete the factory file and then REName swhx.exe as oed.exe).

  The Mac v4.0.0.3 update lacks a number of required files, and cannot be installed in self-standing fashion (unlike the SOED v3.0.2.2 Mac update, which required only the "swhx.app/Contents/MacOS/swhx" bootloader from swhx-1,2,0.zip to be essentially complete).

Common elements

Verdict(s)

• New users may jump on it. The Full version price from discounters has never been lower, installation is simple and fast, the annoying array of Windows copy protections starting with v1.13 through v3.1 are largely removed (although anxiety lurks around SecuROM under Windows), the software bloat is gone, and the user interface is about as attractive as it is likely to get (the fonts, to my eye, are ugly sans-serif instead of the graceful Plantin fonts of v1-v3, but… we won’t quibble). If you’ve always wanted the OED, but never been willing to spring $800 or $400… how about $200?

• Why would a longstanding Windows user upgrade? From the user perspective, the experience of version 4 differs little from version 3. There are cosmetic changes and a bit more speed (maybe) due to the Flash-based user interface, but otherwise… not much to write home about:  a redecorated gateway to the same data. I’m willing to wait a few extra milliseconds to read a v3 definition (and frankly, I like the v3 “look” better, and the v1 “look” best: they’ve crammed v4 into a little box, and it looks like some impromptu canned app — a calculator maybe, or a Javascript popup). If you’re stuck at v2.0 or v3.0 level and annoyed with verification or C-Dilla malware, then v4.0 might be a welcome release; but if you dutifully pursued the OUP upgrade trajectory through v.3.1.1, then I see little gain and some specific loss (also risk, from SecuROM). OUP is certainly diligent about issuing new software versions, but note that while v3.1.1 supports Vista, v4.0 does not announce support for Windows 7|8 (and 9x|ME|NT4 no longer work at all), so v4 cannot claim to be a response to new versions of Windows. Ominously, users of v3.1.1 who experienced difficulty with Win7 were told by OUP customer service that Win7 is a “beta” and “Dear Sir, we do not support betas. We’re sorry for the inconvenience.” So look for yet another new OED update/upgrade soon, because Win7|8, Snow Leopard, and Lion are now officially released [update: see Tech Support website, paragraph 13].

  In truth, marketing hyperbole aside, the only thing that’s genuinely new (IMO) is Flash, residing under the GUI and invisible to the user. Flash may make a significant difference to future OED software development, but in v4.0 Flash doesn’t add anything concrete for a Windows user. New plumbing notwithstanding, it’s hard to escape the conclusion that OUP is simply assuring an income stream, and that they wholesale the OED to third-party sellers like Amazon at ever-lower prices in order to sustain interest. OUP could have waited for Windows 7, or liaised with Microsoft like other developers to ensure forward compatibility.

• The real reason, and perhaps the only sufficient reason, to upgrade to version 4 is the new, native Mac software — except that you can’t “upgrade”, you must buy the Full version! It works beautifully, and Mac users who’ve installed it are truly joyful. They waited 15 long years for this. Dual-system upgraders might think of their expenditure as a 29% discount (from Amazon) off the Full version of OED for Windows, with a versatile Mac VM thrown in for free (and no more Parallels or VMware or Crossover technogimmickry). Any way you analyze it, v4 for OS X is pretty good. The only serious criticism leveled so far at the Mac version specifically is that “it hooks cut/paste to do automatic word lookup, but there is no integration with the Macintosh dictionary framework… so that the data would be available through the OS supported search/lookup mechanisms.”

I invite reports and other opinions regarding v4.0.

• Map the local Daemon Tools virtual CD|DVD to the host’s hard-disk dictionary data file, e.g. E:\IMAGES\OED_CD_3.BWT|B5T. Mount this image manually the first time, to find out what local driveletter Daemon Tools assigns to the virtual CD — thereafter Daemon Tools will always use the same driveletter, e.g. M:. Make sure that OED_CD_3.BWT|B5T is in a Shared drive:\directory on the host.
• Map the host’s top-level OED v3.0 installation directory to an unused local driveletter, e.g. L:, with NET USE.
• Adjust your local OED.INI to reflect “CD_PATH=M:\” (the Daemon Tools virtual drive), and “INSTALL_PATH=L:\OEDV3\” (the local path to the top-level OED installation directory, just mapped with NET USE).

A sample STARTOED.BATch file may clarify these procedures:

@ECHO OFF
::	Mount the OED v3.0 image file
D:
cd \DAEMONTOOLS
::	Dismount currently mounted image file, if any
DAEMON.EXE -unmount 0
::	Mount OED data
DAEMON.EXE -safedisc on -mount 0,"\\OEDSERVER\E\IMAGES\OED_CD_3.BWT [or .B5T]"
::
::	Check whether OED host already mapped to L:, otherwise map it!
if not exist L:\OEDV3\bin\* NET USE L: \\host_IPaddress\E\IMAGES [password]
::	Mapping Examples:
::	… NET USE L: \\OEDSERVER\E\IMAGES meagain
::	… NET USE L: \\192.168.1.1\E\IMAGES
::	… NET USE L: \\209.28.144.70\E\IMAGES host_password
::
::	Launch OED
L:
cd \OEDV3\bin
start L:\OEDV3\bin\OEDCD_V3.EXE
exit

• With NET USE, map the driveletter of the host (server) machine’s OED v3.1.1 installation to an unused local driveletter, e.g. L:  In the example below, the OED’s top-level host directory is E:\OEDV311. It will be “net used” as L:\OEDV311 on the local machine — thus it acquires a different driveletter, but otherwise inherits an identical/mirror directory structure
• Make sure that “Sharing” of the OED drive on the host is enabled for “Everybody”
• Copy OED.INI from the host machine to the local %windir% or %systemroot%, e.g. C:\WINDOWS [or C:\WINNT]
• Adjust this local copy of OED.INI to reflect e.g. “CD_PATH=L:\OEDV311\” and “INSTALL_PATH=L:\OEDV311\” (the local path to the top-level OED installation directory — the “top-level” directory on the host is the folder that contains the Bin, Collects, Common, Data, Help, tempfonts etc folders)
• Copy the 22 (twenty-two) *.TTF fonts (totaling approximately 1Mb) from the OED v3.1.1 “tempfonts” folder on the host to a temporary directory on your local machine, and then install them locally via Control Panel → Fonts → File → Install New Font (be sure to check the box “Copy fonts to Font folder” in the “Install New Font” [or “Add Font”] dialog)
• Test it: Run “L:\OEDV311\Bin\oedcd_v3.exe” on the local machine. On first-time use only, CD-Cops v1.71 will demand your master verification code (enter it all lower-case), and then you will be asked to insert the v3.1.1 data CD (labeled “OED31R2_DATA”) on the local machine – click the checkmark after the CD is spinning and readable

You need to verify and insert the data CD on this initial use only; thereafter the OED will run hands-off, and validation will survive hard reboots. The OED does not need to be running on the host. In sum, you save almost 2Gb of hard disk space on your local LAN machine(s).

A simple BATfile for use in local machine Shortcuts might look something like this (leave the Properties’ “Start in:” box empty, lest L:\OEDV311\Bin not yet exist — i.e. let the START command’s “/Dpath” argument perform the CHDIR maneuver):

@echo off
if not exist L:\OEDV311\Bin\oedcd_v3.exe NET USE L: \\HOSTMACHINENAME\E /USER:UserName password /PERSISTENT:YES
if not errorlevel 1 start /DL:\OEDV311\Bin L:\OEDV311\Bin\oedcd_v3.exe
exit

• With NET USE, map the driveletter:\directory of the host (server) machine’s OED v4.0 installation to an unused local driveletter, e.g. “E:”  In the example below, the OED’s top-level host directory is “C:\Program Files\OED v4.0”. It will be “net used” as E:\ on the local (client) machine
• Make sure that “Sharing” of the OED drive on the host is enabled for “Everybody”
• On first use only, put the v4 Install disk in your local CD drive before launching the OED
• In Vista/Win7, you may(?) need to turn off UAC
• Customize the BATchfile below for your drives/directories, and then run it (it launches “E:\oed.exe” on the local machine)

You save 655Mb of hard disk space on each local LAN machine, at the cost of infecting each local box with SecuROM.

A BATchfile for use in local machine Shortcuts would look something like this (leave the Properties’ “Start in:” box empty):

@echo off
if not exist E:\oed.exe NET USE E: "\\HOSTMACHINENAME\C\Program Files\OED v4.0" /USER:UserName password /PERSISTENT:YES
if not errorlevel 1 start /DE:\ E:\oed.exe
exit

Star Office or OpenOffice.org:

• AutoLookup works only in Windows GUIs (not in DOS boxes, although you can Copy to the clipboard in DOS boxes by first turning on the capability to select text with your mouse (Properties → Options → Edit Options → check the QuickEdit Mode box), highlighting the desired text, and then Copying with Enter or with Alt-spacebar+“E”+“y”, which achieves the same result)
• AutoLookup does not require C-Dilla

Although v1.1x uses DDE instead of the clipboard to pipe a lookup query into the OED engine, elementary programming can splice the abovementioned concepts together to produce auto-lookups of clipboard text in OED v1. If you don’t have AutoLookup.exe, use Ctrl-C to put words on the clipboard after double-clicking them (one extra keystroke only).

The following is written in (free) WSH (Windows Scripting Host), because the language is installed on almost all modern M$ boxes (or get the latest versions: Win95 OSR2, Win98 WinME and WinNT 4.0, Win2000 and WinXP, plus Documentation). You need one additional component (also freeware): AutoItX3.dll. Put AutoItX3.dll (an Active X control that can read the clipboard) in the system directory %WINDIR%|%SYSTEMROOT%\system[32], and register it with your system, i.e. command from DOS:

REGSVR32 AutoItX3.dll

' OEDCLIP.VBS for Windows Scripting v5.x+ [VBS]
' Fetch word from Clipboard, pass lookup query to OED v1
' Requires AutoItX3.dll (freeware) from www.hiddensoft.com
' Optionally uses AutoLookup.exe (+ DblClickHook.dll) from OED v3.x
' R.J.Holmgren  6/18/03 LastRev.7/3/04
' Syntax:
' [d:\path\]{c|w}script.exe //nologo [d:\path\]oedclip.vbs

dim OED,WshShell,text,word,x
set WshShell=Wscript.CreateObject("WScript.Shell")
text=Wscript.ScriptFullName
OED=left(text,InStrRev(text,"\",-1,1))&"OED.EXE"
set AutoIt=CreateObject("AutoItX3.Control")
text=AutoIt.ClipGet()
do
  word=text
  do until word<>text
    Wscript.Sleep (1000)
    word=AutoIt.ClipGet()
    loop
  text=word
  word=lcase(trim(word))
  if len(word)>0 then
    if len(word)>59 then word=left(word,59)
    x=InStr(1,word," ",1)
    if x>1 then word=left(word,x-1)
    WshShell.Run OED,1
    Wscript.Sleep (600)
    WshShell.SendKeys Chr(94)&"w"
    WshShell.SendKeys word
    WshShell.SendKeys Chr(94)&"l"
    WshShell.SendKeys "{ENTER}"
  else
    WScript.Echo "Look-up word not supplied"
    end if
  loop
WScript.Quit(0)

OED="N:\OED\OED.EXE"

[d:\path\]cscript.exe //nologo [d:\path\]oedclip.vbs

@ECHO OFF
rem Script assumes that AutoItX3.dll has already been registered with REGSVR32
d:				<== Adjust “d:”
CD \OED			<== Adjust “\path”
rem START AUTOLOOKUP.EXE	<== Delete “rem” if you have this file
START /MIN D:\WINDOWS[or WINNT]\SYSTEM32\CSCRIPT.EXE //nologo D:\OED\OEDCLIP.VBS	<== Adjust both “d:\paths\”
ECHO .
ECHO Ctrl-C stops OEDClip cscript
ECHO .

Reply:

<HTML><BODY BGCOLOR="#CFCDCD"><FONT FACE="Arial OUP" COLOR="#0709C1">Hello World</BODY></HTML>

Printer drivers authored by Hewlett Packard (and other manufacturers, such as Lexmark, Samsung, etc) are often incompatible with OED v1 (and with v2-v3, though for different reasons — see solution above). If one of these is set as the current “default” printer (driver), OED.EXE crashes (General Protection Fault) when it starts to load. You’ll see two successive error messages:

General Protection Faults (GPFs) are reported at a variety of addresses, e.g. 0006:E8BA, 0007:6114, and others. Under XP, I have also seen fatal “memory could not be written” errors, reported just like the “Application Error” message displayed by v3. These are increasingly common problems which, for many owners, seem to bring use of v1.1x to an insurmountable dead end. But, in fact, fixes are several and simple. (N.B.: The backward “Compatibility” settings available in XP and Win2000 “Properties” are NOT the solution — although that is often the first potential fix that afflicted users explore.)

Unfortunately, an “equivalent” M$ driver is often unavailable (e.g. for newly marketed printers), or the M$ driver may not support all features of the printer. In that event, the solution — a more satisfactory solution than the above for modern printers — is to swap default printer drivers for a few seconds while OED.EXE initializes, temporarily assigning “default” status to a driver that is compatible with the OED, and then (in background) to restore the original default driver as soon as the OED is up and running.

Alternatively, several very simple fixes — temporarily disabling the printer spooler — exist for users of Windows NT4, 2000, XP, and Vista (and for 9x|ME, with installation of a special printer driver) if networking [Internet connectivity, or a LAN] is installed: see the “Start OED Solution for Windows 9x (95, 98, ME)”, below, or skip to the better “Start OED Solution for Windows NT+|9x”, or to the preferred “OEDXP.EXE: Start OED Solution for Windows NT+|9x (Vista, Server, XP, 2000, NT4, ME, 9x” (otherwise, if no networking is installed, apply the following Win9x solution on NT+ machines).

If an M$-authored Fax printer driver is already installed (and works!), you may skip the
(indented) steps below (which install a “Generic / Text” driver — a useful thing
to have for non-OED purposes, actually); otherwise…

	Go to Control Panel → Printers → Add printer
	Add a “Local printer”
	Do NOT check “Automatically detect & install PnP”
	Use Port “FILE”
	Use Manufacturer “Generic”
	Use Printer driver “Generic / Text Only”
	Insert an operating system CD if necessary…
	Continue to Finish installing the Generic / Text driver

Download OED-GPF.ZIP, which collects required (freeware) executables together in a
single ZIPfile: DELAY.EXE, by Douglas Good (originally from DLYWFT10.ZIP, which
has recently disappeared from the Net); and the SDP15 package, a.k.a. “Set Default Printer”,
by Edward Brophy (obtained originally from a Simtel site).

Extract DELAY.EXE, SDP.EXE, and SDP.INI into the same directory as OED.EXE, e.g. d:\OED

Go to a DOS command prompt in d:\OED
  Command:  SDP<EnterKey>
SDP will report the names of all the printer drivers which you have installed.
Make note of a unique substring of two reported printer devices:
  “Generic / Text Only” (a suitable substring is “Generic”)
  your incompatible printer
You’ll use these substrings when calling SDP in the STARTOED.BATch file that you create, below.

Edit SDP.INI to say:
	timeout=0
	no_window=0
(The SDP.INI file in OED-GPF.ZIP is already prepared thus.)

Write a BATch file called STARTOED.BAT, and put it in a directory in the PATH,
e.g. “C:\WINDOWS” or “C:\WINNT\system32”:

  @ECHO OFF
  d:				<== Adjust “d:” drive to that of the OED EXEcutable
  CD "\OED"			<== Adjust “\path” to ditto
  SDP.EXE Generic		<== [or “Fax”]
  START "d:\OED\OED.EXE"	<== Adjust “drive:\path\OED.EXE” to ditto
  DELAY.EXE 6 >NUL		<== Adjustable delay, in whole seconds
  SDP.EXE {sub$tring_of_SDP-reported_devicename_for_incompatible_printer_driver}
  EXIT

@ECHO OFF
d:				<== Adjust “d:” drive to that of the OED EXEcutable
CD "\OED"			<== Adjust “\path” to ditto
NET.EXE STOP Fax >NUL 2>&1	<== If fax service is running, only
NET.EXE STOP Spooler >NUL 2>&1
START /MIN "d:\OED\OED.EXE"	<== Adjust “drive:\path\OED.EXE” to ditto
DELAY.EXE 4 >NUL		<== Adjustable delay, in whole seconds
NET.EXE START Spooler >NUL 2>&1
NET.EXE START Fax >NUL 2>&1	<== !ONLY! if fax service was running!
EXIT

NET.EXE STOP "Fax Service" >NUL 2>&1
NET.EXE STOP "Print Spooler" >NUL 2>&1
…
NET.EXE START "Print Spooler" >NUL 2>&1
NET.EXE START "Fax Service" >NUL 2>&1

Type the location of the item:	d:\OED\STARTOED.BAT
Type a name for the shortcut:	Oxford English Dictionary

Target:		d:\OED\STARTOED.BAT
Start in:	d:\OED
Shortcut key:	None [or whatever you want]
Run:		Minimized

OEDXP /E="C:\Oxford\OED"

OEDXP /K

OEDXP /N

OEDXP /P="Fax"

	General DOS Command-Line Usage of OEDXP.EXE:

oedxp.exe [/?] [/D=["]d:\path_to_OED2.DAT["]] [/E=["]d:\path_to_OED.EXE["]] [/P=["]Printername["]] …
	… [/F] [/L] [/N] [/I#] [/K] [/W] [Lookup_Text]
 where:
/?			Help command summary
/D=["]d:\path["]	Path to Datafile OED2.DAT [default = search all root dirs on drives C: - Z:]
/E=["]d:\path["]	Path to Executable OED.EXE [default = current dir of OEDXP, else search
			  for a "d:\OED" subdir on C: - Z:, else search in
			  system dir "Program Files\OED"]
/I#	Milliseconds to Idle before executing OEDXP [default = 0]
/K	sKip disabling/swapping of printer driver(s)
/W	Wait for OED.EXE to terminate (prevent premature return to parent that
	  calls OEDXP as a child process)
/L	start search in the “Word Look-up” dialog (for selection of “Words,
	  Phrases etc, Variant Forms, Phonetics, Greek, Date Filter, Part of
	  Speech Filter”) instead of the “Word List” dialog
/F	check whether correct Files and Fonts for your specific OED version are
	  installed and recognized by the Operating System (works only when the OED
	  is not running; may also require /D and|or /E switches)
		Win 9x|ME Only:
/N	List installed printer Names
/P=["]Printername["]	Alternate Printer that does not incur GPF in OED.EXE [default="Generic / Text Only"]

		Examples:
oedxp						Launch or Focus the OED
oedxp palimpsest				Lookup word
oedxp /d=V:\ /e=W:\OED				Accelerate launch (by omitting file search)
oedxp /d=E:\OEDDAT /e=E:\OEDV110		Specify path (only) to unusual file locations
oedxp /d="C:\OED Data File" /e="C:\Program Files\Oxford"	ditto
oedxp /p="EPSON Stylus C60 Series"		Indicate alternate (non-GPF) Printer to load temporarily
						  (default="Generic / Text Only") [Win 9x|ME Only]
oedxp /n					List installed printer Names [Win 9x|ME Only]
oedxp /i1000 papion	Idle for 1 second (1000ms); permit DOS "START" session to
			  end before focusing on OED
oedxp /k		Using good printer drivers (no GPF)
oedxp /w expapillate
oedxp /e=F:\OXFORD /f	Check Files & Fonts installation (OEDXP *must* find
			  OED2.DAT and OED.EXE first, in order to check Files/Fonts)
oedxp /?		Help

All switches except Lookup word and /i (Idle) are ignored if the OED is already running
N.B.: Path and Printer specs that include spaces MUST be enclosed in quotes!

When the OED cannot find the fonts it prefers, it defaults to “related fonts”, often the Greek font; when it can’t find any related fonts, it goes haywire (black screens, etc). The solution is to reinstall the OED fonts, and to do it correctly this time. It involves a bit of manual work, but the effort is worthwhile.

ATTRIB +R *.TTF

ATTRIB +R HADAS.TTF
ATTRIB +R TRNPHON.TTF
… etc. etc.

Note: You cannot just manually COPY all of the OED’s *.TTF files to \WINDOWS[or \WINNT]\FONTS — it won’t work!

The fonts used in v1.10 versus v1.11* appear to be different, and this may cause problems (if you switch OED versions). There are eighteen (18) or twenty (20) dedicated OED fonts, depending upon whether you use OED.EXE v1.10 or v1.11*. It does no harm to install all 20 (get them here). v1.14 uses 18 fonts, and they are not interchangeable with the v1.10|v1.11* fonts!

Other possible font problems include conflicts with fonts installed by OUP’s Dictionary of National Biography. See OUP’s OED v1 support site for solutions.

The cause is an AUTOEXEC.NT file that has gone astray. In most cases, upon bootup Windows has moved the file from its default location “C:\WINDOWS\system32” (or “C:\WINNT\system32” on NT4 and Win2K machines) to “C:\WINDOWS\REPAIR”. Why the OpSys has done that — who knows. An attempt to dissuade/discourage/frustrate DOS users, probably. In any case, the fix is simple:

Go to DOS and find out first where AUTOEXEC.NT has relocated:

DIR C:\AUTOEXEC* /S /P

MOVE C:\WINDOWS\REPAIR\AUTOEXEC.NT C:\WINDOWS\system32
ATTRIB +R C:\WINDOWS\system32\AUTOEXEC.NT

The only real solution is to reboot. A tourniquet that circumvents a reboot is to close first all 16-bit Win3.x programs running under WOW (“Windows-On-Windows”, the Win16 subsystem), and then to use Task Manager or e.g. SysInternals’ fine Process Explorer or a command-line KILL utility, to stop the single instance of NTVDM.EXE which is running WOW32.DLL and which is, or was, running your culprit 16-bit Win3.x program(s). You can usually identify this particular NTVDM among, possibly, many NT Virtual DOS Machines that are concurrently running, because this NTVDM was not started by, and is not a dependency of, EXPLORER.EXE. After killing the WOW subsystem, you can usually resume work and you need not reboot. You can relaunch the OED; it may run for days before triggering the error message again — or it may only work for 20 minutes. Terminating the WOW subsystem may be effective only once or twice.

The underlying cause is that WinXP+ has assigned a “Graphics Device Interface” (GDI) object number higher than 16,384 to a 16-bit process (the quota of GDI objects per session was raised from 16,384 to 65,536 with WinXP). Quote a web page of Dan Fulger, who debugged it:

For installation suggestions (not easy!), consult Dan Fulger’s page or a copy of it here. (Thanks to Shakib Otaqui for the initial proposal that the GDI was implicated in this problem.)

The only effective workaround is to transport SETUP.EXE, along with your Data CD, to another (e.g. Win9x) machine, and “install” the OED there, the narrow goal being to unpack the OED files contained in SETUP.EXE. Once decompressed, copy those files to a ZIPfile, floppy, or USB flash memory key, etc, or Email them to yourself, and finally erase them from the temporary host machine. SETUP may not launch on your machine, but OED.EXE will! (Don’t forget to fetch also the fonts — probably in C:\WINDOWS on the temporary host if you have “installed” v1.14.)

Simpler still, download v1.10 from an abandonware site — the ZIPfile is already unpacked. Version 1.10 is better than v1.14 anyway.

Please contact me if you have a solution for this problem. It occurs on some Win2K and WinXP machines with a variety of 16-bit programs (not just SETUP.EXE). Microsoft gives no guidance.