Converting from VFP to Access?! (Site)

These guys were advertising on Amazon. It's the first time I've ever heard of anyone doing such a thing. I wrote to them, and here's what they said:

We use the linked-tables and ODBC features in MS Access, and we have yet to come across a version of FoxPro to which we couldn't connect. So, all versions of FoxPro.

We can convert to MS Access 2.0, '97, 2000, 2002/XP, 2003 and 2007.

Insight into VFP Studio (Posting: Matt Slay)

Link:

I think I know what this is going to be... Listen to the recent Ken Levy podcast on DotNETRocks.com show # 303. I bet Craig is using the Visual Studio IDE shell and the Visual Studio Extensibility (VSX) kit to somehow work with VFP code/forms/reports/ etc. The title of the show is "Ken Levy on Visual Studio Extensibility (VSX)" It's a great show, and really gets your mind to thinking about how cool it is that the Visual Studio 2008 IDE shell can be extended to many uses. They even mention Craig Boyd and Foxpro near the end of the show. DotNetRocks is usually hard (and clueless) on FoxPro, but it pops in there every now and then.

VFP Studio (Links)

The mysterious home page

and

what's sure to be a dead link once things are revamped: a mysterious login screen

VFP Studio Details (Posting: Craig Boyd)

Someone reposted a post by Craig Boyd:

"Using Microsoft's DLR it is absolutely possible to integrate .NET with VFP. Right now we are concentrating on getting it to work with native VFP code, however we are planning on implementing .NET into this as well so that the language/development tool ends up being very similar to VC++ where managed and unmanaged code can co-exist. So, those looking to do just pure VFP will end up with a greatly enhanced IDE and some additional language features that we are adding and will be able to compile to standard VFP executables/dlls/apps. And, those wishing to use VFP and .NET together will be able to do so as well. The latter will greatly extend the usefulness and future of VFP/VFP Studio and the applications created with it by allowing VFP devs to generate .NET assemblies. The overall goal is to marry the best of both worlds and allow VFP devs to access their beloved VFP runtimes providing applications with unrivaled data performance and access .NET to take advantage of all that is available there as Microsoft moves forward with the CLR and DLR.

We'll be revealing more as we move forward with this."

VFP Studio Code Editor (Blog: Craig Boyd)

From the posting:

Some of the mystery surrounding VFP Studio has been on purpose and some of it has been because we (Bo Durban and I) are not yet sure what all is possible working within the framework provided by Microsoft via the Visual Studio Isolated Shell.

---

VFP Studio's Code Editor, which is made possible via a Language Service Bo Durban and I created in Visual Studio 2008, provides some significant enhancements when compared to the editor included in VFP 9.0 including outlining, Quick Info, Intellisense for user-defined classes, line numbers, word wrap, VS-style navigation bar, improved Code Snippets and various other features we are implementing in to VFP Studio.

On VFP Studio (Blog: Alan Stevens)

Link

Our project is called VFP Studio. We are using the Visual Studio 2008 Isolated Shell to build an IDE for building Visual FoxPro projects inside Visual Studio. We have plans to include reg-free COM for enabling click-once deployment of Visual FoxPro applications. We are working on a VFP project type, so that we can add a new or existing VFP project to a Visual Studio solution. We keep coming up with exciting possibilities for this project, and we will be announcing more soon.

Windows 7 & VFP (Thread: MSsForum)

Users discuss compatibility:

As Win7 is being built on top of the Vista kernel and code base, my guess is
yes.

---

If there is going to be some support of the product until 2014 then I would
imagine that any MS OS that comes out prior to that should run VFP.

---

VFP on Linux (Thread: MSsForum)

Link

Finally, someone speaks out strongly against the MSBS regarding licensing:

Some of those links are dead. The ones that live don't really settle the
matter, nor is this matter every likely to be setteled until someone
actually goes head to head with Microsoft (which is very unlikely to
happen). For fear of beating a dead dog - Ken Levy's "opinion" that the VFP
runtime files that a VFP app requires to run is considered a redistributable
file is not supported by the wording of the eula or the contents of
redist.txt. I've been saying this for a few years now, and the comments you
can find on the referenced website below say pretty much the same thing.
This is why we, and many others, have had this conversation over and over
again :-)

Debate over VFP's future (Thread: MSsForum)

Thread where a user asks about Foxpro's future.

Highlights:

Is there a future for VFP? In your larger shops and mainstream IT in
general, VFP is dead. Those still using it are migrating away from it as
fast as they can. Few if any IT managers are going to risk their career by
starting new development using VFP. VFP apps will be around for many years
to come, but they will continue to dwindle in numbers as they have been for
the last few years.

In the Mom and Pop shops, you will still see some VFP apps for a few years
to come, but even they are going to move away from it.

It's dead and just waiting for someone to come along and bury it :-)

---

The community is making VFP better. See the VFP projects on Codeplex etc.
The community always made vfp better anyway, not so much the microsofties.
PHP has not done so bad without a corporate sponsor and VFP is way better
than it...

---

The biggest problem VFP has
ever had is Microsoft. Get rid of them, and VFP could prosper. And it would
be cross-platform again. Think about it - VFP on Linux would become very
popular very fast.

---

But, as has been repeated often before, it is not an option to say 'get rid
of M$'. This implies that 'we' have any power over it. The product belongs
to them, and they decide what happens to it. They are not going to release
vfp in a million years because of the code within it they want to retain
control of.

---

IT managers that decide on technology because of the impact on their
career have switched in the 90ties. IT managers today are either younger
folks that replace VFP centric managers. Those usually switch to whatever
technology they learned during university/college. Older IT managers that
are still supporting VFP applications decide, in my experience, on technical
terms rather than career terms. Frequently this means to keep maintaining
existing projects in VFP and start new ones in .NET or Java.

If there's budget for a rewrite, it depends on several factors what they
choose. .NET/Java is typically choosen if the budget is sufficient for a
rewrite and managers expect to keep working for a longer period. Often it's
not a single project that is the reason not to go with VFP, rather the
possibility of having training being paid by this project. If the budget
isn't huge, the application is data bound and very inexpensive ($50-$500 a
year), the time to retirement isn't that long (10-15 years) or development
resources are expensive, managers tend to stay in FoxPro (VFP and FPD). That
seems to be the case the farther you go away from the US. My impression is
that the most active VFP communities are in Asian, Eastern European and
Spanish speaking countries.

There's alaways a problem with generalization or drawing a bigger picture
from individual incidents. However, one of my clients sold another license
of his DOS application a few weeks ago. Sometimes getting work done for a
low price is more important than a modern looking UI.

VB 6 is dead and see how VB developers refuse to accept that. ;-)

Any Future for FoxPro -- Do I switch? (Thread: MSS Forum)

Link

Highlights:

If you've written a lot of VFP
code that surely will be your
"funds".

Can you afford throwing that away?

Is there really a need to work with
another programming language?
and do your customers care if
your software is written with X
or Y?

---

Listen, don't start wiggin' out now. The VFP community cannot be canned and
tossed out - keep writting until the OS can't support it I say.

I currently don't see a reason to bail out of VFP and start from scratch
with a new language. And finally, because MS says they are not releasing a
new VFP doesn't mean it will die. You never know what will happen.

---

MS Stopped development on VFP cause IT IS CODE COMPLETE-
i.e. - ya don't need anything else in it, to use it as a development tool.

---

Even if they ultimately come out with a non-VFP friendly OS, it still may be
possible for someone to write a "compatibility" box that allows the legacy
application to run. That would seem to be an easier task then rewriting VFP
or switching to something else.

Fox technology to be integrated into MS products (Blog: Craig Berntson)

Link

The article, Microsoft to Serve Up SQL Server 2005 Preview, includes this paragraph (emphasis my own):

Sources said high-level Microsoft architects are focusing on how "Orcas," the follow-on version of Visual Studio, will more easily and efficiently handle data via future versions of both Visual Basic and Visual C#. In fact, Anders Hejlsberg, a top Microsoft software architect, is working on Visual C# 3.0 and has produced compiler technology that accelerates data integration. The Visual Basic team is working to deliver similar functionality, based on Microsoft's FoxPro technology base, sources said.

So, Fox, while I believe won't be available as a separate product, will live on. It will be reincarnated as something different -- new data manipulation and access technologies in Orcas.

Fox is Dead, Long Live the Fox (Thread: TheMSSForum):

Link

Highlights:

This is a nail in the coffin. I don't read "will run on 64-bit Windows in
32-bit compatibility mode" as a statement of improving VFP. I see it as a
VFP-friendlier phrasing of what is more likely the case--that Longhorn was
planned so that you won't have to scrap your legacy systems, yet. I recall
getting beat up when Win95 had rolled out and we were still developing our
product in 16-bit FoxWin. It's just one more shortcoming for a competitor
to point out. A statement like that would make me VERY jittery about
starting any new development on a product that has stated no plan to make
use of the future of Windows architecture.

VFP is too good of a language to "deserve" this, but I don't have any reason
to believe that MS has any intention other than letting VFP slip into COBOL
status. :-(

---

Although they say there are no plans to merge, a de facto merge could be
coming, if only because dotnet copies Fox's features.

---

For those who find the work, it will
probably become more and more lucrative. And for that same reason, someone
will very likely continue to build add-ons or other ways to work with it.

But over time, very few new endeavors are likely to be undertaken by
companies that do not already have other VFP ties. And for those that do
decide to replace their legacy apps, VFP looks less likely to be the
language of choice. And, while I'm sure MS didn't build COM Interop into
.NET specifically to crush VFP, it provides at least some easing of such a
path, should a company decide to replace existing systems.

Vienna (Windows 7) to run 32-bit Apps (Blog: Andrew MacNeill)

Link here

In response to a ZDNet article which states:

Like Vista, Windows 7 will ship in consumer and business versions, and in 32-bit and 64-bit versions.

Craig states:

This suggested to me that realistically, 32-bit apps have a future life-span of 10, maybe 15, years.