not sure where vfp would fit. although, mysql doesn't support transactions or foreign key constraints and postgres sql doesn't support left joins. if someone wrote a vfp driver for apache and aol server, that would help ...

and i actually find the storing of stuff in dbf's a handicap to working in group projects--you can't diff files to see changes and you can't merge two developer's changes together, like you can if you have plain texst files ...


>Hey all,
>
>With the possibility for Microsoft to be split into an OS and applications company, the mind tends to wander when it comes to shakeouts for this new scenario. Being an optimist for the most part, I see the split as being potentially wondrous for the applications portion. No longer worrying about ties specifically to Windows, the applications unit can start developing more robust tools reaching a wider (i.e. cross-platform (i.e. Linux *smile*)) audience.
>
>As I was thinking about this, I realized that my beloved Foxpro may sit in the fabled cat-bird's seat when it comes to this intriguing possibility. Let's look at the facts:
>
>- Foxpro has a legacy of being a cross-platform tool (Mac and Unix), and even the latest versions of the tool still stick with some standards that while questionable in the Windows world, have let VFP remain viable as a cross-platformable tool (such as the non-standard, non-handled controls...Fox is used to drawing its own GUI).
>- Foxpro's methodology of holding all application files in a database format should make the port even more feasible. Once the database engine works on other platforms, the whole development area should work.
>- Linux (which is what I am getting at) runs mainly on Intel x86 architecture, so the C/C++ code (and some assembler no doubt) that makes up the core of VFP should not be all that difficult to port. We are not talking about converting non-standard code to obscure hardware. C and C++ are very standard tools (provided the Fox team did not get too carried away with Win32-specific libs) and the hardware architecture is the same from Windows to most of the Linux world. Plus, many of the VFP addons are already written in VFP...those would follow without a hitch.
>- VFPs runtime is only a few main DLLs...could these really be that difficult to port?
>- IMHO, Linux is in dire need of a standalone database tool. By this I mean that most data-centric apps in Linux right now range from file-based text/'grep' solutions to client/server tools like MySQL and PostgreSQL -- with not much in between. Don't get me wrong, MySQL is a great database (and very fast from the tests I have run), but a lot of applications just require a simple, self-contained database engine with an integrated language to create apps. Can the average user really be bothered to set-up and maintain the mysqld daemon just to run an app to hold recipes or catalog his/her CDs? *smile* Heck, VFP thrives in this mid-range arena in the Windows world even with competition from dBase, Paradox, Access, FileMaker...the list goes on. In Linux there are a lot fewer tools in this arena (I can't think of a single one off the top of my head). And if you want such a database tool in Linux right now with a GUI IDE to match something like VFP, forget about it -- there is nothing.
>A recent statistic in Linux Journal showed that over 50% of Linux developers still use command-line tools and debuggers... I have nothing against "old-school" coding, but VFP simply rocks when it comes to rapid, robust development.
>- Once VFP exists, Windows apps can be ported by simply copying program files to the Linux side and re-building. That's the beauty of VFP program files...PRGs are just pure test, and everything else is a database file. Once the engine is there, everything else should fall into place. There are hundreds (heck, thousands?) of Foxpro apps ranging from simple hacks to high-level business-support packages, and bringing them over would be good for the companies that make them (and good for Linux, getting the more apps/more OS acceptance ball rolling even more than it already is!)
>
>OK, I am sure I am missing something. It can't be this simple. So what are some other issues to consider? Here are few to start with:
>
>- Even though program files should be fairly portable, what about the porting of the VFP environment itself? It is probably quite a bit of hairy C code, including the interpreter, IDE, debugger, etc.
>- Even if the application side of MS becomes autonomous, would they want to break VFP out and port it to Linux without bringing all of Visual Studio over? Would porting all of the Studio prove to be too momentous a task? VFP is the only tool where the GUI elements are still handled abstractly enough to be easier to port. All the other tools seem more entrenched in Win32 as far as the GUI elements go.
>- Would there be enough interest? The VFP community is a relatively small one (although very robust and growing), and Linux has not gained wide acceptance yet. Put these two facts together, and recouping expenses for a port (even a relatively simple one) begins to sound more like fantasy than reality.
>- Is all of this just crazy? Even on its own, will the application side of MS remain a Win-centric house?
>
>This is all just food for thought, but it is food that tends to get me sort of pumped up. Having VFP on Linux would just be so incredible that I have a hard time putting it into words (though I have, and at length...sorry *grin*)
>
>So, what does everyone think?
>
>Joe Kaufman
>sutekh@dwx.com