Visual FreePro development resumes 8

[foxmuldr3]

I'm going to be resuming development on Visual FreePro, Jr. It plans to clone the VFP9 operational environment and add some new functionality. I'm going to be focused on compatibility with existing source code and features presently so that existing code bases will gain a new lease on life regardless of what Microsoft update might break existing VFP functionality.

If any of you would like to participate ... please! Jump on board!

--
Rick C. Hodgin

 

[GriffMG]

Well, good luck to you, could you start with a 64 bit OLEDB? please

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[vernpace]

foxmuldr3,

Well, unless you open source it, VFP developers would be foolish to use it. Same goes for VFP Advanced. Problem is most VFP developers are either too ignorant or don't care about potential security issues.

 

[ggreen61]

I would suggest tying to build a compiler that would compile standard VFP code to true 32 or 64 bit that would be independent of the VFP runtimes. Not sure if this is the direction of FreePro.

Greg

 

[foxmuldr3]

Visual FreePro is a completely self-contained replication of the VFP9 environment, written entirely from scratch. Fully open source under a type of public license similar to public domain.

It has been in development since July 12, 2012 through March 2016 when I got sick. I stopped development at that time. I recovered in late 2019 and then COVID hit. I have resumed development this past week and will continue working on it as I have free time.

Two other developers who assisted me previously have indicated they're also willing to help develop it, which was most reassuring.

I have an x86 assembly tutorial I'm creating which will take most of my time between now and September, but after that I'll resume full-time on Visual FreePro. Until then it will be periodic.

--
Rick C. Hodgin

 

[ggreen61]

What is meant by "the VFP9 environment"? Is this the design-time and run-time environments? Or is only one? Will FreePro still depend on the VFP run-time support files for execution?

Greg

 

[foxmuldr3]

Visual FreePro currently replicates the entire runtime environment, like _screen, _vfp (though it's called _vjr for Visual FreePro, Jr.), all environment variables, all constants, all syntax, everything. It has about 30% of the functions coded, the data engine works for XBASE commands without the FOR clause, and the FOR clause works in some cases not all. It supports ActiveX/COM, DLLs, etc. Everything that VFP9 does it's been my goal to 100% replicate all functionality exactly.

It's a very complete design, and a partially complete implementation. Ironically, I still learn new things about VFP from time to time that I didn't know, and therefore didn't account for. It will be interesting as it matures to see what else I missed.

I also later discovered that my calling convention is almost identical to the one designed by the VFP authors. I honestly did not know how they did it at the time, and simply developed what I thought made sense. I was later honored to realize I had nearly 100% replicated what they had done independently. I even had the same bug where non-opaque background labels would get darker and darker on subsequent redraws, and had to jump through a few hoops to avoid that.

--
Rick C. Hodgin

 

[GriffMG]

Good luck to you.

That is an Everest of a project.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Mike Lewis]

Rick,

I admire your ambition and I wish you the best of luck with this ambitious project.

But I do have a slight worry about a legal issue. Not because of any possible cloning of the language or the IDE. That's been done many times before. But rather with the name. "Visual FreePro" sounds uncomfortably like "Visual FoxPro", to the extent that you could leave yourself open to a passing-off action. Although the chances are that that will never happen, it is something I feel you should keep in mind if you ever get to the stage of selling or giving away copies of the final product.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[foxmuldr3]

I'm open to a real product name. Visual FreePro could just be its project name. If anyone has a good idea throw it out there. I had considered calling it Data Flex at one point. Also MasterPro.

Maybe Maestro. Hmmm...

--
Rick C. Hodgin

 

[Chris Miller]

Well, in comparison, Chen from Shenzhen Baiyujia Software uses "VFP" in his product names, too. So Mike, do you think this is no issue as he is actually providing patches for VFP.EXE and it actually would be a problem if he would not use VFP in his product names as the legality of his patches are based on the fact you can't disallow fixes under the circumstances MS has discontinued VFP? That would be quite ironic, indeed.



Chriss

 

[ggreen61]

VFP is probably not trade marked so using that would probably not be a violation (typically hard to trademark an acronym). However, the MS license does explicitly state that you cannot decompile or reverse engineer the software. China may not honor the license so that would cover Chen from any liability. But someone in the US might be liable if they use the product (not sure here -- you would need to consult a lawyer that specializes in this area). Lots of products in the US market have similar sounding names, so I would not think that Visual FreePro would be a problem.

Greg

 

[GriffMG]

I don't think Chen reverse engineered the product, someone handed him the source code - voluntarily or otherwise.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[german12]

HDP
HyperDatabase Pro

Peace worldwide - it starts here...

 

[Chris Miller]

MS license does explicitly state that you cannot decompile or reverse engineer the software

I also brought up this argument in an earlier thread. Mike Lewis argues under the circumstance of a discontinued product such license agreements can be overridden. At least in UK, as I understood him, the need to support a discontinued product then has priority over the copyright. The copyright act is quite strong, still, and very international.

Technically the VFP9.EXE file is patched to VFPA.EXE, that means a patch of just a few bytes, and you can always patch fileX to fileY by removing all bytes of fileX and replacing them with all bytes of fileY, but that's not a small patch. As far as I saw in youtube videos describing the VFPA setup this patching is done with least possible changes. One basis for that could be Chen has the full code decompiled and I also still strongly guess so, you don't end up with a well-manageable and extensible C++ project, but the alternative would be patching on the level of Assembly and that's even less probable to me. I think alone of the feature of VFPA to allow usage of more memory for variables. You can't just patch some assembly instructions to go from 32bit to 64bit. It is hard enough if you have the full sources where it's also not done done by switching from x86 to x64, data structures have to change, too.

There's not only VFPA, Chen also posts VFP9.exe bugfixes. If you pick a random bugfix Chen lists at

http://www.baiyujia.com/vfpdocuments/default.asp

like

http://www.baiyujia.com/vfpdocuments/f_vfp9fix227.asp

you see he actually lists assembly code, so in part I think he works on that basis. In some way it is easier, you can turn the runtime DLL and VFP9.EXE into Assembly. That's not decompilation, that's just translating the bytes of the EXE and runtime DLLs to assembler instructions. And that also allows for small patches of just a few bytes for a fix. But I wouldn't want to add features to a product this way.

Chriss

 

[foxmuldr3]

Visual FoxPro is not a discontinued product.

You can still get new license keys under an MSDN subscription.

It's just not receiving any new development.

--
Rick C. Hodgin

 

[Chris Miller]

That's not the point. I think MS declared VFP as discontinued themselves, when they announced there'll be no VFP10. So that terminology comes from them. Just because you can get it with subscriptions is also not making it an alive product, support has stopped completely. It's just there as you can also get older versions of OSes, Office and any MS product within subscription levels, but that doesn't make it a product MS still sells.

Chriss

 

[foxmuldr3]

Chris, I disagree. Legally, Microsoft is still selling Visual FoxPro. You have to pay for an MSDN Subscription to obtain it, and they generate revenue from its sales.

Just because it's not receiving any new development presently doesn't mean it can't in the future. Microsoft will likely never do anything further with VFP9, or any later revision of it ... but it's still their product, and it's still legally their asset. They still have value there because even in Windows 11 it still works and is still in use 13+ years later. And most importantly, they are still generating revenue from it no matter how small. That's the very definition of why companies go into business, so by any business legal standard they are still selling a viable product.

We also don't know what Microsoft is doing with Visual FoxPro. They might still have an NDA government contract requiring them to issue security bug fixes. All of that would come out in a court case. But, even so ... Microsoft is generating revenue from VFP. It is an active product in their line. And I think the idea of discontinuing development, versus discontinuing sales ... are two very different things (legally).

I honor Microsoft's copyright on the product. It's why I'm literally writing everything from scratch. And for anything in reason they dispute I will alter that part of the program to have slightly different functionality so as to not trample on what they believe is their intellectual property.

Property rights mean something. Ownership is real. It's why it's so dangerous to move to the cloud. You become a renter, not an owner. Renters can be evicted. Owners cannot. This is actually THE reason why I'm resuming development on Visual FreePro. I do not believe in the cloud as a service. I believe in using interconnected computers to exchange data, but each person should have ownership of everything.

Think of even our bodies. Every cell has a full copy of everything required to make the entire body work (in the form of DNA). But each cell does its part. I think that's how our software should be. We should be able to do everything offline, and go online where it's beneficial. It will be my primary goal with Visual FreePro to allow things like this:

USE vjr://192.168.10.1/folder/my_table.dbf
OPEN DATABASE vjr://192.168.10.1/path/my_container.dbc

DO FORM vjr://192.168.10.1/path/my_form.scx
* Et cetera

Things should make sense. Moving everything to the cloud and using a web browser to access data 100% does not. In my opinion it's a huge mistake because of how fragile it makes your system. At least with local storage and owned servers you can hop on a bicycle rigged up to a generator to charge a battery to run through a UPS and generate enough power to get your data if you need it.

--
Rick C. Hodgin

 

[Mike Lewis]

Lot of good points here. I'll reply to some of them after I've had a chance to read the thread in more detail. For now, let me just pick up a couple that Greg made:

VFP is probably not trade marked so using that would probably not be a violation.

My point wasn't about trade marks. It was about passing off. A person who brings a passing-off action doesn't have to show any infringement of trademarks or other intellectual property. They only have to show a likelihood that potential customers might be misled. There is probably nothing to worry about in this case. I'm just saying that it is something that Rick should keep in mind.

However, the MS license does explicitly state that you cannot decompile or reverse engineer the software.

Well, licences imposed by a vendor cannot override legislation. On the contrary, in the EU, there is a specific right to reverse engineer a product if it is done to promote interoperability. I don't know whether, in this case, Rick is actually reverse engineering VFP, but there is a good argument that it is being done to promote interoperability. Of course, the law might be different in Rick's country.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[foxmuldr3]

Rick has not reverse-engineered anything in Visual FoxPro, its DLLs, EXEs, or anything. I have learned how VFP works and have translated that into my Visual FreePro design (VFrP for the full version, and VJr for the 100% VFP9-compatible version -- VFrP is like .NET and runs in its own virtual machine, and VJr is like VFP9 which is a real x86/AMD64 binary).

[Edit: I have looked at the SCX/VCX/DBC/etc files as tables, and figured out what they do, but I view that as simple data that's available through a standard interface (BROWSE window, for example), and is not part of a compiled binary / executable requiring external tools to deconstruct. Everything I've done can be done in VFP from the command window using only built-in features.]

In the U.S. you are legally allowed to decompile and reverse-engineer a product for the explicit purposes of identifying security issues and design flaws. You cannot patch it yourself, but only inform the original author of the condition / state / issue / whatever, and make informed decisions on whether or not to continue using it. You can publish your findings as well, which will often encourage a company to fix the issues to preserve the reputation of their product.

When I wrote articles for TG Daily back in the 2000s, I wrote an article on Intel's 32-/64-bit CPU line, and how they have had listed errata for multiple generations. It got such traction it prompted Intel to contact us and respond. The attention brought light into something they'd been silently propagating and keeping in the background.

Light is good. It removes darkness.

--
Rick C. Hodgin