1

Believe it or not, we've been asked to resurrect an ancient MS Access 2.0 application that hasn't been used for a few years. However, we cannot even get it to run under XP. We're getting:

Application: MSACCESS The Win 16 Subsystem has insufficient resource to continue running. Click on OK, close your applications, and restart your machine.

Does anyone know how we can get around this? If we can get it to run, perhaps we can actually port it. :-)

5 Answers 5

2

I recall having problems with running Access 2 on NT 4, and the solution was to give full permissions on certain folders. I don't recall what they were, and it seems wrong because it wasn't until Windows 2000 that the programs folder was locked down, but I definitely require having to set full NTFS read/write/delete permissions on the folders where Access 2 stored its files. Certainly WinXP has the programs folder locked down to read-only for users, so that would be a place to start.

1

It was a long time ago, but I recall a similar situation in a past life. If I recall correctly, the error message itself is something of a red herring, and the real source of the problem was a lack of Environment space allocated to the 16-bit subsystem. (512 bytes comes to mind) It used to be that you could specify how much Environment space to allocate, however we don't boot with config.sys anymore. :) I believe I solved that particular instance by trimming down the entries in my PATH environment variable.

Open the Environment Variables dialog by right-clicking on My Computer, selecting Properties, go to the Advanced tab and click the Environment variables button.

Copy the PATH value from both the "User variables for {username}" and "System variables" sections into a text document for safe keeping (i.e in case you decide you want/need to restore them).

Now, examine the PATH entries in both User and System variables (which are combined to make your PATH environment variable):

  • Remove any duplicate entries from your User variables since they're already specified at the higher System level,
  • Convert any long paths to 8.3 notation. E.g. all instances of C:\Program Files\foo\ --> C:\PROGRA~1\foo\
  • Judiciously, you may also decide to remove entries that you know are not needed. Sometimes apps will add PATH entries that you, yourself, never actually require.

These changes fixed that error message in my case. The problem was that the (old) PATH was fine in a 32-bit environment, but overflowed the environment space when shoehorned into the 16-bit subsystem. (A good follow-up question might be how to override the 16-bit subsystem's environment space, but I didn't need to resort to that in my case.)

1

Also note that Access 2.0 did not use the registry so you don't need to worry about anything there. But as others, hi David, have pointed out it's settings were kept in an INI file in the appropriate Program Files folder

0

Have you tried running in "compatability mode" in XP? May take soem tweaks but has worked for me in the past in a similar scenario

0

You may want to try installing Win31/WfWG311 and then Access 2.0 under dosbox. Not as seamless a user experience as running it directly under XP, but much less overhead than trying a full virtualization solution.

Alternatively, have you tried running the Access DB under a newer version of Access?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .