Running Access 97 on Windows 7

Today I had to get Access 97 running on a Windows 7 64bit PC. When I arrived on site, my colleague had already successfully installed Office 97, and the SR-1 patch (sr1off97.exe). So I guess that the well known "Hatten" file issue had already been resolved.

 "There is no license" error message starting Microsoft Access
 http://support.microsoft.com/kb/141373

On further investigation, I found that an attempt to install the SR-2 patch had failed, and also that the on-line help for Access 97 was not working at all. And I could see that the "Programming help" file had not been installed.

To install "Programming help", I ran the maintenance setup, but it soon failed, reporting message "Setup Error 825 - Object 9807". This issue is covered by the Microsoft support Article ID: 156638

 OFF97: International English SR-1 Patch Offpro97.inf
 http://support.microsoft.com/kb/156638

Basically, you need to download file "offpro97.exe" and extract from that the file "off97pro.inf" and copy it across to the 'setup' directory, replacing the existing file.

To get the help working, you need to install support for "winhelp32.exe".
This issue is covered by the Microsoft support Article ID: 917607

 I cannot open Help files that require the Windows Help (WinHlp32.exe) program
 http://support.microsoft.com/kb/917607

But then when you try to use the Access 97 help files, you will get error "There was a problem running the macro. (1037)". The fix for this is covered in the same Microsoft support article.

Basically, you need to run "C:\WINDOWS\syswow64\regedit32.exe" and create key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WinHelp" and then create DWORD "AllowProgrammaticMacros" and set it to value "1".

In order to install the SR-2 patch (sr2bof97.exe), you need to replace some of the Windows 7 font files, with older versions copied from Windows XP. These are the font files, from Windows XP, that I used:

17/07/2004  11:39   127,596 comic.ttf
29/08/2002  13:00   111,476 comicbd.ttf
21/11/1996  00:00    41,408 hatten.ttf
17/07/2004  22:55   383,140 tahoma.ttf
17/07/2004  22:55   355,436 tahomabd.ttf

Finally, I installed file "Jet35sp3.exe" to make sure the Jet Engine was at the final version.

Ok, so that's it. I tried testing a few things with Access 97, and it seems to run fine on Windows 7.

Patching vmxnet to disable LRO

We've been playing with two Centos 5.5 virtual machines connected over a virtual switch on VMware ESX 4.0 update 2. Unfortunately we experienced very poor TCP performance. I think the same issue affects ESX 4.1 as we found this reference in the release notes:

Poor TCP performance can occur in traffic-forwarding virtual machines with LRO enabled
Some Linux modules cannot handle LRO-generated packets.
As a result, having LRO enabled on a VMXNET 2 or VMXNET 3 device in a traffic
forwarding virtual machine running a Linux guest operating system can cause
poor TCP performance. LRO is enabled by default on these devices.

Workaround: In traffic-forwarding virtual machines running Linux guests,
set the module load time parameter for the VMXNET 2 or VMXNET 3 Linux driver
to include disable_lro=1.

We found that this works:

# rmmod vmxnet
# modprobe vmxnet disable_lro=1

BUT the problem is how to make vmxnet default to disabling LRO when the VM is first booted.

We tried editing '/etc/modprobe.conf' and adding 'options vmxnet disable_lro=1' but this was not sufficent. It seems that the vmxnet module is first loaded during bootup from the initrd.

Our conclusion was that patching the source code of vmxnet was the best way. So here is what we did:

# cd /usr/lib/vmware-tools/modules/source/
# tar xvf vmxnet.tar
# cd vmxnet-only
# grep -n disable_lro *
vmxnet.c:155:static int disable_lro = 0;
vmxnet.c:157:   module_param(disable_lro, int, 0);
vmxnet.c:159:   MODULE_PARM(disable_lro, "i");
vmxnet.c:931:       !disable_lro) {
# cp vmxnet.c vmxnet.c.orig
# chmod +w vmxnet.c
# vi vmxnet.c
# diff -u vmxnet.c.orig vmxnet.c
--- vmxnet.c.orig       2010-07-19 13:20:44.000000000 +0100
+++ vmxnet.c    2010-07-19 13:57:43.000000000 +0100
@@ -152,7 +152,7 @@
#endif // VMXNET_DO_ZERO_COPY

#ifdef VMXNET_DO_TSO
-static int disable_lro = 0;
+static int disable_lro = 1;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 9)
module_param(disable_lro, int, 0);
#else
@@ -932,6 +932,14 @@
  lp->lpd = TRUE;
  printk(" lpd");
}
+
+   if (disable_lro) {
+     printk(" disable_lro:1");
+   }
+   else {
+     printk(" disable_lro:0");
+   }
+
#endif
#endif

# cd ..
# mv vmxnet.tar vmxnet.tar.orig
# tar cvf vmxnet.tar vmxnet-only/
# vmware-config-tools.pl -c

The change to the source code was just to change the value of the disable_lro variable from zero to one. And we also added some code to report the value of the variable when the module loads.

To recompile the modules, you will need these rpm packages installed:
gcc, binutils, kernel-devel, kernel-headers

For reference, the version of vmware tools we were using was:
VMwareTools-8195-261974

Of course, if you update vmware-tools, you may need to review this fix, and re-patch the file.

If you are using the vmxnet3 driver, the fix should be similar to the above.

I'd like to thank Michael Melling for helping test the above patch.
Regards
Nigel Smith