By now, users of older versions of Advanced Accounting and TAS (5.1 and prior) are aware that they cannot run these legacy programs under 64-bit versions of various Windows operating systems absent setting up a virtual PC or running in an environment like vDOS. The better solution for users needing to replace older PC's that need to continue to run 16-bit programs on a daily basis and in multi-user environments is to simply use a 32-bit version of the newer operating system.
Even Windows 10 is available as 32-bit (sometimes referred to as "Win32") but it does present new obstacles and setup considerations that weren't an issue with, for example, Windows 7. Win32 versions have not been the default operating system included on newer PC's for quite some time, so if running a 16-bit application is a requirement, be very careful when planning the replacement of an older PC.
Some of our users have for reasons of performance and other issues elected to use newer versions of Btrieve (referred to under a variety of names including Pervasive, PSQL, Actian, and Actian Zen) with their 16-bit software which has been possible due to backward compatiblity these engines have offered. Ironically however that newer record manager engine component has created issues when moving to different operating systems.
The 16-bit version of Btrieve that came standard with legacy Advanced Accounting and TAS as well as the DOS4G introduced in the version 5 series work without issues in 32-bit versions of the Windows 7, 8, and 10 operating systems. And the 16-bit Btrieve 5.x (which only coincidentally has a similar version and file format number as the Advanced Acccounting and TAS products) scales up fairly well for multi-user access and at no additional cost. It isn't however client-server capable and can have limitations (although we've had users with upwards of 20 concurrent users utilize it, both back in the older 16-bit OS days but also currently using Windows 10).
Users however that were using the modern engines and then moved to Windows 7 and especially to Windows 8 and now 10 have encountered some new challenges. They can however still be made to work (and even with Pervasive v9).
After moving to a newer operating system and installing Pervasive and making other setup changes, users have found that they may still be greeted with an error response such as:
Recently we've seen this happen with both Windows 7 and Windows 10 involving 16-bit accounting software users using Pervasive/PSQL engines.
The problem seems to be caused by Windows not fully recognizing established path environments when running 16-bit applications and DLL's are called. This problem has become worse in Windows 8 and 10.
The solution for Windows 7 is to COPY the btrdrvr.sys and btrvdd.dll files from your Pervasive BIN folder to c:\windows\system32 folder on each PC.
In Windows 8 and 10, all of the DLL's in the Pervasive BIN folder need to be copied to c:\windows\system32. In essence these newer operating systems can't find the DLL's they need to call even though they are sitting in an established path.
The Pervasive BIN folder in versions 9 was typically found at:
c:\pvsw\bin
In newer Pervasive versions, they can be found instead at:
C:\Program Files\Pervasive Software\PSQL\bin
or somewhere similar.
Additional Windows 10 specific issues:
(1) Legacy options must be enabled and NTVDM made active. For an example see:
https://www.groovypost.com/howto/enable-16-bit-application-support-windows-10/
(2) Enable CMD's legacy console (this is different than enabling NTVDM). See for example:
https://www.tenforums.com/tutorials/94146-enable-disable-legacy-console-mode-all-consoles-windows-10-a.html
Checklist for other issues involving 16-bit Adv/TAS programs running under 32-bit operating systems:
In addition to dealing with the Pervasive DLL issues, here are some additional items that need to be checked (some of which also apply to using the 16-bit version of Btrieve):
(1) The pvsw\bin or "PSQL"\bin folder must be in the user's path (it probably already is).
(2) The users PATH= can't be longer than 255 characters which is 16-bit program limitation - if it is (and on any given modern Windows PC it often is), it will prevent the application from running (on even XP Pro as well as Win 7 and above.). So you may have to create an "ADV.BAT" unique for the user that explicitly setting the path, e.g.
PATH=c:\windows\system32; c:\pvsw\bin;
along with any others that are needed/desired. You could then restore the path at the end of the batch file if necessary (probably not) and even create separate batch files per user if different users require different paths. We discussed this issue in greater detail here:
https://addsuminc.blogspot.com/2016/04/dos4g-error-2001-exception-0dh.html
This issue applies to all versions regardless of whether Pervasive is being used.
(3) Run NOTEPAD as administrator and retrieve:
c:\windows\system32\Config.nt
Change the default FILES=40 to:
FILES=150
and save. This too applies to all situations involving 16-bit Adv/TAS applications including running under XP-Pro.
(4) If you are using Pervasive, also in c:\windows\system32\config.nt make sure that the line:
DEVICE=c:\pvsw\bin\btrdrvr.sys
(or whatever the appropriate path is to the installed Pervasive engine - the above is a version 9 example)
has not been REMmed out or removed. That's the line that gives Pervasive engine "DOS Box" support for older applications. Without that, programs using Pervasive won't run.
NOTE: we've had a least one report that a Windows 10 update completely removed this DEVICE= line in CONFIG.NT thereby disabling the application from being able to run. Users are advised to make CONFIG.BAK back-up copies or equivalent that can be easily restored.
(5) To make NET USE statements for LPT ports, you'll need to run CMD as administrator in order to make them (and if the ADV.BAT is making any NET USE statements, then the icon's property would have to be set to "run as administrator"). The user must have some kind of LPT1 connection. You can NET USE LPT1 to a USB connected printer as long as that printer can receive/output characters directly without a Windows printer dialog box (such as some monochrome laser printers, dot matrix printers, etc.) To do that on a local PC, you would have to create a share to that printer on the local PC. Or just NET USE to some other printer on the network as LPT1 even if the user won't be printing to it. Note that the legacy versions require an LPT1 port of some kind in order to print. Newer versions of course simply use whatever is installed in Windows and don't require any special printer setup.
If a printing delay issues occur, you may have to set:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW\LPT_timeout
to a value of 1 or 2. For more information:
https://www.addsuminc.com/ad012098.htm
The foregoing applies to all 16-bit environments (but only those environments).
NOTE: a big advantage in the using the modern Pervasive engines is that you do not have to run the program as administrator (which is also required when running the 32-bit legacy Btrieve 6.15 version with even the newer version of Advanced Accounting).
(6) Because this is a legacy version, it needs to be drive mapped preferably the same way as on other PC's. (Since UNC paths are not supported by 16-bit applications.) This issue is unrelated to whether Pervasive is being used or not.
(7) If you are using the Pervasive workgroup engine (WGE), it has to be configured to run as a service. Newer versions of Pervasive normally automatically install this way. Version 9 did not but a special utility can be run to make that WGE version run as a service. This issue does not apply to client-server installations. however, normally for client-server installations to work properly on newer versions of Windows, you need to be running at least on Pervasive v11 (true for all versions of Advanced Accounting or TAS whether 16-bit or 32-bit).
(8) If you are using Pervasive (or newer named versions), neither the TSR BTRIEVE.EXE nor any Btrieve 6.15 32-bit legacy components (which shouldn't be the case because the 16-bit versions were not compatible with that particular engine) should be present in the application folder where tpc50.exe or the equivalent is launched.
(2) The users PATH= can't be longer than 255 characters which is 16-bit program limitation - if it is (and on any given modern Windows PC it often is), it will prevent the application from running (on even XP Pro as well as Win 7 and above.). So you may have to create an "ADV.BAT" unique for the user that explicitly setting the path, e.g.
PATH=c:\windows\system32; c:\pvsw\bin;
along with any others that are needed/desired. You could then restore the path at the end of the batch file if necessary (probably not) and even create separate batch files per user if different users require different paths. We discussed this issue in greater detail here:
https://addsuminc.blogspot.com/2016/04/dos4g-error-2001-exception-0dh.html
This issue applies to all versions regardless of whether Pervasive is being used.
(3) Run NOTEPAD as administrator and retrieve:
c:\windows\system32\Config.nt
Change the default FILES=40 to:
FILES=150
and save. This too applies to all situations involving 16-bit Adv/TAS applications including running under XP-Pro.
(4) If you are using Pervasive, also in c:\windows\system32\config.nt make sure that the line:
DEVICE=c:\pvsw\bin\btrdrvr.sys
(or whatever the appropriate path is to the installed Pervasive engine - the above is a version 9 example)
has not been REMmed out or removed. That's the line that gives Pervasive engine "DOS Box" support for older applications. Without that, programs using Pervasive won't run.
NOTE: we've had a least one report that a Windows 10 update completely removed this DEVICE= line in CONFIG.NT thereby disabling the application from being able to run. Users are advised to make CONFIG.BAK back-up copies or equivalent that can be easily restored.
(5) To make NET USE statements for LPT ports, you'll need to run CMD as administrator in order to make them (and if the ADV.BAT is making any NET USE statements, then the icon's property would have to be set to "run as administrator"). The user must have some kind of LPT1 connection. You can NET USE LPT1 to a USB connected printer as long as that printer can receive/output characters directly without a Windows printer dialog box (such as some monochrome laser printers, dot matrix printers, etc.) To do that on a local PC, you would have to create a share to that printer on the local PC. Or just NET USE to some other printer on the network as LPT1 even if the user won't be printing to it. Note that the legacy versions require an LPT1 port of some kind in order to print. Newer versions of course simply use whatever is installed in Windows and don't require any special printer setup.
If a printing delay issues occur, you may have to set:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW\LPT_timeout
to a value of 1 or 2. For more information:
https://www.addsuminc.com/ad012098.htm
The foregoing applies to all 16-bit environments (but only those environments).
NOTE: a big advantage in the using the modern Pervasive engines is that you do not have to run the program as administrator (which is also required when running the 32-bit legacy Btrieve 6.15 version with even the newer version of Advanced Accounting).
(6) Because this is a legacy version, it needs to be drive mapped preferably the same way as on other PC's. (Since UNC paths are not supported by 16-bit applications.) This issue is unrelated to whether Pervasive is being used or not.
(7) If you are using the Pervasive workgroup engine (WGE), it has to be configured to run as a service. Newer versions of Pervasive normally automatically install this way. Version 9 did not but a special utility can be run to make that WGE version run as a service. This issue does not apply to client-server installations. however, normally for client-server installations to work properly on newer versions of Windows, you need to be running at least on Pervasive v11 (true for all versions of Advanced Accounting or TAS whether 16-bit or 32-bit).
(8) If you are using Pervasive (or newer named versions), neither the TSR BTRIEVE.EXE nor any Btrieve 6.15 32-bit legacy components (which shouldn't be the case because the 16-bit versions were not compatible with that particular engine) should be present in the application folder where tpc50.exe or the equivalent is launched.
More references:
Win 8.1:
https://social.technet.microsoft.com/Forums/scriptcenter/en-US/3202934d-cd47-447e-b927-e605c80d48ea/running-dos-applications-requiring-device-drivers-in-confignt-that-load-dlls-from-the-search-path?forum=w8itproappcompat
vDOS:
https://addsuminc.blogspot.com/2016/02/extend-life-of-old-applications-with.html
Pervasive 7/2000 and 2000i issues:
https://www.addsuminc.com/ad092299.htm
https://www.addsuminc.com/ad070902.htm
