|Response to Negative Reports on Visual FoxPro|
Some recent reports have surfaced calling into question Microsoft's continuing commitment to Visual FoxPro. We find this quite odd at a time when we've just released two new Fox products, Visual FoxPro 3.0 for Power Macintosh and Visual FoxPro 5.0 for Windows, and would like to respond to these reports and reassure our customers world-wide that Microsoft remains committed to Visual FoxPro.
In May of 1996, Microsoft released the "Open Letter to the Fox Community" in which key Microsoft executives stated our direction: continuing support for Fox products and developers. A number of enhancements were announced, and to date, Microsoft has delivered on everything that was stated in that letter. Readers are urged to consult this letter, if they haven't already done so, because nothing has changed since that publication.
Following are the key assertions that we find problematic, along with our responses:
Error: Too much focus on the term "Xbase"
Xbase is the language of Visual FoxPro; however, Microsoft does not view Visual FoxPro as an Xbase tool. We view it as a development tool whose language is an evolution of Xbase.
The Visual FoxPro language is far removed from the Xbase of the 1980's. It has full object orientation with inheritance, local, remote and off-line views, full SQL and built-in SQL pass-through, transaction processing, cursors with row and table buffering and ActiveX container and server support. The Visual FoxPro language is very robust and is full of modern features.
Error: The Fox return on investment is too low to make it a viable product
Microsoft believes that the return on investment calculation for Visual FoxPro is not just a dollars and cents issue. Visual FoxPro represents an investment in our customers and the installed base of applications, the value of which is not measured solely by current revenue or current contribution to profit. We are committed to the Fox community and to the customers using FoxPro applications to run their businesses.
An interesting data point is that for the Visual FoxPro developer conference, in Phoenix, we've registered over 1,500 people. This tells us that the interest in Visual FoxPro is massive, thus the opportunities justify our continued investment and interest.
Error: Too much focus on current sales, vs. installed base
While sales of products that use the Xbase language have decreased, the overall market for these tools remains viable and sustainable. Narrow-sighted estimates of current sales do not take into consideration the installed base of Fox customers and code, numbering in the hundreds of thousands. Many of these are running on earlier versions of FoxPro (as opposed to the current Visual FoxPro product line). We see these customers as having code and skills that will be well-served by upgrading to Visual FoxPro, so we intend to continue offering product for them to take advantage of as their budgets and plans allow them to upgrade.
Much of the FoxPro and Foxbase (version prior to FoxPro) code is MS-DOS based, and Visual FoxPro offers these customers a natural migration path to the Windows platform.
Error: Visual FoxPro is "inconsistent" with other Microsoft tools
This statement is untrue. Each new release of Visual FoxPro has been in the forefront of adopting Windows platform technologies, and consistency and integration with other Microsoft tools and applications has increased with each new release. For example:
With all these examples of shared technologies, consistent models and behaviors, and support for the Windows platform, it seems that terms like "separate model" and "inconsistent" are inappropriate when applied to Fox products.
Error: Fox does not fit in a multi-tool development shop
Some reports have claimed that Fox is less strategic because it does not integrate well with other tools. On the contrary, Visual FoxPro integrates very well with other tools and technologies. Visual FoxPro is both an ActiveX automation server and controller. It can drive and be driven by other Windows applications and tools that support automation, including Microsoft Office, Visual Basic, and Visual C++. Any tool that supports ODBC can use Visual FoxPro data, while Visual FoxPro can use data from any ODBC compliant source. Visual FoxPro can call DLLs that are created with Visual C++ and other tools. And Visual FoxPro provides full support for ActiveX controls, over 1000 are available from over 400 independent software vendors.
Error: Client server reduces the need for file server engines
This assertion is completely false. Both local storage and server storage capabilities are required to create modern client server and Internet-ready applications. Using a local data store can improve the performance of these applications, often dramatically. The Fox data engine is very fast. We have made it faster and continue to improve its performance. In addition, Microsoft Office, Visual Basic and Visual C++ applications can all use the Fox local engine, either via Jet, via ODBC or by calling a Visual FoxPro ActiveX server.
Visual FoxPro itself offers excellent performance with client server databases. Combined with its powerful local engine, Visual FoxPro is a very robust client-server development tool.
Error: FoxPro developers have legacy skills
It is just not true to say that Visual FoxPro programmers have legacy skills. Visual FoxPro has object oriented programming, client/server support, ActiveX automation controller and server support, an Internet wizard and ActiveX control support. In Visual FoxPro forms and classes are objects, with a full complement of properties, methods and events. In addition, FoxPro developers know data. These are not legacy skills and are fully transferable across the Microsoft Visual Tools line.
Questionable Conclusion: Contain future development
There are thousands of FoxPro applications running today, many of which are very large and very important. Some of these will be rewritten, however many will not and will continue to run in FoxPro and save their companies millions of dollars. Microsoft remains committed to providing the tools and support necessary for developers to continue maintaining and enhancing these applications for years to come.
We see absolutely no reason to contain development or seek alternative solutions to Visual FoxPro. It is unrealistic to suggest that existing FoxPro applications should be terminated. It is equally unrealistic to suggest they be rewritten. This would represent many millions of dollars wasted on fixing applications that aren't broken.
We do think customers should upgrade from FoxPro to Visual FoxPro, as there are many benefits to doing so. However, there is no reason to migrate applications written with Fox products to other languages.
For Additional Information
Please continue to visit our site. You can also send us feedback through Microsoft's "Write Us" option or send email to email@example.com.