Foxbase+/FoxPro Information Sheet
Foxbase+ was last released in August 1988. The last release of the FoxPro 2.x series
was in August 1994 (for a more complete history, click here).
While these products are still very usable, they were never written
for the latest computers and operating systems. This sheet attempts to point out some of
the problems that has risen in the last few years and possible solutions.
FYI: If this sheet doesn't answer your question, check my Frequently Asked
Questions papers, FoxPro 2.6 for Mac,
FoxPro 2.6 for Unix,
Visual FoxPro 6.0,
or Visual FoxPro 9.0.
You could check other web sites, such as Universal Thread
or Visual
FoxPro Wikis (for VFP Bugs, click here). You could post your problem
to the Microsoft
FoxPro forum or the google newsgroup microsoft.public.fox.programmer.exchange.
For FoxPro 2.6 problems, you could try the online book Painless Legacy FoxPro Applications on Modern Networks.
All information contained on this sheet is provided as is. There are no warranties, expressed or implied. The author and contributors may not be held liable for any damages, including any lost profits or other incidental or consequential damages arising out of or inability to use this information. Use of this information constitutes acceptance of this disclaimer. You should always double check any information before acting upon it.
This sheet contains references and/or links to other sites or to third party suppliers of goods and/or services. Such references or links should not be considered as an endorsement by the sponsors of this web site.
If a FoxPro application was compiled on drive D (be it EXE, APP, or FXP), when the
application is executed it will search for it's source code on drive D. Many computers
have their CD-ROM or Zip disk as a drive D. So if the CD-ROM is empty, FoxPro will report
'Cannot read drive D:'. If your CD-ROM is not connected, or don't have a drive D,
FoxPro may report 'I/O operation failure'.
Note: This problem is not unique to drive D. It can happen on any higher drive. Say the
project was compiled on drive F and the client site has a CD-ROM drive F.
There are a couple of solutions. One solution is to move your project to drive C. My
personal favorite is to add a 'SUBST K: D:\' to the AUTOEXEC.BAT file. Then store and
compile all your FoxPro applications on drive K. This is a simple solution, since not many
people will have a CD-ROM drive K.
If you can't recompile your applications, there is a fixdrive utility available on the Abri Technologies web page.
You can also read the Microsoft KB
article on I/O failure.
When FoxPro for Windows is launched, a timing loop is executed. On fast computers
(Pentium 333Mhz+ machines), the timing count can become huge, resulting in a 'divide by
zero' error. Thus preventing you from running FoxPro for Windows.
Microsoft used to offer a
free utility to patch
FoxPro 2.6a for Windows called PATCH_26.EXE (IPATCHFP.EXE for any version of FoxPro 2.x for
Windows). You may still find a copy by running a google search for "Fixes Divide by Zero Error on Fast Computers".
As I understand it, the C5 error has been around since Visual FoxPro was
created. I've never seen this error, but most of my procedures are still written in
FoxPro 2.x code. It can be caused by a variety of problems. Here's what I've learned thus far:
The problem is often times the result of a corrupted resource file,
otherwise known as a foxuser.dbf file. If your application doesn't need a resource file, then turn it off
in your config.fpw file: RESOURCE=OFF. If that doesn't fix the problem, try
removing or replacing the suspected foxuser.dbf and foxuser.fpt files.
Someone suggested the error has to do with docking a toolbar restoring and maximizing the
desktop. Again, the foxuser.dbf file might be corrupted and should be replaced.
The problem might be the result of a HP Printer driver. The standard Windows HP IV printer driver doesn't cause this
problem. If your client is using a HP 4300, don't use the 4300 printer
driver, use the HP IV driver to run the HP 4300 printer and set the
workstation's default printer to an HP printer using the HP IV driver.
The problem might be a third party print driver. You
might have to remove/reinstall each third party driver in your printer folder
until you find the bad one. A faulty print driver should be removed from your
workstation, even if the driver is not being
used by the default printer. Sometimes a faulty print driver has additional
software, which also needs to be removed (check add/remove programs). If you
suspect the server has a faulty print driver, don't use NDPS as it sends the driver to the
workstation during printing. Use the legacy queue based printing in Novell.
Fatal exception errors can be caused by third party video drivers. It is worth checking those things to make sure they are either Windows
standard drivers (first choice) or the latest vendor provided drivers available.
Some people get C5 errors running VFP with the video set to 256 colors and 1024 x 768
resolution. Try changing the video settings.
Another person reported a C5 error opening a form. I heard the problem
was resolved by reindexing every table used by the form. (open the table, then
"REINDEX").
If you still having C5 problems, see http://fox.wikis.com/wc.dll?Wiki~C0000005ExError
has more information.
People reported this random problem on Win2000 and WinNT machines. Turned out it was caused by a divide by zero condition in code and somehow the VFP error handler was not triggered - it passed back to the OS as an exception error.
People reported this problem when they move files between computers with different
types of FAT (File Allocation Table). For example, Windows 98 to/from Windows NT/2000.
As I understand it, this problem is the result of a corrupted dbf file. Try to REINDEX
and/or PACK your file. Might have to perform a COPY TO WITH CDX.
When using a shared a runtime unit, you might encounter a boot error such as 'file
access denied'. On networks I've seen this happen when the CONFIG.FPW has RESOURCE =
ON and the foxuser.dbf file doesn't exist. FoxPro tries to create a temporary foxuser.dbf
file, but cannot. Either the directory doesn't exist or the user has no read/write
privileges.
I've also seen this boot error on older networks. Sometimes sharing a runtime unit
requires all *.ESL, *.ESO, and *.EXE files to be marked as read-only. Really old versions
of DOS might require SHARE.EXE to be loaded.
Visual FoxPro (or FoxPro for Windows) was installed from the CD-ROM disc without installing the help files, and the CD-ROM disc is not in the drive. Just make sure you have a CD in the client's CD drive. See Error: Can't Read Drive D.
If you get "insufficient memory" errors from FoxPro for DOS, try launching it with the +X option. Otherwise, try increasing the following settings in your config.fp, config.fpm, config.fpw, or config.fpu
MVARSIZE: Set the maximum size of any given memory variable. I don't know the
default, but start with 50
(50K).
MVCOUNT: Sets the maximum number of memory variables that FoxPro can maintain. This value can range from 128 to 65,000, default is 256 in
FoxPro for DOS, 1024 in FoxPro for Windows.
MEMLIMIT: The syntax for this statement is MEMLIMIT=%,min,max where % is a calculated amount based on available memory and min and max represent actual minimum and maximum allocations.
For example, specifying MEMLIMIT=40,1024,4096 allocates 40 percent of your system's available memory to
FoxPro with a minimum allocation of 1024K and a maximum of 4096K.
The most common causes of this error is either bad indices or low resources (not emough
memory and/or hard drive space). If you open a dbf file and get this error, try to
remove/replace the index file. Otherwise, right-mouseclick mycomputer-> properties->
performance. If you see a low percentage number, you might have to reduce the number of
background applications. Either that or add more RAM to your computer.
You also get "Resource Manager - Internal Consistency Error" with FoxPro
2.6a
for Windows, transporting FoxPro for DOS reports. If you try to change font or font pitch
during transport, FPW 2.6a will crash. I heard this problem has to do with FPW 2.6a and
FONTMETRIC(). The solution is to change fonts only after transport.
FYI: I have been able to use courier 10 pitch during transport. Better than the default
arial 10 pitch. Select the tranporter fonts, then just press [ok].
When you try to open a DBF file, you may see the error message "invalid/missing
memo file". In the freeware section of
this web site is a utility called Data Wire Four. DW4 has the ability to repair a
corrupted memo file header. Other repair utilties are available from Abri Technologies.
Note: A corrupted memo file may appear normal, except when you try to PACK a couple of
times. If you suffer from a PACK problem, create a brand new DBF file and append your data
from the corrupted DBF file. DW4 does it this way.
There is index corruption, likely caused by those network disconnects. The operating system and/or network hardware is your primary suspect. For more information, see http://fox.wikis.com/wc.dll?Wiki~InvalidSeekOffsetError1103
When you try to open a FoxPro 2.6 DBF table/file, you may see the error message
"not a database table/file". The most common cause for this error is a bad record
count. In the freeware section of this web
site is a utility called Data Wire Four. DW4 has the ability to repair a bad record count.
Other repair utilities are available from Abri Technologies.
Using FoxPro 2.6 to open a Visual FoxPro DBF file will also cause this error. To avoid
this error, keep your DBF files in the FoxPro 2.x format (COPY TYPE FOX2X).
A Plockyn (a.plockynigg.co.uk) had a
mangled DBF and couldn't get DW4 to work. He used "simple code" which
just added a blank record:
* Before trying this code, make a backup of your tables!
wait window "If you get a 'Not a database file' click ignore" nowait
use MyTable
&& replace with dbf name
wait window "ESC to cancel or any key to continue adding blank record"
fh = FOPEN("MyTable.dbf", 2) && replace with dbf name
=FSEEK(fh, 0, 2)
&& go to EOF
=FWRITE(fh, SPACE(123)) && at least add
the count of one record length
=FCLOSE(fh)
&& corrected original with (fh) and FOPEN !!
wait window "If you can see the data then the fix was successful"
use MyTable exclusive &&
replace with dbf name
go bottom
BROWSE LAST nowait
reindex
The error "there is not enough memory to complete this operation" on a multiple application, multiple workstation system is probably the result of a blown index. Try rebuilding your index (you might have to delete your cdx file, then rebuild it).
You are trying to run FoxPro 2.6 for Unix with an outdated Linux-abi patch. For these and other related FPU installation problems, see the FoxPro 2.6 for Unix FAQ Sheet.
Try to run a FoxPro 2.6 FXP file with a Visual FoxPro runtime, and you get "Object file was compiled in a previous version of FoxPro". In my applications, there should be Visual FoxPro versions called V*.APP files. If not, you may have to install a FoxPro 2.6 runtime. An example of a runtime can be found in the freeware section of this web site.
The "Picture too big" type error has usually been related to compressed BMP images.
FoxPro for Windows does not handle large bitmaps (pixels) or bitmaps with more than 16 colors very well. Try to avoid them. If you wish to use a repetitive or tiling bitmap, use a 50x50 one.
The most common cause of this error is to open a file exclusively (USE tmp.dbf EXCLUSIVE or APPEND FROM tmp.dbf), with tmp.dbf already opened. Another cause is having tmp.dbf set to read-only. This error happens at the OS level, before FoxPro can trigger error handling. My only suggestion is to try a nFILE = FOPEN('tmp.dbf',2). If nFILE > 0, the file can be opened exclusively (after you FCLOSE(nFILE)).
You might see this error running FoxPro 2.6 for Windows on Novell 4.1 with Client32 version
2.2. I've been told this error is caused by other applications (Lotus Notes) hogging
memory. Even when closed, they do not release all of the memory. The only way free up the
memory is to restart the machine.
To reduce the occurrence of this error, teach the users to open FPW applications first.
Also advised them to leave the FPW applications open all day, rather than going in and out
of them.
One person actually solved this problem by uninstalling netware client 2.2 and
installing client 3.0.
Note: To be a good "sharing" application, you should limit how much memory your
FPW allocates by including a MEMLIMIT statement in the CONFIG.FPW file. For example,
specifying 'MEMLIMIT = 60, 4096, 10000' allocates 60 percent of your system's available
memory to FoxPro with a minimum allocation of 4096K and a maximum of 10000K.
Since the early days of dBase, most xBASE dialects have been able to retrieve and store
year 2000 dates. But to save space on crowded data entry screens, and to maintain customer
comfort levels, many applications prompt with eight-digit dates (mm/dd/yy), two-digit
years.
When you cannot enter the century, the language must use a default. The "bug" in
Foxbase+/FoxPro is that the century default will always be "19". Thus, typing a
date of "01/01/00" will translate to "01/01/1900". Always.
Oh, some people say there is also a problem the leap day February 29, 2000. But this
problem is the result of the century default. Typing "02/29/00" will translate
to "02/29/1900", which is not a valid leap day.
In my applications, I use SET CENTURY ON. Users will be prompted with ten-digit dates
(mm/dd/yyyy), four-digit years. The century default is still "19", and typing
"01/01/00" will still translate to "01/01/1900", but at least you can
type "01/01/2000" to input the correct date.
For people who need a century default of "20", there are other solutions. For
one, you can use the Visual FoxPro version of my applications. The Visual FoxPro
version
will look and feel like FoxPro for Windows. The Visual FoxPro code, however, includes the
command: SET CENTURY ROLLOVER 50. This command gives you century rollover. That is, typing
"01/01/20", will translate to "01/01/2020", while typing
"01/01/60" will translate to "01/01/1960".
Another solution is to purchase a product called Y2KFOX from Communication
Horizons. They have developed a front-end launcher for Foxbase+/FoxPro to enable
century rollover. It also handles the Feb. 29, 2000 leap day. Simple to install. You don't
need to change code. Very nice.
Here's yet another solution. Let's suppose you continued to use the old Foxbase version of
an application after January 1, 2000. Or suppose you forgot that typing "01/01/00"
in Foxbase+/FoxPro 2.x translates into "01/01/1900". Well, that's why I wrote Y1900.PRG.
Y1900.PRG is a simple Y2K program.
It will check all the DBF files in the current directory. Any date field, in the specified
date range, will be incremented 1200 months. 01/01/1900, for example, will be
incremented to 01/01/2000.
Note that Y1900.PRG won't touch dates stored in character fields (C(8)). Also remember to
backup your data files before using such a program.
FoxPro 2.6 for DOS should still work on most Window platforms. On my Windows 98 SE machine, however, FoxPro for DOS is not as stable. I can startup the MS-DOS prompt, run and exit the FoxPro executable, no problem. If I restart the executable more than a couple of times, however, I risk memory corruption. If you need to restart FoxPro, I suggest launching a new copy of the MS-DOS prompt.
Couple of people had problems with slow execution under Windows 2000. One person had mapped drives and fixed the slow-down by switching to the old DOS SUBST command.
According to the other person's hardware guy, the problem was the program ntvdm.exe. This program executes under Windows 2000 as a process and is in charge of the DOS applications. For some reason, it couldn't handle the load of 20 users. The hardware guy fixed the problem by installing a program called Tame.
Just a couple of suggestions. Check to see if your CONFIG.NT or CONFIG.SYS
has at least FILES=240. You might also want to add this command (or equivalent) to
your CONFIG.SYS:
SHELL=%SYSTEMROOT%\SYSTEM32\COMMAND.COM /E:2048
If FoxPro for DOS seems to be getting smaller you may have to adjust your Command Prompt. Under Start->All Programs->Accessories, right-click the Command Prompt, Send To->Desktop (create shortcut). Now right-click the Command Prompt icon, select properties. Under the Shortcut tab, run Maximized. Under the Options tab, run full screen. Under the Layout tab, set the screen buffer size to 80 width by 25 height. Oh, make sure you invoke FoxPro for DOS with the +X option. Otherwise, you might be short of memory.
As I understand it, FoxPro for DOS will use almost 100% of the available CPU time on a
NT 4.0 or Windows 2000 machine. There have been several reported ways to solve this
problem. If you have NT 4.0 SP4, upgrading to SP5 might solve the problem. Another way is
to type the following from the DOS prompt:
start /low foxprox.exe -cconfig.fp myapp.app
...the /low tells NT to give this application low priority when running in the background.
Another solution is to have the application SET CLOCK OFF. In my applications, you can use
the DOS environment variable SET STATUS = OFF to turn off the clock (see configuration
manual).
FoxPro 2.6 for DOS and FoxPro 2.6 for Windows are simple 16 bit applications.
They should work on most Window XP platforms. FoxPro 2.6 for Windows might have
problems sending raw output to the printer (See FPW:
Printing to XP). On my last Windows upgrade, I
didn't use the installation disks. Instead, I simply copied my c:\foxpro26 and
c:\foxprow folders
to my new Windows
Machine.
FYI: With FoxPro 2.6 for Windows, you might have to copy your foxfont
file
to
the windows system directory containing fonts.
Under any 64 bit OS, support has been dropped for 16 bit programs like Fox
2.6. There is no way to run it natively.
If you have FoxPro 2.6 for DOS, you might want to try DOSBox on Windows 7. It's a DOS emulator which
should work with older programs like FoxPro 2.6 for DOS.
If you have FoxPro 2.6 for Windows, try running it under the Windows XP or
Windows 98 mode. If your copy of Windows 7 doesn't have it, try Windows
Virtual PC XP Mode on Windows 7, which is available for free download from
Microsoft. It will give you Windows XP 32 bit mode in a virtual machine, free
key included.
On one project, I upgraded most of my software to be FoxPro 2.6a for Macintosh compatible. To help other people, I created a FoxPro 2.6a for Macintosh FAQ sheet. It should answer some of your installation and compatibility questions.
On one of my projects, I upgraded most of my software to be FoxPro 2.6 for Unix/Linux
compatible.
If you're installing FoxPro 2.6 for Unix on a non-SCO version of Unix, like Linux or
FreeBSD, you need to watch out for a couple of things. If you start up FoxPro and get a
'floating point exception' error message, might not have your iBCS component installed.
I've also seen this message using an incompatible terminfo file. If you start up
FoxPro and get 'Not enough memory to allocate name table', you have an outdated
linux-abi patch. If you start FoxPro and
get 'cannot find terminfo database', your system probably stores the terminfo database in
/usr/share/terminfo (FoxPro searches for /usr/lib/terminfo).
For these and other related FPU installation problems, see the FoxPro
2.6 for Unix FAQ Sheet..
When FoxPro for Windows is launched, a timing loop is executed. On fast computers
(Pentium 333Mhz+ machines), the timing count can become huge, resulting in a 'divide by
zero' error. Thus preventing you from running FoxPro for Windows. There are a couple of solutions. For
example, you can switch to Visual FoxPro. Visual FoxPro is an application designed for
fast Pentium machines.
Microsoft used to offer a
free utility to patch
FoxPro 2.6a for Windows called PATCH_26.EXE (IPATCHFP.EXE for any version of FoxPro 2.x for
Windows). You may still find a copy by running a google search for "Fixes Divide by Zero Error on Fast Computers".
List Boxes: In FoxPro for Windows, on fast Pentium machines, list boxes displaying database fields
and having more than about 600 records often run into the "Insufficient Memory"
error message. There are a couple of solutions. You can increase the MEMLIMIT command in your CONFIG.FPW file. For
example, specifying 'MEMLIMIT = 60, 4096, 10000' allocates 60 percent of your system's
available memory to FoxPro with a minimum allocation of 4096K and a maximum of 10000K.
Another solution is to slow things down by padding your list boxes. I don't use screen
sets much, so I can't give any more advice. I suggest you go to the Abri Technologies web page for
more help.
Moving from DOS to Window applications means working with fonts. If you wish
to keep your software DOS/Unix compatible, there are a couple of things you can
do.
Define your application's font via MODIFY WINDOW SCREEN FONT (Visual FoxPro uses
_Screen.Font). I would avoid proportional fonts, such as
Arial. Instead, use "Courier
New" or other non-proportional font such as foxfont.
If you don't have foxfont, copy the file foxfont to the windows system directory, where fonts are stored.
Oh, had a situation where a client could not read a Word 97 document unless FoxPro
for
Windows was running. Come to find out, the document had FoxPro for Window reports in it.
These reports use the font foxprint, which is normally installed from your FPW
distribution disks. Copy either the file
foxprint.ttf or the file foxprint.fot
to the windows system directory, where fonts are stored.
I heard of this problem on the newsgroup microsoft.public.fox.programmer.exchange.
Someone tried to install FoxPro for Windows on a Windows XP machine and got an
error message: "An error has occurred in your application / If you choose
Ignore you should save your work in a new file / If you choose close, your
application will terminate.". The error window within the FoxPro install
window is titled "DSHELL".
As I understand it, the problem is caused by a menu option in the Start Menu
folder with a name greater than 49 characters in length (FoxPro 2.6 has made
before long file names came out). If you want to install FoxPro for Windows, you
must decrease the length of the name.
A patched FoxPro 2.6a for Windows should be pretty stable, but can be a memory hog at
high resolution. If you're video resolution, for example, is at 800x600x16million colors,
lower it 800x600x256color. See if that helps.
If you are unable to run FoxPro for windows, due to insufficient memory, add a MEMLIMIT
statement to your CONFIG.FPW file. The syntax for this statement is MEMLIMIT=%,min,max
where % is a calculated amount based on available memory and min and max represent
actualminimum and maximum allocations. For example, specifying MEMLIMIT=40,1024,4096
allocates 40 percent of your system's available memory to FoxPro with a minimum allocation
of 1024K and a maximum of 4096K.
FYI: SYS(2019) tells you exactly where your CONFIG.FPW is located. And remember that
changes to the CONFIG.FPW don't go into effect into the next time you launch FoxPro.
If you still have problems, I suggest posting your problem to the Microsoft
FoxPro forum.
Many people report problems with FoxPro 2.6 for Windows, printing to Windows
XP. On my machine, I get a "General Protection Fault". Other people
will experience "Unsupported Protocol".
In my case, my application was sending raw out directly to the printer (using
???). One solution is not to send raw output to the
printer. If you have a more recent HP print driver, try switching to an
older (more seasoned) driver.
Andrew Howell of microsoft.public.fox.programmer.exchange help me create an actual workaround to this bug. For code and details, click here.
If you crash using a FRX report, but you might want to remove the printer definition (see next section).
A lot of people have problems with report FRX files. Mostly because FoxPro for
Windows/Visual FoxPro FRX files store their own printer information. After you complete a
MODIFY REPORT, the current printer is stored in the FRX file. When you print a report, the
FRX file will send output to the stored printer. If that printer doesn't exist, however,
results might be unpredictable. Could even cause a computer crash.
There is a couple of ways to handle this situation. You could remove the printer
definition stored in the FRX report (open the FRX file as a table and look at
the EXPR, TAG and TAG2 fields in the first record). To remove this printer definition,
go to the Microsoft KB article "How
To Use the Default Windows Printer in Visual FoxPro".
You could also that prompt the user for a
printer. The selected printer can then be installed on a temporary copy of the report
FRX file, which is used to print the report. To see how this works in code, see
report forms in my Visual
FoxPro 6.0 FAQ sheet.
One other suggestion. If you're crashing on your REPORT FORM command, add a
FLUSH command before it. Less chance of losing data that way.
When transporting FoxPro for DOS reports into FoxPro for Windows, you might run into a
couple of problems. If you try to change font or font pitch during transport, FPW 2.6a
will crash (See Error: Internal Consistency Error). The solution is to
change fonts only after transport.
The other issue is about text that will no longer print. All you get is solid black type,
either in print or MODIFY REPORT. The solution is to do a [Ctrl]-[A], select all. Then
object->mode and change the mode from opague to transparent.
Suppose you have a FoxPro application on a network file server. Your network has fifty
workstations. With FoxPro for DOS or FoxPro for Windows, it is possible to include the
runtime files with the application. With Visual FoxPro, however, you most likely need to
reinstall the application from each and every workstation.
One solution is to create your own Visual FoxPro runtime. A "runtime"
is actually a stand alone application. Created from foxrw.prg,
this application's only
purpose is to launch other FoxPro applications. Download foxrw.prg
and compile it as a
stand-alone executable in it's own directory. Then use the VFP setup wizard to create your
own runtime installation/distribution disk(s).
Note: Visual Foxpro 9 does not have a setup wizard. You will need to run
InstallShield Express or another installation package. See Microsoft
knowledgebase.
With a distribution disk, you can install a runtime on each workstation. After each install, create a Windows shortcut icon
to the runtime and modify it's properties, as in the following example:
Command Line : c:\vfprun9\vfpr9.exe -t -cc:\vfprun9\config.fpw vmal9
Working Directory: c:\dmail4\
...where "c:\vfprun9" is the runtime directory, "vfpr9.exe" is the
compiled Visual
Foxpro 9.0 version of foxrw.prg, "config.fpw" resides in the user resource
directory "c:\vfprun9\", "vmal9" is the startup application module
"vmal9.app", and "c:\dmail4\" is the application (working) directory.
Note: You can apply this same technique to create FoxPro 2.6 and Visual FoxPro
6.0 runtimes. An example of a runtime can
be found in the freeware section of this web
site.
I've upgraded all my FoxPro 2.6 software to be Visual FoxPro 6.0 and Visual FoxPro 9.0 compatible. Upgraded, not converted. My software still runs on FoxPro 2.6 as well as Visual FoxPro 6.0 and 9.0. To help other people to upgrade, I created Visual FoxPro 6.0 FAQ sheet and Visual FoxPro 9.0 FAQ sheet. It should answer some of your compatibility questions.
People always ask me where to purchase a copy of FoxPro. You might try either
ebay.com or amazon.com.
Keep checking the ebay stores. Copies float on and off that site all the time. Also try one of the
following:
EMS Professional Software
Retro Tools CC Systems, a Florida consulting firm: (727) 596-1460. FoxPro for Unix.
In the event you can't find a development copy for your operating system, don't despair. A
FoxPro 2.6 for DOS/Windows compiled FXP or APP file will work just fine in FoxPro
2.6 for
DOS, FoxPro 2.6 for Windows, FoxPro 2.6 for Macintosh, or FoxPro 2.6 for Unix.
All you need is a runtime. An example of a runtime can
be found in the freeware section of this web
site.
I hope you have found this information sheet useful. If you have a tip to add, drop me an email (
[Return to Top]
[Go to Home Page]
Copyright © 2013 Dennis Allen.
This web page was last updated 02/09/18