Slashdot Log In
Microsoft to Open Source FoxPro
Posted by
ScuttleMonkey
on Wed Mar 21, 2007 12:27 PM
from the better-than-the-circular-file dept.
from the better-than-the-circular-file dept.
rah1420 writes "Microsoft has announced that it will open-source the core portions of the Visual FoxPro DBMS software to its CodePlex community development site. At the same time, Microsoft has announced that it will no longer be making new versions of the FoxPro DBMS."
Related Stories
[+]
Your Rights Online: FoxPro On Linux, Drama Ensues 409 comments
bltfast32 writes "I don't know how many people have been following this, but this is definitely worth keeping an eye on. Whil Hentzen, prominent FoxPro and Linux advocate, has received some heat lately for publishing a HOWTO in the March 2003 FoxTalk issue for running Visual FoxPro 8.0 on Linux with WINE. Of course, the aforementioned heat, is coming from Redmond. Here is a link to a nice summary of the interactions by Whil." That summary mentions the Register article online here. bltfast32 also points to another article which requires registration.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Umm, no. (Score:5, Informative)
NOTE that the released part is Sedna and NOT VFP nor VFP core elements!
Sedna is a project Microsoft has been working on for the past year or so. Sedna is built using the extensibility model of VFP9 and provides features like better connectivity to SQL Server, integration with parts of the
Re:Umm, yes (Score:2, Informative)
Instead of releasing new versions of FoxPro, Microsoft will release core portions of the FoxPro software to its CodePlex community development site, said Alan Griver, a group manager within the Microsoft Visual Studio team, which leads the FoxPro team.
and then, later:
Meanwhile, Microsoft has been working on "Sedna," which is the code name for the project that takes advantage of enhancements in Visual FoxPro 9.0. The primary goal of Sedna is to expand on the ability of Visual FoxPro-based solutions to better integrate with other Microsoft products and technologies, such as Visual Studio 2005, SQL Server 2005 and Windows Vista.
No, it really looks like Microsoft is open-sourcing VFP, or at least its core components.
Re:Umm, still no (Score:5, Informative)
That seems pretty definitive to me.
For clarification: Sedna (the stuff that's going into CodePlex) is not now (nor was it ever intended to be) the next version of Visual Foxpro. It's just a set of VFP-based tools intended to help current VFP developers to make better use of new features in Vista/SQL Server/etc...
Meanwhile, VFP 9 is getting a final service pack and then that's it as far as Microsoft is concerned. There's certainly no plans to open-source the IDE or the VFP engine because, frankly, Microsoft would never do that. Some of the technology (and people) from VFP is going towards the LINQ project, but
Parent
Re: (Score:3, Informative)
Rushmore technology anyone? (Score:5, Interesting)
I'm curious because I really want to know what made FoxPro the speed demon it's always purported to be. I read somewhere that it was the first dbase-class database program that used bitmap indexes, but that was contradicted by another article from somewhere else.
Reason for speed (Score:2)
I was told that one reason that FP was so much faster than access was that the data was separate from the application - as opposed to Access lumping it in one ever growing file.
That wouldn't explain how it was faster than dBase though...
Re:Rushmore technology anyone? (Score:5, Interesting)
It's not. It may be quick for the common case of a small table (10K lines) on a local drive, but move outside that and it's horrid. FP supports multi-user access by putting the data files on a network drive. If you want to query it, your machine has to read to entire file, throw out the lines it doesn't want, and present the results. My company has about 40 people using the same legacy FP database from a RAID 1+0 system over gigabit ethernet, and it's still hundreds of times slower than running similar queries via SQL to any "real" database.
Let me put it this way: I wrote a program to export our FP tables to tab-delimited text files and then import those into PostgreSQL. This takes about 25 minutes, and we run it hourly - and it's still worth the pain. Reports altered to query PostgreSQL instead of FP typically see speedups of several hundred times, multiple users can run the same reports simultaneously, and you can actually run the reports over a slow link since only the query and resultsets have to traverse the network instead of the whole table.
I know this will come across as flamebait, and I'd normally not say this, but anyone who claims that FoxPro is fast is a hobbyist programmer. It's simply not fast by any imaginable standard other than the trivial case of small files on a single user's drive.
Parent
Re:Rushmore technology anyone? (Score:5, Insightful)
I did the programming on a system which resided on a Netware v4.11 server back around 1993 and it had one table with somewhere around 3 million records. Queries were lightning fast if you didn't match too many rows and the query was optimized to work with your indexes. Queries which couldn't utilize indexes, however, were painfully slow.
Having said all that, however, I can't think of any legitimate reason to use DBASE style databases these days. With free DB servers like MySQL and PostgreSQL why bother?
Parent
Re:Rushmore technology anyone? (Score:5, Insightful)
But even indexed queries pale when compared to a "real" database. Since FP is file based - that is, each client has to read the files directly - even the index files have to be transmitted over the network to do those lightning fast queries. At some point you saturate your NIC, and after that all the processing power, RAM, or fast drives in the world won't make it a millisecond faster.
Compare and contrast with any client/server system, where all those queries are consolidated into one cache shared among all clients, and only the actual requested rows have to be returned. By its inherent architecture, FP simply cannot ever hope to be as fast.
Parent
Re: (Score:2)
I'm (fortunately) not directly responsible for supporting it, but I knew the people who are and I trust that they've tried everything. Maybe it's just a different usage pattern that's.
I was brought in a few years ago to rewrite the quickly-written ASP website with something more extensible and maintainable. For
Re: (Score:3, Interesting)
More than speed though, I enjoyed the data-centric programming language. It was a joy to use and a bunch of functionality coul
If only all orphaned software would go this route (Score:4, Insightful)
Except for games, which have a commercial nostalgia market, most software over 10-15 years old wouldn't be commercially viable even if it did run on the latest operating systems.
I for one would love to fire up Windows 3.1 with a 15 year old copy of Microsoft Word and print to my Postscript printer, just to see how fast it is on my modern PC.
Re:If only all orphaned software would go this rou (Score:4, Insightful)
Being at the software vendor's mercy for an application's longevity sucks hard, and it's one of the reasons I've been embracing Free and open software so passionately. As long as anyone still cares, the program will live on. Good software shouldn't die. That said, anything related to FoxPro can and should be erased from existance as soon as possible as far as I'm concerned, but surely somebody's happy about this, so good for them.
Parent
Re: (Score:2)
Try DOSIDLE: http://www.vmware.com/software/dosidle210.zip [vmware.com]
License (Score:2, Insightful)
Probably the MOSL (Score:3, Funny)
Shared Source (Score:5, Informative)
The relevant part of the actual announcement on Microsoft's site [microsoft.com] reads "To reiterate, today we are announcing that we are not planning on releasing a VFP 10 and will be releasing the completed Sedna work on CodePlex at no charge. The components written as part of Sedna will be placed in the community for further enhancement as part of our shared source initiative. You can expect to see the Sedna code on CodePlex sometime before the end of summer 2007."
Shared Source [microsoft.com] is not Open Source.
Parent
one word... (Score:2)
Status of "intellectual property" (Score:3, Interesting)
burnin
Crazy (Score:3, Funny)
Take Note! (Score:3, Interesting)
Re: (Score:2)
What about Bob? (Score:2, Funny)
A Brilliant Move? (Score:2)
So, we have here a product that Micro$oft already had other versions of, and wishes to no longer spend money on. Sooooo, is this yet another way of keeping the world on Micro$oft software? By making the source available, y
Irrelevant (Score:3, Interesting)
Please don't be to harsh when you mod me for this speculation: What if Microsoft open sources this product with a different goal in mind? For instance, maybe M$ is curious to see what new ideas become of their abandonware? Perhaps, the community might give it a new lease on life and re-develop a market for it? Should that happen M$ could close the source again, if the license is not GPL, LGPL, or BSD. Just my thoughts anyway
Re:Open source is not a verb (Score:5, Funny)
Parent
Re:Open source is not a verb (Score:5, Funny)
Excuse me, I have to go full my belly.
Parent
Re:Open source is not a verb (Score:4, Funny)
Parent
Re: (Score:2)
Re: (Score:2, Offtopic)
I'm normally a stickler for grammar but verbing [wikipedia.org] is a pretty widely accepted practice in colloquial English.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
ESE might be based on Jet or it might be a superset of it or whatever, but I don't think they're the same thing.
Re: (Score:2)
I can't claim to really know much about either Access or Exchange, but I do seem to recall that Exchange (2000 anyway) did have some kind of transaction logging to allow atomic commits and backups whilst the system live. And I might be being mean to Access, but I thought did basically nothing in this respect!
Re: (Score:3, Informative)
Apparently ESE stands for Extensible Storage Engine as well...so I'm gonna have to say Exchange doesn't use JET.
Re: (Score:3, Informative)
http://en.wikipedia.org/wiki/Extensible_Storage_En gine [wikipedia.org]
So it's apparently a flavor of JET...but different.
I could "see" them opening JET Red (Access) in about 10 years, because there are no plans to make it 64 bit, but not JET Blue (ESE/Exchange). That'd open up Exchange and MS wouldn't want to do that.
Re: (Score:2, Interesting)
That said, it feels very dated working in VFP. Especially with things like arrays, which are horribly crippled compared to the equivalent in perl or python. VFP's OO-ness isn't all it could be, either. I'd hop
Re: (Score:2)
It was rather a fun and useful software and a whole lot nicer to work with than say MS Access at the time if you were developing your own database software.
I even got to attend a developers conference with them (I did training for them and support) and there were plenty of people that did Fox Pro.
However, they did have a contingency plan to switch all their products to MS SQL based solutions which I don't know how that went since I left the company.
It h
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
FoxPro for DOS 2.6
But it's not my choice! Stupid application still works like a charm. Whoever wrote it back in '92 did a pretty decent job overall. New enhancements are written by me grudgingly. A re-write is in the pipes, so I'll be looking forward to turning it into a web app and be done with it.
(XBase was cool!) Re:what's next? (Score:4, Insightful)
Although they never got their GUI conventions right, the XBase language was outstanding for ad-hoc and small-scale data chomping. You can tell it was invented by people who had to deal with data and tables all day long.
Unlike MS-Access, there was an easy path to ad-hoc manipulations and script writing. In MS-Access the language world and mouse world are too distinct. Xbase allows a more incrimental, integrated approach.
And unlike SQL, it easily allows one to do cursor-oriented manipulation and see intermediate results. Sometimes cursoring around is easier than bulk, declaritive queries that SQL gives you. Newer dialects of XBase incorporated SQL to allow one to use whichever is best for a task. (However, index dictionaries were never standardized across dialects.)
I used to do all kinds of table-oriented stuff in XBase, like store programming code or expressions in the tables. Think of it as Design Patterns where you can easily query, search, and print the patterns rather than dig thru linear code. It was also easy to generate tables programatically. Meta-programming was a snap. Data dictionaries could drive a lot of the app, even the GUI.
The newer stuff tends to put bulky API's between you and the data, which slows one down. There is no such fense in Xbase (usually a good thing for productivity, but it does have its downsides if you are not careful and not used to it.)
Ah, the good ol' days. -Tablizer-
Parent
Re:glad to see foxpro dead (Score:5, Funny)
And then when someone does redistribute it like other source code (without reading the M$ license), they'll sit quietly for about 3 or 4 years, while this person's redistributed code becomes ever more popular. Eventually, it will become incorporated in digital cameras worldwide, database software that drives the next Google, and your next-generation toaster.
Approximately 1 year after that happens, and $1 billion have been made off the redistributed code, Microsoft will sue for not following the license. They will cite the fact that "I like porcupines" is not in the code and that a link to the Microsoft homepage is not included. They will complain that the lack of a link to Microsoft will have decreased Vista sales by $3 billion (because, naturally, the price of their OS is probably 3 times that of the code in question). They will demand the profits, win the case, and said company will have the option of either paying the legal fees, or being bought out by Microsoft.
On another note, "open source" of itself does not always mean "free to redistribute", it just means you get to view the source.
Parent
Re: (Score:3, Informative)
Yes, I used FoxPro back in the early nineties. It was a great product under Fox, but when Microsoft purchased it, they supported it only for a while, then let it languish while they pushed Access (an UTTER POS with all the "reliability" and brain-dead design decisions Microsoft is known for).
I was at a computer show in San Francisco standing at the FoxPro booth actually when I heard that Microsoft had bought them.
But I don't think the "Jet" engine came from Foxpro. I might be wrong about that. I think the A
Re: (Score:3, Informative)
Didn't MS just buy FoxPro, to steal the 'jet' engine from it to stick into access?
A few years ago, I ran into a couple of FoxPro-based applications and I learned a little about the history of the product.
FoxPro was rather popular with application writers and there are still a lot of small business applications based on it. Apart from the technical merits, it had one big advantage over MS Access: you could bundle FoxPro with your application for free, while Access required an Office license for each PC.
Microsoft bought the company mainly to destroy a competitor. They ended up suppor
Your Comment is Incoherent (Score:3, Insightful)
It's only fast at running code in it's own language? You don't say! I'd be pretty impressed at any language that could run code written in another language.
Perhaps what you meant to say was that Foxpro is only fast when dealing with data. In that case you are correct. I wouldn't write a protein-folding program in Foxpro, be
Re: (Score:2)
I do say. It's not a fast database. It's not a particularly nice programming environment. It has little support for any kind of ACID goodness, and then only in the very newest release (which isn't completely backward compatible with its predecessors). No, it's true that the only thing FoxPro is particularly good at is running FoxPro code. Unless you have legacy FP applications to support, it has absolutely nothing to offer.
Your Comment is Still Incoherent (Score:2)
The mistake you're making is that you look at VFP and you see a DBMS package that's forcing you to program in Foxpro. You have it backwards. VFP's DBMS system is an extra bonus (especially if you're at a company that doesn't have the resources or the need for a SQL Server/PostgreSQL database).
Yes, all the BDMS systems
Re: (Score:2)
It was a literary device aimed at native English speakers, and I apologize for any confusion it might have caused.
The key distinction is that Python isn't a crappy database - it doesn't pretend to be one at all - and PostgreSQL isn't a crappy programming language - it doesn't even try. Combining an aw