Re-Writing The Visual-Foxpro Language From Scratch
Re-Writing The Visual-Foxpro Language From Scratch
(OP)
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.
Ahmad.
RE: Re-Writing The Visual-Foxpro Language From Scratch
Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS, ATD
"I try to be nice, but sometimes my mouth doesn't cooperate."
RE: Re-Writing The Visual-Foxpro Language From Scratch
VFP Advanced Version 10 - http://www.baiyujia.com/vfpadvanced/f_vfpa_about.a...
X Sharp - https://en.wikipedia.org/wiki/XSharp
Harbour - https://en.wikipedia.org/wiki/Harbour_(programming...)
Joe
RE: Re-Writing The Visual-Foxpro Language From Scratch
I admire your zeal, and I would hate to discourage you. But have you thought about the scale of this undertaking?
Writing VFP from scratch - even if you just focused on the language and data handling, and ignored the IDE, designers, editors, builders, debugger, toolbox, project manager, etc. etc. - would be a massive undertaking. How many volunteers would you need? How would you coordinate them? What about project management, quality control, testing, documentation, distribution? And even open source projects need marketing.
I'd love for you to prove me wrong. If you manage to get the project off the ground, you would have my admiration and good wishes. But I'm afraid I'm not optimistic.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
RE: Re-Writing The Visual-Foxpro Language From Scratch
You said that Foxpro was part of .Net language. This is not so. Foxpro was conceived in the early 1990s, and was based on the earlier Foxbase snd dBase. That was long before .NET was even a gleam in Microsoft's eye.
"Microsoft killed it on purpose because they know very well that programmers will prefer Foxpro as a .Net language". That is also not correct. Microsoft killed FoxPro because they couldn't see a large enough market for it. The main customers for FoxPro are developers. One developer might create an application for a hundred users, but Microsoft would still only get one sale out of that. With Microsoft's other database / development tools - mainly Access and SQL Server- there would be one sale per user.
"It does not have to be exact the same because of copy rights but somehow it could be 95% the same." There are two separate issues here. It is by no means certain that a fresh implementation of the language would infringe copyright, provided it didn't duplicate any existing code. (There were a couple of court cases in the 1980s and 1990s that established that principle.) But if there was an infringement, confining the new version to 95% of the language wouldn't change that.
There's also the technical issue. If only 95% of the language was implemented, think of the implications for backward compatibility.
Finally, I would be interested to know what you mean by "Unify The VFP Database into a single container". If you mean getting rid of free tables, I can see the attraction of that, but the issue of backward compatibility would again rear its head.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
RE: Re-Writing The Visual-Foxpro Language From Scratch
Visual Free Pro by Rick C. Hodgin (a member here on tek-tips, too) has no website anymore.
Guineu by VFP MVP Christof Wollenhaupt http://guineu.foxpert.com/, with a current version from 2013.
The only thing I see still mentioned as a living project is VFPA, based on the VFP9 binary which is patched to apply fixes and changes, see a 2020 FoxFest session about that:
https://youtu.be/iQqoLBOCTrI
My concern: If a language isn't developed by a major vendor like Microsoft, but by a single person only, you'll end up with a last version of that sooner or later, too. C++ - in contrast to that - is in the product range of MS, but not only that: It also has a more general stronghold by being a continuing standard targetting many more platforms than Windows, too. Cheng adds that into the mix, too, as he also has the VFP C++ Compiler. That compiles and allows mixing in C++ which also enables C or assembler, as that's what C++ compilers support, too, and the actual C++ compilation is done with the MS VC++ compiler you also need, as John Ryan mentions at 43:00 in the video.
I'd be more into an idea like that, if your goal would be to create a new language just in the style of VFP, some kind of simplified VFP, that isn't backward compatible but is like VFP a tool to do both the backend (database) and the frontend (UI) with support of interoperation. And actually, that's what's hardest part, to support ODBC, creating and using COM/OLE/ActiveX controls. Unlike the freedom to develop your own language syntax and features, this means implementing complex standards and keeping up to date with them. Not at all an easy task.
Chriss
RE: Re-Writing The Visual-Foxpro Language From Scratch
Keep in mind that in the 80's you can manage a quite large ammount of data together with a 'bunch' of formulas in a spreadsheet with just an 8086 x8 CPU and 256 kb of RAM.
So do you really need a x64 windows11 ? maybe part of the answer is here -
https://www.intowindows.com/where-can-i-download-w...
My point is that you will see 128 bit systems in the future due 3-D or games demand, but the power and graphic cards is overdimensioned and also unjustifyed in the data-world. ( at least until someone would came and justify that a new 3D-movie Memo field will be a 'basic' need, and those without it are just an arcaic technology)
I must copywright that slogan for selling :)
You can still find on another VB forum ( not linked but dated 2001) comments like :
The NOT official truth about VFP role inside MS is very well explained here ( behind the lines).
http://joelleach.net/2011/10/13/why-microsoft-canc...
Was adquired to incorporate It's technology into MS products, but mostly consist, not in sales, but an strategy to stay away of the competitor's standards, ( DBF/Xbase).Same method used in the past along DOS/iexplorer-Netscape etc etc.
okarl
RE: Re-Writing The Visual-Foxpro Language From Scratch
Hi Mike. at the initial stage VFP was embedded in the package of the Visual-Studio.Net same like VB and C# and others ( i think in the first and second edition of the studio ) i had a copy of that but then subsequently it was removed from the package because most programmers went for it instead of VB.NET and others
Mike Lewis <I would be interested to know what you mean by "Unify The VFP Database into a single container>
Yes i meant single entity database like Access but at the same time the concepts of free tables can remain. but for security purposes a single entity with password protection makes it more appealing
Chris Miller <I'd be more into an idea like that, if your goal would be to create a new language just in the style of VFP, some kind of simplified VFP, that isn't backward compatible but is like VFP>
Hi Chris. Yes Correct this is my idea. this is what i meant, it can start with the most important basics then expand into a fully functional front end and backend RAD language. just drop all the complexity out and add to it a server option that mimics SQL for small scale, mid scale applications.
RE: Re-Writing The Visual-Foxpro Language From Scratch
You can start extending the whole functionality from the runtimes, ( It is perfectly Legal and you have half of the work done) and even it should work the same for x64 runtimes.
There was an attempt in the past, but I can't remember now what happened to it.
So you can add modules , helpers , and classes as a full package.
The language is also extensible, so you can use SYS(20001-nnnn)
Nice Idea, but lot of effort, so I wish you the best of luck.
okarl
RE: Re-Writing The Visual-Foxpro Language From Scratch
That's not correct. VFP was included in the Visual Studio 6 box, but that was before .NET. In addition, the reason it was excluded later was not that "most programmers went for it," but because there was no .NET version of VFP and there wasn't going to be.
I assure you it is not the case that more people who bought Visual Studio 6 used VFP than either VB or VC++. Had that been the case, Microsoft would have figured out how to fit VFP into their new web framework.
Tamar
RE: Re-Writing The Visual-Foxpro Language From Scratch
Would there be enough demand for the proposed product among Foxpro programmers? I don't know the answer to that, but speaking only for myself, I have to say that I would not be interested in using it. All of my recent applications run happily in a 64-bit environment, and I can't see that changing in the future.
As I understand it, the main benefit of a 64-bit system is that it can access larger amounts of memory. That certainly is not an issue for the sort of projects I have worked on. It could be that with a 64-bit system, there would be a way of overcoming the 2 GB table limit (not sure about that). But the only way to do that would involve changing the layout of the file header which would break backward compatibility. In any case, if an application of mine needed such big tables, I would almost certainly have gone to a back end such as SQL Server.
Against those dubious benefits, I would have all the work of implementing a new version of the application, with all that that involves for testing and distribution. Not to mention all sorts of compatibility issues.
Of course, I might not be typical of VFP developers. My point is that, before undertaking a project of this scale, you really need to research the market.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
RE: Re-Writing The Visual-Foxpro Language From Scratch
VFP was included in the first two versions of Visual Studio: Visual Studio 97 and Visual Studio 6, which both predate .NET. It was NOT included in any subsequent versions
RE: Re-Writing The Visual-Foxpro Language From Scratch
So, only start with a native file-based database without the support of ODBC, don't support ActiveX or OLE automation, you still have a hard time establishing a futureproof mechanism of decentralized data handling. You forget that even if you integrate all data into one file you handle as a byte array as any system (OS And file and network protocols) will very likely allow that, you still don't get independence from any other detail. You even worsen the problem of write access. Any file change in NTFS needs at least temporary exclusive access as that's how NTFS works. When all tables become part of a single file database you remove the possibility to act on multiple tables concurrently. So concurrency even becomes a worse problem. You don't become independent from that alone, no matter what ideas you develop to partition a single DB file into tables, views, procedures, udfs, and metadata about transactions, locking, and snapshots or more general read/write isolation levels. Well, and all that becomes part of your todo list.
Most such problems only vanish, when you decide to make it a database server. But then you remove a major feature VFP developers like about VFPs DBFs. Not that there is another way than SQL to handle data, but the feature they are likely not even very aware of, as it's so natural to them: Any VFP executable is its own client and server of data and there are things like locks other clients see even though there is no central server process that would normally be needed to handle them. The file and network system of Windows has that role currently, done on the premise of features of NTFS that were not intended that way, even.
So, add in a server instance just for those tasks and make all clients go through a server process to access the one DB file in some low level ways, i.e. for example do USE of a table on behalf of you. The communication from the clients to that new server instance still needs to use what the OS offers in network communication and file system. You open up Pandora's box if you want to get this fully into your own control.
And then we didn't even talk about UI, forms and controls to reimplement. That's the other big portion of your new programming language that also needs to be rebuilt.
Chriss
RE: Re-Writing The Visual-Foxpro Language From Scratch
Chris, just your first paragraph tells me I would NEVER attempt to recreate VFP even if I could.
The remaining paragraphs tell me the enormity of the job done originally by the team to get where VFP9 is and all its capabilities. I can't imagine an individual or even a small team doing that now. A large team would be worse (witness dBASE III).
As we know, there was actually a single individual (Wayne Ratliff) who did a monsterous job writing a "database" app[lication. That was dBASE II - a FAR cry from VFP9!
Good luck, whoever.
Steve
RE: Re-Writing The Visual-Foxpro Language From Scratch
A few months ago, while in a meeting with a Hi Tech General Manager, a topic that I knew about came up, but the scale and dimensions exceeded my worst omens.
He explained to me how virtual demands, unreal needs and also artificial difficulties are created in the industry. Everything is related to 'sell ' something that the public does not need, and thus manipulate his concept of the necessarily useful and turn the accessory into essential.
He gave me a very clear example of a client who needed a specific device, a mobile phone, that has an autonomy of weeks, the client did not need 3 cameras, or 1080 or 4k videos, nor of course watching movies or playing video games on the phone, and also had a plan to change his battery in 15 seconds with a spare one in his pocket.
The seller's response was ... that product does not exist, mobile phones have the latest generation CPU that consumes a lot even without the use of video, because 5G, the high resolution touch screen and fast Wi-Fi require additional energy, the battery is glued on and cannot be replaced. Oh, and all this without mentioning planned obsolescence.
To make matters worse, the seller added, the market \'demands\' the devices we manufacture, not the ones you request, uploading 4k videos to tik-tok and video games is a \'basic\' need for our customers (teenagers).
The customer response is one of my favorites, then I need a 'single device for all', laundry, cooking, and please redesign it so that it has wheels and can travel recharging it every 5 minutes.
Then the GM explained to me, this happens in all industries worldwide, but in software it is especially scandalous.
The big brands intentionally create these difficulties with the purpose of selling modules that must be assembled in a complex way, when the client only needs something that works well, does not take months to develop, is fast and as simple as possible.
Thus, the alternative that they allow is to create \'Frankenstain\' systems, where any piece can fail, it is necessary to do stability and speed tests (the newer the product, the greater the probability of undetected bugs).
Just an example of how technology will complicate everyone's life in the future as we hear 'everything is easier now'
okarl
RE: Re-Writing The Visual-Foxpro Language From Scratch
Excuse my stupid question. I've never written anything in FoxPro, but even before that in the 80's I worked extensively with dBase II and III and was considered the dBase guru in my area at the time. The dBase programming language was actually my third programming language after Basic and Assembler. All I know about FoxPro is that it should be an improvement over dBase.
So my question is: If FoxPro was killed by Microsoft and has been without any support for years, wouldn't it be wiser to switch to dBase, which seems to be constantly supported and developed by a commercial company? Or is there such a big difference between today's dBase and FoxPro that it wouldn't be possible, or wouldn't it make sense for some other reason?
https://www.dbase.com/
RE: Re-Writing The Visual-Foxpro Language From Scratch
Tamar
RE: Re-Writing The Visual-Foxpro Language From Scratch
From the promises vendors make, Alaska xbase++ would be a good option to do VFP application modernization. They specifically target FoxPro developers. Besides Servoy and Lianja, who also addressed VFP developers as VFP was discontinued, although they are no dBase clones, as far as I know.
Chriss
RE: Re-Writing The Visual-Foxpro Language From Scratch
RE: Re-Writing The Visual-Foxpro Language From Scratch
The source code is well developed and documented. It has about 30% of the VFP functions completed, a few commands, the entire VFP9 object and environmental framework is duplicated. It has a full XBASE parser, plus my own VXB extensions. It can declare DLLs, has partial COM support, a somewhat limited but fully event responsive IDE. It compiles in 32-bit and 64-bit code, and is only about 5 MB compiled. It has a full data engine to traverse and read/write DBC, DBF records. It has CDX support, but it's limited.
It just needs attention and time. I stopped working on it in 2016 because I got sick. It took me until 2019 before I felt normal again. COVID hit after that and I've been working on another project called Inspire, which is a new type of CPU architecture you can read about on comp.arch.
I figure if I could work on it 40 hours per week I'd have it usable as a real optional replacement in one year, and would have it optimized, bug free, and really working well in two years.
If anyone's interested in helping me complete it you'd be more than welcome.
--
Rick C. Hodgin
RE: Re-Writing The Visual-Foxpro Language From Scratch
Regards, Gerrit
RE: Re-Writing The Visual-Foxpro Language From Scratch
You said
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
RE: Re-Writing The Visual-Foxpro Language From Scratch
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 DO FORM 192.168.10.1/main.scx where it would auto-communicate with the VFP Server at that IP address, and download the form and present it. Same with everything else. OPEN DATABASE 192.168.10.1/mydata.dbc and USE 192.168.10.1/my_free_table.dbf, 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