|
| |
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):
- 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.
- 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.
- 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.
- The "Block Size" defaults to 2048. Leave this, or increase it as
needed. See separate notes below.
- 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]
- 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...
- A specially-modified DLL must be used to avoid the "4GB" blow-ups.
See here.
- 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!
- 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 ] |
|
