November 30, 1998
With the release of Visual FoxPro version 6.0 in September, Microsoft upgraded and improved its tool for building high-performance database applications. In this interview with MSDN Online's John Swenson, John Rivard, lead developer on the Visual FoxPro team, explains the many changes that make Visual FoxPro 6.0 easier to use, more powerful, and up-to-date. Learn how this new member of the Microsoft Visual Studio 6.0 tools suite improves developer productivity, maintains its reputation for speed, and supports front-end, middle-tier, and back-end development.
MSDN: What is your role on the Visual FoxPro development team, and how long have you been with the team?
RIVARD: I've been with the team since the release of Visual FoxPro 3.0 several years ago. I was a lead for several of our releases during that time. During the development of Visual FoxPro 6.0, I was dev lead for the whole team.
Today my responsibilities are split between managing the development cycle and coding features and fixing bugs.
MSDN: What did you do before you joined the Visual FoxPro team?
RIVARD: I worked on Windows for Workgroups 3.1, Windows 95, and the Windows Networking Team here at Microsoft.
MSDN: So you had some experience in operating-system development before you joined the Visual FoxPro team.
Let's discuss Visual FoxPro. The product seems to have an unusually loyal following among the developers who use it. Why is that?
RIVARD: The question I always ask customers when I go to developer conferences is, "Why do you use Visual FoxPro?" They tell me their No. 1 reason is the database engine in Visual FoxPro—specifically the speed of that engine.
Developers adopted that technology because it's very easy to use and fast. With it, they know their solutions are going to have good performance.
The old style of FoxPro programming centered on the xBASE database language. When Microsoft released Visual FoxPro 3.0, it brought object-oriented programming to FoxPro. Since then, developers have taken to this wholeheartedly. They love the OOP programming model. Most FoxPro developers are heavily entrenched in that.
With the OOP style in Visual FoxPro 6.0, developers can build very complex object models and classes that encapsulate all their functionality. Some developers I talk to tell me they don't really even use the FoxPro database language directly. They've wrapped it all up in nice little classes. That's one powerful feature of the FoxPro language they really love.
MSDN: Would you say FoxPro developers are loyal to the product?
RIVARD: Oh, yes. That's clear. They're loyal because they love the product. But there's also something outside of Microsoft that keeps developers loyal to Visual FoxPro. That's the FoxPro developer community, which is very tightknit.
FoxPro developers help one another a lot. They answer questions for each other. They tend to be big supporters of each other, because they know the more FoxPro developers who do well and understand the product, the better it is for their own business.
FoxPro developers are kind of an entity unto themselves in this way. They're different from other developer communities. Most have spent years with the product, and they're always championing new features they want us to put in the next version.
MSDN: Where does Visual FoxPro get its speed?
RIVARD: Performance becomes interesting when you start thinking about it as a feature, as something to be designed into a product. That's what happened in early versions of FoxPro, before I worked on the product. From the beginning, it was designed to be fast.
In the old xBASE market, the speed of a database engine was critical. Speed was the benchmark that xBASE competitors measured their products against. Because speed was such a big deal, a lot of effort always went into making FoxPro fast.
We're still working on that. Because Visual FoxPro uses a local database engine, it basically runs on local tables. Most of the processing happens right in memory on your PC's own CPU. This gives us the advantage of being able to code the product to perform as quickly as possible. Visual FoxPro is limited only by the speed of the machine it's running on.
FoxPro grew up in the days of slow, clunky machines running MS-DOS and Win16. It was optimized for these machines. As we get faster and faster machines, we inherit that old architecture. But that old architecture still works really well, since it lets Visual FoxPro do all of its processing locally, in memory. We try to buffer as much information as possible in memory, without hitting the hard drive. This gives Visual FoxPro its speed.
MSDN: What are the most significant new features in Visual FoxPro 6.0?
RIVARD: We focused on a lot of key areas in version 6.0. I divide them into two camps: interoperability and RAD [rapid application development]. By RAD, I mean features that help developers get things done quickly.
For interoperability, we improved our COM server support. Now you can create Fox automation components that run in MTS [Microsoft Transaction Server]. With Visual FoxPro 5.0, there were some technical problems with that.
A lot of developers using Visual FoxPro 6.0 and MTS are able to deploy solutions that run on Web servers or do back-end server processing. They can achieve a lot better performance and interoperability.
For better interoperability, we also added OLE drag and drop to the forms package in Visual FoxPro 6.0. This is one feature you would expect all Microsoft products to have, but FoxPro didn't grow up with it, so we had to plumb it in. We had a drag-and-drop model before that was not OLE drag and drop, which meant it didn't interoperate with Microsoft Office, Visual Basic forms, and other important things.
Now Visual FoxPro includes standard OLE drag and drop. Our customers really love this. It's a much easier model than our previous one.
MSDN: What did your team add to Visual FoxPro 6.0 to improve developer productivity?
RIVARD: We added a huge amount of sample code or library code and predefined a slew of base classes, which we call the FoxPro Foundation Classes. These ship in a subdirectory named FFC.
A couple of our key developers on the Visual FoxPro team came up with these classes to try and speed development. With Visual FoxPro 6.0, you can go grab these base classes and use them to add functionality to your application in a whole bunch of different areas.
This was one of the important features developers asked us for. They wanted to be able to crack open the Visual FoxPro 6.0 box and right away get a very high-level toolset to start building applications.
Developers also asked us for a wizard-like tool to help them get started building applications. So we created the new Application Wizard in Visual FoxPro 6.0. The wizard makes it easy to create a simple running application with a framework developers can build on.
Developers who are new to Visual FoxPro can use the Application Wizard to get started. Experienced FoxPro developers can use it to learn about new features. They can try plumbing them in with the wizard.
The other thing we did to improve developer productivity was add a new Component Gallery. Ken Levy, one of our star developers, wrote this. He's well-known in the FoxPro community.
The Component Gallery is like a space where developers can organize their work in Visual FoxPro 6.0 and have it interoperate with the rest of the Visual FoxPro IDE. In creating this gallery, Ken pressed the limits of what our object manager and OOP language can do. He would always come to me and say, "I need it to do this, I need it to do that." It was great for me, as a developer, to see the kinds of intricate and complex things he was trying to design into Visual FoxPro 6.0.
Our users will just see that there's a new Component Gallery in Visual FoxPro 6.0 that does all these great things. They won't see that under the hood, it's a very complex piece of code. The gallery really made Visual FoxPro 6.0 a lot better.
MSDN: Where does Visual FoxPro 6.0 fit into Microsoft's Windows DNA platform architecture for building three-tier applications?
RIVARD: Visual FoxPro 6.0 is designed primarily to build really good two-tier applications. We've offered really good client-server support since Visual FoxPro 3.0. Visual FoxPro applications can talk to ODBC data sources, for example. Our users like that because it makes all data appear just like native Visual FoxPro database information. They don't have to learn a new technology to import data from SQL Server or other sources.
That said, Visual FoxPro 6.0 can plug into the front end or middle layer of a three-tier application. In order to extend Visual FoxPro 6.0 into this n-tier space, we have our COM server technology. This lets developers write middle-tier business logic components that can access data on the server.
Once an application has called one of these middle-tier components, it can use all the power of the Visual FoxPro language—not the visual parts of the language, since the component is running on the server, but the Visual FoxPro engine and parts of the language, its OOP model. So, in the n-tier environment, Visual FoxPro can live on the middle tier and interoperate with other tiers.
The other side of the story is traditional FoxPro developers. Many of them only want to build one- or two-tier applications. They may choose to write their front ends as a rich client using Visual FoxPro 6.0, and tie that client into back-end services using technologies in Visual Studio or BackOffice.
MSDN: So developers can use Visual FoxPro 6.0 to build the front end or middle tier of their n-tier Windows DNA applications. Can they use Visual FoxPro 6.0 on the third tier, the back-end data store?
RIVARD: When it comes to scalability, Visual FoxPro is great as a local database engine. But we think many developers will prefer to use SQL Server on the back end, especially if they want enterprise-level features such as security, transactions, and other high-level features that are available in SQL Server but not Visual FoxPro.
Whether or not a developer uses Visual FoxPro, SQL Server, or another data store on the back end depends on their business needs. It depends on their business and scalability requirements. We don't try to compete against SQL Server in that area.
MSDN: How can Visual FoxPro developers take advantage of the Web? I haven't heard you mention the Web yet.
RIVARD: There are two different ways to go about building Web applications in Visual FoxPro 6.0. The main way is to use Visual FoxPro automation servers on the middle tier, to have Active Server Page (ASP) objects talking to FoxPro objects. This lets Visual FoxPro do all the work on the middle tier for accessing data, and in many cases even producing HTML. The FoxPro language is inherently good at manipulating and merging text. It lends itself really well to producing HTML on the fly like this.
Another method of building Web applications with Visual FoxPro 6.0 is to use ISAPI. Visual FoxPro has an ISAPI layer that allows developers to take a regular FoxPro form—complete with form controls, data binding, and everything else—and transform it into HTML. When users click on your Web page or Web application, the ISAPI layer transforms the presentation into HTML, even if you designed your FoxPro form as a middle-tier server.
MSDN: What did your development team do in Visual FoxPro 6.0 to help developers address the year 2000 issue?
RIVARD: This was a big deal for us. We determined that developers already could produce Year 2000-compliant applications in Visual FoxPro 5.0, but in Visual FoxPro 6.0 we tried to make it easier. In Visual FoxPro 5.0, there are ways developers can produce noncompliant applications and not realize they are doing it. Specifically, Visual FoxPro 5.0 allows developers to add date constants to their code that use two=digit years, since Visual FoxPro 5.0 has an algorithm that can interpret two-digit years.
The ambiguity of not knowing if a two-digit year is 1900-something or 2000-something can cause unexpected behavior. To eliminate this issue, we added a feature called StrictDate to Visual FoxPro 6.0. When you turn on StrictDate, the compiler will choke if you try to use two-digit years in your code. This new feature also allows FoxPro developers to take older code built with Visual FoxPro 5.0, Visual FoxPro 3.0, or even FoxPro 2.6, and recompile it with Visual FoxPro 6.0. The new compiler can then check it for two-digit years.
We also addressed another class of Year 2000 issues related to how software generates constants on the fly. In the past, if developers wanted to generate data on the fly, Visual FoxPro made them compose it in a date string, have that string parsed, and then produce the date. The problem with that method is that parsing strings can lead to errors if you haven't formatted the string right. So we added some features to Visual FoxPro 6.0 to generate dates based on numeric values.
Together, all of the new Year 2000 features in Visual FoxPro 6.0 should really help developers scrub their applications and prepare them for the Year 2000.
RIVARD: Visual FoxPro 6.0 improved our MTS support, adding a level of scalability that pleased many customers. But other customers really wanted us to push scalability even harder. We'll address that in the next release.
The next release of Visual FoxPro will focus on improving scalability in middle-tier servers. Our customers are adopting more and more middle-tier technology because of the Windows DNA architecture. They want to do more with Visual FoxPro on the middle tier. This may not sound like much, but technically it's a very big thing for us. It means we'll pour a lot of time and energy into restructuring the guts of Visual FoxPro. To build a good, scalable middle-tier component is not a trivial thing. Just talk to any developer who's trying to write in that middle-tier space. We want to make this easy for our customers.
The fact that Visual FoxPro 6.0 now works with MTS was a big jump for us, because our Visual FoxPro 5.0 servers did not. Our users expect Visual FoxPro to have a high level of compatibility with system services. It just takes us time to design it all and get everything working. In the next release, we're looking forward to having Visual FoxPro work very well in the middle-tier space.
The next release also will focus on traditional FoxPro developer who builds one- and two-tier applications. We'll add various features to improve their RAD experience, as well as add features to make Visual FoxPro integrate well with the next release of Visual Studio.
John Rivard manages the Visual FoxPro development team. He joined Microsoft in 1991 as a developer on the Windows for Workgroups 3.1 team, and later worked on Windows 95. Rivard moved to the Visual FoxPro team in 1994, and has worked as a developer there ever since. He was the lead developer on the team that designed and built Visual FoxPro 6.0. He holds a bachelor's degree in computer engineering from the University of Washington.
Comments? Send us e-mail.