Visual FreePro

[foxmuldr2]

I am an advocate of free software. In late 2010 I began working on a free software project (currently unreleased) called Visual FreePro.

Visual FreePro was to be a VFP9 follow-on (since Microsoft killed it). My idea was to have 75% support directly in source code (up to 75% VFP commands would run without any source code changes), to have 15% of VFP code needing slight modifications, and the remaining 10% would be thrown out and replaced with other code I would like to see. I was also going to provide full (true) backward compatibility support from the DOS-based versions of FoxBASE+ on through the FoxPro for Windows versions, allowing those apps to run 100% without any modifications.

I am wondering if anybody here would like to participate in such a project?

I have the application started in Linux, written in GNU's C++ compiler. I have the class structure setup (which allows everything else to work with dot references, including _vfp, _screen, etc.), part of the source code parsing engine completed (for an unrelated project I worked on), and in terms of "the next thing to do," am ready to start working on that part of it (source code execution).

I have considered continuing this project but have not worked on it much since early 2011. The time may be for this project to take off again.

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

Olaf,

Absolutely! Ask him if there are any legal issues. Tell him I want to basically replace Visual FoxPro 9 with an almost clone, but with some differences, losses and enhancements, entirely written from new source code using my own engine design.

I'd be curious to see what he says.

As for the former Microsoft FoxPro team developers ... much appreciated, but I'll pass.

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

As for the former Microsoft FoxPro team developers ... much appreciated, but I'll pass.

I've been thinking about this. Surely the developers were under constraints from Microsoft, and there were things they wanted to (1) do and (2) do differently, but were prohibited from doing so because of executive decisions.

Maybe I'm being too harsh on what could be a wonderful source of assistance. :-(

If they had open minds, were advocates of free software, and were interested in moving forward with VFP in the VFrP form, I think I'd be interested in hearing from them and receiving contributions.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

Well, that connection to the Microsoft employees is unlikely to lead to assistance by them. The partly moved fomr Micorsoft and mostly moved to other Dev Teams. But as far as info is not NDA, I'm sure Christof is willing to share what you need to know.

OK, I'll ping him on G+

Bye, Olaf.

 

[foxmuldr2]

In progress!

Will soon host the source code I already have developed on that machine through a git repo. Will switch to a Windows development environment until it is sufficiently edited as I desire to work with edit-and-continue tools (Microsoft's Visual Studio).

Oh, that's something else VFrP will have -- an edit-and-continue debugger. Have missed that every day I've used FoxPro.

[URL unfurl="true"]http://www.visual-freepro.org/[/URL]

Here's to dedication. Here's to prayer. Here's to doing something wonderful before all men, that they may benefit! And all this indeed, if the Lord be willing.

Best regards,
Rick C. Hodgin

 

[TamarGranor]

On the issue of not being able to edit the parent class when a form is open, the VFPX project Thor offers a really nice tool. Basically, when you run the tool (which can live on a hotkey), you get a form that shows you the inheritance hierarchy for the selected object and for the form as far back as that object is on it. You close the form you're editing, choose the class you want from the tool's form and click a button, do whatever you need there and save and close the class. The tool form is still open and has a button to return to wherever you started. It's really nice and much easier to use than it was to describe. (Also, written entirely in VFP.)

Tamar

 

[foxmuldr2]

I spent most of the afternoon and evening Sunday setting up the website. There's a landing page and a wiki now. Officially, Visual FreePro will be referred to as VFrP, pronounced "vee ferp".

Visual-FreePro.org

I have decided not to reference the name "Microsoft" or "FoxPro" (or "FoxBASE") in the entire project.

I have created compatibility modes that will be targeted. These will handle screen input and output identically to their early counterparts, but will also provide all new software abilities (meaning TB can use full SQL commands, reference objects, etc., but for old code that was written in the 80s, 90s or 00s, it will work without alteration).

I have also targeted to include as close to 100% compatibility as is possible with those two older versions because I want the investment people had back then to continue bearing fruit without the new costs associated with developer expense, and more importantly, continual monthly payments for new SaaS alternatives. I may also increase the compatibility with V3-V9 modes as well:

TB - Text-based (like Multi-User FoxBASE+ 2.1)
GB - GUI-based (like FoxPro for Windows 2.6)
V3 - Visual FoxPro 3 compatible
V6 - Visual FoxPro 6 compatible
V9 - Visual FoxPro 9 compatible

The repository on GitHub is the code and design I had back in Feb/March 2011. It is incomplete and quite lacking. It also only compiles on Linux using the CodeLite IDE, GCC toolchain and GDB, and works only with x-windows. That will soon change.

VFrP on GitHub

I am migrating the project and source code to Visual Studio 2008. I will do my development in VS2008 because in my experience, VS2010 is still (to this day) buggy.

If anyone would like to contribute, let me know and I'll give you write rights (LOL!) to the wiki, or push/pull access on github. The github project has a fox_docs directory which contains all the commands, functions, methods, events, et cetera, supported in FoxPro. I was going to add that list to the wiki, and then as they are completed indicate the date, etc.

I realize it may take some time before people begin thinking of this project as more than a fad. So, I'm prepared to go it alone for the time being if need be. Some recent changes in my life have afforded me the time and focus to continue development again.

Here's to prayer and a continued commitment (unto such time as my life changes again)!

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

Regarding the VFrP fox icon:

I wanted to convey a much more laid back, at peace with himself, kind of mascot. If you look at the FoxPro icons, they all have this sneaky-looking, "I'm ready to eat your chickens" looking fox. Didn't want that.

I wanted a confident animal, one who doesn't have to sneak around and be harmful to those people around him, but rather one who fully confident in his abilities because he's doing everything he can, as best he can, and God is providing for his needs, and it's working out completely and in harmony with those who are around.

Hope this makes sense ... And ... peace!

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

Reagarding the levels: It would perhaps be better to offer the levels the language also suggests: 70,80,90 (see REPORTBEHAVIOR,ENGINEBAHAVIOR), I'd also agree on another mode for old apps in dos style.

It would of course be nice to see an ODBC driver also supporting DBC Events, there is no reasoning to make many compatibility levels for it, support the full VFP9 engine SQL, perhaps you even introduce some other features like MERGE or INTERSECT etc, anyway.

In regard of the icon, I did a new one myself for mashant (a social network for developers I joined recently and added a foxpro group), you can find it over there at but as you call it FreePro there even is no need for a fox anymore, is there? No reason to stay with that animal or an animal at all. Maybe go for a more specific fox? The desert fox or fennec fox, looks more cute perhaps, with his tiny head and big ears.

Bye, Olaf.

 

[foxmuldr2]

The desert fox or fennec fox, looks more cute perhaps, with his tiny head and big ears.

You crack me up! You old softy!

I am going to remove all obsfucation from anything related to future DMBS in Visual FreePro. Everything will be accessed through the traditional set of xBase commands to access local tables, along with SQL commands (I will support the behaviors as options), but will work not only at the local level, but also on remote data sets.

It will be set up so everything is hidden through either an InDisk-like external software layer, or through a built-in driver which allows EVERYTHING to work with traditional xBase and VFrP commands, but without ever doing anything in code that looks even remotely remote-specific, except options on the USE command, which will need to be added for remote data, such as:

USE table ALIAS whatever REMOTE(127.0.0.1, port[, usr, pwd[, driver]])

VFrP will also be able to serve as its own stand-alone server through the InDisk-like protocols.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

http://fennecfox.biz/

really cute

USE of remotely stored DBFs? Okay, good idea. But I think access to foreign database data would still also be nice, you'll miss interoparability if not supporting that.

Bye, Olaf.

 

[foxmuldr2]

http://fennecfox.biz/

really cute

He's certainly all ears!

But I think access to foreign database data would still also be nice, you'll miss interoparability if not supporting that.

Not just remote DBFs from a remote instance of VFrP. The idea would be that you access foreign databases through native VFrP commands, which either go through an InDisk layer to get it, or more preferably to have a built-in plug-in which, based on some type of identifier at USE time (the driver in use, for example), would be used to access the foreign data.

I think enough people will come on board at some point that they can help me write all of the required local/remote/foreign database code. Visual FreePro, Lord willing, will be a whole project, one that ends up being as robust as VFP, with ongoing maintenance and a lot of extensions making it a wholly desirable NOT-IN-THE-CLOUD form of business software available anew.

I do expect Microsoft to step in at some point and try to shut it down. They stand to lose a lot of money if a free software project can pick up where they left off, improve upon it, and continue.

I've always held that Microsoft killed VFP for only one reason, and one reason only: The unlimited royalty-free runtime distribution model, and the ability to connect with free software SQL server alternatives, like MySql, meant they couldn't monetize it like they can .NET. Another big part was that porting VFP to .NET totally killed it in performance so we (the developers) would see that .NET was really not a good thing after all because VFP by itself, with much smaller runtime libraries, was actually faster on nearly everything, and this of course through native use of the CPU and well-tested / established Win32 abilities, and not those found in a virtual machine layer sitting on top.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

Many people have their own theory about why MS finally discontinued VFP, but license fees could have been introduced.

Their main reasoning was the business failure it was for MS, wasn't it? That may include the missing income from fees but mostly meant they spent more money on developement of VFP than they earned by it's sale, doesn't it? And it's toally believable, if you take into account how many fox apps stayed as dos apps or at other earlier versions and how litte version upgrading is done. Also they may wanted to concentrate on one main dev tool line with dotNet and VFP didn't fit in there with it's macro substitution.

Technically speaking VFP code actually is quite like Java bytecode or DotNet CIL, the difference is, it's neither input of a VM nor a JIT compiler, VFP bytecode is read by the fox runtime and so it's an interpreted language. The interpretation is quite simple, eg the opcode of a command is turned into calling some function of the VFP runtime DLL, which itself is compiled C++. That's still faster than a VM execution, but it's still far from compiled and optimised asembler code, only the runtime code itself is compiled and optimised, but not the VFP code (see

http://www.foxpert.com/docs/fxp.en.htm

for reference on BFP object code structure).

The idea of dotNETs CLR - the VM executing CIL - is to pass it on to a JIT compiler creating assembly code, isn't it? That's how I interpret several sources about CIL, CLR and the JIT Compiler. So even if that's still not making dotNet EXEs fast, it has the potential, hasn't it? Coming out with optimised code for the actual CPU and GPU combination of a PC and auxiliary hardware like the north/southbridge would make the final code be adopted for hardware locally available. Maybe MS just lacks better JIT compilers and persistance of the compiled code, is it persisteed or is the JIT compilation redone at every restart?

It could at least get far better than Java ever was or will be and VFP ever was. But if you really aim for a VFP compiler that could become better, as there aren't multiple languages to support there is no reason to compile VFP sources to an intermediate language, perhaps you will, prehaps you will output C++ code and forward that to a C++ compiler. Or are you going that low level in outputting assembly code?

 

[foxmuldr2]

Their main reasoning was the business failure it was for MS, wasn't it? That may include the missing income from fees but mostly meant they spent more money on developement of VFP than they earned by it's sale, doesn't it? And it's toally believable, if you take into account how many fox apps stayed as dos apps or at other earlier versions and how litte version upgrading is done.

It's obvious. They could not monetize VFP as well as they could .NET. And were MS to re-release VFP 10 under a new non-royalty-free runtime license, or re-release even new versions of prior products, people would just continue to use the older ones. MS had to kill it so they could force companies everywhere to give them more money for the higher monetizing products.

Or are you going that low level in outputting assembly code?

Another private repo I have on github is called RDC, the Rapid Development Compiler. It is designed to be an edit-and-continue compiler with a language similar-to-C/C++. It has the ability to read source code and compile it into executables. I will make that feature available for VFrP at some point. These will be native executables that are completely stand-alone (no supporting DLLs are required, though the option of reducing the EXE size and requiring external DLLs will also exist).

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

In looking over this VFrP code I uploaded to githup, this is not the most current version. I'm not sure what happened to it. I can't seem to find a newer versions that have anything populated in the directories, just a naming structure (like FreePro2) where the internal content was deleted.

Hmmm....

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

A lot of work. Migrated to VS2008. It compiles now, but is missing two constructors indicating that this is, indeed, not the current version.

VFrP on github

Also, I found references in dates to source code from 2009 and early 2010. I had not remembered beginning it so far back.

I believe this is a very early version of the code I later had. It's kind of frustrating to have potentially lost that code. :-( But I have gone through a couple machines since then.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

I'm confident you'll find something more recent. External drives? Some backup somewhere else in the cloud?

Bye, Olaf.

 

[foxmuldr2]

Possibly. I do have a couple TB drives I use for backup. I may have one hidden somewhere up in there.

Regardless, some of the work I've done on a project this year has made the way I would've handled the program execution, threading, stack and variable space somewhat altered. I may be better off to just write it anew from scratch.

Best regards,
Rick C. Hodgin

 

[mmerlinn]

VFP sill carries baggage from the Mac and Unix versions. Surely that won't need to be in there.

Personally, I would love to be able to move my old FP code from my Mac OS 9 to Mac OS X, but I realize that whatever established Mac base that there was, is long gone, so there is no justifiable reason to support the Mac.

So far as I know, there is no relational database like FoxPro available for the newer Macs. So, somewhere down the road, it might be justifiable if and only if the Mac crowd would jump on board.

I don't expect to live long enough to see that happen.

mmerlinn

http://mmerlinn.com

Poor people do not hire employees. If you soak the rich, who are you going to work for?

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Raymond

 

[Olaf Doschke]

Well, Mac OS X is based on BSD, which is a POSIX OS. Surely APIs on top of that just really make it a Mac, but most pepole not developing with Apple's XCode/Objective C use that POSIC layer to make use of popular Free Software as MySQL and PHP, besides Java running on it, of course.

Wikipeadia says "Since OS X is POSIX compliant, many software packages written for the *BSDs, Linux, or other Unix-like systems can be recompiled to run on it."

And from that perspective there are several good databases already available to the Mac developers: I already mentioned MySQL, but also FireBird, PostgreSQL and many more can run on Mac, besides running apps in the web with a mere GUI at the client side also is easy enough.

Still it's true there are only those SQL Servers, good enough for serious developers, but not aiming towards lighter database use. You only have FileMaker as the most important end user database, if I name it that way instead of file based database, and besides OpenOffices. But even Access is missing from Office for Mac. There seems to be littel demand for the most Mac users to fiddle with data. Actually I can understand that from the viewpoint of a graphic designer, which still is the main audience of Mac computers, aren't they? A graphic designer can mostly live with the file system as it's 'database' of graphics portfolio, so the demand is really low.

On the other side such an offer of DBFs on Mac would perhaps also change the market. There surely are enough Mac Users wanting more than to save their few contacts and mails. That's also a reason I mentioned C++ as intermediate compiler output to feed into a C++ compiler, that can also be finalised to an executable on Linux and Mac, so it would really be a good idea to have a VFP to C++ compiler. VFP to C# may also be possible, but wouldn't port good of course, even if there is Mono.

It's not evan an unusual approach. I remember my time with Lattice C on Atari and Borland C++ on PC, I think both of them created Assembly source code and you could even look at it. And I was good at 6502 and 68000 Assembler, once. I mostly did graphics and liked interrupt programming on C64 very much. So compiling to a lower level language isn't that hard and can make use of many compilers around on that level, from Intel, MS, Borland/Inprise, even Watcom. Or let it be C++0x / C++11, the direct successor of C++.

Bye, Olaf.