Macintosh Windows emulation and PB

[BOB MECHLER]

A prospective customer has the latest Macintosh system and says they run
Windows programs all the time in emulation mode.

Any of you have this situation? Does it work? What questions should I give the salesman to pose to the prospect? I put the brakes on the salesperson from committing till I gather some info. Got to be others who have this come up.

It would also be helpful to know what DB's you've used in a PB Mac environment.

BOB MECHLER

[Marco Pontello]

Modern Mac are Intel based, so they are powered by the same x86 family CPU of a typical PC. Basically, they are PC in a (usually) nicer box, with a different OS (there are also some differences in the way the system star, since they use the more modern EFI instead of BIOS).
The typical ways to run Windows/PC software are 2:

• via Dual Boot: a separate partition is created and there you install XP, Vista or wathever. In this way, compatibility is a non-issue.
• via Virtual Machine: again, no differences here in respect to running a VM in a standard Win PC. The most used softwares for the Mac are Parallels (was the first available) and VMware Fusion (other software solutions exists, even free, but are a lot less used). If a software run, say, in a VM with XP on your PC, you can bet it will run on a VM in the Mac too. Some issues/limitations may be present (both for Win an Mac) for graphics intensive applications (i.e. ones that require accelerated 3D hardware), at the moment.
• Via Wine: like in Linux, it's possibile to run some Win32 software with this "win compatible API package". It's a lot less straightforward than the previous, and results may vary. But this is not the typical way to run Win software on Mac.

Bye!

[Ronald Zutz]

Yes, PB Can Mac

I have observed several Intel Macs (iMac, notebook) running PowerBASIC programs (or other programs calling PB DLLs) under Parallels Desktop. No problems have been reported. (For obvious reasons, I won't commit to fixing Mac-unique anyway.)

FYI, I have also seen Visual Basic 6 apps, with many OCX/ActiveX components, work fine.

Once I observed Windows XP crash (Word appeared to be the culprit) and the system would not reboot. No problemo. Parallels stores the disk as a single file, and the config as another file. Simple copy those two files from last night's backup and everything is restored.

My advice: if your PB app works on a client's Mac, encourage them to try it, but clearly warn them that you don't plan to spend time tracking down problems caused by Windows/Parallels/VMWare/OS X interactions.

Though if I could see my app run on an iPhone, who knows?

Ron

[Marco Pontello]

Though if I could see my app run on an iPhone, who knows?

The iPhone haven't an x86 CPU; seems to be an ARM one, at about 600-700MHz. So the only chances of running PC software is trough a full blown emulator, but that would be rather slow on such a CPU. A dynamic translator could be much speedier (seeing how Rosetta on Intel Macs can run PowerPC binaries), but I doubt there will ever be enough interest to develop such a thing.

Bye!

[Cliff Nichols]

FYI, I have also seen Visual Basic 6 apps, with many OCX/ActiveX components, work fine.

So have I, as long as the app did not deviate from the API of the device that it was running on. (an exact "Verb for Verb" translation as MCM would put it)

Though if I could see my app run on an iPhone, who knows?

I have seen one of my apps (written in VB6 and upgraded to VB.NET (VB7 I guess) work as well, but only on one device)

The iPhone haven't an x86 CPU; seems to be an ARM one, at about 600-700MHz. So the only chances of running PC software is trough a full blown emulator, but that would be rather slow on such a CPU. A dynamic translator could be much speedier (seeing how Rosetta on Intel Macs can run PowerPC binaries), but I doubt there will ever be enough interest to develop such a thing.

All the above quotes just strengthen my urge to learn enough of each, and see if "Since I can do it in one language, why can't I do it in another language?" kind of concept. (AKA...if VB, why not PB?...It would make it that much faster probably).....but the whole thing boils down to "What did you write it for? vs What is it running ON? vs Is there something translating what you originally wrote and the end usage?"

Its like 2 people (each speaking a language) and a translator between them. As long as the translator gets it right, all is fine. If the translator screws up a vowel, but the other person understands and forgives, all is fine. But if the translator screws up, and the other person is offended.....wellllll thennnnn you could have a catastrophic International incident

(Although, still would be interesting to find enough time to see what happens on each OS/Device/etc with different translators to see what PB code worked or failed?)

[Marco Pontello]

So have I, as long as the app did not deviate from the API of the device that it was running on. (an exact "Verb for Verb" translation as MCM would put it)

Uhm... no. That would be the case for Wine, that is a "compatible API" under a completely different OS, so as long as your application does things politely, using officially sanctioned API calls & rules, and provided that the same API & rules are correctly reimplemented by Wine, it run/works.
But with a VM that's not required. Your application would have to do some "really scary hacks" (that probably would cause issues even when running in other real PCs, or with a slightly different hardware or operating systems, etc.) to cause problem on a well done VM like Parallels of VMware Fusion.

Bye!