Foxpro 2 6 For Dos free download - Microsoft Visual FoxPro 9.0 Service Pack 2.0, WebFerret, Apple iTunes (Classic), and many more programs. I have a MS-DOS Batch File that I need to run FoxPro 2.6 for Windows. The command is shown below: START /w foxprow.exe program.prg logfile.log It executes FOXPRO for WINDOWS Version 2.6 but it needs to open a new window for the foxprow.exe since it is a window application.

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%SYSTEM32COMMAND.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:vfprun9vfpr9.exe -t -cc:vfprun9config.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

FoxPro was a text-basedprocedurally orientedprogramming language and database management system (DBMS), and it was also an object-oriented programming language, originally published by Fox Software and later by Microsoft, for MS-DOS, Windows, Macintosh, and UNIX. The final published release of FoxPro was 2.6. Development continued under the Visual FoxPro label, which in turn was discontinued in 2007.

FoxPro was derived from FoxBase (Fox Software, Perrysburg, Ohio), which was in turn derived from dBase III (Ashton-Tate) and dBase II. dBase II was the first commercial version of a database program written by Wayne Ratliff, called Vulcan, running on CP/M, as does dBase II.^[1]

FoxPro was both a DBMS and a relational database management system (RDBMS), since it extensively supported multiple relationships between multiple DBF files (tables). However, it lacked transactional processing.

FoxPro was sold and supported by Microsoft after they acquired Fox Software in its entirety in 1992. At that time there was an active worldwide community of FoxPro users and programmers. FoxPro 2.6 for UNIX (FPU26) has even been successfully installed on Linux and FreeBSD using the Intel Binary Compatibility Standard (ibcs2) support library.

Version information[edit]

Operating system compatibility[edit]

Technical aspects[edit]

Microsoft Foxpro 6

FoxPro 2 included the 'Rushmore' optimizing engine, which used indices to accelerate data retrieval and updating. Rushmore technology examined every