Re-Writing The Visual-Foxpro Language From Scratch 8

[Ahmad kaj]

With so many Visual-Foxpro Programmers scattered around the world why not sponsoring a group of hard-core programmers to Re-Code VFP In 64 Bit Version?. Unify The VFP Database into a single container and Create a stand alone service for it and make it open source so it can get a fresh start?. It does not have to be exact the same because of copy rights but somehow it could be 95% the same. i think there should be a forum sponsoring this option ( i personally ready to contribute finances and i guess many will do the same) !!!. we all know that initially Foxpro was part of .Net language but Microsoft killed it on purpose because they know very well that programmers will prefer Foxpro as a .Net language over any other one and for that VFP and the community of VFP had to pay the price.

Ahmad.

 

[Gerrit Broekhuis]

For a rewrite (or extension) a browser version would be nice to run applications in a browser. Existing additions have not yet convinced me.

Regards, Gerrit

 

[ggreen61]

Ahmad--

You said

Microsoft killed it on purpose because they know very well that programmers will prefer Foxpro as a .Net language over any other one

As others said, this was not the case. I know many shops began to move away from FoxPro long before 2006 (end of VFP) as they were uncertain of the future of VFP. Many that I knew, moved to Java at the time. Also, when VFP 7, 8 and 9 were released there was not a large migration to each new release by the developers; many developers stayed with VFP 6 which was revenue loss for Microsoft. VFP had to have the developers continue to purchase each new release. Microsoft did what any company would do that saw a low revenue stream for their product -- ended it and moved the programmers to other more profitable positions.

Greg

 

[foxmuldr3]

Ggreen61,

I agree with Ahmad. Microsoft killed VFP because it did in one tool what no other tool since has ever been able to do. It was fast. It was free for end users. Only developers had to pay for the software license. It didn't have any tracking ability as it ran natively on the CPU and not through a .NET engine. It also allowed people to process all their data locally with ease. One tool to do it all. Microsoft could not have that with their subsequently revealed vision of having everything monitored, tracked, logged, arguably spied on, and everything stored on the cloud. Even Office now, you have to go through clicks to get to your own hard disk to save files. It's obviously suggesting and encouraging you to save everything on the cloud. It's crazy IMO. Why anybody would want to put their personal documents on any one else's machine is just nuts (unless you're purposefully doing collaboration). But personal documents, personal files ... no way.

VFP9 needed to add better support for graphics and networking for later versions, but that could've easily been added.

IMO, Visual FoxPro needed three things to make it truly soar:
1. The addition of static types for direct compilation (like C/C++).
2. Support for an OpenGL or DirectX based forms engine, with native triangle and quad support
3. Support for networking to allow VFP to operate as client and server, with the ability to do something like [tt]DO FORM 192.168.10.1/main.scx[/tt] where it would auto-communicate with the VFP Server at that IP address, and download the form and present it. Same with everything else. [tt]OPEN DATABASE 192.168.10.1/mydata.dbc[/tt] and [tt]USE 192.168.10.1/my_free_table.dbf[/tt], etc.

And possibly a 4th thing:
4. A much more robust / flexible report forms engine.

All of these things were added to Visual FreePro. If development ever resumes, it is close enough to being complete that it would be a relatively trivial effort for a team to accomplish. Most of the hard work has been done in the initial design, setup, implementation, and low level function support. What's left now is mostly higher level algorithms which use those primitive tools in the right orders.

If I were to pick it up at this point, I would focus first on completing the secure data engine, which allows encrypted databases. I used .dbe instead of .dbf, and .sdx instead of .cdx. Each record, or each 512 byte index page was encrypted with a key that had to be provided when the table was opened for it to be accessible.

--
Rick C. Hodgin