Looking further into this it seems that my MacBook Pro CPU should support Intel VT-x.
Running this in Terminal …
sysctl -a | grep machdep.cpu.features
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 XSAVE
… shows VMX is supported, but VMWare Fusion 6 says ‘this host does not support EPT’.
Is Yosemite stopping VMWare using Hypervisor??
Microsoft documents the system/hardware requirements for WP8 emulator support here…
http://msdn.microsoft.com/en-us/library/windows/apps/ff626524(v=vs.105).aspx
The requirements are different depending on if you’re using an Intel or AMD processor. Since you are using an Intel CPU, odds are that your CPU does not support “SLAT”.
Microsoft documents a procedure on how to check if your machine supports the required hardware features via the link below. Have a look at section “Checking BIOS settings required by Hyper-V for virtualization and SLAT”. This involves downloading and using a command line tool named “coreinfo.exe”.
http://msdn.microsoft.com/en-us/library/windows/apps/jj863509(v=vs.105).aspx
Also, please realize that the WP8 emulator is really a virtual machine. In my opinion, running a virtual machine within a virtual machine is not going to be a pleasant experience from a performance standpoint. You’re probably not going to be happy with it if you do get it working. I personally use a dedicated Windows PC for WP8 development. In particular, a touchscreen laptop, which gives me the added benefit of testing multitouch support in the WP8 emulator.
You could also try this with bootcamp perhaps.
There is also settings that have to be turned on in windows under “features and services?” which is listed under the hyper-v section
I’m pretty sure this won’t work for him via BootCamp either. His Intel CPU does not support SLAT (aka: EPT), which is required by the WP8 emulator.
Joshua, on this note, do you think we might be able to get WP8 support straight out of the simulator one day? Just like the IOS & Android support we have in the regular Corona SDK today? Is that ability somewhere on the planning horizon? Thanks for all your hard work.
Not in the near future. The reason we released a CoronaCards version for WP8 is because we currently only support a subset of features compared to Corona Simulator built apps. The features we do support for WP8 is at about the same level as it is for CoronaCards for Android/iOS (ie: no support for native UI, in-app purchase, ads, notifications, etc.). But most of the features that are missing can be implemented on the native side via our Lua/.NET Bridge, making a CoronaCards-like solution the best option at the moment. And since CoronaCards is your only option for WP8, we thought the reasonable thing to do was to make it freely available to Pro and Enterprise subscribers. This seems like the most reasonable compromise at the moment. Especially for those Corona developers who want to take advantage of Microsoft’s incentive programs to port their apps to the Windows App Store, of which their is a time limit.
But that said, even if we did add WP8 support to the Corona Simulator, you would still need a Windows machine to do the final app signing via Microsoft’s developer tools. Meaning you would still need a Windows OS license. So, why not give WP8 CoronaCards a chance? You can get Microsoft’s Express version of Visual Studio for free and we offer WP8 CoronaCards at an unlimited trial basis. And I’m proud to say that our CoronaCards integration with Visual Studio is far simpler to set up compared to what we have on Android and iOS. We worked really hard to make it as easy as possible. Check out the videos from the link below to see how simple installation and app project creation in Visual Studio is…
http://coronalabs.com/resources/tutorials/coronacards-enterprise
Hi Joshua,
Thanks for taking the time to respond. I appreciate all the hard work that went into this solution and will make sure to check it out in the near future. For me, full API compatibility is most important and the current solution is hopefully a temporary transitional path.
Keep up the great work. Thanks much!!!
Regards,
Kerem