Re-Writing The Visual-Foxpro Language From Scratch 8

It's already been done.


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.

For your reference;

VFP Advanced Version 10 -
X Sharp -
Harbour -
Joe

Ahmad,

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

Ahmed, could I pick you up on a few points in your post. These don't detract from you overall goal but I think they need clarifying.

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

I can add two projects that started and never finished:

Visual Free Pro by Rick C. Hodgin (a member here on tek-tips, too) has no website anymore.
Guineu by VFP MVP Christof Wollenhaupt 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:

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

Ahmed, x64 language support isn't needed in most majority of cases , just the use of > 4 gb of RAM to allow open many high resource-apps at the same time is the main reason ( although some DLL/s and libs doesn't have a x32 version).
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 -
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 :

Actually it was dropped from studio.net and will be released as VFP 7.0.
It works infinitely better using large tables (3GB+) over WAN's with multiple users (1000+) than anything provided by VB or Access. I work for a major international fulfillment house / call center that uses a custom-built VFP program that uses 28GB tables, has over 12,000 end users, and is 'live' over a global WAN. Access would either crash or be so slow it would be useless. I don't think VB could handle that either.

Click to expand...

The NOT official truth about VFP role inside MS is very well explained here ( behind the lines).

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

Mike Lewis. <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>

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.

Ahmad

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

Ahmad Kaj said:

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

Click to expand...

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

As well as the all the technical points that we have discussed here, there is a more important factor to take into account: demand.

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

>at the initial stage VFP was embedded in the package of the Visual-Studio.Net

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

Access capabilities grew since you last looked and so it would still be the competitor of such a new proposed language for RAD and mid-range business applications. As I already said it's the easier part to implement a language. It's much harder to implement the OLE/COM and ODBC standards you will need to interop with the world in Windows and also networking. Access has all that done and it's a steep way to get just on the same level in only these aspects.

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

Just another slant:

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

Before I leave the forum, and also the programming galaxy forever 'almost', I would like to explain something important.

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

Hello fellow colleagues,

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?

@mikrom, yes, there is a huge difference today between FoxPro and dBase. Essentially, dBase 4 and FoxPro 2.6 were the last nearly interchangeable versions. The products went in different directions after that.

Tamar

There still are a lot of the other languages that started as dbase clone, like Clipper, Harbour, Flagship, and others. Of course, dBase could be an option, but not to continue using your VFP code, but as Tamar said both the original and all the clones developed in different ways. And sure you could keep your xbase thinking, but still not all your data, code and UI. And you have the wrong idea about developers, if you think someone picking up Foxpro as a dbase clone keeps track of all the other clones and how they developed.

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

Many thanks for the clarification.

I still have the Visual FreePro, Jr. source code if anyone's interested. The website still exists too, but it's been pulled down on purpose.

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