INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS
Come Join Us!
Are you a
Computer / IT professional?
Join Tek-Tips now!
- Talk With Other Members
- Be Notified Of Responses
To Your Posts
- Keyword Search
- One-Click Access To Your
Favorite Forums
- Automated Signatures
On Your Posts
- Best Of All, It's Free!
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.
Partner With Us!
"Best Of Breed" Forums Add Stickiness To Your Site
(Download This Button Today!)
Feedback
"...At last there is indeed a website/forum that
deals with professional and serious matters. Keep up with the good work!!"
Geography
Where in the world do Tek-Tips members come from?
|
|
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
|
|
I would be looking not only for developers to write Visual FreePro, but also people to test it and document each function.
I remember Fox Software's FoxBASE+ coming with a very simple black and red 3-ring binder which had each function and command in alphabetic sequence, with an explanation on each page, some source code examples, and see other tabs.
I'd like to make a literal simple help file like that. Would prefer a wiki.
I can set all of this up and get it started if anybody would like to help out.
Best regards,
Rick C. Hodgin
|
|
Several people and companies have tried to do similar things and failed. I'm not going to hold my breath on your efforts, but good luck. Craig Berntson
MCSD, Visual C# MVP, www.craigberntson.com/blog
|
|
Craig,
I'm not sure why you posted any comment here at all, except to be discouraging. Thanks?
Best regards,
Rick C. Hodgin
|
|
My point was, it's a HUGE job. Much bigger than you think it is. Companies that supposedly were well funded have tried and failed. Individuals with good intentions to do an open source project on this have tried and failed. I think that's why VPFX has worked. The projects are small and managable, yet add great value.
Don't get me wrong, I wish you success. Craig Berntson
MCSD, Visual C# MVP, www.craigberntson.com/blog
|
|
Quote:Good luck ... I wish you success.
Thank you.
Best regards,
Rick C. Hodgin
|
|
Rick
I'm curious about the ten percent that would have to be thrown out.
You say you aim 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." If that's the case, wouldn't you need to keep 100 percent of the language?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
|
|
VFP sill carries baggage from the Mac and Unix versions. Surely that won't need to be in there. Craig Berntson
MCSD, Visual C# MVP, www.craigberntson.com/blog
|
|
Quote (Craig)VFP sill carries baggage from the Mac and Unix versions.
True. I'd be surprised if that consituted the ten percent. But what do I know?
Mike __________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
|
|
Quote (Mike)I'm curious about the ten percent that would have to be thrown out ... If [100% backward compatibility with FoxBASE+ and FoxPro for Windows is required], wouldn't you need to keep 100 percent of the language?
It's been over a year since I considered any of this stuff. I don't remember all the details.
There were a lot of features added post VFP6 that I'd throw out. Some probably common use features (like ActiveX/OLE support so it would work on other platforms -- though I would provide similar support through supplied DLLs which handle common things, allowing also for developers to code and contribute their own extensions back to the community), some of the reporter abilities (though I would replace the reporter with something far more WYSIWYG and flexible to use), some SQL engine enhancements, several things I can't remember off the top of my head.
I would add:
CODESET FREEPRO TO [FB,FW,V3,V6,V9]
* Emulate FoxPro at these levels:
* FB = Multi-User FoxBASE+ 2.1
* FW = FoxPro for Windows 2.6
* V3 = Visual FoxPro 3.0
* V6 = Visual FoxPro 6.0
* V9 = Visual FoxPro 9.0
* (no support for 5.0, 7.0 or 8.0)
This would allow certain functions to behave as they did in those particular versions. These can be set while the code is running.
I would alter the way some things are done today so they aren't quite as obtuse. For example, ICASE(). Having a sequential series of parameters is obtuse. Instead, I would devise a definition which allows for the test conditions and then multi-line code snippets to be created (similar to way DEFINE CLASS works today, but it would be DEFINE ICASE name), which then would be referenced by name in the ICASE() statement.
CODEDEFINE ICASE myicase
[LPARAMETERS lxTest]
[RETURNS lcReturn
* Whatever value lcReturn has at the end is what's returned]
* Can have explicit RETURN clauses at any point
CASE condition1
* code goes here
CASE condition2
* code goes here
OTHERWISE
* code goes here
ENDDEFINE
* Use in code:
k = ICASE(myicase[, variable])
* the ", variable" portion is not needed as myicase will
* inherit the current data environment plus variable state.
* Double-click on "myicase" in the ICASE() statement to
* edit its definition.
In source code the GUI editor would present it as a popup or tooltip (similar to the way memo fields pop up with Ctrl+PgUp in a browse window). That way the code can be multi-line, vertical, spread-out, formatted, easy to observe, easy to line debug, and with full support of multiple commands per case condition, etc., with the end result being a complex case condition able to be used easily as an immediate.
Things along those lines are mostly what I mean by throwing some things out and adding my own stuff, though some of my own stuff would include tables as objects. Records as objects. Fields as objects. Memory variables as objects. Basically everything as an object, able to have objects added to them, method code, event responses, including triggered global and local user events.
All of this is in addition to supporting the standard syntax used today.
A new data storage format would be added to explicitly indicate what type and size I want to store my variable as, such as integer, unsigned integer, floating point, character string, unicode string, etc., and I would provide full conversions between types.
CODE* Store 1234 as a native type without explicit form
foo = 1234
* Store 1234 explicitly as a 32-bit unsigned integer quantity
* Note: This now allows over-/under-flow events to be
* thrown (see addEvent() below).
foo.u32 = 1234
* Store 1234 as a 64-bit floating point quantity
foo.f64 = 1234
* Store .t. as a text string
foo.c = .t.
* Store "hello world" as unicode
foo.u = "hello world"
* Store current contents as unicode (if not already)
foo.u = foo.as(u)
Other such options.
Objects make it possible:
CODEfoo.alltrim && same as foo = ALLTRIM(foo)
foo.release && same as RELEASE foo
* Add an object to a variable
foo.addObject("Name", "Data tag to go with it, can be anything")
* Add method code to a variable
foo.addMethod("name", reference to code when called)
* Specify that this variable should respond to an event
foo.addEvent("event name", reference to code when called)
* Create multiple clones of itself, which for mere data is
* only of mild interest, but if objects, events or methods have
* been added to a variable, can be more powerful (see below)
foo.clone(newvar1, newvar2, newvar3)
* And of course
foo.saveAsClass(...)
Assignment within use:
CODE* Today:
foo = 1234
sam = foo * 4
* FreePro:
sam = foo.(1234) * 4
The object nature of everything makes a lot of possibilities.
Other additions are synchronous debugging between two machines, remote debugging, real-time variable monitoring (debugger doesn't have to have code paused to examine variable contents, but continues to examine variable contents while running).
Lots more. Can't remember them all right now. Visual FreePro was well thought out. I may push the code to github in the near future regardless. The object/class structure and program stack I've developed may be useful to another project anyway.
Best regards,
Rick C. Hodgin |
|
One other huge one was wide multi-threading support. Threads are spawned by a setting for global or local events (so they execute in parallel, or suspend execution until they are completed -- which is VFP's model today):
CODEDO whatever WITH parameters NEWTHREAD
* And for function references
k = some_function(parameters).newthread(tag)
* Execution will continue here in parallel
* Then you can use a join clause:
_threads.join(this, tag)
* Code execution will not continue here until
* some_function(parameters) completes.
* Multiple tags can be used so several spawned-
* in-parallel things can be joined at once.
* The same can be done with DO:
DO whatever WITH parameters NEWTHREAD(tag)
Best regards,
Rick C. Hodgin
|
|
Rick,
I must say it sounds very ambitious. You'll need a lot of time - and a lot of helpers - to make it work. I wish you luck with it.
Personally, I would favour a version that abandons FoxBase and Foxpro 2.x compatibility in return for a lighter language. I'm thinking of things like the old UI commands (@ / SAY, @ / GET, READ, etc), as well as the commands that no-one ever uses (FIND, INSERT, JOIN, etc) and perhaps the old window commands (DEFINE WINDOW, etc).
I would say get that working first, before trying to add radically new features like object-oriented records. But that's just my opinion. You've obviously thought about this in great depth, and a more aware of the issues than I am.
By the way, you wrote:
Quote:I remember Fox Software's FoxBASE+ coming with a very simple black and red 3-ring binder which had each function and command in alphabetic sequence
I still have that binder.
Mike __________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
|
|
In my oppinion the time has passed for such a project, if you want to make it a commercial success. Your name for it suggests not so, at least not for the language itself. Even disregarding that, the german in me warns me about legal issues. Even if reimplementing the language fully yourself, this hurts rights. reminds me of replicates of brand articles.
As a foxpro guy I would like such a resurrection, even if only compatible partly. For any private programming that would be sufficient, already.
Also there are good chances to make the most wanted changes: Unicode support, specifically for the native controls and no 2GB limitation. In my oppinion the 2GB limitation is none, as it's impractical for working the xBase way anyway, you should go the client/server route with that much data anyway. There are other things to fix with DBFs, eg the mechanisms of locking table or record shouldn't make use of file system trickery. The file structure and file access should be changed to avoid problems with the SMB protocol, oplocks and leases, especially where multiple client access is likely the developer should be able to decide when caching would be an advantage and when not.
Bye, Olaf. |
|
Olaf,
xBase was ruled to be a non-exclusive dominion of dBase in the Ashton-Tate / Fox Software case. So, any free offering would not be in rights violation. And since it would be written entirely from scratch, entirely of new source code, all free software ... it would be out there.
I have no plans to make it commercial. Although, I wouldn't mind having a lifetime of work working in VFP (Visual FreePro) development. 
One thing I would like to add is more native integration between client/server and VFP's inernal abilities. I don't like the idea of coding for complex remote SQLEXEC() statements. I'd rather see that handled by a converter and allow native VFP code to be written, when then executes the commands on the server.
I have two paths for this. One is here (a native relationship between VFP (Visual FreePro, perhaps called VFrP from here out), which relies upon an interface on the local machine to "behind-the-scenes" handle client / server natively:
http://www.youtube.com/watch?v=EM56J1QRS-I
The other is through add-on modules which are plug-ins to VFrP which would allow these kinds of interfaces to be handled directly as an extension of the VFrP app itself, without the need for something like InDisk.
Best regards,
Rick C. Hodgin
|
|
A couple fixes. I've noticed myself making these particular states recently. Odd.
Quote:One thing I would like to add is more native integration between client/server and VFP's inernalinternal abilities.
I'd rather see that handled by a converter and allow native VFP code to be written, whenwhich then executes the commands on the server.
Best regards,
Rick C. Hodgin
|
|
I remembered another big one. It was the ability to edit any user class code used on any form in the traditional way (bringing up the code and changing it).
Such changes then propagate through all open instances of the class, and changes made to any of them are reflected in all of them in real-time.
This would allow a form to be opened which includes code from twelve separate user classes. Each of those classes could be altered, as well as native form code, from the one instance of the form. And if multiple instances of a class are in use, or if multiple forms are open and each form uses some of the same classes, changes made to any of the open form editor windows goes to all.
It's the way it should've been all along.
Best regards,
Rick C. Hodgin
|
|
Another big one was a "quit.force" option, which would remove the "Cannot Quit Visual FreePro" type messages.
It's all starting to come back to me.
Best regards,
Rick C. Hodgin
|
|
>Such changes then propagate through all open instances of the class, and changes made to any of them are reflected in all of them in real-time.
If I understand you correctly, that would alter parent classes? Or all equal instances of classes? In both cases I don't see this as good or wanted or elegant. If you want to override class behaviour, you can do at the last instance level in foxpro, eg at a control put on the class. If you want that change in all instances, you better change the class, not the instance. I would like that to stay that way, besides discouraging such things.
I agree what you said in the other threa, OOP can be an overhead for very small or even medium sized apps, but then you should build a set of classes (framework) over time, which pays very soom after the third or fourht project, even small ones. And this way of propagating code would only be welcome, if you can specify, whther you want that propagagion or want it to be a local change. Any such change propagation would resemble search&replace within copy&pasted code, which is not a good way of programming, is it?
Good reasons to propagate changes would be the change of a table field name or anything having a more or less public scope.
Bye, Olaf. |
|
Quote (Olaf)Quote (Rick)Such changes then propagate through all open instances of the class, and changes made to any of them are reflected in all of them in real-time.
If I understand you correctly, that would alter parent classes? Or all equal instances of classes?
Yes.
Quote (Olaf)In both cases I don't see this as good or wanted or elegant. If you want to override class behaviour, you can do at the last instance level in foxpro, eg at a control put on the class. If you want that change in all instances, you better change the class, not the instance. I would like that to stay that way, besides discouraging such things.
All overrides would still be in effect. What I'm proposing would save you doing this:
CODE(1) Open the form which has some user classes on it.
(2) Edit, in the process realize you need to change some parent class code.
(3) Close the form.
(4) Open the class.
(5) Edit.
(6) Close the class.
(7) Re-open the form.
(8) Continue editing the form.
In Visual FreePro, the sequence would be:
CODE(1) Open the fom which has some user classes on it.
(2) Edit, in the process relalize you need to change some parent class code.
(3) Change the parent class code.
(4) Continue editing the form.
The changes made to the parent would propagate through all open instances of the class, but all overrides would remain in effect.
Best regards,
Rick C. Hodgin
|
|
One other thing: I personally know Christof Wollenhaupt, the author of guineu: http://guineu.foxpert.com/. He only implements what he needs to make some smaller apps run on mobile platforms via this runtime, he also has little time to move forward, like you he stopped developing this, even though the latest release is from end of june. Anyway, he might be open for some idea and code exchange.
He also knows former developers of the former foxpro team at Microsoft, so he had a bit of insider info on the legal stuff. Like me Christof was an MVP, even much longer than me, up to the last year Microsoft gave that Award in that competence.
I can't say what's true about the xbase code, it sounds plausible, as Fox Software also reimplemented and extended dBase/Clipper, still I think one reson for Chrstof to stop promoting this and making it a product was the legal stuff, might just be some brands, he sure can tell you more.
You can contact him via the guineu homepage, or via foxpert, but I might personally make contact, if you like. We just met yesterday at our monthly meeting (regional microsoft developer roundtable, former foxpro roundtable).
Bye, Olaf. |
|
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
|
|
Quote (Rick)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
|
|
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. |
|
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.
CODEhttp://www.visual-freepro.org/
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
|
|
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 |
|
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:
CODETB - 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
|
|
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
|
|
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.
|
|
Quote (Olaf)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:
CODEUSE 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
|
|
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. |
|
Quote (Olaf)
He's certainly all ears!
Quote (Olaf)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
|
|
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?
|
|
Quote (Olaf)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.
Quote (Olaf)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
|
|
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
|
|
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
|
|
I'm confident you'll find something more recent. External drives? Some backup somewhere else in the cloud?
Bye, Olaf. |
|
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
|
|
Quote: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 |
|
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. |
|
|
 |
|
Talk To Other Members
Read More Threads Like This One