Drivers for Access to use should help you with your foxpro files I am guessing.
http://www.winbeta.org/news/dbase-file-support-comes-back-microsoft-access
dBase IV format. Useful for people without VFP to open them, and for Access users to connect and pull in data.
I thought it gave you the hooks to work from Excel to pull in dbf data. Or to call the standard dbo engine from any app and consume other M$ data. It was never intended as a VFP replacement, just an opener to data that is in dbf format.
On Thu, Sep 8, 2016 at 10:33 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
dBase IV format. Useful for people without VFP to open them, and for Access users to connect and pull in data.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
You can already do that in Excel through the VFP OLE DB driver.
Resurrect Visual Foxpro, please! Make it 64-bit at least! :)
On Thu, Sep 8, 2016 at 11:16 PM, Stephen Russell srussell705@gmail.com wrote:
Drivers for Access to use should help you with your foxpro files I am guessing.
On Sep 10, 2016, at 6:39 AM, Man-wai Chang changmw@gmail.com wrote:
Resurrect Visual Foxpro, please! Make it 64-bit at least! :)
Well, Paul McNett and I *tried* to do that when we created Dabo, which does pretty much everything that VFP does, but with an open license and a future path forward. It did require learning Python instead of Xbase, but other than that, it had data binding, support for multiple backends (even a DBF backend, if someone had maintained it). It's been production-ready for over a decade.
Very few people were willing to make the effort to move to Dabo. Sure, you couldn't directly port a VFP app to Dabo, but new development work doesn't have that problem. It really seems that people are much more willing to invest in a product with no future from its owner than to invest in a product with a future. It's like people who lived on the coast who have been flooded as sea levels rose: instead of moving to higher ground, they keep propping themselves above the waterline and praying for a miracle.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature ---
True, but change is painful or at least it seems like it would be painful.
I, like some others on this list started with Fox back in the 1980's and like some others on this list, I hope god will deliver a miracle and save us. I haven't prayed yet. Maybe that would help?
Note that VFP9 SP2 works great with Win10, even with only 2gb memory - even better than on Win7,8,8.1.
On 9/10/2016 8:46 AM, Edward Leafe wrote:
On Sep 10, 2016, at 6:39 AM, Man-wai Chang changmw@gmail.com wrote:
Resurrect Visual Foxpro, please! Make it 64-bit at least! :)
Well, Paul McNett and I *tried* to do that when we created Dabo, which does pretty much everything that VFP does, but with an open license and a future path forward. It did require learning Python instead of Xbase, but other than that, it had data binding, support for multiple backends (even a DBF backend, if someone had maintained it). It's been production-ready for over a decade.
Very few people were willing to make the effort to move to Dabo. Sure, you couldn't directly port a VFP app to Dabo, but new development work doesn't have that problem. It really seems that people are much more willing to invest in a product with no future from its owner than to invest in a product with a future. It's like people who lived on the coast who have been flooded as sea levels rose: instead of moving to higher ground, they keep propping themselves above the waterline and praying for a miracle.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature
[excessive quoting removed by server]
V1.02 was first for me. Been with it ever since.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken McGinnis Sent: Sunday, 11 September 2016 6:08 AM To: profoxtech@leafe.com Subject: Re: M$ giving more support to dbf?
True, but change is painful or at least it seems like it would be painful.
I, like some others on this list started with Fox back in the 1980's and like some others on this list, I hope god will deliver a miracle and save us. I haven't prayed yet. Maybe that would help?
Note that VFP9 SP2 works great with Win10, even with only 2gb memory - even better than on Win7,8,8.1.
On 9/10/2016 8:46 AM, Edward Leafe wrote:
On Sep 10, 2016, at 6:39 AM, Man-wai Chang changmw@gmail.com wrote:
Resurrect Visual Foxpro, please! Make it 64-bit at least! :)
Well, Paul McNett and I *tried* to do that when we created Dabo, which
does pretty much everything that VFP does, but with an open license and a future path forward. It did require learning Python instead of Xbase, but other than that, it had data binding, support for multiple backends (even a DBF backend, if someone had maintained it). It's been production-ready for over a decade.
Very few people were willing to make the effort to move to Dabo. Sure, you
couldn't directly port a VFP app to Dabo, but new development work doesn't have that problem. It really seems that people are much more willing to invest in a product with no future from its owner than to invest in a product with a future. It's like people who lived on the coast who have been flooded as sea levels rose: instead of moving to higher ground, they keep propping themselves above the waterline and praying for a miracle.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature
[excessive quoting removed by server]
haven't looked at Dabo, but doesn't Python mean web based apps? Can it do desktop?
Laurie
On 10 September 2016 at 22:45, Darren foxdev@ozemail.com.au wrote:
V1.02 was first for me. Been with it ever since.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken McGinnis Sent: Sunday, 11 September 2016 6:08 AM To: profoxtech@leafe.com Subject: Re: M$ giving more support to dbf?
True, but change is painful or at least it seems like it would be painful.
I, like some others on this list started with Fox back in the 1980's and like some others on this list, I hope god will deliver a miracle and save us. I haven't prayed yet. Maybe that would help?
Note that VFP9 SP2 works great with Win10, even with only 2gb memory - even better than on Win7,8,8.1.
On 9/10/2016 8:46 AM, Edward Leafe wrote:
On Sep 10, 2016, at 6:39 AM, Man-wai Chang changmw@gmail.com wrote:
Resurrect Visual Foxpro, please! Make it 64-bit at least! :)
Well, Paul McNett and I *tried* to do that when we created Dabo, which
does pretty much everything that VFP does, but with an open license and a future path forward. It did require learning Python instead of Xbase, but other than that, it had data binding, support for multiple backends (even a DBF backend, if someone had maintained it). It's been production-ready for over a decade.
Very few people were willing to make the effort to move to Dabo. Sure,
you couldn't directly port a VFP app to Dabo, but new development work doesn't have that problem. It really seems that people are much more willing to invest in a product with no future from its owner than to invest in a product with a future. It's like people who lived on the coast who have been flooded as sea levels rose: instead of moving to higher ground, they keep propping themselves above the waterline and praying for a miracle.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature
[excessive quoting removed by server]
On Sat, Sep 10, 2016 at 9:12 PM, Laurie Alvey trukker41@gmail.com wrote:
haven't looked at Dabo, but doesn't Python mean web based apps? Can it do desktop?
Take two minutes to skim http://www.dabodev.com/
Ted,
That is interesting. I can see where Dabo would be able to replace VFP. For many years I have used some DBI ocx controls for scheduling, and a few other functions. I like the way that DBI works and I was not able to make VFP code that would do the same things as nicely as DBI does it. Is there something like that for python? Maybe the DBI controls would work with python?
On 9/11/2016 7:56 AM, Ted Roche wrote:
On Sat, Sep 10, 2016 at 9:12 PM, Laurie Alvey trukker41@gmail.com wrote:
haven't looked at Dabo, but doesn't Python mean web based apps? Can it do desktop?
Take two minutes to skim http://www.dabodev.com/
[excessive quoting removed by server]
On Mon, 12 Sep 2016, at 12:29 AM, Ken McGinnis wrote:
Is there something like that for python? Maybe the DBI controls would work with python?
Controls like that can be leveraged by creating a Python wrapper for them and PyWin32, then tying you into the Windows platform of course. Is there something like that for Python? Python is a general purpose, cross-platform language that doesn't have its own native UI. So you bolt on a UI toolkit like PyQt or something, and the question then becomes whether there is a calendar\schedule for your chosen toolkit. For PyQt there would be for example:
http://pyqt.sourceforge.net/Docs/PyQt4/qcalendarwidget.html#details
On Sun, 11 Sep 2016, at 02:12 AM, Laurie Alvey wrote:
haven't looked at Dabo, but doesn't Python mean web based apps? Can it do desktop?
Laurie
Yes, Python, like Ruby, is fairly synonymous with web applications. However that was one of the goals of Dabo - to create a desktop application framework using Python.
On Sun, Sep 11, 2016 at 12:46 AM, Edward Leafe ed@leafe.com wrote:
Well, Paul McNett and I *tried* to do that when we created Dabo, which does pretty much everything that VFP does, but with an open license and a future path forward. It did require learning Python instead of Xbase, but other than that, it had data binding, support for multiple backends (even a DBF backend, if someone had maintained it). It's been production-ready for over a decade.
Dabo is NOT resurrecting Visual Foxpro. It's building something similar to replace it. Dabo is competing with Visual C#, Visual Basic.Net and alike. Then Dabo must prove itself to be a real VFP replacement in *ALL* aspects.
When I said "resurrecting Visual Foxpro", I was referring the one and only Visual Foxpro owned by Micro$oft. :)
Very few people were willing to make the effort to move to Dabo. Sure, you couldn't directly port a VFP app to Dabo, but new development work doesn't have that problem. It really seems that people are much more willing to invest in a product with no future from its owner than to invest in a product with a future. It's like people who lived on the coast who have been flooded as sea levels rose: instead of moving to higher ground, they keep propping themselves above the waterline and praying for a miracle.
If Dabo offered a tool to convert Visual Foxpro projects.... there was never a 100% conversion tool that really does it.
BTW, have your team ever considered to write a conversion tool that translates *ALL* VFP codes into Python, including its Report Writer?
Why would you want to be limited to another desktop form based UI is my only question.
On Mon, Sep 12, 2016 at 7:05 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
BTW, have your team ever considered to write a conversion tool that translates *ALL* VFP codes into Python, including its Report Writer?
Kind of a big ask.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On Mon, 12 Sep 2016, at 02:26 PM, Stephen Russell wrote:
Why would you want to be limited to another desktop form based UI is my only question.
That's the thing. If you were starting 'Visual FoxPro' today you would have to end up something designed to operate with various types of presentation layer, and any type of database through a data layer.
On Mon, Sep 12, 2016 at 9:33 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
On Mon, 12 Sep 2016, at 02:26 PM, Stephen Russell wrote:
Why would you want to be limited to another desktop form based UI is my only question.
That's the thing. If you were starting 'Visual FoxPro' today you would have to end up something designed to operate with various types of presentation layer, and any type of database through a data layer.
So, perhaps a console ("command line") interface for quick-and-easy scripting, an ability to use a variety of desktop widget packages, like wxWidgets, GTK, etc., the ability to plug into popular web servers like Apache and nginx, and ports to new up-and-coming hardware platforms like IOS and Android and Raspberry Pi? Compatibility with common OS platforms of Linux, OSX and Windows, of course,...
Python sounds like a good choice. Or JavaScript, Perl, Erlang, Ruby, Haskell, or PHP.
It's hard to imagine there's a market niche left untapped.
Though I still think the form- and report-designer UI tied into the project generation of VFP was pretty compelling. And the re-entrant app generation of our 3rd-party frameworks like FoxExpress for round-tripping is a high bar that's rarely reached.
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
On Mon, 12 Sep 2016, at 03:40 PM, Ted Roche wrote:
So, perhaps a console ("command line") interface for quick-and-easy scripting, an ability to use a variety of desktop widget packages, like wxWidgets, GTK, etc., the ability to plug into popular web servers like Apache and nginx, and ports to new up-and-coming hardware platforms like IOS and Android and Raspberry Pi? Compatibility with common OS platforms of Linux, OSX and Windows, of course,...
This is what I wish the Lianja guys would do. They have a proven engine there (Recital as was) which is 64-bit, proven, cross-platform, database-agnostic and supports most of the non-legacy Visual FoxPro syntax that isn't concerned with UI, and then adds a lot of new commands into the bargain. However it's tied into their IDE and application framework and licencing model.
On Sep 12, 2016, at 6:40 AM, Man-wai Chang changmw@gmail.com wrote:
Well, Paul McNett and I *tried* to do that when we created Dabo, which does pretty much everything that VFP does, but with an open license and a future path forward. It did require learning Python instead of Xbase, but other than that, it had data binding, support for multiple backends (even a DBF backend, if someone had maintained it). It's been production-ready for over a decade.
Dabo is NOT resurrecting Visual Foxpro. It's building something similar to replace it. Dabo is competing with Visual C#, Visual Basic.Net and alike. Then Dabo must prove itself to be a real VFP replacement in *ALL* aspects.
Seriously? And do you want that on a silver platter?
When I said "resurrecting Visual Foxpro", I was referring the one and only Visual Foxpro owned by Micro$oft. :)
The final step in grieving over death is to accept it and move on. Resurrection is the stuff of myths, not reality.
Very few people were willing to make the effort to move to Dabo. Sure, you couldn't directly port a VFP app to Dabo, but new development work doesn't have that problem. It really seems that people are much more willing to invest in a product with no future from its owner than to invest in a product with a future. It's like people who lived on the coast who have been flooded as sea levels rose: instead of moving to higher ground, they keep propping themselves above the waterline and praying for a miracle.
If Dabo offered a tool to convert Visual Foxpro projects.... there was never a 100% conversion tool that really does it.
There was never a 100% conversion tool for moving from Fox 2.x to VFP, but people made that move anyway. Anyone who tried to do conversions quickly realized that the converted apps sucked, and were impossible to maintain. It was much smarter to realize that VFP was a new tool that did things differently, and that only by coding your app to match the tool would you ever get the results that VFP offered.
BTW, have your team ever considered to write a conversion tool that translates *ALL* VFP codes into Python, including its Report Writer?
Sure, we did, and after a couple of quick attempts, decided that it wasn’t worth it. We have a visual report writer, a visual class designer, and lots more. The thing is, we started this in 2004, and very few people made the move. So when I Paul and I took jobs that didn’t use Dabo (but paid the bills), it got put in a holding pattern. There hasn’t been much new development in Dabo for the last 5 years or so.
Unlike VFP, though, the source code is 100% freely available at https://github.com/dabodev. And I mean free in both senses: no cost, and you are free to modify it to your heart’s content. You could even write a VFP conversion tool!
-- Ed Leafe
On Tue, Sep 13, 2016 at 12:21 AM, Ed Leafe ed@leafe.com wrote:
When I said "resurrecting Visual Foxpro", I was referring the one and only Visual Foxpro owned by Micro$oft. :)
The final step in grieving over death is to accept it and move on. Resurrection is the stuff of myths, not reality.
That's why I am still wishing for a miracle! ;)
If Micro$oft hadn't lost the source codes of Visual Foxpro, It should always be easy and possible to resurrect it!
There was never a 100% conversion tool for moving from Fox 2.x to VFP, but people made that move anyway. Anyone who tried to do conversions quickly realized that the converted apps sucked, and were impossible to maintain. It was much smarter to realize that VFP was a new tool that did things differently, and that only by coding your app to match the tool would you ever get the results that VFP offered. .... Sure, we did, and after a couple of quick attempts, decided that it wasn’t worth it. We have a visual report writer, a visual class designer, and lots more. The thing is, we started this in 2004, and very few people made the move. So when I Paul and I took jobs that didn’t use Dabo (but paid the bills), it got put in a holding pattern. There hasn’t been much new development in Dabo for the last 5 years or so.
Unlike VFP, though, the source code is 100% freely available at https://github.com/dabodev. And I mean free in both senses: no cost, and you are free to modify it to your heart’s content. You could even write a VFP conversion tool!
If Dabo could break the ice.... a 100% converter.... meow! Maybe this dream needs another miracle....
Work and creativity usually do more than miracles... Chen has released a 64-bit VFP compiler (http://www.baiyujia.com/vfpcompiler/), and many other 3rd party softwares dramatically extend VFP's scope compared to what it was 10 years ago.
Thierry Nivelet http://foxincloud.com/ Give your VFP app a second life in the cloud
Le 13 sept. 2016 à 04:57, Man-wai Chang changmw@gmail.com a écrit :
On Tue, Sep 13, 2016 at 12:21 AM, Ed Leafe ed@leafe.com wrote:
When I said "resurrecting Visual Foxpro", I was referring the one and only Visual Foxpro owned by Micro$oft. :)
The final step in grieving over death is to accept it and move on. Resurrection is the stuff of myths, not reality.
That's why I am still wishing for a miracle! ;)
If Micro$oft hadn't lost the source codes of Visual Foxpro, It should always be easy and possible to resurrect it!
There was never a 100% conversion tool for moving from Fox 2.x to VFP, but people made that move anyway. Anyone who tried to do conversions quickly realized that the converted apps sucked, and were impossible to maintain. It was much smarter to realize that VFP was a new tool that did things differently, and that only by coding your app to match the tool would you ever get the results that VFP offered. .... Sure, we did, and after a couple of quick attempts, decided that it wasn’t worth it. We have a visual report writer, a visual class designer, and lots more. The thing is, we started this in 2004, and very few people made the move. So when I Paul and I took jobs that didn’t use Dabo (but paid the bills), it got put in a holding pattern. There hasn’t been much new development in Dabo for the last 5 years or so.
Unlike VFP, though, the source code is 100% freely available at https://github.com/dabodev. And I mean free in both senses: no cost, and you are free to modify it to your heart’s content. You could even write a VFP conversion tool!
If Dabo could break the ice.... a 100% converter.... meow! Maybe this dream needs another miracle....
-- .~. Might, Courage, Vision. SINCERITY! / v \ 64-bit Ubuntu 9.10 (Linux kernel 2.6.39.3) /( _ )\ http://sites.google.com/site/changmw ^ ^ May the Force and farces be with you!
[excessive quoting removed by server]
On Sep 13, 2016, at 12:36 AM, Thierry Nivelet tnivelet@foxincloud.com wrote:
Work and creativity usually do more than miracles...
+1000
The common response in the open source world when someone complains that their project doesn’t do Feature Foo, is “patches welcome!”. That’s a snarky way of saying “if you want something done, start contributing and others will join in”.
As one of the primary developers of Dabo, I’m not going to invest hundreds of hours of my time to add a complex feature I personally don’t need if the people who want it so badly aren’t willing to pitch in and help.
-- Ed Leafe
The simplest solution is still resurrecting Visual Foxpro. Micro$oft has its source codes. Market shares of VFP has nothing to do with maintaining an old but popular tool.
Of course, abandoning VFP could force everyone to buy new developments from Micro$oft and hire new programmers.
Sometimes, I think the death of VFP was not just a normal product cycle but a political if not military tool for affect other countries. Micro$oft and US Government clearly knew the consequences. :)
On Tue, Sep 13, 2016 at 1:36 PM, Thierry Nivelet tnivelet@foxincloud.com wrote:
Work and creativity usually do more than miracles... Chen has released a 64-bit VFP compiler (http://www.baiyujia.com/vfpcompiler/), and many other 3rd party softwares dramatically extend VFP's scope compared to what it was 10 years ago.
I think the death of VFP was not just a normal product cycle but a political if not military tool for affect other countries. Micro$oft and US Government clearly knew the consequences. :)
I really think that's tinfoil hat territory. It didn't fit in with the .NET world and SQL Server and the general Microsoft roadmap at the time, so it got canned. No need to overthink it.
Bingo.
When your truck has 250,000 miles on it you consider getting a replacement and enjoying the new features instead of yanking the engine and rebuilding it before it has an internal problem.
VFP did it's thing and it was a purchased entity not grown in house by M$.
This is business not family. Having developers expand their capabilities and leverage the web in the 2000s was the desire. .NET was the vehicle by m$ vs java and php.
Today it is all javascript, html5 and uber cool frameworks to get it done today.
On Wed, Sep 14, 2016 at 7:39 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
I think the death of VFP was not just a normal product cycle but a political if not military tool for affect other countries. Micro$oft and US Government clearly knew the consequences. :)
I really think that's tinfoil hat territory. It didn't fit in with the .NET world and SQL Server and the general Microsoft roadmap at the time, so it got canned. No need to overthink it.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On Wed, Sep 14, 2016 at 9:52 PM, Stephen Russell srussell705@gmail.com wrote:
This is business not family. Having developers expand their capabilities and leverage the web in the 2000s was the desire. .NET was the vehicle by m$ vs java and php. Today it is all javascript, html5 and uber cool frameworks to get it done today.
POS systems don't usuaslly require web access, especially for small shops. Standalone applicaiton still has its place in this time-space continuum.
Anyway, we need a miracle... :)
On 2016-09-14 07:47, Man-wai Chang wrote:
The simplest solution is still resurrecting Visual Foxpro. Micro$oft has its source codes. Market shares of VFP has nothing to do with maintaining an old but popular tool.
Of course, abandoning VFP could force everyone to buy new developments from Micro$oft and hire new programmers.
Sometimes, I think the death of VFP was not just a normal product cycle but a political if not military tool for affect other countries. Micro$oft and US Government clearly knew the consequences. :)
Sometimes I see stuff like this and wonder if it's a post from 10+ years ago.
Old habits die hard Mike!
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: 15 September 2016 23:10 To: ProFox Email List profox@leafe.com Subject: Re: M$ giving more support to dbf?
On 2016-09-14 07:47, Man-wai Chang wrote:
The simplest solution is still resurrecting Visual Foxpro. Micro$oft has its source codes. Market shares of VFP has nothing to do with maintaining an old but popular tool.
Of course, abandoning VFP could force everyone to buy new developments from Micro$oft and hire new programmers.
Sometimes, I think the death of VFP was not just a normal product cycle but a political if not military tool for affect other countries. Micro$oft and US Government clearly knew the consequences. :)
Sometimes I see stuff like this and wonder if it's a post from 10+ years ago.
[excessive quoting removed by server]
Wrong!! Did you lose your old combat skill? :)
On Fri, Sep 16, 2016 at 3:34 PM, Dave Crozier DaveC@flexipol.co.uk wrote:
Old habits die hard Mike!
Dave
You talking about wars and peace-time conflicts? They never end. :)
Keeping VFP alive without adding new features is a simple task. But Micro$oft and possibly US Government chose the Dark Side.
On Fri, Sep 16, 2016 at 6:09 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Sometimes I see stuff like this and wonder if it's a post from 10+ years ago.
On 2016-09-16 08:31, Man-wai Chang wrote:
You talking about wars and peace-time conflicts? They never end. :)
Keeping VFP alive without adding new features is a simple task. But Micro$oft and possibly US Government chose the Dark Side.
Actually I'd wager the US Govt--if anything--had a hand in keeping it from behind totally taken off the table LONG ago. You may recall that several speculated that the govt had LOTS of Foxpro stuff and they didn't want M$ to drop all support and/or do anything to prevent the legacy stuff from working. (DR-DOS anyone?)
On Wed, 21 Sep 2016, at 03:01 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
(DR-DOS anyone?)
What, DR-DOS where the pre-release version of Windows 3.1 wouldn't run on it (or any other non MS-DOS) but the check was disabled in the release version of Windows 3.1 ?
Nah, I'll take FreeDOS, thanks.
https://opensource.com/life/16/9/interview-jim-hall-freedos
On Wed, Sep 21, 2016 at 10:19 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
On Wed, 21 Sep 2016, at 03:01 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
(DR-DOS anyone?)
What, DR-DOS where the pre-release version of Windows 3.1 wouldn't run on it (or any other non MS-DOS) but the check was disabled in the release version of Windows 3.1 ?
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On Wed, Sep 21, 2016 at 10:01 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2016-09-16 08:31, Man-wai Chang wrote:
Actually I'd wager the US Govt--if anything--had a hand in keeping it from behind totally taken off the table LONG ago. You may recall that several speculated that the govt had LOTS of Foxpro stuff and they didn't want M$ to drop all support and/or do anything to prevent the legacy stuff from working. (DR-DOS anyone?)
You got an insider in US Government that is dealing with all Foxpro projects? :)
Hey all,
FWIW, while I think all this conspiracy stuff is just that, I do have to point out that the US military has specific requirements which make no sense to me. One of them states that if a software (or many other) product is specified in a contract, it cannot be changed for any reason without some tedious process being followed.
I have a client that is a major defense contractor and they occasionally call me in to help with some of their apps that were written in VFP. Not only can they not move to a new app, they can't even have me re-write it in something else even if the new app did the exact same thing with the exact same interface.
Even worse, when they found out that an in house developed tool was being used by 2 different project teams, they required that a totally separate set of source code be kept for each project team and changes made for one team could NOT be applied to the other project teams source code. And if the other project team needed the same feature, it had to be written again using that teams source code.
So yeah, I could actually see there being someone in the government pressuring MS to not obsolete VFP. But do I really think it happened? It sounds too intelligent for me to believe.
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson beknown.com/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Man-wai Chang Sent: Thursday, September 22, 2016 4:48 AM To: ProFox Email List Subject: Re: M$ giving more support to dbf?
On Wed, Sep 21, 2016 at 10:01 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2016-09-16 08:31, Man-wai Chang wrote:
Actually I'd wager the US Govt--if anything--had a hand in keeping it from behind totally taken off the table LONG ago. You may recall that several speculated that the govt had LOTS of Foxpro stuff and they didn't want M$ to drop all support and/or do anything to prevent the legacy stuff from working. (DR-DOS anyone?)
You got an insider in US Government that is dealing with all Foxpro projects? :)
-- .~. Might, Courage, Vision. SINCERITY! / v \ 64-bit Ubuntu 9.10 (Linux kernel 2.6.39.3) /( _ )\ http://sites.google.com/site/changmw ^ ^ May the Force and farces be with you!
[excessive quoting removed by server]
On Mon, Sep 12, 2016 at 9:57 PM, Man-wai Chang changmw@gmail.com wrote:
On Tue, Sep 13, 2016 at 12:21 AM, Ed Leafe ed@leafe.com wrote:
When I said "resurrecting Visual Foxpro", I was referring the one and only Visual Foxpro owned by Micro$oft. :)
The final step in grieving over death is to accept it and move on.
Resurrection is the stuff of myths, not reality.
That's why I am still wishing for a miracle! ;)
If Micro$oft hadn't lost the source codes of Visual Foxpro, It should always be easy and possible to resurrect it!
I don't think that the core of the OS is today what was around when they were making VFP. There is a 2 gig limit for a reason and that is no longer a property of the filesystem.
On Tue, Sep 13, 2016 at 9:22 AM, Stephen Russell srussell705@gmail.com wrote:
I don't think that the core of the OS is today what was around when they were making VFP.
Nonsense. No matter how much lipstick they slap on the pig, this is still Windows NT at its core.
There is a 2 gig limit for a reason and that is no longer a property of the filesystem.
Of course not. That was a VFP choice to limit file offsets to a single 32-bit int.
On 2016-09-13 09:49, Ted Roche wrote:
On Tue, Sep 13, 2016 at 9:22 AM, Stephen Russell srussell705@gmail.com wrote:
I don't think that the core of the OS is today what was around when they were making VFP.
Nonsense. No matter how much lipstick they slap on the pig, this is still Windows NT at its core.
There is a 2 gig limit for a reason and that is no longer a property of the filesystem.
Of course not. That was a VFP choice to limit file offsets to a single 32-bit int.
...which I might add that using vfp2c32.fll (on VFPX), you can get past the 2GB barrier (in terms of reading text files anyway). https://vfpx.codeplex.com/wikipage?title=VFP2C32&referringTitle=Home
-
Alan Bourke -
Darren -
Dave Crozier -
Ed Leafe -
Edward Leafe
-
Fletcher Johnson -
Ken McGinnis -
Laurie Alvey -
Man-wai Chang -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Stephen Russell -
Ted Roche -
Thierry Nivelet