Is it Possible to Run a very Lean RT build for use with Phones without massive amounts of storage?
what is the absolute smallest RT Install?
and can it be istalled on ARM phones?
anyone have info on the actual minimum requirements for RT?
and can RT be stripped down, so its main function is to Run Windows Programs off of SD cards?
Wow... you're new here (at least to this part of the forum), right?
First of all, we don't actually really have an installer for RT. There are restore images and update images, but those all either have device-specific drivers already embedded in them, or can only apply to things that have such drivers.
As for slimming down an RT build, I suppose it's possible simply by removing OS components, but the OS isn't really made to be highly modular and there's no (public) deployment kit tool for customizing installations. You can save some megs here and there by stripping out stuff like Powershell, any part of the .NET framework not needed for apps, parts of Office you won't use, and so on... but it's not likely to get down to phone-OS-like levels without taking a rather brutal approach. At that point, you're still stuck with the need to install it.
Again, there's no installer. Putting it on an ARM phone would be done by flashing the OS image, and it would already need to have the relevant drivers for that phone embedded in the image. You'd need a phone with an unlocked, EFI-based bootloader, NT drivers available, and flashing tools. I know of no such device, although some sufficiently enterprising people have supposedly achieved at least partial success.
Genuine minimum requirements depend on what you class as "RT". You can run the NT kernel on a machine with surprisingly little RAM, although the ARM port of NT does require certain CPU features that an old or extremely basic CPU won't have. You need DirectX10-capable graphics, and probably at least half a gig of RAM, for full desktop functionality; you need a certain resolution (I forget what it is for 8.1, for 8.0 it was 1024x768) for Metro apps, and so on. While technically capable of running on single-core, the performance would be pretty bad at typical ARM core performance; even the 4x1.3GHz Tegra 3-powered Surface RT is considered to be slow by some. Again, nobody has published minimum specs, because there's no need for them when you can't actually install the OS yourself. Tablet manufacturers obviously have spec guidelines to adhere to - the Metro resolution requirement, for example, means you won't see an RT tablet with resolution any lower than that - but those can't properly be considered a true minimum and will vastly exceed the specs of nearly all smartphones.
Finally, your last question is particularly silly when you consider that, by default, RT can't run (third-party) Windows programs at all! After jailbreaking (which would be easy to do permanently on a non-SecureBoot bootloader) you can run Win32 programs that have been recompiled for ARM (and don't require any of the libraries which are missing from RT, such as OpenGL; stripping out stuff puts you at risk of making this worse) but there's only a few dozen such programs at this time (see the link in my signature). It will *not* run Windows Mobile / CE software. Getting Windows Store apps to install to, and run from, an SD card is difficult, but possible.
WinRT has one major requirement: UEFI. Android phones don't have it, Windows phone <8.0 don't have it too. 8.0 phones have UEFI (I'don't own such a phone - information is taken from MS docs), but it is locked - you can't boot anything except for the phone OS signed by microsoft certificates. And, obviously, these certificates are not same on WP and RT.
Cotulla has wrote his own UEFI implementation for HTC HD2, so theoretically it is possible to boot RT on any ARM device that allows running your bootcode, but this would require lots of time and brains and kernel hacks.
And the second problem is drivers. There are no hardware standards like on desktop PCs - so there is no driver database, like on a desktop Windows, for your device.
UEFI provides some subset of functions that can be used in drivers to boot into OS and even to see a picture - but they are too slow and too limited to be useful in a real work. And you'll still need to write a driver that uses those functions.
Related
Hi all,
I ask this question cuz I counldn't find enough information about How to install Linux on my PPC.
My ppc is: I-teq X-bond like as Gigabyte gsmart i. with 64MB ROM.
Is there any linux ROM distribution for my ppc? or general linux ROM distribution for PPCs?
Thanks in advance.
Pedram
The reason you could not find information is because there isn't much of it to be found.
Unfortunately, Linux for PPC is in its infancy. The main problem is the drivers - they all need to be reverse engineered and there is no help from the OEMs as they designed this things to only work with MS crap and seem to have no interest in releasing drivers or specifications.
Official reason: Because you can not mess with the OS the device is more stable and secure.
Real reason: If you need to by new phone to get new OS we make more $$$ and so does MS.
As far as I heard there is a half decent version for some iPaq model, and there is version for some HTC devices (check WiKi) but all it does is boot up: no drivers even for touch screen, no graphical interface, no apps.
Thnx levelnum.
I think if linux developers I mean open source world focus on handheld devices they can publish good distribution as desktop or laptop PCs. Today they are very powerful in reverse engineering, .NET Framework in Linux named MONO is one of these reverse engineering issues.
I believe that Linux is much more customizable that WM, especially for XDA-developers that make interesting works on WM. And also it doesn't have copyright restriction as WM has. So may be it makes many progress in world of handheld devices.
Oddly enough I was looking for Linux on Smartphone info yesterday as I've got an Alpine I'd like to be able to do something interesting with.
Demand for something like this is going to be a bit odd - by definition anyone who finds this site, let alone opens an account and posts, is going to be interested in pushing the boundaries of their device but the vast majority of WM device users are going to be in the "don't care how it works as long as it does" group.
Also, I reckon a lot of Linux dev types aren't even going to look at the device, it will never occur to them to buy one because it's sold as a Windows Mobile device, and hence isn't going to be near their installation of the hacker mentality. Without a critical mass of people who can develop in/with Linux it's always going to be a struggle.
problem is the program base
all current wm programs unless they are .net
would not run under linux on our pda's
new ones would be required to be written
or ported or....
The Nokia Internet Tablet runs on a version of Linux with a pretty robust set of applications, and this device uses an ARM processor which should be pretty friendly with regard to 'porting'.
But you'd still be stuck without a telephone application.
You can find some information here:
http://handhelds.org/moin/moin.cgi/HaRET
http://www.handhelds.org/
Oddly enough I was looking for Linux on Smartphone info yesterday as I've got an Alpine I'd like to be able to do something interesting with.
Demand for something like this is going to be a bit odd - by definition anyone who finds this site, let alone opens an account and posts, is going to be interested in pushing the boundaries of their device but the vast majority of WM device users are going to be in the "don't care how it works as long as it does" group.
Also, I reckon a lot of Linux dev types aren't even going to look at the device, it will never occur to them to buy one because it's sold as a Windows Mobile device, and hence isn't going to be near their installation of the hacker mentality. Without a critical mass of people who can develop in/with Linux it's always going to be a struggle.
Click to expand...
Click to collapse
May be! as you said it is Windows mobile device and linux lovers aren't going around of it. but I think they are so curious than it.
problem is the program base
all current wm programs unless they are .net
would not run under linux on our pda's
new ones would be required to be written
or ported or....
Click to expand...
Click to collapse
I do think so. since I in previous post I mentioned that .NET framework available in linux. so many of windows program can run on it.
You can find some information here:
http://handhelds.org/moin/moin.cgi/HaRET
http://www.handhelds.org/
Click to expand...
Click to collapse
Hart (Reverse engineering tool for wm hardware) was interesting tool.
yeah but due to limitations and slowness only the minority of applications on windows mobile are made in .net :S
i want this one
http://www.openmoko.com/press/index.html
Regards,
Jason
Rudegar said:
problem is the program base
all current wm programs unless they are .net
would not run under linux on our pda's
new ones would be required to be written
or ported or....
Click to expand...
Click to collapse
This is not a real problem. If you want to use a particular program from WM that is a problem but why you would do that? There is very large program base for desktop Linux (many of them also exist for desktop Windows) which could be very easily ported to a handheld platform with ARM processor. If you ever looked up how many qualitative programs do exist for Japanese Linux handhelds...
Wexx said:
This is not a real problem. If you want to use a particular program from WM that is a problem but why you would do that? There is very large program base for desktop Linux (many of them also exist for desktop Windows) which could be very easily ported to a handheld platform with ARM processor. If you ever looked up how many qualitative programs do exist for Japanese Linux handhelds...
Click to expand...
Click to collapse
Thats one of the things that is grate about open source software - you don't even have to depend on the original developer to find the time / will to port it. Anyone with the programing knowledge can.
I've just successfully upgraded my UK Orange SPV M700 to AX3L's WM6 ROM, and enjoying it. However, the relative ease of re-writing a ROM has led me to other questions of a more speculative nature.
I'd like forum members to know that I am not a genius in the mobile OS field, so apologies if my enquiry is 'common knowledge' so to speak, and that my question is purely speculative. I wouldn't be interested in carrying out the modifications to my own handset.
My question is this:
Given the relative ease of modifying and/or installing a new ROM on a Windows Mobile handset, would it be possible to install a non native OS onto a Windows Mobile handset. For instance, the UIQ version of Symbian, used on the P series handsets from SE, and perhaps installing Symbian Series 60 3rd Edition on non touchscreen handsets?
an os are binary files made for the cpu in the device
for an os to be able to boot
the bootloader have to be compatible with the format of the rom
and the rom have to be native binary cpu
and some drivers are required to be present for the device to boot at all
nobody i know off have 100% transfered a rom from one device to another
core kernel and driver related things have to be kept for the device to boot
upgrading a rom to another rom for the same htc device type is easy
upgrading a device to another and newer version of the os but keeping the core of the os and only add the shell and program changes is alot more work for the rom maker
To correct my previous post, Im not sure if using Windows Mobile device to run Symbian UIQ could be considered 'upgrade' more like 'sidestepping' ;-)
I understand the comments about specific programming for the device CPU. But couldn't a software workaround bypass this?
I think the same could be said for Mac and PC. In theory, you could use a G5 to run Windows (not Boot Camp). By just using the physical hardware of RAM, Hard drive and BIOS, (and of course, a CPU workaround, maybe not so much a problem with the newer Intel Macs) surely you could format the Mac structure enough to run Windows XP, and vice versa. And you could surely apply the same theory to a Pocket PC. IF you 'format' the system enough, so its basically just an empty shell, or a blank canvas if u will, you could use it for pretty much anything.
If an iPod can run a version of Linux and even Doom, then, if you so wished and had the inclination to do so, it could run the Creative Zen (or even Zune!) software.
All of these speculative suggestions are of course subject to the physical human interface. But then, the IT guy at work runs a Mac keyboard and mouse on a Dell PC at work..
ianrendall said:
To correct my previous post, Im not sure if using Windows Mobile device to run Symbian UIQ could be considered 'upgrade' more like 'sidestepping' ;-)
I understand the comments about specific programming for the device CPU. But couldn't a software workaround bypass this?
I think the same could be said for Mac and PC. In theory, you could use a G5 to run Windows (not Boot Camp). By just using the physical hardware of RAM, Hard drive and BIOS, (and of course, a CPU workaround, maybe not so much a problem with the newer Intel Macs) surely you could format the Mac structure enough to run Windows XP, and vice versa. And you could surely apply the same theory to a Pocket PC. IF you 'format' the system enough, so its basically just an empty shell, or a blank canvas if u will, you could use it for pretty much anything.
If an iPod can run a version of Linux and even Doom, then, if you so wished and had the inclination to do so, it could run the Creative Zen (or even Zune!) software.
All of these speculative suggestions are of course subject to the physical human interface. But then, the IT guy at work runs a Mac keyboard and mouse on a Dell PC at work..
Click to expand...
Click to collapse
well, if you could compile the os for the type of chip in use, write all the drivers , you could in theory get it to work....
there was a project bsck in '05 to run win 95 and 98 on a ppc and they succeded in that
and then we ave linux releases for some ppcs
also got it from some macosX developers that the system being based
on a BSD kernel which was more mature on x86 then on motorola platform
the whole macosX was first developed on pc's but never released
what you ask could be don but it would most likely time more manhours then it would be worth
and could also result in a law suit from the symbian people
you're the only person i've seen to request this i've seen so far
maybe an emulator would be the way to handle it
I'm not actually interested in doing any of this, as you say, it would be pretty pointless and legally troublesome. Just interested in the science of it.
Okay, so since the unlocked emulator has a file manager and task manager, does that mean it would be possible to extract them and run them on an actual WP7S device? And if that was possible, would it also be possible to extract the Native APIs from these apps? I'm fairly certain that they use Native APIs because ordinary apps can only access their own directory. I'm not very smart with these things, so sorry if it's obviously impossible or something.
It's wince - the native API is always there, where do you want to extract it from? Also some people figured out most WP7 apps from the emulator ROM are written in native as well. it's always here.
But you can't just put file manager on a WP7 device because there's no access for you to put anything on it, except apps from Marketplace you got the picture? even if we could cook our custom ROMs in the future the only thing we could do is throw in our own DLLs, services or background tools on it and customize it a little. I still doubt you'd be able to develop real WP7 style apps like a file manager or registry editor because the GUI is supposed to be written in Silverlight/XNA. And from those frameworks you can't access the native API unless Microsoft would add support for it.
101% dumb phone. If you think about it then WP7 is even WORSE then iphone.
But what if you could use Visual Studio to load it onto the device? If you look around in it, there is an option for that.
Actual devices will have to be unlocked for developement purposes to allow sideloading through Visual Studio and even then I doubt the system would be able to deploy native code. Developer phone means a yearly fee for membership in the MS developer programm.
I don't think that using native APIs from managed code would be impossible in the SDK - carriers, e.g. will be allowed to use it, but for normal applications the Security Context in .Net would prevent the programm from calling them (Code Security Managers are configurably available in Java and .Net from the beginning, so i believe that would be what MS uses to block access).
And of course programs using those wouldn't get on the marketplace.
Oh, too bad then, but thanks for your response anyway!
Fdo35 said:
Okay, so since the unlocked emulator has a file manager and task manager, does that mean it would be possible to extract them and run them on an actual WP7S device? And if that was possible, would it also be possible to extract the Native APIs from these apps? I'm fairly certain that they use Native APIs because ordinary apps can only access their own directory. I'm not very smart with these things, so sorry if it's obviously impossible or something.
Click to expand...
Click to collapse
Okay, the issue here is the lack of a few key DLLs: Windows 7 Series will not offer GDI most likely (I'm downloading the emulator set now, and will confirm this soon) and will lack comctl32.dll and the like, removing these functions. As it's been stated before, like Windows 7 uses the 6.1 NT Kernel, Windows Phone 7 series uses the 6.5 Windows CE kernel, at least, last that I've heard. It would then be both possible to bring Windows Mobile 6.5 DLLs over, but anything that calls GDI will not work. Solution? Make a mock GDI that uses the new render.
This isn't new either, Windows 7 uses WPF more than ever (Which composes most of the games as well as Windows Media Center), which is a 3D accelerated and fancier way to draw to the screen, and Windows 7's GDI subset has been updated to allow hardware acceleration granted the graphics card allows it (It's actually something the video card driver must tell Windows, as MSDN states)
Deploy native code, no. Run it, of course
I'll be investigating the possibility of native code here shortly. Chances are, you will need to set the target to ARMV6, and set the compile type to Native, not Windows. Most developers, if not all, probably have overlooked this.
I would expect that it'll require privileged access to run native code, so you'll need to solve the code signing problem.
ThymeCypher said:
Okay, the issue here is the lack of a few key DLLs: Windows 7 Series will not offer GDI most likely (I'm downloading the emulator set now, and will confirm this soon) and will lack comctl32.dll and the like, removing these functions. As it's been stated before, like Windows 7 uses the 6.1 NT Kernel, Windows Phone 7 series uses the 6.5 Windows CE kernel, at least, last that I've heard. It would then be both possible to bring Windows Mobile 6.5 DLLs over, but anything that calls GDI will not work. Solution? Make a mock GDI that uses the new render.
Click to expand...
Click to collapse
Well, I doubt things like comctl.dll and some other things like GWES will be that big of an issue once Platform Builder 7 is released and we can just generate these components ourselves. Hell, adding back GDI support (if those rumors aren't just lies) may be as easy as replacing the GWES with a less crippled one generated by Platform Builder. Maybe GDI support is still compiled in but just doesn't output directly to the screen using the default graphics driver implementation. That's how the Dreamcast implementation of Windows CE was. To even see apps like IE on the screen, you need to copy the contents of the standard WinCE GDI output to a DirectDraw surface.
What I'm more worried about is the hackability of the hardware/software. I'm really hoping it's not as insanely locked down to the point to being unhackable like every Zune.
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
RAMMANN said:
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
Click to expand...
Click to collapse
Platformbuilder is for the OS, which is Windows CE. There is still some debate as to what version the emulator is running, leaving alone the possibility that the actual version of the OS may be different at release.
If the CE6R3 camp is right, you can get platform builder for that right now, though you wont have telshell.exe (WP7 replacement for explorer.exe), and the WP7 specific apps. It would be an interesting exercise to see if they could be run on CE6R3. If no one beats me to the punch, I plan on trying this for myself when I am less swamped at work.
If the CE7 camp is right, you will have to wait till MS releases that version to the public. And they WILL release it because there are far too many embedded systems outside of phones that run on CE for them to neglect it.
No, I was talking about the generic Windows CE 7.0 Platform Builder and not the OEM specific OAK for WP7S. Unless MS plans to completely drop their generic Embedded Windows CE offerings, I see no reason why PB 7.0 will not be released and help with hacking WP7S (if it is even based on 7.0). You always needed to be a large ODM and sing an NDA to use a Platform Builder addon/OAK for the MS platforms like Pocket PC. Those almost never leak and I can't imagine this would be much different.
RAMMANN said:
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
Click to expand...
Click to collapse
Yes, platform builder was used to build leaked wp7 arm image.
d:\wm700_6176\platform\common\src
\soc\qcom_v1\oal\power\sleep.c
It is from from nk.exe
use dumpbin.exe to get all methods in dll/exe
today I talked about the RT OS with ffriends.Suddenly one said that win8 os pad can run on Windows RT and a RT OS PAD can run on win8 x86！！he is joking ！！Besides，he said he did that successfully for many times。。。。。
seven7xiaoyang said:
today I talked about the RT OS with ffriends.Suddenly one said that win8 os pad can run on Windows RT and a RT OS PAD can run on win8 x86！！he is joking ！！Besides，he said he did that successfully for many times。。。。。
Click to expand...
Click to collapse
No it cannot. Your friend clearly lacks the common knowledge that RT is for ARM and windows 8 is for x86. Round pegs do not fit square holes.
I can't really understand your English; did you mean "app" where you wrote "pad"? The fact that Win8 and WRT share apps is well known; there are a few apps which are only for one platform or the other but almost all the apps are available for both. Native code apps need to be recompiled for the other platform, but managed (.NET) and HTML5 apps will run un-modified. This is not news.
If you mean the ability to run some x86 desktop apps unmodified on Windows RT, that's due to mamaich's emulation layer, combined with clrokr's "jailbreak" exploit (and usually netham45's scripts to automate the process). Relatively few apps run correctly through that emulation layer, though, and the new Windows Store apps are not supported. There is no support that I'm aware of for running ARM-compiled Windows apps on x86, although ARM emulators certainly do exist and if you could boot Windows RT on one of them, that would allow you to run the apps (somewhat indirectly).
If you mean actually installing Win8 (or any other x86 OS) on Windows RT, that's technically possible through the use of emulators (not sure DOSbox supports enough CPU features for Win8, but Bochs probably does) but the performance is abysmal.
GoodDayToDie said:
I can't really understand your English; did you mean "app" where you wrote "pad"? The fact that Win8 and WRT share apps is well known; there are a few apps which are only for one platform or the other but almost all the apps are available for both. Native code apps need to be recompiled for the other platform, but managed (.NET) and HTML5 apps will run un-modified. This is not news.
If you mean the ability to run some x86 desktop apps unmodified on Windows RT, that's due to mamaich's emulation layer, combined with clrokr's "jailbreak" exploit (and usually netham45's scripts to automate the process). Relatively few apps run correctly through that emulation layer, though, and the new Windows Store apps are not supported. There is no support that I'm aware of for running ARM-compiled Windows apps on x86, although ARM emulators certainly do exist and if you could boot Windows RT on one of them, that would allow you to run the apps (somewhat indirectly).
If you mean actually installing Win8 (or any other x86 OS) on Windows RT, that's technically possible through the use of emulators (not sure DOSbox supports enough CPU features for Win8, but Bochs probably does) but the performance is abysmal.
Click to expand...
Click to collapse
sorry for my poor English!:crying:.I meant the os not the APP
seven7xiaoyang said:
sorry for my poor English!:crying:.I meant the os not the APP
Click to expand...
Click to collapse
You cannot install Windows 8 x86 directly onto Windows RT hardware. It doesn't work.
You probably saw someone RDPing to an x86 desktop.
netham45 said:
You cannot install Windows 8 x86 directly onto Windows RT hardware. It doesn't work.
You probably saw someone RDPing to an x86 desktop.
Click to expand...
Click to collapse
Thank you! I am thinking about the sideloadling the appx,hope for some help
OK, I'm still not sure what you're talking about - just a couple posts up, you said you weren't talking about apps, and now you're talking about .APPX files - but as was mentioned above, most APPX files will be architecture independent (managed code or HTML5); only the native code ones will need different .APPX files for Win8 and RT.
Hello:
This is my first posting here and I'll be getting a Surface RT tablet this thanks giving. I have a iMac 2013 running Windows 8.1 and Visual Studio 2013 Ultimate thru MSDN.
I would like to develop Windows Store desktop/tablet/phone apps (using C#, XAML) or Xojo that should run on Surface RT, Surface Pro, Windows Phone, Windows 8, Windows 7, Vista and XP (supporting both 32 bit and 64 bit). I wanted to know whether the desktop apps I'm developing would run on all of these environments or is it limted to run only on Surface variants. The intent of buying a Surface RT is to take it to college while at the same time test the apps on Surface RT and deploy to the Windows store. I'm confused on the ARM and Intel/AMD cpus and do I need to change anything in Visual Studio 2013 config to target these environments.
Please advise.
ARM vs x86 is simple enough to cover quickly. Computer processors always use a particular "instruction set" to tell them what to do. x86 is one instruction set, ARM is another instruction set, an ARM processor of course uses the ARM instruction set and an x86 processor uses the x86 instruction set.
Computer software is usually compiled from human readable source code into machine code which the processor then executes or they are interpreted where a piece of software which has already been compiled via the previous method then reads your source code and processes the output directly (as they rely on existing software, you cant write an operating system in an interpreted language, they are often referred to as scripting languages instead of programming languages but in terms of application software they are sometimes just as capable if just slightly slower). Then standing write in the middle you get the bytecode languages, you take human readable source code and compile it into bytecode, the bytecode essentially being an instruction set for a processor which doesn't exist in hardware, you then take a piece of software called a virtual machine which takes the bytecode and processes the output, sort of a half way between being fully compiled and fully interpreted.
Java compiles to java bytecode for the java virtual machine, as long as you have a functional java virtual machine you can run your java application on any platform (and java is indeed on most desktop operating systems and on multiple instruction sets). C# and Visual Basic .NET both compile to .NET Bytecode for the .NET virtual machine, again, with a functional .NET virtual machine you can run a C# application on any platform (unfortunately only windows (including RT) has microsofts official .NET virtual machine, but mono is compatible and runs on other platforms too). C or C++ are compiled, compiled languages must be compiled for a particular operating system and instruction set. Python, lua or batch are interpreted, as long as you have a functional interpreter they will run on any platform. One thing to take note of, in theory it is possible to take a particular programming language, lets say a compiled one, and then write an interpreter for it instead of a compiler (and there are indeed C interpreters) or an interpreted language and write a compiler for it (has been done too), but we are ignoring that.
Visual studio will build windows applications in C/C++ or it is the IDE of choice for C# or VB.net on .NET. No surface limitations, with plugins (or considering usage of mono on other operating systems) it can even do extra platforms and languages too (I personally use it for python and have used it for arduino microcontrollers). It supports both ARM and x86 for C/C++, I admit I have not tried C/C++ in visual studio for windows software so I dont know if it simply builds your software 2/3 times or if you need to manually select ARM but the drop down for it is in the build configuration manager either way so you can always take a look in there for yourself, for .NET it says Any CPU (it is possible to tell it to make an x86 or ARM only .NET application, I am yet to come across why with the exception of perhaps optimisations). Windows store apps generally have to be done in Visual studio and officially your only options for store apps are C++, C#, VB.net and Javascript.
Store apps in my opinion are *not* a good introduction to programming. Console applications are far better to start off with. Leaves you with an issue, windows RT cannot run any application except store apps without a digital signature attached to the executable, which is great but we have no way of obtaining those signatures ourselves, only microsoft do. End result is that you can compile your C project for ARM from visual studio or take a .NET application, but you cant run it on the RT (which is an ARM device). Useful huh? Someone wrote a jailbreak which removes this restriction, but its for RT 8.0 only, the 8.1 update breaks it.
Also windows store apps are different from windows phone apps. You wont be able to write an app for both. You would have to write 2 entirely seperate apps. Only windows 8, 8.1, RT and RT 8.1 can run store apps. Only windows phone can run windows phone apps. Officially only windows 8 (including 8.1) and below can run desktop. Your cross platform ambitions are just that, ambitions. For 1 beginner, they are unattainable.
Xojo is for web apps, aka glorified websites.