Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Crossover Impersonator 2
- Thread starter Auguy
- Start date
TamarGranor
Programmer
More compatible with what than others?
My view is that, unless there's a really good reason, VFP development should be done in VFP9 SP2.
Tamar
My view is that, unless there's a really good reason, VFP development should be done in VFP9 SP2.
Tamar
- Thread starter
- #3
I have a request from a client to tun an old FoxPro app on their ipad. I found the Crossover Impersonator web page and read that various versons of FoxPro will run but have some problems. I'm trying to find what problems or work arounds others may have encountered with Crossover Impersonator. The current app is written in 6.0. The easiest thing for me to do would be to update it to 9 and use the Crossover Impersonator to run on the ipad, but if there are going to be real issues then I will have to convert the program to something compatible with the ipad.
Auguy
Sylvania/Toledo Ohio
Auguy
Sylvania/Toledo Ohio
-
1
- #4
Olaf Doschke
Programmer
Skip Crossover, what's truely emulating a pc and running any os even on the ipad is parallels:
Via that you run windows and any windows software with no compatibility issues at all.
Bye, Olaf.
Via that you run windows and any windows software with no compatibility issues at all.
Bye, Olaf.
-
1
- #5
Dan Freeman
Programmer
And, short of Parallels, use Jaadu RDP on the iPad and run the app on a Windows terminal server. (Not your best choice with VFP6, granted.)
- Thread starter
- #6
Thanks Olaf & Dan. I tried to talk them into remoting into the pc in their office, but they are worried agout lag time, etc. I don't have much experience in this area but thought it wasn't that big of a deal with today's internet/wifi connections. I would appreciate anybody's input that have experience with this type of situation.
Auguy
Sylvania/Toledo Ohio
Auguy
Sylvania/Toledo Ohio
Olaf Doschke
Programmer
Depends much on the bandwidth.
Wifi can be faster than UMTS or HSDPA, if the connection compares to LAN bandwidth and indeed is inohouse you can use the ipads comparable to any normal client pc of the lan via paralells.
If the wifi connection is comparable fast, but the ipad is in the private LAN of users, not the company lan, the limiting bandwidth would be the internet connection between private wifi and company lan.
A real installation on the ipad with parallels can offer a better experience in the situations the bandwidth is low. But you would then also need to take care of data transportation to and from the ipads.
If the ipads need acccess to your central server data during the use of the application you are much better off with a remoting solution. Sending screen graphics and mouse moves and keyboard usage back and forth is possible with a low bandwidth. It will get less repsonsive, and have a lag time, the lower the bandwidth of the connection is, but it would even be worse with data access through a low bandwidth.
Only if you can both install application and data locally on the ipad it would profit from not remoting in smooth usage like on any client. For that you at least need to add the capability to check in and out data from the central database to a local database on the ipad.
It's much easier to first try a remoting solution and then decide to go for parallels or something similar and add a data exchange between ipad and central database if the remoting turns out to be too slow.
Bye, Olaf.
Wifi can be faster than UMTS or HSDPA, if the connection compares to LAN bandwidth and indeed is inohouse you can use the ipads comparable to any normal client pc of the lan via paralells.
If the wifi connection is comparable fast, but the ipad is in the private LAN of users, not the company lan, the limiting bandwidth would be the internet connection between private wifi and company lan.
A real installation on the ipad with parallels can offer a better experience in the situations the bandwidth is low. But you would then also need to take care of data transportation to and from the ipads.
If the ipads need acccess to your central server data during the use of the application you are much better off with a remoting solution. Sending screen graphics and mouse moves and keyboard usage back and forth is possible with a low bandwidth. It will get less repsonsive, and have a lag time, the lower the bandwidth of the connection is, but it would even be worse with data access through a low bandwidth.
Only if you can both install application and data locally on the ipad it would profit from not remoting in smooth usage like on any client. For that you at least need to add the capability to check in and out data from the central database to a local database on the ipad.
It's much easier to first try a remoting solution and then decide to go for parallels or something similar and add a data exchange between ipad and central database if the remoting turns out to be too slow.
Bye, Olaf.
Dan Freeman
Programmer
So they're willing to trade compatibility issues for potential comfort issues? <g>
People use RDP all the time, every day, without problems. But why not set up a test? You don't even need an iPad for that. Any Windows client using RDP to any other Windows machine will work the same way.
People use RDP all the time, every day, without problems. But why not set up a test? You don't even need an iPad for that. Any Windows client using RDP to any other Windows machine will work the same way.
- Thread starter
- #9
Olaf Doschke
Programmer
Be sure you test with the newest available RDP / RDC versions.
There can be huge differences in lag time and responsiveness between the different versions used and third party tools may also be better. So if a first test is successful it's good, if it fails it's still not saying remoteing the desktop is a bad solution.
For example RDP does send GDI plus graphic commands to clients instead of the drawn graphics, which is much faster drawing the gui at the client side. That is, if the application draws it's forms via GDI. VFP6 does not draw it's forms with GDI though. Therefor porting to VFP9 simply by compiling in VFP9 could enhance the remoting speed.
Bye, Olaf.
There can be huge differences in lag time and responsiveness between the different versions used and third party tools may also be better. So if a first test is successful it's good, if it fails it's still not saying remoteing the desktop is a bad solution.
For example RDP does send GDI plus graphic commands to clients instead of the drawn graphics, which is much faster drawing the gui at the client side. That is, if the application draws it's forms via GDI. VFP6 does not draw it's forms with GDI though. Therefor porting to VFP9 simply by compiling in VFP9 could enhance the remoting speed.
Bye, Olaf.
Dan Freeman
Programmer
As Olaf said, a later version of VFP would be much friendlier to the RDP environment, but be aware that it MAY not be a simple as a recompile.
VFP 6 was a lot more forgiving of minor syntax errors than later versions. I once upgraded a project (not written by me!) that had a ton of errors like:
See the missing comma at the end of the first line? VFP6 overlooked it, but later versions will raise compiler errors.
Fortunately, for these kinds of things VFP generates .ERR files that will give you a punchdown list of things to fix and the work goes pretty quickly. It isn't difficult and doesn't take long, but you'll probably wonder "how did THIS ever work?" <g>
VFP 6 was a lot more forgiving of minor syntax errors than later versions. I once upgraded a project (not written by me!) that had a ton of errors like:
Code:
LPARAMETERS p1, p2, p3 ;
p4, p5, p6See the missing comma at the end of the first line? VFP6 overlooked it, but later versions will raise compiler errors.
Fortunately, for these kinds of things VFP generates .ERR files that will give you a punchdown list of things to fix and the work goes pretty quickly. It isn't difficult and doesn't take long, but you'll probably wonder "how did THIS ever work?" <g>
Olaf Doschke
Programmer
There surely are some issues, but you will get these listed once you do build to a new EXE. Some other incompatibilities can be overcome by setting sql and report engine via SET ENGINEBAHAVIOR and SET REPORTBEHAVIOR.
Bye, Olaf.
Bye, Olaf.
- Thread starter
- #13
Thanks again. I have converted quite a bit of my work over the years from 6 to 9 without much of a problem so I don't anticipate any real issues. I've seen these programs for the iPad: iTeleport, LogMeIn, GotoMyPC, Teamviewer, Splashtop. Are there any recommendations on these or others?
Auguy
Sylvania/Toledo Ohio
Auguy
Sylvania/Toledo Ohio
Olaf Doschke
Programmer
Sorry, don't know all these on iPad. Googled a bit and from the following discussion would extract, that LogMeIn and Teamviwer are good solutions, if the iPad is connecting via internet, also slower connections like 3G mobile and Splashtop is good for in house use over wifi, so if you're connected with a higher bandwidth:
The discussion is not too old to be relevant.
I have only personal experience with gotomeeting and teamviewer besides the native remote desktop, which of course is not available on ipad as long as you don't first install windows, which first needs a virtualisation host. I assume something running natively on apple iOS and supporting the newest iOS version and the newest Windows remote desktop protocol version (RDP version) would turn out to be best.
As long as it's free or cheap: try it. If it's more expensive look out why. Of course that's also a hint it's better than free tools, but it could also only offer a specialty you won't need, eg wake on lan or remote sound or 3d graphics accelleration.
Bye, Olaf.
The discussion is not too old to be relevant.
I have only personal experience with gotomeeting and teamviewer besides the native remote desktop, which of course is not available on ipad as long as you don't first install windows, which first needs a virtualisation host. I assume something running natively on apple iOS and supporting the newest iOS version and the newest Windows remote desktop protocol version (RDP version) would turn out to be best.
As long as it's free or cheap: try it. If it's more expensive look out why. Of course that's also a hint it's better than free tools, but it could also only offer a specialty you won't need, eg wake on lan or remote sound or 3d graphics accelleration.
Bye, Olaf.
- Thread starter
- #15
Olaf Doschke
Programmer
To add: The personal experience I have is not from iPad, but remotely controlling PCs from Windows PC to Windows PC. So I can't really tell you, how good the iPad version of eg Teamviewer works. In general all the tools I used where quite equal and more depending on the bandwidth of the connection than anything else.
There's the support of forwarding gdiplus commands rather than the graphics themselves, which would by the way not help on an iOS plaform, as long as the remoting software does not understand and emulate gdiplus on iOS.
Bye, Olaf.
There's the support of forwarding gdiplus commands rather than the graphics themselves, which would by the way not help on an iOS plaform, as long as the remoting software does not understand and emulate gdiplus on iOS.
Bye, Olaf.
- Status