Logo-01

Kennedy Software & Systems Ltd


  
  Home
  What's New
  Solutions

    LesSpace
    PatchCRT
    AwardMJK
    Paradox(DOS)
    ReBuild OE
    Time-Dilation
    TD-MOConnor
  Old-Apps!
  Anti-Spyware
  Downloads
  Forum
  Orders
  Links
  Feedback
  Referrals
  Contact us

 Running Old Applications under Windows 2000, NT and XP


Latest Rev: Jan, 2006.

General Notes:
    1. Please do NOT copy these notes, nor any associated files, from here to any other public website, newsgroup, etc. Just refer to or link to the notes here. That way, all of us can always locate the up-to-date details.
    2. On the same basis, we hope that these notes are not duplicates of similar info elsewhere. If you notice such duplication, please let us know.
    3. These notes generally refer to XP, but most (if not all) comments apply to W2K also, and a few comments apply to OSes prior to W2K.
    4. These notes assume the latest Service-Packs and all major patches have already been applied to the OS.
    5. Regarding XP: very many XP “tips” suggest that XP-Pro is significantly better and more stable than XP-Home. These notes assume XP-Pro.
    6. Some of the following segments are "technical". If you think sections are badly written, let us know, and we'll gladly try to improve them. If some items relate to your needs, but are "incomprehensible" (though, hopefully, accurate!), then perhaps you should request your IT folk(s) to investigate.
    7. If you notice any errors/omissions/incompleteness, etc, we will gladly update accordingly. Thank you.

Bibliography:
For good information, please first refer to the following articles, and search the 'net for similar essays:
    1. “Old Apps Find a New Home On Windows XP”, by Brian Proffit (PC-Mag).
    2. “Make legacy applications feel at home in Windows XP”, by Faithe Wempen TechRepublic.
    3. Microsoft Knowledge Base (KB) Article [Q]279792: “HOW To: Enable Application Compatibility-Mode Technology in Windows 2000 SP2 and SP3”.
    4. Also the following MS KB articles:
          303528, HOW TO: Keep a Jet 4.0 Database in Top Working Condition
          296264, Configuring Opportunistic Locking in Windows
          129202, PC Ext: Explanation of Opportunistic Locking on Windows NT
          148367, Possible Network File Damage with Redirector Caching
          142803, Locking Error or Computer Hangs Accessing Network Database Files
          174371, Possible Database File Damage When Data Is Appended
          124916, Some Client Applications Fail When Writing to Windows NT
          126026, Server Optimization in RFCB Caching
          219022, Improving Performance of MS-DOS Database Applications
          161504, PRB: "Error Reading Drive" with Windows NT 3.5 as Server
          169608, Occasional File Corruption When Using Unbuffered I/O
          165403, Windows 95 Update Prevents Sending Clear-Text Password Over Net
          321733, "Delayed Write Failed" Error Message When You Write a File to a Server
          812937, (XP bug), File Lock or Access Denied Error Message When You Save Files Over the Network
          330174, (XP), "Delayed Write Failed" !!!
          293842, (2K), "Lost Delayed-Write Data" !!!
          811492, (XP and W2003 DEL-timeout bug), It May Take 35 Seconds to Delete Files over the Network
          314106, Troubleshooting MS-DOS-based programs in Windows XP
          163525, Delay when saving Word file to Windows NT 4.0 server. (Op-Lock issues with MS-Office products!!!!).
          249799, Slow Network performance with SP 4, 5, 6, or 6a (Windows NT 4.0). You must install SP 6a anyway, and then contact Microsoft for updated RDR.SYS files.
          281672, Possible data loss after you enable the "Write Cache Enabled" feature on Hard-Disks (Windows 2000). BUT, check the SuperBase notes here, especially down near the end of the page, which discusses the "automatic (?)" enabling of "Write-Caching", even after it has been manually Disabled!!
          And many others!!!!
    5. MS KB article 321169, re Slow performance when copying files from XP to a W2K Domain controller. See these notes also at SmallBizServer.
    6. An excellent Delphi-Magazine article is here, and covers Paradox File-Corruption issues, Op-Locks, etc.
    7. Some Op-Locks notes by the SuperBase folks here and here.
    8. MSDN essays on Opportunistic Locks.
    9. Super notes on bugs in W2K, possible patches/fixes, etc, at Djgpp_w2k and Djgpp/w2k_workaround. (DJGPP is a FREE highly recommended C/C++ development environment, to produce MS-DOS/MS-Windows/Linux-DOSEmu apps; see Delorie). Maybe Off-Topic, but a Free PASCAL system is available at FreePascal.org, and is slated as a clone of TP 7 – and is similar to Delphi).
   10. Tabs3. This seems to be an excellent source of Networking notes, and has much info on Novell software, updates, KB essays, etc.
   11. Axcel21.Very well known and highly recommended site.
   12. Brinkster.com/ivanf (beware some of the humour !!).
   13. Is-it-true has massive and excellent XP/NT/W2K tips.
   14. Samba/docs/man has excellent details on Samba (file server running under Linux for MS clients), especially a section on Op-Locks, Damaged lock files, etc.
   15. NtCompatible is a busy site.

Registry Settings, Op-Locks, Write-Cache & Flush-Buffers under W2K/XP:
You are advised to make all the Registry edits as documented in the above references, and in various relevant Paradox FAQs, newsgroups postings, etc. The important references include Disabling Opportunistic-Locking and Write-Behind Caching. Some users report no unusual problems when some or all of these updates are NOT applied, and some suggest that performance might be reduced somewhat with some of the updates. However:
    • most of these suggestions come directly from Microsoft
    • most apply to all types of shared data-bases, and not just Paradox apps.
My overall opinion is that it's better to make all the changes.

For simplicity, refer to the following steps and to a “Registry file” which I've prepared:
    1. If you don't understand exactly what we're doing here, then please do NOT proceed. Seek assistance from an IT person who's familiar with Registry updates...
    2. Run these steps at your own peril!!
    3. Download the REG file. Unzip. Check that all entries in it are “reasonable”, and that the file is not corrupted.
    4. Feel free to insert additional entries, or remove some of the suggested entries, if appropriate. And, making the suggested changes may reduce performance a little on your systems... you must make the final decisions...
    5. Just in case some problems arise while you're trying to apply the supplied REG file: There are different versions of RegEdit; W98SE uses RegEdit ver 4.x and XP uses ver 5.x. However, it seems that the XP version accepts REG files written by ver 4.x, but 4.x does not accept 5.x formats. Further, it seems there are just a few differences in the REG format:
         • Remove the comment-lines in the file, if your copy of RegEdit blows up on them – they begin with a semi-colon.
         • W98SE uses a header (line-1 of the Reg file) of “REGEDIT4” (which is in the supplied file). XP (SP1) normally writes and reads a header of “Windows Registry Editor Version 5.00”, but it also accepts the W98SE header.
         • From some tests, it seems there are some minor syntax changes in the REG files; sometimes Double-Words and 4-byte Hex values retain their exact identities, and sometimes each might appear as the other (with the individual bytes reversed, as expected). Technically, these two formats are usually equivalent, so perhaps there is no significance to these syntax variations.
         • Finally, the REG file must end with a blank line – otherwise the end-entry is not imported...
    6. Perhaps print the REG file, and go through all the entries in it, noting the current settings in your Live Registry. That way, you can easily reset to the old values, if anything goes wro...
    7. Make a backup of your live Registry files. (This is documented in the Windows Help systems).
    8. “Click” on the final (!) REG file to automatically import it into your Registry – using the RegEdit/RegEdt32 utility. This option might be disabled in your system; if so, you might try a right-click on the Reg file, and select the Merge option. Or seek assistance from your IT folks.
    9. Verify (very carefully!) that all the required updates have been made to your Registry.
   10. You should make these changes in all client-PCs, and, where possible and appropriate, in all your file servers.
   11. You'll probably have to re-boot to activate the changes.
   12. If your Registry is not updated correctly, then restore your backup, and investigate further...
   13. From time-to-time, I suggest you check back on the website, to retrieve the latest rev of the REG file.

If these REG updates won't apply automatically, you'll have to implement them manually, using RegEdit/RegEdt32. And with Great Care!. (If updating the “DiscardCacheOnOpen” parameter manually, select a data-type of BINARY. If updating the “OpLockBreakWait” parameter, note that the HEX value of 23 (seconds) corresponds to a decimal value of 35).

If the REG file works well for you, perhaps you should update the startup programs in your apps to ensure that the stated settings are always in the live Registry – just in case some other apps decide to alter them later – or, perhaps better, to always “force” the above stated values...

I've seen some conflicting advice on some of these registry updates, and the suggested settings may contain redundant values. Eg, the “Linkage” entries are sometimes listed as belonging INSIDE the “Parameters” Key, and sometimes listed as at the SAME level as the Parameters key.

Netware Server: The REG file contains SOME Netware recommendations (at the end of the file), but, alas, only SOME!! If you're running Netware, you'll probably have to try to make additional Registry updates manually - check on the Novell website (at least here and here). I have not verified the exact spelling of the "Name" of each entry (both in the Netware entries in the REG file, and the reg entries listed below). It's likely that you'll find access to many of these entries through Netware Config menus - but perhaps it's still worth checking using RegEdit/RegEdt32!

The nasty issue arising here is that, on XP (and perhaps W2K/NT), users cannot add a Key directly under [HKLM]. Normally, this is a "permissions" issue in RegEdt32, and can be easily changed by an "admin" user right-clicking the relevant "key", and modifying the permissions. But not, seemingly, directly under [HKLM]. As far as I know, there is no "normal" way to create such keys!! Therefore, the subkey of \NETWORK\ cannot be easily added to a registry under [HKLM], and therefore the various "values" listed below cannot be created. I have no solution. You might look at a Registry utility by Frank Keyne named RegDACL. Or, you might just "hope" that your Netware drivers do not rely on any of the following registry values!!. I think these key-creation problems do not arise under older versions of Windows:
      • Note-1: the following reg-entries alre already in the REG file, but they appear only as "comments". If you know that your OS will accept subkeys under [HKLM], then, for convenience, you can simply un-comment the set of entries at the end of the REG file, and import the entire REG file.
      • Note-2: for DWORD entries, 0=Off/No, 1=On/Yes. For STRING Values, the GUI may show the entries as ON/OFF, Registry uses YES/NO.
      • [HKLM\Network\Novell\System Config\NetWare DOS Requester], a STRING value Name of "CACHE WRITES" should be set to "OFF" (default = ON/YES).
      • [HKLM\Network\Novell\System Config\NetWare DOS Requester], a STRING value Name of "TRUE COMMIT" should be set to "ON" (default = NO/OFF).
      • [HKLM\Network\Novell\System Config\NetWare DOS Requester], a STRING value Name of "DELAY WRITES" should be set to "OFF" (default = NO/OFF).
      • [HKLM\Network\Novell\System Config\NetWare DOS Requester], a STRING value Name of "FILE CACHE LEVEL" should be set to "0" (default = 3, Range = 0-3).
      • [HKLM\Network\Novell\System Config\NetWare DOS Requester], a STRING value Name of "OPPORTUNISTIC LOCKING" should be set to "OFF" (default = NO/OFF).

Corrections to the REG file are most welcome!

Many thanks to Dr. Andrew J Stevenson for inquiring on the “Win95Truncate[D]Extensions” entry. I now think BOTH values are needed (Win95TruncateExtensions and Win95TruncatedExtensions) – web searches throw up info on both settings.

Warnings: A few of the suggested registry edits have been discussed many times on the Paradox newsgroups. Usually, some of the Registry Keys are stated, with the suggested Values. However, over the past few years, some of the keys have been consistently mistyped in the NG postings. Presumably, someone got it wrong originally, and then others merely re-posted the incorrect messages.... etc.... Furthermore, many of my recommendations have never been mentioned on the Paradox NGs, AFAIK. Is this because they do not apply, or because..... So, if readers simply followed the instructions in these NG messages – especially the incorrect ones – then they have NOT implemented the recommended precautions. NOT SMART!!. If there is a possibility that YOU implemented incorrect or incomplete instructions, then I respectfully suggest you run the above procedure – anyway – to be sure – to be sure!!

Windows-2000/XP – Write-Caching: An additional setting should be checked for each appropriate Hard-drive. Presumably, this should be applied to all Server and all Shared (P2P) Drives. Maybe it's not as important on Drives which hold only temporary files... such as Local drives... but some technical folks would advise that ALL drives (involved in shared-database apps) should have Write-Caches disabled. Unfortunately, I cannot build these updates into another simple REG file, because the keys depend on your hardware. So, you'll have to proceed as follows (the following sequence applies to XP – you'll notice that a few of the steps don't arise under W2K):
    1. Start; Control-Panel; System
    2. Select Hardware
    3. Click on Device-Manager
    4. Expand the “Disk Drives” list
    5. Right-Click on the relevant drive
    6. Select Properties
    7. Select Policies
    8. Un-Check the Write-Cache option
    9. OK
   10. Repeat from step-5 for other relevant drives
   11. Save; Exit.

Windows-NT/2000/XP – Flush Buffers: MS-KB article 224922 discusses shared database access, data-integrity, OpLocks, etc, and recommends that app developers should “flush file buffers at any time that represents delineation of a transaction. This can be done by calling the Win32 FlushFileBuffers API Call”.
 
Copying data to/from a TCP Server:: See MS KB 823764. "Slow Performance Occurs When You Copy Data to a TCP Server by Using a Windows Sockets API Program". One solution is to manually add/change a registry entry. These entries are NOT in the OpLocks.Reg file (because the entries contain GUIDs), so you'll have to make the change manually:
   HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Interface GUID>
   W2K: TcpDelAckTicks; Reg_DWord = 0
   W3K/XP: TcpAckFrequency; Reg_DWord = 1

Samba Servers:
Check the Samba documentation mentioned above. Chapter 14 includes recommendations and notes on how to disable Op-Locks on the Samba server, how to recover from Lock errors, etc.

It's essential to use recent Samba builds, because older versions had issues regarding full Windows compatibility, etc.

DNS and WINS must be configured correctly also.

Michael Lueck (of LDS) has a presentation on Samba-PDC, which is mentioned frequently on the NGs, and which is highly recommended.

Long Delays when Printing - System.ini:
A: If you experience long delays before spooled reports start printing, perhaps you should update the SYSTEM.INI file. Please refer to a full explanation written by Dave Porter. Until I have a reference to Dave's notes, here's my shorthand version:
    1. Open SYSTEM.INI for editing.
    2. Check if there is a section headed [NETWORK]. If not, create that head at the end of the file. (This section applies to the Real-Mode redirector).
    3. In that section, insert a line: PrintBufTime=10
    4. Check if there is a section headed [IFSMGR]. If not, create that head at the end of the file. (This section applies to the Protected-Mode redirector).
    5. In that section, insert the same line: PrintBufTime=10
    6. Save System.ini.

The above times are in Seconds, and control the delay between the end of the generation of a spooled print file, and printing it. The default is 45 seconds. You may have to tweak the above values a little:
    • If the generation of all print files is fast, and there are no long pauses during the generation process, then perhaps the values could be even lower.
    • If the generation is sometimes slow, and, especially, if reports are long, with long pauses during the generation process, then you may have to increase the above values accordingly, so that printing does not commence prematurely.
    • This matter is covered in some detail by Davide Guolo, here.

B: I've seen references to the following suggestion, but I've not tested it:
    1. Run REGEDIT, and access HKLM\System\CurrentControlSet\Control\WOW
    2. Locate the "LPT_timeout" entry, and reduce the value to, perhaps, 2-5 (seconds)

C: If using the Capture command (in Netware) to control the allocation of LPTn:, then use EndCap to release the print queue when it has been generated, or access the Novell printer options and activate Auto-EndCap (AU). Use "Capture /?" for more info.

Realtek NICs:
I've seen many references to problems with Realtek NICs. Seemingly, the Drivers supplied by MS on the W98 CDs are broken, as noted in MS KB 189778. The recommendation is to get updated drivers from Realtek.

Path / "%PATH%":
Watch out for Paths which are not acceptable to the parser code in older DOS apps. Older programs might not understand embedded spaces, embedded double-quotes, etc. And older parsers might blow up on very long PATH statements.

In your BAT files, constructs such as: “IF [%Path%]==[123] GOTO ABC” are not processed properly in XP. Sometimes, where %PATH% is referenced, the command-interpreter does not expand the syntax like it did in W95/W98, and the operations either fail, or yield incorrect results. The only syntax that I found acceptable is to use double-quotes in the above lines; eg IF “%PATH%”==”123” GOTO ABC.

CHOICE.COM:
Also referring to BAT files, utilities like CHOICE.COM are no longer supplied (in Windows\Command) with the newer OSes like XP. You'll need to copy these from elsewhere (maybe some older MS OS CD, or some MS resource-kit) into some accessable folder.

Alternatively, you might check out some interesting utilities from Bill Stewart (BStewart@IName.com). Look at GetKey, GetKeyD, GetVar and GetVarD. They are powerful and extremely well documented. And Free!. At GetKV.

"&" in Folder-Names:
The “&” character is the Continuation character for CMD.EXE commands in W2K/XP, and is therefore now unacceptable in BAT lines. So, an old folder-name like “COM&EXE” is not allowed. Change it to, say, COM_EXE, and change all references in BAT files, Menu systems, etc.

"If Exist ...\NUL":
Despite being recommended by Microsoft as a method to check for the existence of a Folder, IF EXIST xxxxx\NUL is problematic again under XP. (It was also broken under initial releases of W95). I wasted very many hours trying to overcome this problem with BAT syntax, and failed! I patched LesSpace to trap the internal execution of IF EXIST NUL commands, and return the correct result to the BAT file. If your BAT files rely on the IF EXIST NUL construct, and you cannot come up with BAT lines which work, you may have to use LesSpace! Hint: you might also check if BAT experts like Timo Salmi, Ted Davis (T.E.D.), etc, have a BAT-only solution.

PKZIP:
At least some versions of PKZIP don't run successfully under XP. Steve Green has more details on his website, where he suggests using the “-3” command-line option.

LPT5-LPT9:
I think that all versions of Windows support LPT1-3 well. And, usually, LPT4. However, as the port-number goes up – problems arise!!

I have apps which were designed to use printers at LPT2-LPT6. Prior to W2K/XP, the following approach worked very well:
    • When the app starts, use the CAPTURE or NET USE command to Capture (Link/Match) the required LPTn port to the relevant named printer
    • In the app, copy the report to the relevant LPTn port – which then sends it to the appropriate “named” printer
    • Release the captured ports when the app closes.

LPT5+ had issues under W2K (The printer-status is returned as “Invalid”, yet printing works well!).

Under XP, LPT6+ don't work properly (I've not investigated).

Solutions:
    • Discard the LPTn:/CAPTURE/NET-USE/COPY/RELEASE approach.
    • Identify just the relevant Windows Printer-Names.
    • Use “Copy Report-File-Name \\Server-Name\Printer-Name” (if the printers are “normal” LPTn-type devices), or
    • Use “Print /D:\\Server-Name\Printer-Name Report-File-name” (for LPTn-type devices), or
    • Maybe try some some suitable Printing utilities such as Peter Lerup's PrintFile, or
    • Davide Guolo's PrintFil. Support here.

CMD.EXE and COMMAND.COM:
XP and W2K (and NT) have two Command-Interpreters (shells), CMD.EXE and COMMAND.COM.

    • CMD is a newer true-32-bit native command-line “shell” - with support for the older “DOS commands”. It is NOT a “DOS Window”. It has a significantly extended Batch language, Long-Filename support, command history (like DOSKEY), multi-threaded, drag-&-drop support, etc. It recognises files with the normal “program” extensions, including .COM, .EXE, .BAT, .CMD, .VBS, .JS, and .WS, and any other extensions that are defined in the PATHEXT env-var as executables. But, interestingly, if it is passed any file-name (with or without the file's extension), either at the command-prompt, or in a BAT file, then CMD.EXE will examine the file contents, and if it recognises it as executable, it will run it !!!!.

    • COMMAND corresponds to the old 16-bit shell, and starts an NTVDM (NT Virtual DOS Machine). It cannot support long-filenames, for example, does not set ErrorLevel after some commands, has the customary memory restrictions, etc. It is available for compatibility with older apps. Tests indicate that COMMAND internally calls CMD (for most functions!). It uses the COMSPEC Env-Var to locate CMD.EXE. If this env-var is not available, or if it cannot find CMD.EXE, then COMMAND.COM will just ignore any DOS-type commands. To check that COMMAND uses CMD:
        1. Close any “Console” windows.
        2. Launch Task-Manager, observe the Processes tab, and note that CMD and NTVDM are not running.
        3. File, New-Task, enter “Command.Com”.
        4. NTVDM will start.
        5. If you run some slow task (eg, DIR \*.* /s) in the COMMAND window, you'll notice that CMD will be run automatically.

I think DOS-like commands are executed as follows:
    • A DOS-Box is activated, from a shortcut, PIF file, BAT file, etc.
    • If a command-interpreter is not required, eg, when running a COM program, the program is activated.
    • For other EXEs, PIFs, CMDs (same as BAT, but processed under CMD.EXE in NT/W2K/XP), BATs or COMs, either CMD.EXE or NTVDM/COMMAND.COM is started, and this program eventually runs the required one.
    • To control many aspects of the execution of programs, PIF files can be tailored as appropriate, as discussed below.

If a command-interpreter is activated, tests suggest that the older COMMAND.COM is usually executed (eg, for BAT files). Some experts suggest that CMD.EXE may be marginally better, and, because it is a more recent product, it's use is generally recommended above COMMAND.COM. However, for older apps, and if all parameters are configured properly, my tests worked satisfactorily under COMMAND.COM.
    • You can usually control which cmd-int is used: eg, to force execution under CMD.EXE on W2K/XP, you could insert CMD.EXE /C in Icons/Shortcuts and at the start of BAT lines which call other programs or other BAT files.
    • If all users have W2K/XP, the perhaps just force CMD.EXE everywhere! (with CMD.EXE /C).
    • Obviously, if you use BAT files that must run on various OSes (and where CMD.EXE is sometimes not available), and if you'd like to exercise some control over which interpreter is used, then you have some choices:
    • You could build different BAT files for each OS, or
    • You could extend the BAT files internally to check for CMD.EXE, and use it where it's available.
    • Otherwise, your BAT file must not have any dependencies on the cmd-ints available; you're stuck with what's installed; you must plan for both....
    • The downloadable PdoxDOS PAL procedures (DO_RUN(), DOUBLE_EMBED(), etc) could be used to Shell-to-DOS. They will seek CMD.EXE, and use it if available. They have been tested (a little!) under W2K and XP, and have worked well so far...

I've seen some notes suggesting that:
    • XP defaults to the interpreter specified in the COMSPEC variable. There are a few places where one might try to SET COMSPEC – which I've not investigated, so I don't know if this comment is true. Overall, I think the statement is untrue.
    • Within a dox-box, COMSPEC can be checked to see which cmd-int is active. From brief tests, I think this statement is also untrue. For example, sometimes, if you open COMMAND.COM, and issue SET, you'll see COMSPEC pointing at CMD.EXE !! Also, as mentioned already, COMMAND.COM uses CMD.EXE to execute most commands, and uses the COMSPEC env-var to locate CMD.EXE. So, for now, I do not know any reliable way to determine WHICH cmd-int is activate – but, so far, I've never had a pressing need to know which cmd-int is running...

Microsoft has a good KB essay on some NTVDM issues.

PIFs:
I don't have a crystal-clear picture of all the angles on the usage of these files in W2K/XP; I've “stumbled” over the following issues... and some solutions which work...

These comments do NOT tell you precisely what to do; they're intended to alert you to the issues – you can then decide what's best for your users/clients/apps... In these notes, I'll try to visualise a Complex site, with lots of users, and all varieties of OSes. Your situations may be simpler...

I suggest that you “configure” the W2K/XP environment which applies to BOTH CMD.EXE and COMMAND.COM. This involves tuning/creating PIF files, and adjusting copies of AUTOEXEC.NT and CONFIG.NT.

W2K & XP have a file named _DEFAULT.PIF in the main “Windows” folder (usually C:\WINDOWS\, but better to use %windir% or %winbootdir%, or %SystemRoot%, as noted below). I think that this is used for all CMD.EXE shells, if no other PIFs are available.

I think the _DEFAULT.PIF is NOT the default for COMMAND.COM, but I don't know where it's default settings are held – perhaps the Registry, or maybe a file named NOCLOSE.PIF (?). However, you can just locate COMMAND.COM in %SystemRoot%\System32, get at it's Properties, and adjust the settings. This process will create (or update) a COMMAND.PIF file.

You might be in a position to configure the _DEFAULT.PIF and COMMAND.PIF files to your apps needs. If so, you probably should delete all PIFs that refer to your programs/BAT files, to ensure the default PIFs are always used.
(or, better, keep them in a safe Backup location, so that they can be retrieved if ever needed).

However, if users run a variety of apps, with different PIF settings, then you probably cannot meddle with these default PIF settings, and instead, you must supply special PIFs tailored for your BATs/Icons/Shortcuts, etc.

Your app might have many BAT files, many EXEs, many COMs, etc. And, you might have PIFs referring to some of these, and no PIFs for others. I assume (but I've not verified) that the dos-box will seek PIFs for each executable, and, where not found, revert to the “parents” PIF settings, and, ultimately, to the _DEFAULT/COMMAND settings.

To configure any PIF file, access its Properties, and adjust them as follows. NB: Many of the“default” settings are NOT suitable for PDoxDOS. You MUST check all the relevant PIFs, perhaps changing to the following settings:
    • Activate “Close on Exit”
    • Under “Program/Advanced”, change the references to the CONFIG and AUTOEXEC files, if relevant. (See below).
    • Under “Memory”, set each of the memory settings to AUTO, Uncheck Protected, and check Uses-HMA. Depending on whether and how your BAT files use Environment space, you may need to set the “Initial Environment” to AUTO, or you may need to set it to a desired value.
    • Under “Screen”, check Restore-Settings-at-Startup, check Fast-ROM-Emulation, and check Dynamic- Memory-Allocation. (However, I'm not certain that these are always the optimum settings ???).
    • Under “Misc”, Uncheck Always-Suspend, move the Idle-Sensitivity slider towards the Low end, Uncheck Exclusive-Mode, check Warn-if-still-Active, check Fast-Pasting, and check all the shortcut keys except Alt-Space.
    • Under “Compatibility”, check the Run-in-compatibility-mode, and select W98 (or W95). (See separate note below on “Compatibility-mode”).
    • A “QuickEdit” option may be accessible – that may have to be set in a particular way to facilitate Mouse/Beep usage. See separate Mouse/Beep section below.
    • Make any other desired changes (fonts, screen-saver, etc), and Save.

Also, if the app runs too slowly, or pauses occasionally, some experts recommend additional PIF changes:
    • Disable Compatible-Timer-Hardware in the active PIF(s) (in the Advanced button)
    • Disable Idle-Detection in the PIF
    • For Printing, choose LPTn in preference to Parallel, if this option is available in the app.

CONFIG.SYS/NT, AUTOEXEC.BAT/NT:
W2K/XP also have default CONFIG.NT and AUTOEXEC.NT files in the %SystemRoot%\SYSTEM32\ folder. I have seen comments indicating that these files are used only with COMMAND.COM, and not under CMD.EXE – I have not checked. You can use just these default files for running your DOS apps, or you can make special copies of them for each App, with whatever location and name that you prefer, (as documented in the above references). If you make separate copies of these files, then ensure that the PIFs refer to the special copies – as mentioned above.

You should check/change the CONFIG file:
    • You might want to activate the ECHOCONFIG command.
    • You might want to activate the NTCMDPROMPT command.
    • You might want to make other changes, add other lines, etc.
    • You might want to use ANSI.SYS.
    • See the Win-9X notes a few lines down for other possibilities.
    • Save.

You should check/change the AUTOEXEC file:
    • You might want to add a PATH statement.
    • You might want to change the defaults, delete/add lines, set Env-Vars, etc.
    • Experts recommend something like “SET PROMPT=$m$_$p$g”, to show the UNC name on LANs.
    • See the Win-9X notes a few lines down for other possibilities.
    • Save.

But, also see separate note below re Env-vars.

Win9X, etc:
CONFIG.SYS should probably include (assuming you use the relevant paths, options, etc, as appropriate):
    DOS=High,Umb
    Device=C:\Windows\Himem.sys /V
    Device=C:\Windows\EMM386.exe NOEMS I=B000-B7FF
    DeviceHigh=...all drivers...
    Maybe load ANSI.SYS.
    Shell=C:\Command.com C:\ /P /E:2048
    Country=353,437,C:\Windows\Command\Country.sys     (for Ireland!!)

AUTOEXEC.BAT should probably include (within reason!):
    Set Prompt=$m$_$p$g
    LH Mode Con Codepage C:\Windows\Command\ega.cpi)
    LH Mode Con Codepage Select=437
    LH Keyb UK,,C:\Windows\Command\Keyboard.sys

NB: I tried similar lines in the above files under W2K/XP to configure the environment, with limited success. Eg:
    lh %SystemRoot%\System32\mode.com CON CODEPAGE %SystemRoot%\System32\ega.cpi
    lh %SystemRoot%\System32\mode.com CON CODEPAGE Select=437
    lh Kb16 UK,,%SystemRoot%\System32\Keyboard.sys
When COMMAND.COM was opened, the first 2 lines above always gave “Bad Command or Filename” errors. I don't know why – except that I've seen some W2K notes indicating that the MODE utility has been changed a lot under W2K/XP. The 3rd line seemed to run correctly !!

In your “Start-Up” BAT files, I strongly suggest you use some utilities to ENSURE that your environment (Memory, Registry, Disk-Space, etc, etc) is acceptable, before starting the main apps. Furthermore, when PdoxDOS itself starts up, you should also run some additional tests on the environment. In some W2K/XP tests which I ran (without these pre-tests active), Paradox started up, but with NO (repeat NO!) extended memory, etc, etc. Unless the app code checks these basic matters, it may not be obvious that the app is running in an extremely restricted and compromised configuration.

PIF Compatibility-Mode: Another “interesting” one. The Properties of any executable file, which, I assume, includes all EXEs, COMs, BATs, PIFs, etc, include a “Compatibility” tab. This has a few settings, including a Win-95 option, W98, etc. One interesting factor is that these settings are NOT held within the PIF file (as applies to all other settings). They are held in the Registry in [HKEY_USERS\ ????\ Software\ Microsoft\ Windows NT\ CurrentVersion\ AppCompatFlags\ Layers]. Which means that it's not so easy to distribute an app with suitable Compatibility-mode settings already prepared. You may need to advise the installer to set them manually. Also, these settings apply to the PIF itself, as well as applying to the BAT/COM/EXE file that the PIF controls. AFAIK, you can have X.BAT, which runs X.COM, and X.PIF (which has the settings applying to X.COM). “Compatibility-mode” options appear on the properties of X.BAT and X.PIF, and can be set differently. If they are different, I don't know which one gets priority. I suggest it's safer to use the same settings on BOTH tabs.

%windir% / %WinBootDir% / %SystemRoot% Env-Vars:
Another issue relating to CMD.EXE vs. COMMAND.COM: If you run SET in each, you'll probably see different Environment-Variables. (I think the CMD.EXE vars are based on those accessed from the Control-Panel, whereas those for COMMAND.COM are based on the relevant AUTOEXEC file). Previous versions of Windows had a %windir% variable to identify the Windows Folder. Under XP, it seems the more appropriate var is %SystemRoot%. So, if you have some code that likes to know the Windows Folder-name, you'll probably have to check for all 3 of these env-vars, as shown in the sample “Do_Run()” PAL code.

Environment Variables:
In W2K/SP, the set used for COMMAND.COM differs from that used for CMD.EXE. So, if you want to assign special vars, or extend the PATH var, etc, you'll probably need to adjust AUTOEXEC.NT and/or any additional special AUTOEXEC files, AND the entries reached under Control-Panel; System; Advanced, Env-Vars. In the later case, you have access to “System” vars, and to vars for a specific user... Perhaps alter the “System” ones, but YMMV (your mileage may vary!).

In some brief tests, it seems the PATH is sometimes still limited to a total length of 127, but I've seen notes that a longer path can be built by inserting a prefix of \\?\.

After making any changes, you should run your BAT file(s), include SET statements where appropriate, and verify that your env-var updates are ok.

And, if all your systems support CMD.EXE, then Script files can use SetLocal and EndLocal to simplify the use of temp variables.

Mouse BEEPs / Hangs under W2K / XP / Terminal-Services:
Since W2K was released, the problems of using the Mouse with older apps continues to be a “work-in-progress”. And some BEEPs sometimes Hang! Hopefully all of you readers will contribute your experiences, and we will be able to itemise the definitive recommendations...

You MUST have all the latest SPs and major OS patches applied. At the time of writing, these are at SP4 for W2K, and SP1 for XP.

Some messages on the NGs mention some never-ending BEEP problems under W2K/XP. Under W2K (without -BIOS), I did encounter “hangs” where, for example, a ValCheck (in PdoxDOS) fails. Normally, a short BEEP would be issued, but in my tests, a hang occurred, probably just before or at the start of the intended BEEP. It seems these Beep and Hang matters are interlinked, and they suggest a problem with W2K/SP4 related to the internal handling of the Keyboard port (which supports the beep also), and timers. No similar issues were noted with XP.

Basically, Mouse movements in the above environments either
    • work properly, or
    • move the Mouse pointer (as used to Select a text-area), but the normal input cursor does not respond, or
    • cause major crashes.

Sometimes BEEP never stops. I think there may be 2 factors here – at least:
    • There's a well-known bug in the Paradox engine: If SLEEP (not BEEP) extends over the period from just-before midnight to just-after, then SLEEP won't stop. For this reason, a special PAL proc should always be used instead of the standard SLEEP operation, to ensure this condition cannot arise. (Example available on request). It's likely that similar code is used within Paradox to implement the SLEEP and BEEP, and maybe there is some connection with this bug in Pdox, and some BEEP problems).
    • Over the years, the general advice is to use “-BIOS”. But, in some environments, this causes Mouse-movements to Bomb (see table below). However, if “-BIOS” is NOT used in the command-line, then sometimes BEEPs will hang (Steve Green has further details) or the system will Hang with no sound. Also, some other users have reported better results generally under W2K/XP if the -BIOS is omitted. ... work-in-progress.... However, so far, I think we simply MUST use -BIOS, and then try to work around any remaining issues.
 
OS? SPs? Cmd or Command Windowed QEdit Ticked? -BIOS Mouse Notes
XP SP1 Both Y/N N (n/a) Y (or N) OK OK
XP SP1 ? ? Y ? OK Select-text only; No app "Cursor".
W2K SP4 CMD Y Y N Hang Generally OK; Might bomb on Startup.
W2K SP4 CMD Y Y Y (n/a) Bomb !!
W2K SP4 CMD Y N N Hang Generally OK; Might bomb on Startup.
W2K SP4 CMD Y N Y (n/a) Bomb !!
W2K SP4 CMD N Y N Hang Select-text only; No app "Cursor".
W2K SP4 CMD N Y Y (n/a) Select-text only; No app "Cursor".
W2K SP4 CMD N N N Hang Generally OK; Might bomb on Startup.
W2K SP4 CMD N N Y (n/a) Bomb !!
W2K SP4 COM Y Y N ? ?
W2K SP4 COM Y Y Y ? ?
W2K SP4 COM Y N N ? ?
W2K SP4 COM Y N Y ? ?
W2K SP4 COM N Y N ? ?
W2K SP4 COM N Y Y ? ?
W2K SP4 COM N N N ? ?
W2K SP4 COM N N Y ? ?

It seems that a variety of factors influence the results:
    • Command-Interpreter: CMD.EXE or COMMAND.COM? I could not get a COMMAND.COM DOS-box running reliably under W2K (probably due to dual-boot problems), so the BEEP and MOUSE results are “pending”. I plan to build another test-PC with W2K, and then hopefully complete the above matrix.
    • Full-Screen or Windowed: Windowed recommended (perhaps mandatory!). Under Terminal-Services, the app should be “locked” into Windowed. Unfortunately, Full-Screen normally yields better performance than Windowed! For some interesting options on how to enable Full-Screen mode, especially under VISTA, check here - it discusses using an XP video driver, using a standard SVGA driver, and using a DOS emulator, eg, DOSBOX.
    • “QuickEdit” ticked in the PIF file: If checked, the Mouse can be used to select text, and cut/copy/paste it. The default XP behaviour is to disallow QE. On the COMMAND.COM icon, this option is greyed out, and unchecked. (Perhaps because COMMAND.COM never supported QE functions?). Yet, when the icon is activated, to open up a “dos-box”, the option is not greyed, and is initially checked. NB: to get at the default XP setting of QE, use RegEdit to access HKEY_CURRENT_USER\Console, and set QuickEdit to a Double-Word of 0 (default, disable), or 1 (enable). While in this section of the Registry, you can also access the QE settings of all defined shortcuts.
    • “-BIOS”: Generally recommended, and others have experienced BEEP problems when it is omitted....

"-NoRealHeap”: Command-line option: I think it matters little, but maybe it results in better stability.

For now, the highlighted lines in the above table seem optimal !! And these suggest that W2K should be used as sparingly as possible !!


Windows 2003 Server:
Dave Porter reports that this OS is much better than W2K, and reports no problems with Beeps, Mouse usage, etc. It might be interesting if someone were to check if the CMD.EXE, COMMAND.COM and/or NTVDM.EXE tools could be lifted from W-2003, and run under W-2000 !!.

Purge Priv-Dir:
I've seen recommendations that the Priv-Dir should be emptied before or just when Paradox starts up. It seems to be a good idea anyway, because temp-files are sometimes left in this folder after crashes. I have a PAL proc to do this – if anyone is interested.

Note:
    • If any ZZZ file is there from a prior crash, it should be copied to some other safer place before the folder is cleared.
    • Any special CFG files should not be deleted.

Paul A (ID is “HyperNoodle” on the NGs) suggested some BAT lines:

   Save the ZZZ file to ???

   For %%i in (C:\Pdox-Pvt\*.*) do If /i Not “%%~nxi”==“PARADOX.CFG”
   Del /f /q %%i

Poor performance with XP & W98:
Very poor performance has been reported when exchanging data between XP and W98 PCs. For much info, check Brian Livingston's newsletters; especially BriansBuzz...030619.

Suggestions:
    1. Replace old Hubs with Switches
    2. Tune Anti-Virus software (don't scan ALL files – see next section)
    3. Disable unwanted LAN protocols.

See separate note here on NIC settings.

If low speed is still an issue, maybe run some "traces" on the LAN, to help identify the causes. Ethereal is highly recommended, and is Open-Source, and Free! As well as logging traffic in a wired installation, it can also handle some Wireless environments. See the Ethereal website for full Docs. Preferably run it on a separate PC which can log the traffic between a suspect client and the server. If "switches" are used, Ethereal may not be able to see all relevant traffic, so you may need to investigate the config and logging options in the switches (eg, port mirror the relevant port on the switch), or perhaps temporarily install an old-fashioned hub!.

Anti-Virus tuning:
Generally, the default settings in Anti-virus tools include:
    • Scan ALL files, each time they are accessed
    • Scan ALL emails as they are downloaded.

The consensus is that these specific defaults are not appropriate for shared databases:
    • Scanning ALL files significantly degrades application performance, and serves no useful purpose where database files contain no executable code, and therefore cannot be “infected”.
    • And scanning all emails are they are downloaded can also degrade performance, and seems pointless if the user will diligently delete all suspect emails before they are opened. Also, I've seen configuration problems where tools (which automatically intercept and analyse emails) upset the standard email software, especially if the email software is being re-installed, re-configured, or upgraded.

Recommendations:
    1. Configure the resident AV tool to scan ONLY files (including emails) that can contain viruses. (In NAV, this is termed “SmartScan”).
    2. When running a full “Batch” AV scan (perhaps weekly), then ensure the AV tool is configured to scan ALL files.
    3. Use some utility to review all emails before they are downloaded, and delete all the rubbish there. (I use Magic Mail Monitor, a free open-source tool from SourceForge.net, but there are many similar tools).
    4. Don't configure the AV tool to scan emails are they are downloaded.
    5. If an attempt is made to open an infected email, the resident AV utility should detect it, and alert the user.

Long-Filenames:
Seemingly, there are at least 3 different algorithms in the various Microsoft OSes to shorten long-filenames to an 8.3 format. To avoid problems, the general recommendation is to ALWAYS use only 8.3 formats.

Further info at:
    http://support.microsoft.com/default.aspx?scid=kb;en-us;Q142982
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;174456
    http://www.chami.com/tips/windows/122496W.html

For WinNT/2000/XP, if you're getting errors related to 8.3 filenames, or if you run any apps that require 8.3 support, then you should verify that the 8.3 naming feature is enabled:
    • Open REGEDIT (Start, Run, Regedit)
    • Navigate to: HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Control\ FileSystem
    • The value of "NtfsDisable8dot3NameCreation" should be '0'.

If you have no "8.3" apps, then disabling the generation of 8.3 filenames (by setting the above value to '1') is supposed to yield improved performance.

LAN speeds at 100Mbs?:
If some/all the NICs and some/all the Hubs/Switches are capable of running at 100Mbps, it is strongly recommended to check the actual LAN throughput. Some users have reported poor LAN speed when the NICs and/or Hubs/switches were set to "Auto" - it seemed the devices were spending significant time trying to negotiate the optimum speeds. In some cases, forcing the speed to 100/Full-Duplex yielded significant improvements. However, in other cases, this approach actually decreased the LAN speed.

For NICs in individual PCs, the usual procedure is something like:
    • Settings/Control-Panel
    • Network
    • Select the NIC/Ethernet Adaptor, and hit Properties
    • Advanced tab
    • Select Duplex-Mode, and set it to Full-Duplex
    • Select Speed, and set to 100Mbps
    • OR, set the speed to Auto!!
    • OK, Save, Exit
    • Test !!!

You should similarly check if there are features/options in your hubs/switches to force them to Full-Duplex, and 100Mbps, and test each option.

"RETURN RETVAL" in Paradox-DOS:
This “burned” me some years ago, and has not been mentioned on the NGs (AFAIK), and arose again just recently in some discussions with Steve Green.

If you're an expert PAL programmer (eg, if you're familiar with changing the standard RETVAL definition to a global Array – perhaps where you're trying to return multiple values in a single RETURN statement), then just ignore this note – you know it all already.

Basically, I think a simple RETURN RETVAL statement should be used with some caution:
    • RETVAL is a normal GLOBAL Variable.
    • RETVAL is automatically filled by very many PAL operations, as noted in the PAL manuals.
    • RETVAL is also filled, automatically, by the RETURN statement, if a value/variable/expression is included in the RETURN syntax. (Long strings are truncated to 255, etc).

From a compiler viewpoint, I think the 3rd point above is odd...

So:
    • RETURN (only) will leave the global RETVAL unchanged, and as per it's more recent update.
    • RETURN XYZ will automatically copy the contents of XYZ into RETVAL.
    • But, RETURN RETVAL ?: Assuming no complex intention is involved, this is a strange statement, IMO, and maybe best avoided. Will the system try to copy RETVAL into RETVAL? Hello?
    • If the CallING code is explicitly using the returned value, then the RETURN statement simply must include the returned Expression, and so-be-it if it's got to be RETVAL.
    • If the CallING code is not explicitly using the returned value, then RETURN RETVAL and RETURN are always equivalent (I think), and I would vote for the latter.
    • The general advice is to use or preserve RETVAL immediately after it has been set, because subsequent operations, including Calling any Proc, may change it.

MS / NOVELL Client (LANs):
The general advice is that you MUST have version 4.83 SP1 (or later) of the Novell-Client drivers. (I have not confirmed that this advice applies only to specific OSes, eg, W2K and/or XP, or to all versions of Windows). Currently, I do not have recommendations for MS clients...

To check the version of the MS client (in W98):
    • Settings/Control Panel
    • System
    • Device Manager
    • Select the Network Adaptor
    • Properties
    • Driver
    • Driver File Details
    • Check the “File Version”, update if needed.
    • (OK, Close)

VREDIR / VNETSUP:
On Windows 95 and NT systems, you MUST check that VREDIR.VXD is at version 4.00.1116 or later, and VNETSUP.VXD is at 4.00.1112 or later. If necessary, download the latest versions from MS (filename is Vrdrupd.exe).

Win98SE Updates:
Recently (2004-2005 epoch !), some tech users have composed excellent "Service Packs" and advice to update W98SE installations. In general, these packs contain many/most of the Microsoft fixes and updates, and also contain some 3rd-party add-ons. For excellent advice, try Bob G's notes here, or Axcel216's (or MDGx!) excellent site here (general) or here (specific). And check out the latest "Win98SE-SP" at Exhuberant or here.

High CPU usage:
Numerous issues can result in very high CPU usage. One which we've experienced recently (in XP) was caused by installing a very large HOSTS file. In such cases, a special Hosts "server" service should also be installed. If no precautions are taken, one of the SVCHOST sessions grabs all available CPU cycles, apparently for periods of 20-25 mins! A recommended solution is to access the running "services", and to stop and disable the "DNS Client".

Some CPU loading is caused by old 16-bit apps that are constantly polling the keyboard, awaiting keystrokes. In these cases, this behaviour results in no other apps getting any worthwhile CPU cycles, and the PC will seem to be "hung". Obviously, the best solution is to change this software to NOT poll the keyboard, and to release all CPU cycles until an actual keystroke occurs (ie, intercept the Keyboard-Interrupt). If the software cannot be adjusted, then the solution is to intercept this polling, pause it briefly (in millisecs!), and yield these CPU cycles to other tasks. The topic is covered in great detail here, where a highly recommended software utility, TameDOS, is available. The subject is also covered by Citrix, here, and a few solutions are discussed - including DOSKBD and DPAKBD (and TameDOS is also mentioned!).

All my tests of Paradox-DOS indicate that it does NOT constantly poll the keyboard in the above fashion, and, therefore does not overload the CPU in that manner. And, therefore, the above solutions are not relevant. So, if PDoxDOS does seem to lock out the CPU, it suggests that other factors are involved - eg, Anti-Virus/Spyware scanners, etc.

BDE - Latest Version (5.2.0.2):
Use only the latest version. Download from the Corel website (or from here, or from anywhere!). BUT, before upgrading, ensure that the manufacturers / suppliers of your BDE apps have no objections to using the latest version.

After upgrading, ensure all the BDE options are still optimal, as noted in the next section.

To get the Version-No of the installed BDE: Start; Settings/Control-Panel; "BDE Administrator"; Configuration; Object; Version Information...


BDE - Optimal Config:
Some basic notes / rules regarding BDE (for optimum stability and speed):
  1. Ensure that "Opportunistic Locks" are Disabled on all PCs on which the BDE is running, and on the servers (if the servers are running Windows). See fuller details above.
     
  2. A special "NET Directory" should be created on the Server, accessible to all BDE clients. It should be down at least 2 levels, eg, X:\BDE\NET\. Use Control-Panel; BDE-Config; Configuration; Drivers; Native; Paradox. It must be EXACTLY the same entry on ALL BDE clients. For stand-alone apps, obviously, it must be somewhere on the "local" PC. If you're changing this value, you should first ensure that no BDE clients are running at that moment, and you should scan all PCs (Server and Clients) for all old PDOXUSRS.NET (and PARADOX.LCK and PDOXUSRS.LCK) files, and delete them. If they won't delete for you, you may have to reboot the PC, and re-try the Delete.
     
  3. A special "Private Directory" must be defined in the apps also. It should be on the Local disk, and should also be 2 levels deep: eg, C:\BDE\PRIVATE\. It should normally be empty.
     
  4. The "Block Size" defaults to 2048. Leave this, or increase it as needed. See separate notes below.
     
  5. Start; Settings / Control-Panel; BDE-Config; Configuration; System; Init - for the following items (thanks to Liz McGuire and others for compiling many of these at www.TheDBCommunity.com)...
    • "Language": "ASCII" ANSI, or whatever is appropriate.
    • "Local Share" (default = FALSE). Change to TRUE - ALWAYS!
    • "Low Memory Usage": 32 (Default)
    • "Max Buff Size" (default = 2048): 8192 (if 32MB RAM); 16384 (if 64MB), 32768 (128MB), up to 65536 (>= 256MB).
    • "Max File Handles" (default = 48): leave at default, or increase, up to 100 max. Run some tests to get the optimal value.
    • "Mem Size" (MB; default = 16); 15 (if 32MB RAM); 35 (if 64MB), 80 (128MB), up to 192 (>= 256MB). (Ie, about 0.75 * "free" RAM)
    • "Min Buff Size" (default = 128): 4096.
    • "Shared Mem Location" (default = Blank): Recommendations to set to 5BDE or 6BDE. (I assume these are Hex values).
    • "Shared Mem Size" (KB; default = 2048): 6000 (if 32MB RAM); 14000 (if 64MB), 25000 (128MB), up to 60000 (>= 256MB). (Ie, about 0.25 * "free" RAM)
    • [Other items left at default values]
       
  6. Of course, it's always possible that some other app might upset the BDE settings at a later time. Therefore, it's recommended that you check them from time-to-time, just to ensure they're not clobbered...
     
  7. A specially-modified DLL must be used to avoid the "4GB" blow-ups. See here.
     
  8. In the properties of your BDE apps/icons, ensure that "BackGround Suspend" is NOT selected. And perhaps check this from time-to-time, to ensure it's still OK!
     
  9. See here for some commentary on Op-Locks, BDE settings, Paradox Data corruption, etc.

BDE - Insufficient Space:
Just like the older Paradox-DOS products, the BDE also cannot handle large Hard-Disks - typically where over 4GB is free in the partition. The internal calculations hit "overflow" conditions, and the BDE incorrectly thinks that the free space is very low (or perhaps negative), and it bombs with an "Insufficient Space" error. For solutions, you should check on the BDE discussion groups, etc.

These links might also be useful:
    • http://qc.borland.com/wc/qcmain.aspx?d=7089. Discussions, some suggestions for developers.

    • http://codecentral.borland.com/codecentral/ccWeb.exe/listing?id=21475. A Delphi-based solution. Reputed to be inappropriate for some OSes, eg: http://threads.borland.com/threads/threads.exe/thread?refid=23207&view=fulltext&anchor=0#0.
.
    • Rick Kelly has created an excellent generic recommended "patch" to eliminate the 4GB bug. Rick Rans composed usage instructions, and I supplied a simple "hex patcher". It's best home is probably here (Downloads, ""), so visit there for all the latest on it. Meanwhile, I've a copy of the package on the Downloads page.

I was marginally involved in a 2GB/4GB discussion on the "Borland.Public.BDE" discussion group, in which the main contributor, C.P., posted the following message on Dec 16, 2006:

"Thanks, I actually saw that.

But, in investigating the Code Central 'fix', I found that Delphi users have 2 versions of GetDiskFreeSpaceEx available:
  - One in Windows.pas, and
  - One in SysUtils.pas).
Both versions of GetDiskFreeSpaceEx return 2 possible values for free space:
  - the total free space on the path, or
  - the free space available to the caller.
Depending on which GetDiskFreeSpaceEx version, which OS you're using, and whether you're checking total free space vs. free space to/for the caller, you'll get different results.  I found the only way to get consistently correct results was to use the SysUtils.pas version of GetDiskFreeSpaceEx.

  1. The Windows.pas version of GetDiskFreeSpaceEx is the 'raw' API version from Kernel32.
  2. The SysUtils.pas version is a Borland version to deal with the fact that some OS'es don't actually have GetDiskFreeSpaceEx in their API.
  3. The Windows.pas version was only correct for Win2000/XP/2003 (but not NT, Win98).

I don't have disk quotas turned on, on my SBS 2003 server.

With the Windows.pas version of GetDiskFreeSpaceEx, it always said there was about 4000 petabytes of free space available to the caller, regardless of OS.  On Win2000/XP/2003, it gave the correct amount of 'total free space'.  (One WinNT/98 it always rounded 'total free space' _down_ to the nearest 4GB, so if there was 7 GB free, it'd say there was 4.  If there was 3 GB free, it'd say there was 0).  I'm guessing that if I did have disk quotas enabled, the free space available to the caller might actually show the correct value on Win2000/XP/2003.

For the SysUtils.pas version, I got the same, correct values for all OS'es, for both free space available to caller, and total free space.  If I had disk quota's enabled, I'd hope to maybe see differing values for free space available to caller, but I haven't tested this.

BTW, my testing is done with a Delphi 5 app.

I'd like to know exactly what Rick Kelly's code looks like - especially if he used Delphi.  The Code Central patch was always checking the space available to the caller using the Windows.pas version of GetDiskFreeSpaceEx. So it thinks there's always 4000 petabytes free, which the patch will then always report as 4 GB free.  My suspicion is that Rick Kelly's patch is probably directly using the Win32 API version of GetDiskFreeSpaceEx.  And, as a result may not get the correct results for free space on 98 or NT.  If he's only checking the free space available to the caller, it may also be wrong on 2000/XP/2003.

I'm posting this in part because this stuff is a bit new to me (I don't usually deal with the Win API).  It's possible that I may have done something wrong, but I'm pretty sure my testing of the 2 GetDiskFreeSpaceEx versions is solid.  There's type conversion going on between standard Win32 API (C) types and Delphi types.  Maybe the problem is actually in Delphi 5, and not the GetDiskFreeSpaceEx Win32 API?  So, if Rick used some other language, then maybe he wouldn't see what I saw."

[I've made marginal formatting changes to the above quote. At the time of writing this note, I could not find the above message/thread via Google, so I was unable to post a direct link to it. My view is that Rick's patch should be OK in all environments, but this is not verified. I'll update the above, if/when any clarity emerges].

BDE / Paradox - DB Capacity:
(This is my summary, and is subject to correction!):

The maximum capacity of each table is determined by:
  - the "Block-Size" of the table
  - the size of each record (= width of each "row") in the table.
  - the max no. of Blocks in a table - always 65,500 (approx).

Block-Size:
"Block-Size" is a parameter among the BDE/Paradox options, ranges from 1k to 32k, and can be any of the following values:
     1024 (1K) [64MB]
     2048 (2K) [128 MB]
     4096 (4K) [256 MB] (there's no 8k block-size, supposedly because of reported bugs with this value)
    16384 (16K) [1024 MB, 1GB]
    32768 (32K) [2048 MB, 2GB]
The value within squared brackets is the maximum size of the data in a table, for the stated Block-Size.

The block-size of each table is determined when the table is created:
  - If the table is created "Manually", the Block-Size is taken from a setting in the BDE config at that time. The block-size is usually either 1k or 2k, which would allow for table(s) to be up to 64MB or 128MB.
  - If the table is created "in code", eg, from a Query, the BDE will decide on the Block-Size, and I think it's usually the biggest block-size of all the contributing tables. However, note that some "Join"-type Queries might initially generate huge volumes of data in temporary tables, and then discard most of this data before delivering the final result table. In such cases, the huge internal tables might exceed the available capacity thresholds (and throw errors, or generate incorrect results), even though the final result is well within the max limits!

Warnings:
  1. I've seen notes somewhere that 8K block-sizes were "problematic", and therefore that value is not supported. Furthermore, at the time of writing this note, some Paradox-NG messages (esp. from Denn Santoro) suggested that 4K was stable, and that 16K and 32K may have "issues" - in some situations. [Personally, having been involved in the development of some similar low-level ISAM handlers, I can understand "boundary" conditions arising when blocks are marginally under or over or exactly at various thresholds. If 8K and/or 16K/32K are problematic sometimes, then I'd guess it's possible that all values are problematic under similar boundary conditions - except that, hopefully, these boundaries occur very infrequently in real-life. The ultimate "test" is to write "Soak" code, which bombards the database with random functions and random data (Reads, Inserts, Updates, Deletes), perhaps running for days-on-end. It must separately record every action it performs, and remember the effect it "should have" on the main database. Then, on demand, it can verify that the database matches the data that "should be" in it - at that moment. If not, retrace the activity until the bug is identified].

  2. Some internal Paradox code, and (because BDE was built on earlier Paradox functions), possibly some BDE code also, is not robust  when using Secondary-Indices into tables that contain over 32,000 (32,767, actually) Blocks. Ie, tables that are more than half their maximum capacity. If any records are held in the upper half of the available blocks, then the Sec-indices are totally ignored, and Sec-Index performance collapses. The solution is to ensure that tables with Sec-Indices never exceed HALF their capacity, and, if it's likely to happen, then to increase the Blocks-size as needed. (And TEST the increased Block-size!!)

  3. Why not always use the MAX Block-size? Obviously, you must first choose a block-size that's adequate for your databases. And then a block-size that's stable. Finally, if this leaves you with a few block-size options, you should check the speed of your app, with typical tables, typical operations (inserts, deletes, searches, etc), and on typical hardware (PCs, LANs, Servers). Not a trivial task - especially if an app has 50-100 tables!! You'll probably find that, in most circumstances, the smallest (acceptable) block-size, per table, will deliver the best overall performance.

Record-Size:
The number of data-records that fit into each "block" depends, obviously, on the size of each record, which depends on the fields (and bytes) in each record... First, here's a list of field-types:
Data-Type Code Bytes
Alpha A 1-255
AutoIncrement + 4
BCD # 17
Binary B *
Bytes Y 1-255
Date D 4
Formatted Memo F *
Graphic G *
Logical L 1
Long Int I 4
Memo M *
Money $ 8
Number N 8
OLE O *
Short S 2
Time T 4
TimeStamp @ 8

* = this data is stored externally, in the table's .MB file. A field-header is stored in the main .DB table - it's 10 bytes + the size (1-255) of the actual data that's held in the main table.

And there's always an overhead of 6 bytes per Block, and a block cannot handle "split" records. Eg: if Record-size = 100, and Block-size is 2048, then the max. no or records per block = Integer of ((2048-6) / 100) = 2042/100 = 20. And, in that case also, the max No. of records in that table = 20 * 65500 = 1,300,000 (approx).

Capacity:
Examples - this table shows the max no of records (approx) that can be in a table, with various Record-Sizes and Block-Sizes:

Rec-Size BlkSz-2k BlkSz-4k BlkSz-16k BlkSz-32k
50 2.6M 5.3M 21M 42M
100 1.3M 2.6M 10M 21M
200 655k 1.3M 5M 10M

Other factors may also limit the theoretical maximum capacity of tables - eg, specs of Secondary-Indices, "Packing", distribution of keys, etc.... And, if Block-sizes are changed, apps must be tested - some users have reported issues with some Block-sizes...

Finally, if you have a table that's "maxing out" with it's current block-size, and you want to give it some more headroom, then the normal procedure is to do the following steps manually - or write special code to implement them:
  - Change the BDE to the block-size you want
  - Build a new empty table (it'll have that new block-size)
  - Copy the data from the old table to the new one
  - Activate the new table instead of the old one (keep a backup of the original table!)
  - Reset the BDE - if needed.
  - TEST!!!!!!

BDE / Paradox - LockWise / NetDump / LockDump (and BDE API):
These utilities are useful to analyse the NET and LCK files, especially when problems arise.

LockWise is available from Al Breveleri, and can be downloaded from here.

NetDump and LockDump are on the Downloads page.

For details on all the low-level functions available in the BDE, check here.

"Lock file has grown too large":
Ensure that the app is designed to use at least 3 separate folders/sub-folders: DATA, NET, and PRIV, and confirm that the app is ACTUALLY using the assigned PRIV and NET folders! More specifically:
    • In Delphi, use something like:
           Session.PrivateDir := ExtractFilePath(ParamStr(0)) + 'PRIV';
           Session.NetFileDir := ExtractFilePath(ParamStr(0)) + 'NET';
    • In C / C++:
           DbiSetPrivateDir(szPath);
                // szPath is the fully qualified path (not relative) to the PRIV directory.
           DbiSetProp(hSes, sesNETFILE, (UINT32)szPath);
                // szPath is the fully qualified path (not relative) to the NET directory.
                // hSes is the current session handle. This can be retrieved using the DBiGetCurrSession function.

BDE / Windows VISTA / Office 2007:
VISTA:
Some folks have reported that the BDE works well under Vista.
    • One needs to be aware of the additional attempts in Vista to control access to Folders, Files, etc, and therefore the .NET file must be placed in a suitably accessible area. ALL Users must have full access to this directory, and these permissions must automatically apply (cascade) to all files and sub-folders in it. The same full-access permissions must also be applied to all database folders - to allow full shared access to the .LCK files, as well as to the data files.
    • To Config BDE under VISTA, choose Objects | Options from the menu; and check the "Win 3.1 compatibility" checkbox (save for use with Win 3.1/Win95). All BDE settings will then be stored in the BDE config file (idapi.cfg), instead of the Registry (HKLM).
    • Ensure the "idapi.cfg" file (and all other "data" files, INI files, etc) are not saved within the "c:\Program Files\" folder and sub-folders.
    • It may be necessary to disable UAC (User Account Control): http://www.petri.co.il/disable_uac_in_windows_vista.htm

OFFICE:
However, BDE apps do NOT work when MS Office 2007 Beta-2 is installed, and the B2TR patch has been applied (Beta-2 Technical Refresh). This is discussed in some detail at Microsoft TechNet - this thread includes a suggested workaround. Depending on your browser, the thread might spread across multiple "pages", and workarounds are split across a few posts there.

Quoting others:
  1. "There are a couple of workarounds you can try, that others have reported helped via editing registry entries, but be cautious on later using either Office 2007 repair or Office 2007 diagnostics as those features can 'repair' things back to the defaults:
Before modifying the registy backup the HKEY_LOCAL_MACHINE (HKLM) branch at HKEY_LOCAL_MACHINE\Software\ODBC
    • HKLM\Software\ODBC\ODBCINST.INI\Paradox  -  Replace 'Paradox' with 'Microsoft Paradox'
    • HKLM\Software\ODBC\ODBCINST.INI\ODBC Drivers\Paradox  -  Replace 'Paradox' with 'Microsoft Paradox'
    • HKLM\Software\ODBC\ODBCINST.INI\dBase  -  Replace 'dBase' with 'Microsoft dBase'
    • HKLM\Software\ODBC\ODBCINST.INI\ODBC Drivers\dBase  -  Replace 'dBase' with 'Microsoft dBase'

  2. Two customers have reported that the following change may help the changes from being undone by MS Office 2007 Diagnostics: For each of the following, add 2 new string values named DLL and DLL32, and use 'blank' for the values for each string (for each key):
    • HKLM\Software\Borland\Database Engine\Settings\Drivers\Paradox\Init
    • HKLM\Software\Borland\Database Engine\Settings\Drivers\DBASE\Init

  3. If those DLL and DLL32 string values already exist, then it may be helpful to check changing 'Paradox' and 'DBASE' in the main keys to 'Microsoft Paradox' and 'Microsoft DBASE', respectively.

My comment: presumably, instead of 'changing' some entries at the tails of the Reg-keys, you could just leave the old branch unchanged, and create a duplicate branch, with the 'Microsoft' terms added. Perhaps Block Copy/Paste operations will do this; or you could export the old branch, change the REG file, and hen Import the revised REG file.

BDE on a P2P arrangement:
SMB2 mist be disabled on the machine that hosts the shared databases:
    • Registry: HKLM/SYSTEM/CURRENTCONTROLSET/SERVICES/LANMANSERVER/PARAMETERS
    • add an entry named "SMB2", DWORD, value = 0
    • Reboot.

Matthew Jenkinson (www.responsive.co.nz, and author of some very neat-looking Accounting systems) referred me to the GartPlan website, which has excellent technical notes on some BDE issues:
    • http://www.gartplan.dk/info/VistaConfig_US.htm
    • http://www.gartplan.dk/info/NetworkSettings_US.htm
    • http://www.gartplan.dk/info/ParadoxSettings_US.htm
    • http://www.gartplan.dk/info/DomainUserConfig_US.htm

BDE/Paradox - VISTA:
The following message was posted by Tom Kreig on a Paradox Forum (www.TheDBCommunity.com). You should look it up there in it's entirety, and all responses to it:

From information so far, it seems Vista security is blocking Paradox, and there are a number of options in Vista which *may* overcome this. In a different thread, Bertil suggested I use the -e switch to stop Paradox writing to the registry. Also, there are a number of places on the web which have provided steps to try when having installation and compatibility problems. Let me summarise what I *think* may be effective, from what others have written:
  1. Run the Paradox installer in WinXP compatibility mode, and as administrator.
  2. Run the BDEAdmin and Paradox in WinXP compatibility mode.
  3. Copy the BDE manifest file from the dBase website and save it to the same directory as the BDEAdmin.exe file.
  4. Create a manifest file for the Paradox exe in the same directory (there are examples on the web).
  5. *Don't* write to the registry in your applications.
  6. Use the -e, -w and -p switches when starting Paradox.
  7. Set all Paradox settings for your application in its startup script.
  8. Turn off "save on exit" and "resume on startup".

Accept the fact that when Paradox starts, users may be asked to verify that it's allowed to start. I don't think this would be a problem with many users, in fact you could sell it as an extra security *feature* or your application.

I don't have a Vista machine to test on as I can't afford the time it would take to set it up. But I will soon and will try Runtime on Vista first (anyone tried it yet?). As I distribute my applications with runtime, if I can get runtime working on Vista I don't care if full doesn't; I can keep going with XP for at least 7 years (according to MS) for my development machine.

I do know that the SQL Server 2005 Management Console is compatible with SQL 2000, so I can run 2000 on SBS2003 or R2 and still control it from a Vista box. I'll be transferring all my databases to SQL2005 shortly and will see if there are any inherent problems with Paradox (I use the MS ODBC driver so I don't foresee many).

Also, as I don't have Paradox shared tables (the only tables I use are in PRIV, the shared data sits in a MS SQL database accessed via pass-through SQL and ODBC), it may be Paradox and Vista will be better behaved than if I were using a Paradox table database. Time will tell.

Remember, there are no such things as problems. There are only solutions waiting to be found.

BTW. I use P10/SP3.

BDE - MS App Verifier:
I've seen references to error-messages produced by the Microsoft Application Verifier utilities, when checking BDE-based apps [TDatabase components using ODBC]:
    • TDatabase.Close emits the error: "Freeing heap block containing an active critical section."
    • App Close (ie, "free" the TDatabase component) emits: "Unloading DLL containing an active critical section."
It's suggested these errors arise in IDAPI32.dll (eg, in the DbiCloseDatabase call), but no solutions have been identified.

PRINTING / USB:
Old apps usually print to LPT1/2/3, or to a File. Printing to Local USB printers, or to Network printers, or to "Windows" printers, is challenging - especially if the app code cannot be changed internally. Some apps were designed to write to only Epson/IBM Dot-Matrix printers, and do not have HP-LaserJet options. There are numerous suggestions, and many utilities to assist in this area; some free, but many are chargeable.

For extensive comments on this topic, you might visit one of the Clipper websites. Near the end, the issue of Mapping LPTn to a local USB printer is mentioned, but my experience is that the suggested solution does not work for Win98SE, and others have indicated that using NET USE is not rock-solid on later OSes. Note that the specific name of DOSPRINT has been used by a few writers! Also, I notice that a few products are not mentioned: DOSPRN, DOSPrinter, and DOSPrint (NT or later only, not Win9x).

We are currently trying to decide on a standard printing approach that covers all Windows platforms (98 to XP). Our conclusions to-date:

    • Apps which can re-direct Printouts to a file, and where licensing/utility costs may also be a factor:
           • For Printing to a local LPTn printer: just "Copy Report.txt LPTn"
           • For Printing to a local Win-Printer: (or, if desired, to a local USB-Printer): use DOSPRINT
           • For Printing to a local USB-Printer: use "Copy Report.txt \\CompName\PrtrName" or "Copy Report.txt LPT1:" - assuming LPT1: has been mapped to \\CompName\PrtrName. To achieve this result, the printer must be configured as "shared":
                   (a) "A" network interface MUST be configured for Windows Networking (even if it's only the MS Loopback Interface - perhaps as 192.168.1.1/24 - see procedure below)
                   (b) "share" the printer ('net share' will show the printer's shared-name, and the actual port)
                   (c) ensure that the printer properties do NOT show the printer's port (probably USB) as "pooled" with LPT1:
                   (d) use "Net Use" to see what mappings are active. If LPT1: is not mapped, then...
                   (e) use "Net Use LPT1: \\CompName\PrtrName" to map LPT1 to that Printer.
           • For Printing to a LAN Printer: use "Copy Report.txt \\CompName\PrtrName" (ie, use UNC rather than NET USE LPT...) To achieve this result, the printer must be configured as "shared":
                   (a) "A" network interface MUST be configured for Windows Networking (even if it's only the MS Loopback Interface - perhaps as 192.168.1.1/24 - see procedure below)
                   (b) "share" the printer ('net share' will show \\CompName\PrtrName)
                   (c) use "Net Use LPT1: \\CompName\PrtrName" to map LPT1 to that Printer.

    • Apps which insist or writing to only LPT1/2/3:
           • We've not investigated this area as thoroughly, because, fortunately, printouts from most of our apps can be re-directed to files.
           • You'll need a "spool" utility - which captures the LPT1/2/3 data, buffers it "somehow", and then sends it to the required printer.
           • Review the options mentioned at the Clipper websites. Ensure your selections will work with the OSes and Printers you're using!
           • Check out Davide Guolo's PrintFil. For support on PrintFil, look here.
           • Check the DOS2USB utility, PrintFile, Pz-Spooler, and DOSPrn, and extensive notes and discussions here and here.

Some folks use commands like "Shell Notepad.exe /p Filename" to print a file. I've also seen the following advice to enable printing from old DOS apps to "Windows" printers under XP. On the "Win" printer Properties/Ports:
    • Check the box(es) next to the relevant unused LPTn port(s).
    • Check the "Enable printer pooling" (not Spooling!!),
    • Apply or Ok.
When a (DOS) print task activates on one of the selected LPTn ports, Windows knows that the LPTn printer is unavailable, but, because it's "Pooled" with the "Win" printer, the job is sent to the Win-printer. This process does not translate internal printer commands - you may still need to use printers which can handle the commands sent by the app. Also, Epson printers which can handle Esc/P2 commands are slated to be less problematic than Esc/P printers.

"Net Use": Depending on the OS (eg, XP), etc, you may need to have Admin rights to use this command on LPT ports. On Netware, the "Capture" command provides similar features. Also, where NET USE is deployed, it may be necessary to change the Printer Properties from RAW to TEXT mode, to facilitate printing from the DOS apps. Use "Net Use /Delete" to remove a mapping.

MS Loopback LAN Interface:
This facility simulates a LAN environment, and can be created as follows (in XP):
    • Control Panel; double click Add Hardware; Next.
    • When the scan finishes, select "Yes, I have already connected the hardware"; Next.
    • Scroll to the bottom of the list, select "Add a new hardware device"; Next.
    • Select "Install the hardware that I manually select from a list (Advanced)"; Next.
    • Select "Network Adapters"; Next.
    • Select "Microsoft" under the Manufacturer list; then "Microsoft Loopback Adapter" in the Network Adapter list; Next; Next; Finish.

Then:
    • Configure the Loopback (Virtual) Adapter just like any other NIC; perhaps assign it a Static IP such as 192.168.1.1/24.
    • Share the printer, assigning, pehaps, a meaningful short (8-char-max!) name.
    • Capture the printer port, using NET USE LPT1: \\[Computer Name]\PrtrName /PERSISTENT:YES

[Top]
Home ] What's New ] Contact Us ] Referrals ] Feedback ] Products Summary ] DownLoads ] Orders ] Links ] Anti-Spyware ]