Old news, but it sets up my question at the end of this post: Developers petition Microsoft to reconsider FoxPro phase out
…and the response from Microsoft on April 3rd (copied from the above article):
“For Microsoft to continue to evolve the FoxPro base, we would need to look at creating a 64-bit development environment and that would involve an almost complete rewrite of the core product.”
Does anyone else feel as though the 64-bit issue is just an excuse? I’m not pretending to know what’s involved with creating a 64-bit development environment for VFP. And I’m not disputing that this is one reason for the decision. But I feel that this has much more to do with channeling more money into .NET and SQL Server then the hardships Microsoft faces by a 64-bit redesign.
Am I on an island here? Or am I the last one off the boat?
Update!
OK, I must be the last one on the island. From the ComputerWorld article, “FoxPro users petition to keep database language alive”:
“But FoxPro’s use of the open .dbf file format made it impossible for Microsoft to raise prices for the software. Even today, Visual FoxPro 9.0 lists for just $649. For no additional fee, developers can embed FoxPro in an unlimited number of their applications.”
FoxPro, though wildly popular, became a burden and an opportunity cost for Microsoft. “Every time Microsoft sold a copy of FoxPro, I think Bill Gates thought about all the money they were losing from not being able to sell a copy of SQL Server,” [Kevin] Cully [of Fox Forward] said.
![[Valid RSS]](http://blog.todmeansfox.com/wp-content/icons/valid-rss.png "Validate my RSS feed"){kind=icon}
![[Valid CSS]](http://jigsaw.w3.org/css-validator/images/vcss "Validate my CSS")
#1 by Victor Espina at April 11th, 2007
| Quote
“Every time Microsoft sold a copy of FoxPro, I think Bill Gates thought about all the money they were losing from not being able to sell a copy of SQL Server,”
So what? strip out DBF support but leave internal cursor technology (this means, the ability to create and manipulate memory cursors). This way we can use VFP as a frontend for SQL Server (or whatever) and Bill AND we would sleep better.
#2 by Tod McKenna at April 11th, 2007
| Quote
But that would kill a great portion of VFP’s appeal. I think one of VFP’s greatest assets — and one of the primary reasons MS bought it in the first place — is Rushmore with native DBF support. If we lost that, then I would certainly jump 100% into C# and not think twice about it.
#3 by Andrew MacNeill at April 23rd, 2007
| Quote
Tod,
I don’t think the 64-bit is an “excuse” as much as it is their reason for moving forward. Look, they dumped FrontPage to recreate Express. VB 6 into VB.Net. VB 6 is never going to be 64-bit either.
I think your points about FoxPro’s appeal are very valid - but if your reason for not jumping to C# is Rushmore with Native DBF support, then I think you’ve shown why they would never do it.
They want developers to embrace the LINQ model, SQL server DOES have rushmore technology now, so you’ve got an OLE DB provider to give you DBF support, LINQ to give you data access and now what is there to keep you in Visual FoxPro and not in C#?
My answer would be the overall architecture of the IDE. The entire “hack it yourself” approach, while yes, you can do it in Microsoft’s newer environments, they just don’t feel the same. I know that sounds fairly “vague” or “sentimental” but I think it’s a valid statement.
Vista (or its server successor Longhorn) is Microsoft’s last 64-bit OS - after that, they will be rebuilding (yet again).
If they could recreate FoxPro in a 64-bit IDE offering but with native DBF support (as well as SQL, etc), would that be the solution? Well, Microsoft wants their languages to be VB or C#. You want something else? Build it yourself. Someone mentioned something to me about a possible VFP-syntax like addition to the CLR. Then you work in the Visual Studio IDE (which Microsoft wants) but have your own language. (The FoxPro DotNet toolkit was one - not sure if there’s another initiative)
Would that answer the demands of VFP developers world-wide?
Sadly, I don’t think it would. Just my two cents.
#4 by Tod McKenna at April 24th, 2007
| Quote
Hi Andrew!
Thank you for your comments (it’s great to see your name)!
I don’t think that the VFP syntax is important. So creating a CLR ‘version’ seems a bit counterproductive and pointless (so I agree that it isn’t a solution).
The true worth of VFP from my POV has always been VFPs position as a RAD tool, its cost and licensing structure, its string handling capabilities, and of course its native database. These four things make VFP a very powerful tool to develop everything from full scale, multi-tiered apps to basic prototypes (and everything in between).
Don’t get me wrong, though. I like C# very much. I’ve also been programming in PHP for several years (and like that, too). I am currently working on a huge Data Warehousing project using SQL Server 2005 and various other tools. I just feel that the issue (from MS) isn’t about ‘moving on’, but more about the bottom line: VFP clearly cuts into the more lucrative .NET/SQL Server ambit. And in some ways, VFP is better!