It's not just "invisible apps", it's Microsoft Access apps and Excel spreadmarts. Any company worth >$10m, nah every company worth >$10m has a dozen or so Access-based reports that a CEO uses and several directories of Excel workbooks with projections/equations.
Maybe it would have made more sense for IBM to first figure out where these renegade apps are, get them all to a Metaframe farm, then introduce Linux on the desktop (since the Citrix Java client works well), then look at migrating any apps back from Metaframe if needed.
Something else that would help is converting desktop apps to the.NET Framework WinForms along with GTK# and WxWidgets, they would/could port to Mono in the future.
I think DiversiDOS was the fastest when it came to BLOADing but for BASIC I think Beagle Bros ProntoDOS was the fastest.
Wait a minute. Now that I remember a little more, the fastest was FranklinDOS v?.? They scrapped some Apple ][ compatibility in exchange for e-x-t-r-e-m-e speed, stuff that smoked even DiversiDOS, but there was one incompatible DOS command that would make FDOS do a disk format....
I still have an original Apple II Red Book. The one Woz's handwriting on some of the pages where he had already printed the assembler code but needed to make edits.
You could do simple X10 stuff. Control the lights or temperature or something.
You could do modem-voice stuff. Get an echo sound card and a modem that can do Caller ID (or do something in software with SAM or a IIGS). When the number comes in have the ][ speak the number or do a data lookup and say the name.
Play audio CD's.
Play a game.
Oh, with the IIGS you can run GNO/ME and get into some BSD-style antics.
My first was a Franklin Ace 1000, then a 2200, then a Laser 128, then a Laser128/EX, then a IIGS then several of the above. Now I'm down to a single Franklin Ace 500 hidden at my brother's house so my wife doesn't throw it out.
1 accumulator
1 X register
1 Y register
Memory usage flowed "up" from zero to the graphics area
Coding in 6502 assembly showed *skill*, you young bucks know nothing about it.
Microsoft likes to make money. So they keep the best VFP people around to update the product to fill its niches (fast scalable local ISAM). There are probably what, 20 people in the whole group? But there are thousands on thousands of folks that buy the latest version each time, I think the VFP group is one of if not the most profitable at Microsoft.
One of the problems at MS is that they own VFP, and killing it means (hundreds of?) millions of dollars lost. They can't sell it off either; they don't want a local database engine that smokes Access/MSDE in the hands of a competitor. Just killing the product means some folks will move to other MS products and others will go elsewhere, again dollars lost.
So running VFP on a Linix is kind of an issue because VFP's free executable distribution clause means the client community can get a strong, lightweight data-centric solution without paying a dime in purchase cost.
As far as the (V)FP community is concerned, developers that are buying it are not using it like they should. With VFP 8, you get a new CursorAdapter class, a new XmlAdapter class, even-easier-than-easy web service tools, and more. And the data engine is still faster than everything else when it comes to local data access (as long as each table is less than 2gb).
However, I bet that the community that should be using all this new stuff is maintaining (or creating new) spaghetti crap that gives "FoxPro" a bad name. Visual FoxPro isn't FoxPro any more than Visual Basic is BASIC. The (V)FP community is the problem and the solution at the same time. One of the problems with the product is that it's so easy to create a solution that won't break (but at the same time can't be maintained), that there are a ton of apps out there running businesses that see no reason to change.
At any rate, without having looked at VFP-on-WINE performance myself, I would believe that a VFP data solution smokes one wrapped around MySql.....
Slashdot Mirror
It's not just "invisible apps", it's Microsoft Access apps and Excel spreadmarts. Any company worth >$10m, nah every company worth >$10m has a dozen or so Access-based reports that a CEO uses and several directories of Excel workbooks with projections/equations.
.NET Framework WinForms along with GTK# and WxWidgets, they would/could port to Mono in the future.
Maybe it would have made more sense for IBM to first figure out where these renegade apps are, get them all to a Metaframe farm, then introduce Linux on the desktop (since the Citrix Java client works well), then look at migrating any apps back from Metaframe if needed.
Something else that would help is converting desktop apps to the
I think the disk was called "9 Different DOSes"
I think DiversiDOS was the fastest when it came to BLOADing but for BASIC I think Beagle Bros ProntoDOS was the fastest.
Wait a minute. Now that I remember a little more, the fastest was FranklinDOS v?.? They scrapped some Apple ][ compatibility in exchange for e-x-t-r-e-m-e speed, stuff that smoked even DiversiDOS, but there was one incompatible DOS command that would make FDOS do a disk format....
Wow, how did I ever remember that stuff?
Can you throw out a URI or 2 on where you got those statistics? They are interesting.
I still have an original Apple II Red Book. The one Woz's handwriting on some of the pages where he had already printed the assembler code but needed to make edits.
You could do simple X10 stuff. Control the lights or temperature or something.
You could do modem-voice stuff. Get an echo sound card and a modem that can do Caller ID (or do something in software with SAM or a IIGS). When the number comes in have the ][ speak the number or do a data lookup and say the name.
Play audio CD's.
Play a game.
Oh, with the IIGS you can run GNO/ME and get into some BSD-style antics.
My first was a Franklin Ace 1000, then a 2200, then a Laser 128, then a Laser128/EX, then a IIGS then several of the above. Now I'm down to a single Franklin Ace 500 hidden at my brother's house so my wife doesn't throw it out.
1 accumulator 1 X register 1 Y register Memory usage flowed "up" from zero to the graphics area Coding in 6502 assembly showed *skill*, you young bucks know nothing about it.
Microsoft likes to make money. So they keep the best VFP people around to update the product to fill its niches (fast scalable local ISAM). There are probably what, 20 people in the whole group? But there are thousands on thousands of folks that buy the latest version each time, I think the VFP group is one of if not the most profitable at Microsoft.
One of the problems at MS is that they own VFP, and killing it means (hundreds of?) millions of dollars lost. They can't sell it off either; they don't want a local database engine that smokes Access/MSDE in the hands of a competitor. Just killing the product means some folks will move to other MS products and others will go elsewhere, again dollars lost.
So running VFP on a Linix is kind of an issue because VFP's free executable distribution clause means the client community can get a strong, lightweight data-centric solution without paying a dime in purchase cost.
As far as the (V)FP community is concerned, developers that are buying it are not using it like they should. With VFP 8, you get a new CursorAdapter class, a new XmlAdapter class, even-easier-than-easy web service tools, and more. And the data engine is still faster than everything else when it comes to local data access (as long as each table is less than 2gb).
However, I bet that the community that should be using all this new stuff is maintaining (or creating new) spaghetti crap that gives "FoxPro" a bad name. Visual FoxPro isn't FoxPro any more than Visual Basic is BASIC. The (V)FP community is the problem and the solution at the same time. One of the problems with the product is that it's so easy to create a solution that won't break (but at the same time can't be maintained), that there are a ton of apps out there running businesses that see no reason to change.
At any rate, without having looked at VFP-on-WINE performance myself, I would believe that a VFP data solution smokes one wrapped around MySql.....