[Q] Anyone working on a Gameboy Advance emulator? - Windows Phone 7 Q&A, Help & Troubleshooting

Let me preface this by saying I already suggested this idea in the DEV POOL sticky of software development. Unfortunately that thread receives very little attention and my question would be better placed here.
Anyways: Currently WP7 has two emulators (at least that I know of) and they are for the NES and classic Gameboy. Unfortunately, we are missing some really great ones like Gameboy Advance (I still have all my Pokemon games from it), SNES, and N64. You may not be aware, but the Zune HD actually had a partially working Gameboy Advance emulator. The Zune HD possess far lower specs then new WP7 devices, even the first generation devices. The original iPhone 3GS can also emulate Gameboy Advance games and its specs are also a lot lower then current WP7 devices.
I'm curious as to why this hasn't been worked on (at least talked about). I understand that code could be a problem, but the Zune HD I'm sure had similar problems on a far lesser known platform with even less developers and still had some form of Gameboy Advance emulator. Also, native code of some kind is achievable now, correct?
Anyways, I'm just curious if anyone else would like to see this/know if something is in the works. If it is of any help, here is the link to the Zune HD Gameboy Advance emualtor; they even have the source code listed: http://code.google.com/p/visual-boy-zune/

Currently there are several issues with emulation on WP7.
1) The lack of hardware access (XNA)
2) Managed languages and the inability to remove excessive runtime safety checks (like bounds checking) makes it very hard to have efficient rendering and sound generation.
3) The lack of native code access and not allowing for unsafe code in managed languages
While technically you can run native code through COM, it would be a huge amount of work porting an existing emulator over that way and it would be limited to fully unlocked devices.
I do know a few people that has been toying with SNES or even GBA emulation for WP7, but in the end they've given up, because of the inability to have it running at any reasonable speed. Which is very understandable considering how slow it is to run an interpreted emulator inside an VM when u have no way remove safety checks or compile code on the fly.
I honestly don't see any of these things changing for WP7, considering how little to none extra API access that we've been given since the Mango SDK.
But looking at Windows 8 and the Metro style API's, Microsoft would be complete idiots to not bring the same set of languages (native/managed) c++/c# (with unsafe code!)/js to WP8 and native access to directx etc. So none of the WP7 issues would be present.
N64/PSX...that would require a whole set of even lower level hardware access.
So in short; The lack of native or unsafe code access is why u don't have a gba/snes emulator on wp7

Nudua said:
Currently there are several issues with emulation on WP7.
1) The lack of hardware access (XNA)
2) Managed languages and the inability to remove excessive runtime safety checks (like bounds checking) makes it very hard to have efficient rendering and sound generation.
3) The lack of native code access and not allowing for unsafe code in managed languages
While technically you can run native code through COM, it would be a huge amount of work porting an existing emulator over that way and it would be limited to fully unlocked devices.
I do know a few people that has been toying with SNES or even GBA emulation for WP7, but in the end they've given up, because of the inability to have it running at any reasonable speed. Which is very understandable considering how slow it is to run an interpreted emulator inside an VM when u have no way remove safety checks or compile code on the fly.
I honestly don't see any of these things changing for WP7, considering how little to none extra API access that we've been given since the Mango SDK.
But looking at Windows 8 and the Metro style API's, Microsoft would be complete idiots to not bring the same set of languages (native/managed) c++/c# (with unsafe code!)/js to WP8 and native access to directx etc. So none of the WP7 issues would be present.
N64/PSX...that would require a whole set of even lower level hardware access.
So in short; The lack of native or unsafe code access is why u don't have a gba/snes emulator on wp7
Click to expand...
Click to collapse
Well that is mighty unfortunate. I'm assuming the current emulators work because they don't need much power to run? Also is it XNA that allowed for the Zune HD to emulate the Gameboy Advance?
I thank you for your time in answering my question, hopefully Windows 8 will change this current situation.

ErikWithNoC said:
Well that is mighty unfortunate. I'm assuming the current emulators work because they don't need much power to run? Also is it XNA that allowed for the Zune HD to emulate the Gameboy Advance?
I thank you for your time in answering my question, hopefully Windows 8 will change this current situation.
Click to expand...
Click to collapse
I don't know much about the Zune HD, but from looking at the GBA project, it's using native code (OpenZDK?) and not XNA.
Current emulators work because most run at 20/30fps and the emulation of 8bit consoles is less demanding. Also most emulators are written in native languages, making it much harder to port over to WP7.
If WP8 is anything like W8 and Microsoft continues to allow emulators, I'm sure we'll see a lot of emulators for WP8.

The ZuneHD was never hacked at all. If I remember correctly (and I was big on the Zune scene), the Zune devices had far superior security software that was never cracked. Not saying it wouldn't have been possible if more people cared about development for the Zune (it had nowhere near as much following as iPhone and iPod).
Microsoft never gave out a full SDK for the Zune, only access to limited functions in XDA. There wasn't even support for 3D games...
But Zune fanatics were able to find a more "back door" method to hacking the Zune. They created OpenZDK, which allowed for more access to what the Zune can really do. It was almost like a partial hack (which you'd be used to if you're in the PSP hacking scene).
Through OpenZDK, you were able to develop software that better used the Zune's potential (that MS never tapped into). Developers could make 3D games, and even make an emulator. Now my ZuneHD crapped out on me before I could try the GBA emulator, but I used the crap out of it when it was just GB/GBC. I still prefer it over anything I've used on iOS and Android. The only downfalls were that you had to save the normal way, no fast forward, and no sound.
If Microsoft had given more freedom for developers in XNA, then they would have used that to make VBZ and it'd probably be easier to port to Windows Phone.
Microsoft just really messed up with the Zune.

whats the best open source GBA emulator? it would be interesting to use NFC and the Local Wireless to emulate Link functionality. I tried to port a GBA emulator to WP7 XNA but it failed, now with native code, i want to try it in metro.

No$GBA, but I'm not sure
Please try it to make a gba emulator for windowsphone

MaryJane420 said:
No$GBA, but I'm not sure
Please try it to make a gba emulator for windowsphone
Click to expand...
Click to collapse
I'm going to make one for windows 8 metro, then I can attempt to port it over.

Related

[Q] Qt on WP7: Possible but why not?

Qt apps work on WinCE. If WP7 is built on top of WinCE, why would Qt apps not be allowed on Win7?
I'm just trying to make sense of it here. Is it an artificial Microsoft restriction for their platform?
Because third-party apps are managed in .NET compact framework. Qt is a C++ framework and thus unmanaged. This is a smart move by MS as it increases system stability and enhances user experience.
leonard2010 said:
Because third-party apps are managed in .NET compact framework. Qt is a C++ framework and thus unmanaged. This is a smart move by MS as it increases system stability and enhances user experience.
Click to expand...
Click to collapse
If that's the lame reason they give for it not being doable then I will just need to hack Qt onto it. Dumbest move in Nokia's history!
discourse said:
If that's the lame reason they give for it not being doable then I will just need to hack Qt onto it. Dumbest move in Nokia's history!
Click to expand...
Click to collapse
givin that one of the main reasons that windows mobile 6 and for that matter windows desktop can be unstable is poor quality 3rd party programs i think the move was a very good one, forcing programers to stick to strict controls means they have to develop good software, also givin MS got most of the flak for these crap programs i think it was a good move on their part
at the cost of lower performance and code easily being stolen. MS don't care about developers. Hacking a silverlight app onto CE and calling it a new OS was a terrible shortcut and will cost them in the long run.
It's a matter of time until Microsoft releases a Native Development Kit. In a recent interview Brad Watson from Windows Phone 7 Development team said:
Brad Watson said:
8) What about native SDK? Android got theirs later, should we expect Microsoft to provide a native SDK also, or just forget about it ?
BLW – if by native SDK, you are asking will we allow anyone to run C or C++ unmanaged code on the device, the answer is “not now.” Our primary concern is ensuring that there is a fantastic customer experience on the phone. We recently announced that we have satisfaction rates for the phone at 93%. That’s amazing. We attribute at least some of that to the fact that customers can buy apps that they don’t have to worry will trash their phones, and they don’t have to worry because of the managed platform.
Over time we will certainly relax certain restrictions on the phone, but we cannot compromise the integrity of the phone experience or the marketplace experience.
Click to expand...
Click to collapse
Microsoft has to release a NDK because the competition has a NDK. Hopefully the competition will have more and more NDK applications (Firefox, Skype) which would make them more appealing to the user.
When such a NDK will be present, Qt (at least lighthouse) will be ported to Windows Phone 7
indiekiduk said:
at the cost of lower performance and code easily being stolen. MS don't care about developers. Hacking a silverlight app onto CE and calling it a new OS was a terrible shortcut and will cost them in the long run.
Click to expand...
Click to collapse
While I agree it's far from the entirely new OS we were promised I very much doubt it will cost them in the long run. They have provided a OS experience that is second to none, this is all because of the limitations they have put in place.
I would expect the platform to open up somewhat for the next wave of [higher-end] devices giving existing users an iOS-like experience where you can certainly upgrade to utilize multitasking and all that jazz but it will cost you some of the current smoothness of the UX.
The fact that .Net assemblies are easily decompiled into fully working Visual Studio projects hasn't been a huge problem on the desktop and as obfuscating tools become better and better I see no reason why it should lead to a problem on the mobile platform either. Looking thru some of the recent marketplace apps they are all but decipherable for the average developer. Also, as more and more processing moves to the cloud it becomes less and less of a problem - most startups are neither willing not capable of mirroring your closed-source/protected backend services.
The missing NDK is not the sole reason. The OS IS different. As others have pointed out, quite some GDI stuff is just not there, or doesn't do anything. So, Qt would probably just not start. And as there will never be (as MS said) (official) OpenGL drivers on WP7 you can't switch the backend.
And there has to be already some kind of NDK, as e.g. Navigon Select is a semi-native application and it is not created by OEMs.
Hades32 said:
The missing NDK is not the sole reason. The OS IS different. As others have pointed out, quite some GDI stuff is just not there, or doesn't do anything. So, Qt would probably just not start. And as there will never be (as MS said) (official) OpenGL drivers on WP7 you can't switch the backend.
And there has to be already some kind of NDK, as e.g. Navigon Select is a semi-native application and it is not created by OEMs.
Click to expand...
Click to collapse
They say IE9 will have accelerated graphics support, which I presume is based on Direct3D. For WinPhone7 Qt needs a Direct3D backend, which should work on all WinPhone7 devices.
Qt should have the same capabilities of IE9, which AFAIK is not written in managed code.
Qt could also use Google's angleproject which should help in translating "OpenGL ES 2.0 API calls to DirectX 9 API calls".
Since this is a discussion thread, this is going in WP7 General.
~~Tito~~
It will simply not happen. It's that easy. (Not w/o homebrew that is)
By not allowing Qt on WP7, Microsoft and Nokia have just shot themselves in the foot. Instead of offering a smooth migration path for the millions of Nokia users and devs, they've basically alienated the entire community. WP7 is also losing out on thousands of high quality applications like Angry Birds for Symbian^3 and MeeGo that was developed using Nokia's Qt SDK. http://www.youtube.com/watch?v=mS1dwYmKMjs
discourse said:
If that's the lame reason they give for it not being doable then I will just need to hack Qt onto it. Dumbest move in Nokia's history!
Click to expand...
Click to collapse
Good luck hacking Qt into it.
Using .NET also increases Security.
WP7 doens't need Qt, and Microsoft should do whatever it can to stop Nokia from putting Qt in WP7.
Those reasons aren't lame, unless you're missing the portion of you brain that controls logic.
discourse said:
By not allowing Qt on WP7, Microsoft and Nokia have just shot themselves in the foot. Instead of offering a smooth migration path for the millions of Nokia users and devs, they've basically alienated the entire community. WP7 is also losing out on thousands of high quality applications like Angry Birds for Symbian^3 and MeeGo that was developed using Nokia's Qt SDK. http://www.youtube.com/watch?v=mS1dwYmKMjs
Click to expand...
Click to collapse
It's much easier to develop for WP7 than it is for Symbian/Qt. I don't think the developers will have much of an issue with it. They didn't shoot themselves in the foot, you people just AREN'T developers, and don't understand it.
You know you're talking to clueless people when Angry Birds is the epitome o fa high quality application to them.
Cause you cannot develop Angry Birds in XNA, and you seriously believe porting Angry Birds to WP7 will involve nothing other than a few code line changes and a recompilation?
Give me a break.
I wish Microsoft had partnered with SE or something. Nokia's fanbase are more bat**** crazy over these pet projects than the Android people.
Qt will continue to be the development framework for Symbian and Nokia will use Symbian for further devices; continuing to develop strategic applications in Qt for Symbian platform and encouraging application developers to do the same. With 200 million users worldwide and Nokia planning to sell around 150 million more Symbian devices, Symbian still offers unparalleled geographical scale for developers.
Extending the scope of Qt further will be our first MeeGo-related open source device, which we plan to ship later this year. Though our plans for MeeGo have been adapted in light of our planned partnership with Microsoft, that device will be compatible with applications developed within the Qt framework and so give Qt developers a further device to target.

[Q] Native code, dead or just waiting?

As far as my stock quantum goes, I really can't complain about wp7. Great features, flows great, everything I could ask of a marketplace based OS. I got the phone knowing it would be locked down, but hoping the possibilities would grow. I do miss the seemingly endless capabilities wm offered though. Access to all resources, running native apps without the need to sideload.
I noticed a month or so ago a few guys in the forum were discovering ways to gain higher priveledges within WP7 and with the little knowledge my noob self has, have looked into the differences between wm6 and wp7, new kernel, beeing sandboxed and whatnot. And im curious, are we waiting for m$'s release of limited native code execution to oem's to be exploited, or is there an update in the privilege adventure?
With the amount of wp7 devices released and soon to be, I doubt I can look forward to an exploited bootloader to run a custom rom on my first gen wp7 quantum (such as a tricked out wp7 or possibly wm support...?), but a ported version of haret to run xdandroid as I did on my diamond would be exceptional, and from what I understand not too impossible considering wp7 uses ce7 (not sure if there's backward compatibility for ce6 though). We would just need a new UI, and an understanding of the device specific hardware for support in android...?
Where do we stand on any of these options, are they likely or if so, nearing?
I can understand your frustration with the restrictions on WP7 but for most scenarios, access to native APIs isn't that essential in my opinion (and I have been developing on WM6 myself). WP7 uses WinCE 6.0 R3 and not CE7. The Windows Phone team do recognise that they have been quite strict with the exposed APIs and I am sure that was a combination of fear of what developers write (in terms of crashing your phone) and work need to be done with Silverlight for WP. Mango brings new low level functionality and should be made available soon - Sockets been the first that comes up in my mind. Is something wrong with sandbox solutions? I believe not
For any other reasons I probably wouldn't have much to say on the subject, but I've always been one to tinker with my Xbox, psp, router, anything fun. If I can get more functionality out of it, I look for a way. Unfortunately I am not skilled enough to make it happen, so I look upon the gurus. In this case I consider dualbooting wm or even starting android from within the current OS as expanding possibilities. Which is why I look for answers to my question. Any answers?

[Q] Mathstudio (Space Time) for Windows Phone 7

Hi everybody, I am an engineer and I think that windows phone is perfect for my needs..so fast and efficient, office integrated, easy to use and many other qualities..the only thing that I can't find for this OS is Mathstudio.
For those who don't know what's this, it's like having a graphic calculator always in your poket. This program doesn't make everything, of course, but many of the most common things can be done with mathstudio.
I was wondering if somebody could port this program from android/iOS to windows phone 7. Otherwise I must always go around with my mobile and with an ipod touch only for this program. I remember that the previous version of mathstudio (called spacetime) exsists for windows mobile 6.5, an other way could be a porting from windows mobile. I wrote to the official developer but he said he won't realse a windows phone 7 version of his program.
Thank you for listening
Porting WinMo apps is technically possible (though hard unless they were written initially in .NET). Making an unmodified WinMo app run on WP7 is very hard and usually requires a custom ROM to run it (the stock ROMs have very restrictive permissions policies that most WinMo apps can't work with). Porting iOS or Android apps pretty much requires re-writing them, which is an expense that some app authors don't find worth doing.
There are a number of graphing calculator apps available for WP7, and the built-in calculator works pretty well for non-graphing functions, but I can understand wanting access to a specific tool. Unfortunately, since I've never used the app you describe, I can't tell you how well any of the WP7 alternatives compare.
I've got an HD7 and I've made on my own an Y-cable to downgrade it, so now I use the DFT's Deepshining ROM..I didn't know it was even possible to run some old WM6 apps on WP7, such a grat news I'll try to find out more about it Can you give me a list of alternative graphic calculators for windws phone 7? I wasn't able to find anywhere Thank's a lot!!!
I just did a search on the Marketplace for "graphing calculator" and got a number of hits.
If you look at the Opera apps for WP7 custom ROMs, those are actually wrappers around the WinMo Opera apps - the wrappers just put the files in the right places and then launch EXEs.
Thank you so much for the help , I had a look on the marketplace and I found different graphic calculators (Graphing calculator, PoketPi, Eval Graph, Grapher Calculator), but none of them can replace mathstudio for the following reasons: they are only in 2D, they don't support the CAS (computer algebra system, the same present in Matlab), you can't write and save scripts or even one algorythm. I will find out more about wrapping for the moment, but I hope it will come a better solution
Unfortunately, MathStudio will never ported on WP7 platform (according to this: http://www.mathstudio.net/forums/discussion/164/platform-requests , check the last post)
The only hope is upcoming Apollo. WinRT (Win8 API) will have C++ compiler and (probably) will support native code, so MathStudio developers can (also - possible, it's not too easy) port their app to Win8.

x86/64 bit emulator for ARM Processor

So I was wondering if its possible for someone to create or start developing an application that can emulator x86/64 code on an arm architecture?
What x86 code, exactly, do you mean? Do you mean running native x86 code directly or do you mean taking Java or .NET code and running it?
Ultimately, pretty much *anything* is possible to emulate. However, emulating it in a way that it can run in a reasonable amount of time is unlikely to happen. There are just so many things that are limited in the RT version of the .NET Framework.
ok, im not exactly best qualified for this but ill try and explain
in short, no, you could potentially make an emulator for a given program, but to make some be all end all x86 emulator to cover everything would be massively inefficient and probably not possible
you primary obstacle is that RT uses managed code, that means MS tells you want you can and cant do, it gives you the frame work if you like and you can build what you want within that frame work but step outside it and do your own thing isn't possible (yet)
once you got over that barrier, next up would be to port every single function and call sent to the CPU to an ARM equivalent, ARM is like a tadpole compared to Blue Whale of X86 so it wont do everything on chip meaning youd need to also convert it in software to something it can do
It would be like trying to blow a golf ball through a garden hose
however, small limited programs that don't rely on many hardware functions and with limited calls outside of its own program would potentially be possible to emulate assuming you can get native code to work anyway
Surface RT - Paperweight
Surface Pro - Glorified Tablet/Notebook
Just go with the Pro, it will make life much easier. The whole emulator debacle isn't even necessary if you just go with the logical choice.
I mean the Tegra 3 is awful as an SoC--I don't know what moron said Quad A9's are better than A15's, not to mention the GPU is junk compared to an SGX.
Overall Micro$oft shot themselves in the foot.
qhdevon43 said:
So I was wondering if its possible for someone to create or start developing an application that can emulator x86/64 code on an arm architecture?
Click to expand...
Click to collapse
Actually Visual Studio 2012 could technically support building desktop applications to run on Surface RT and other RT (ARM) tablets. However, at this time, Microsoft is also allowing Microsoft signed applications. And, I heard that if you disabled that check in the registry, then you get blocked by RT. It is definitely possible that in the future, Microsoft might allow desktop applications to be recompiled for RT.
In the meantime, Remote Desktop is wonder in that I can connect to my Windows 8 laptop and use it to run any application with almost full touchscreen functionality. So, combining a Surface RT and a Windows 8 computer is ideal for me.
wrexus said:
Actually Visual Studio 2012 could technically support building desktop applications to run on Surface RT and other RT (ARM) tablets. However, at this time, Microsoft is also allowing Microsoft signed applications. And, I heard that if you disabled that check in the registry, then you get blocked by RT.
Click to expand...
Click to collapse
Add it stands, you can't even really disable UAC without breaking Metro in full Windows 8 (the UI setting to disable it doesn't really disable it). They have that thing locked down pretty well!
You can enable test-sign mode on RT, this would allow you to run your own ARM desktop apps, signed by your own cert, not with MS one. This is absolutely legal, but it can be closed by MS in some of the new hotfixes (and they'll definitely will, when this mode would be used to run cracked apps).
It is really possible to make a working x86 CPU emulator that would allow you to run x86 windows programs on RT. Just remember my port of "heroes of might and magic" 1 and 2 for Windows Mobile - it was more difficult to make it, as WM had a more limited Win32 API than Windows RT has.
I'll make a nearly universal emulator for RT when I'll buy a device, project is already started and has good results. But I'm waiting for a device that is based on quad-core Snapdragon S4. I would not recommend buying Tegra devices, 4-core Krait beats them in CPU and 3D speed. And high CPU speed would be necessary for smooth x86 emulation.
Quad A9's are better than A15. If you wasnt too busy kissing jobs ass, you would know this. Tegra line is alot better that any apple "cpu"
Ace42 said:
Surface RT - Paperweight
Surface Pro - Glorified Tablet/Notebook
Just go with the Pro, it will make life much easier. The whole emulator debacle isn't even necessary if you just go with the logical choice.
I mean the Tegra 3 is awful as an SoC--I don't know what moron said Quad A9's are better than A15's, not to mention the GPU is junk compared to an SGX.
Overall Micro$oft shot themselves in the foot.
Click to expand...
Click to collapse
@Jaxidian: Disabling UAC disables Mandatory integrity Controls, which is how the sandboxes for both IE and Metro-style apps are implemented. Metro-style apps check, when they are launched, if they are running in such a sandbox, and exit if they aren't.
Disabling UAC is, and always was, a terrible, idiotic thing to do, and I truly don't know why MS made it an available behavior. Just set it to auto-elevate without UI instead, if you really can't stand having proper principle of least privilege in your OS. This is a little more complex (you have to use the Local Security Policy editor, which can be launched by typing "secpol.msc" into Run or by going into the Administrative Tools) but is a much better solution as things which explicitly want to be run with limited permissions (sandboxing) still can be.
@dazza9075: Dosbox is an x86 emulator that is already available on other ARM platforms. It just doesn't support the (many) x86 opcodes that have been added since the 386. It certainly can't do 64-bit. However, it's fine for running old DOS programs, including games. Somebody should port it to the Windows Store if possible, or at least see about making a homebrew build of it that we can run on RT devices. This is totally not my area of expertise or I'd do it myself.
A full x86 emulator, like Microsoft's old Virtual PC for Mac (except running on ARM instead of PPC), is technically possible. It's just hard. It sounds like some people are already working on this, though.
Regarding publishing DosBox, Bochs, Qemu, ScummVM and other emulators to Windows Store - they would be unable to pass the certification. Read the requirements here http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx
3.9 All app logic must originate from, and reside in, your app package
Click to expand...
Click to collapse
For emulators - app logic resides in an emulated program that is typically not present in app package.
By the way, Microsoft Internet Explorer can't pass this check too - as it downloads and executes flash from web. But MS is already known for its double-standards.
The other reason why those apps may be refused:
3.5 Your app must fully support touch input, and fully support keyboard and mouse input
Click to expand...
Click to collapse
Old programs (games at least) may be unusable without keyboard or mouse. My own program was refused for this reason, because it is unusable without hardware keyboard.
It is possible (and really easy) to port Bochs or DosBox for RT as a "desktop" application (making a "metro" port would be a bit more difficult). I can do that myself when I'll get hands on a Krait-based quad-core RT device, if someone would not port them earlier.
Regarding Tegra 3 vs Krait - Krait is not directly based on A9 nor on A15.
mamaich said:
You can enable test-sign mode on RT, this would allow you to run your own ARM desktop apps, signed by your own cert, not with MS one. This is absolutely legal, but it can be closed by MS in some of the new hotfixes (and they'll definitely will, when this mode would be used to run cracked apps).
It is really possible to make a working x86 CPU emulator that would allow you to run x86 windows programs on RT. Just remember my port of "heroes of might and magic" 1 and 2 for Windows Mobile - it was more difficult to make it, as WM had a more limited Win32 API than Windows RT has.
I'll make a nearly universal emulator for RT when I'll buy a device, project is already started and has good results. But I'm waiting for a device that is based on quad-core Snapdragon S4. I would not recommend buying Tegra devices, 4-core Krait beats them in CPU and 3D speed. And high CPU speed would be necessary for smooth x86 emulation.
Click to expand...
Click to collapse
mamaich said:
Regarding publishing DosBox, Bochs, Qemu, ScummVM and other emulators to Windows Store - they would be unable to pass the certification. Read the requirements here http://msdn.microsoft.com/en-us/library/windows/apps/hh694083.aspx
For emulators - app logic resides in an emulated program that is typically not present in app package.
By the way, Microsoft Internet Explorer can't pass this check too - as it downloads and executes flash from web. But MS is already known for its double-standards.
The other reason why those apps may be refused:
Old programs (games at least) may be unusable without keyboard or mouse. My own program was refused for this reason, because it is unusable without hardware keyboard.
It is possible (and really easy) to port Bochs or DosBox for RT as a "desktop" application (making a "metro" port would be a bit more difficult). I can do that myself when I'll get hands on a Krait-based quad-core RT device, if someone would not port them earlier.
Regarding Tegra 3 vs Krait - Krait is not directly based on A9 nor on A15.
Click to expand...
Click to collapse
But its only a matter of time before we figure out a way to sideload metro apps without going through the store.

Hacking possibilities

So after playing with my Surface for 5 days now, it is obvious there is a lot of capability in the back end through the Desktop. II have networked printers, and drives at both home and office going, streaming content etc. It is very capable for what it is, way beyond any other Ipad and Android tablet out there. So it seems to me it is just a matter of time before some XDAer figures out a way to unleash it and possibly load other programs (non-RT) programs some way. We know the official MS word is no, but it seems to me it is a fully capable Win8 machine that just has some goierners on it and limited processing power, just waiting to be cracked.
Am I just dreaming?
I would love to see this happen. The one thing holding me back from purchasing one. I'd love a Windows 8 Pro version tablet at the Surface RT pricing but wouldn't we all...
I dont think rt can run x86 app properly. Because the cpu is not as good as x86 core. I am interested in porting rt to compatiable device such as tergra 2 and 3 pad.
Sent from my GT-N7000 using xda app-developers app
liu2002 said:
I dont think rt can run x86 app properly. Because the cpu is not as good as x86 core. I am interested in porting rt to compatiable device such as tergra 2 and 3 pad.
Sent from my GT-N7000 using xda app-developers app
Click to expand...
Click to collapse
I don't think it's necessarily about the Tegra being "as good" as an x86 - the issue is that you'd need an emulator, or the source for the x86 app which you'd then need to re-compile for ARM. I believe MS made a developer toolkit available that allows simpler conversion from x86 to ARM but it's still up to the app vendors to do it.
In theory, the same code could compile for both x86/64 and ARM (RT), but VS2012 will not allow you to compile an ARM desktop app. There is no legit way to write/compile a desktop app on RT. Its an arbitrary BS limitation put in place by MS. You cannot side load apps, everything must come through the MS store, RT enterprise being an exception... which doesn't help us. And the MS store will only offer Metro apps. MS office shows that's desktop apps are fully possible, albeit recoded/recompiled for ARM, but MS will not allow it. In an ideal world, RT would be a fully supported OS, and the likes of Adobe and others could release desktop apps for RT, but sadly it won't happen.
Sent from my Galaxy Nexus using Tapatalk 2
Skitals said:
In an ideal world, RT would be a fully supported OS, and the likes of Adobe and others could release desktop apps for RT, but sadly it won't happen.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Why do you say that?
Because its not allowed, only metro style apps published through the app store are allowed. Even if you compile compatible desktop software, the OS won't run it. Its a closed sandbox.
At best we can hope for a "homebrew" community to compile open source software, and find some hacks to get it running.
Sent from my Galaxy Nexus using Tapatalk 2
Hello,
I’m a happy owner of the Surface RT and I just wanted to add my 2c.
I think that Metro UI is great for tablet, but lacks apps !
So I cannot understand why Microsoft didn’t include .Net on this platform ! I think the main goal and the first “Homebrew” must be recompilation of Mono for ARM. As this will allow us develop a lot of programs, quickly and using “good” tools (Visual )
I just started to study WinRT and I’m already hitting a lot of blocks (For instance, I cannot find a way to open Shared Socket ! So if any other app listen on 1900 port, I lose my SSDP discovery... )
But I think recompilation of Mono is definitely a way to go ! I think i’ll try it this week-end, if I have some time, but It’s sure I will not be able install on my surface  As for now it seems to be impossible to enter Testing Mode on it.
Jurion
jurion said:
So I cannot understand why Microsoft didn’t include .Net on this platform !
Click to expand...
Click to collapse
I think people seem to be missing something here (well, not just here, on other threads/forums.blogs too). MS have essentially (it’s really quite impressive) ported over the entire Windows OS to run on ARM – and this includes all of .NET v4 with supporting libraries/DLLs.
You only have to pop to C:\Windows\Microsoft.NET\Framework\v4.0.30319 on your Surface RT to see – all the same libraries for the same version of .NET a x86 desktop seem to be there - including Linq, SQL, reflection etc.
Now, this could be really great news! I’d bet that it would be entirely possible for standard .NET applications (by standard, I mean programs that only use managed code and nothing legacy) to be reasonably easily recompiled to run on ARM - ideally as easyily as changing a drop-down!
Furthermore, this is all supported in Visual Studio, it’s just locked down a bit - I’ve been able to compile, with VS2012 (and a minor tweak to remove the ARM compile block) a simple command line EXE for ARM (using .NET calls – though only in C++ which is a shame). The problem is, as soon I open it on Surface, I get an error saying the ‘digital certificate’ couldn't be validated – a common issue which has a simple fix documented online. The catch... that the instructions to remove this block don’t work with secure boot enabled, and - at present - we can’t disable this on the Surface (on normal PCs this can be turned off in the bios).
So – the key to all this, is for MS to open it up (not impossible, but who knows if or when) or for someone to get round this secure boot/certificate requirement. I’m sure there’s some smart people on here with abilities to work on, and hopefully succeed in doing this. Even if people aren't able to work a way round this block, I'm hopefully that eventually MS may release some firmware update tools that someone can hack to switch off UEFI secure boot. Or perhaps someone at MS or a partner may leak some file/app/boot that unlocks this for dev/enterprise purposes.
I look forward to it happening!
T
Skitals said:
In theory, the same code could compile for both x86/64 and ARM (RT), but VS2012 will not allow you to compile an ARM desktop app. There is no legit way to write/compile a desktop app on RT. Its an arbitrary BS limitation put in place by MS. You cannot side load apps, everything must come through the MS store, RT enterprise being an exception... which doesn't help us. And the MS store will only offer Metro apps. MS office shows that's desktop apps are fully possible, albeit recoded/recompiled for ARM, but MS will not allow it. In an ideal world, RT would be a fully supported OS, and the likes of Adobe and others could release desktop apps for RT, but sadly it won't happen.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Everything doesn't have to come through the MS store, you can install applications that you build in Visual Studio 2012 for Windows Store, create an appx package and choose not to publish it in Windows Store. VS2012 then creates an appx package as well as a PowerShell script that you can run on Surface, accept security warning, get the developer's license on the device (it's free) and that's it!
It is fairly obvious why MS does not allow installation of "Desktop" apps on ARM tablets. Otherwise dev's would get lazy and just recompile desktop apps for ARM. The experience on a touch tablet would not be great on (unmodified) Desktop apps, hence Microsoft set this constraint on Windows RT in order to push dev's towards making a proper touch friendly app. The result is of course the lack of apps initially, but in the long run the benefits will be a greater experience as the apps would be optimized for touch.
Sure there are obvious downsides to this strategy, but the decision itself makes a lot of sense from a useability standpoint. You already read the complaints in reviews about "Office" not being Metro-style and unfriendly to touch. However this is naturally a decision due to time constraints, because MS would have also preferred to not include a desktop on RT. Office is the selling point now, to gravitate people towards RT and when there is enough demand, the touch friendly (Metro) apps will flow in eventually
Backflipping said:
I think people seem to be missing something here (well, not just here, on other threads/forums.blogs too). MS have essentially (it’s really quite impressive) ported over the entire Windows OS to run on ARM – and this includes all of .NET v4 with supporting libraries/DLLs.
You only have to pop to C:\Windows\Microsoft.NET\Framework\v4.0.30319 on your Surface RT to see – all the same libraries for the same version of .NET a x86 desktop seem to be there - including Linq, SQL, reflection etc.
Now, this could be really great news! I’d bet that it would be entirely possible for standard .NET applications (by standard, I mean programs that only use managed code and nothing legacy) to be reasonably easily recompiled to run on ARM - ideally as easyily as changing a drop-down!
Furthermore, this is all supported in Visual Studio, it’s just locked down a bit - I’ve been able to compile, with VS2012 (and a minor tweak to remove the ARM compile block) a simple command line EXE for ARM (using .NET calls – though only in C++ which is a shame). The problem is, as soon I open it on Surface, I get an error saying the ‘digital certificate’ couldn't be validated – a common issue which has a simple fix documented online. The catch... that the instructions to remove this block don’t work with secure boot enabled, and - at present - we can’t disable this on the Surface (on normal PCs this can be turned off in the bios).
So – the key to all this, is for MS to open it up (not impossible, but who knows if or when) or for someone to get round this secure boot/certificate requirement. I’m sure there’s some smart people on here with abilities to work on, and hopefully succeed in doing this. Even if people aren't able to work a way round this block, I'm hopefully that eventually MS may release some firmware update tools that someone can hack to switch off UEFI secure boot. Or perhaps someone at MS or a partner may leak some file/app/boot that unlocks this for dev/enterprise purposes.
I look forward to it happening!
T
Click to expand...
Click to collapse
Hmmm, sorry my bad, didn't look enougth to find .Net assemblies.
As for open it for MS, may be, maaaay be it's the same scheme which they followed with Windows Phone 7.
No native developpment for 7.0 -- 7.8
But they open it for 8.0
May be they just want to force people developp Metro app to populate the store first.
So where's the best place to get one?
I'm looking into buying one very very soon, I found some on ebay for $585 with the cover, That sounds like a win to me. I wish QVC had it, That'd be lovely.
I'm praying we get a work around for all this, But still If the device isn't made for it, I can't be mad that it doesn't do it, That's like being angry that my car doesn't fly.
But it's such a tease, it worries me that I'll have an entire desktop, Sitting, Obselete, With nothing but Office, which I wont even use.
Can't_Live_Without_My_Evo said:
I'm looking into buying one very very soon, I found some on ebay for $585 with the cover, That sounds like a win to me. I wish QVC had it, That'd be lovely.
I'm praying we get a work around for all this, But still If the device isn't made for it, I can't be mad that it doesn't do it, That's like being angry that my car doesn't fly.
But it's such a tease, it worries me that I'll have an entire desktop, Sitting, Obselete, With nothing but Office, which I wont even use.
Click to expand...
Click to collapse
It is made for it. It has the full desktop, and the full desktop Office suite. Its a big tease. The whole "do more" campaign advertises you can "click in" and have full laptop productivity with touchpad and mouse/keyboard. Except the only software to take advantage of it is desktop IE and Office.
Sent from my Galaxy Nexus using Tapatalk 2

Categories

Resources