Database Users

New Programmer (Maybe)

Hi to all,
i'm new in xda\xda2 world...and i would like to develop under it? What i need for developing? What cpu type\model it have?

Well.. The About and Device Information screens in the System Settings menu should take care of your questions..
But if you're lazy, the XDA typically runs PocketPC 2002 on a StrongArm CPU, and the XDA II PocketPC 2003 (Windows Mobile Edition) on an Intel XScale (which is backwards compatible with ARM).
If you simply visit www.pocketpc.com and click on developers you'll end up at http://www.microsoft.com/windowsmobile/information/devprograms/default.mspx
Where you can even order a free DVD-Rom with the PocketPC SDKs, compilers etc (they will charge shipping and handling, at a freakishly high rate). You can also download that stuff.
However, you will need Visual Studio .NET as well, which is not a free download (in fact, even the academic version will set you back more than EUR 100).
I've not ventured into it myself yet, so it's quite possible you can actually do without Visual Studio (as the compilers themselves can be downloaded). Also, there's a version of gcc for pocketpc.
Any one developing for pocketpc who wants to chip in here? (I'd like to toy around with programming a bit on PPC - regretably it doesn't have a built-in scripting language like epoc32 has/had).

You only need Visual Studio .NET if you want to create .NET applications. If you are just programming in C++, I'd highly recommend downloading Embedded Visual Studios 3 and 4 and get the appropriate SDKs (all of which are free). At least, that's what I use.

What about Java Midlets?
I am thinking on writing a couple of apps for PPC, but going into VS.NET might be too deep for me. I also want to extend those later for palm and maybe desktop. No hardware specific stuff so I thought I might get away with Java which I am pretty good at.
Does anyone have anything to say - pros / cons? How midlets are on O2 in general - fast / slow, too much memory or processing power? Please share.

Why don't you get down to c++? Fast, small, general support...
--------------
У нас сегодня день вежливости, так что вы просто идите за мной и никуда не сворачивайте!

Some day
Good old C++. Too many years with Java - softened my mind... Undoubtedly C++ is the best way to go in terms of speed and size. Lets see what people say. :idea:

I've been programming in Visual .NET (VB.NET more specifically), but even after installing the SDK I have no idea where to start? When creating a project, I don't see any new project type for Pocket PC applications ? In fact, what else do I need to do if I want to program in VB.NET ?

i read that visualstudio .net 2005 will be able to make pocketpc applications in all languages not just .net applications like 2003
not sure about how you get started with vb.net since vb is very evil and nasty
but with c++ mfc and c# .net you start out with a form and there you can place components on it and program what functions they have
but if you want to make games and stuff which dont use normal windows stuff then you are better off programming them in c++ directly for the arm platform

I use Embedded VC++ and MFC as it's far tighter/smaller than .net. Purists can go completely Win32(ce) native and avoid MFC altogether but MFC does make development a good deal easier without the bloat of .net (not to mention how slow it is..).

Same thing for me. C++ with EVC tools. No mfc for me (a little purist and feel it gives a clearer code )
Best way to have samller and optimize applications

I've been programming in Visual .NET (VB.NET more specifically), but even after installing the SDK I have no idea where to start? When creating a project, I don't see any new project type for Pocket PC applications ? In fact, what else do I need to do if I want to program in VB.NET ?
Click to expand...
Click to collapse
If you have VS.NET 2003 you don't even need the SDK.
just File-> New->Project
on the left column "Project Types" choose your language and on the right click the "Smart Device Application"
Basically is like any windows application but less possibilities and if you want to create any serious application you'll have to do a lot of optimization and native coding.
Good luck

Books?
I'm also interested in programming with Embedded VC++...and was wondering if anyone know of books out there I can pick up that will help my learning process a little quicker. Its been a long time since i coded in C++ and need to refresh.
The part I'm really need help is the basic parts ...like how to get things started.
I'm confident that once I get started i'll start to remember my C++ coding.
I'm downloading the Embedded VC++ from Microsoft as I type this post ...hope it wont be too hard to understand how to create a simple "hello world" program for PPC devices
Also if anyone knows a good web sites with code samples ...please PM or post the URL, I'v seen some but not all that great
Thank You

Sometimes less is more.......
zendrui said:
Same thing for me. C++ with EVC tools. No mfc for me (a little purist and feel it gives a clearer code )
Best way to have samller and optimize applications
Click to expand...
Click to collapse
As mentioned above, if you drop ATL, MFC .NET and all the implied baggage they have to bring with them to work, you are left with the old WIN32 programming model. This is now considered very 'old hat', but if all your program uses are API's in WIN32's kernel.dll, user.dll, gdi.dll etc...... i.e. the very primative windows stuff, then it is possible to write an application that will run on any version of Windows Mobile. This application will be pretty simple, but the compiled .EXE file targetted at an ARM4xx model will run on almost any Pocket PC, without any other files. (i.e. The single APP.EXE file will run on any upwardly compatable system, no fancy implementation project to create or run, just copy the release '.exe' file to the target machine, and it will run!). These days 99%+ mobile PDA's run ARM class processors. The manufacturers call them by their own processor IDs but under the hood they are all the same.
To create an app that will run on the Mobile 5/6 platform without looking like previous Mobile 2002/3/SE apps, limit the Main menu items to two. This will make sure they appear either side of the input icon, as menu items. More than two and the Mobile 5/6 menu items appear as 2002/3/SE apps in the old control bar style.

wfberg said:
(I'd like to toy around with programming a bit on PPC - regretably it doesn't have a built-in scripting language like epoc32 has/had).
Click to expand...
Click to collapse
As far as scripting goes... I'm a big fan of Mortscript. It's so simple... I guess I'm a little purist myself

Basic 4PPC
Basic for Pocket PC, has anyone tried this. I went to the site and it only cost around 40.00 US. I've worked with "basic" before and the progs were usually bloated and sluggish. Wonder if this would be the same.

i have started developing in ppl language the program name is PIDE from ariana soft..its very easy..it also lets u make games
ive created my first clock in it

Windows Mobile 6 Kernel Open Source (also drivers)

I am writing from my pocket pc:
http://www.windowsfordevices.com/news/NS2632317407.html
"Microsoft officially launched the sixth generation of its flagship device software "platform, today. "Windows Embedded CE 6.0" boasts kernel architecture enhancements, new software stacks targeting three high-volume device categories, enhanced development tools, and, for the first time, 100 percent availability of Windows CE's kernel source code. "
Doesn't this mean we can port to any device?

This is for links:
http://msdn.microsoft.com/embedded/community/community/communityprojects/
http://www.codeplex.com/
---
Develop now, pay later
A free 180-day evaluation version of Windows Embedded CE 6.0 is available for download, here. The kit includes the operating system, the standard shared source components described above, and Visual Studio 2005 Professional.
http://www.windowsembeddedkit.com/

sorry to burst your bubble, but CE6.0 is NOT WM6
WM6 is BASED on CE5.2
WM7 will be BASED on CE6.0
Neither will be creatable/editable using the CE shared source as windowsmobile is not shared source.

True hehe
forgot Windows Mobile 6.0 is based on CE 5.2
Was a quick read and post on my pocket pc
Apologies

Might still be useful,
If we can get Windows CE 6.0 to run on a device...
It may be possible to get Windows Mobile 6 to run using a CE 6 core?
Windows CE 6 should be backward compatible with Windows CE 5.2 (although new drivers will probably be needed)
Long shot, but just might work...
(isn't Windows Mobile just a pretty shell for Windows CE?)
Problems:
*Probably against the Microsoft license. (Donations? Maybe can even buy Windows CE 5.2 Tool Suite)
*Windows CE 6 Core needed for Windows Mobile might be significantly bigger than Windows CE 5.2 Core.
*Need to know everything Windows Mobile uses in Windows CE to build a working core.
*Device Drivers may have to be rewritten depending on how much Windows CE 6 differs form Windows CE 5.2 (Will be easier with source code)
*Getting it to work will require quite a bit of development and research

basically, it's not impossible, just highly unlikely.

hehe any volunteers
I know its crazy, but there are huge benefits in getting this to work.
(Far less limitations in what we can do)
I would investigate myself but it looks like I am about to be computerless for the next 4 weeks!

OK, I hate to burst your bubble even further, but I don't think it will be possible at all.
Why?
1) They are only publishing the Kernel, and there is a lot more to the OS than that.
2) Because of the different kernel architecture the drivers will defiantly need to be rewritten and for that they will have to be reverse engineered first. Just look a the state of various Linux projects to see how long and hard something like that would be.
3) M$ is notorious for making OSs that are not forward compatible - namely although the difference between WM 6 and 5 is almost non existent compiling a simple "Hello word" app with WM 6 SDK will prevent it from running on a WM 5 device (bad exe error).
Also, the fact that they are "releasing" the code does not make it open source. It will still require a ton of paper work to get and you will probably have to be a real company or at least an academic establishment to get it.
M$ already gives out a lot of code for previous embedded OSs under special license.
So by the time someone leaks the code, figures out a way to patch together new kernel and additional required components from previous OS, plus reverse engineers and rewrite drivers for a given device not only that device will become obsolete but the whole CE line.
My guess is, a few years from now phone size devices will be powerful enough to run a normal OS like UMPCs do today.

levenum said:
1) They are only publishing the Kernel, and there is a lot more to the OS than that.
Click to expand...
Click to collapse
I don't want to compile the whole of Windows Mobile 6, just the parts that don't allow it to be run on older devices (or newer) e.g. nk.exe
(I haven't downloaded the kit yet so I don't know if this is possible or not, could be, could not be)
levenum said:
2) Because of the different kernel architecture the drivers will defiantly need to be rewritten and for that they will have to be reverse engineered first. Just look a the state of various Linux projects to see how long and hard something like that would be.
Click to expand...
Click to collapse
Many Windows CE 4 (Windows Mobile 2003 SE) drivers are used on a Windows CE 5.2 (Windows Mobile 5) platform. So there is a slight chance they may work in Windows CE 6.
levenum said:
3) M$ is notorious for making OSs that are not forward compatible - namely although the difference between WM 6 and 5 is almost non existent compiling a simple "Hello word" app with WM 6 SDK will prevent it from running on a WM 5 device (bad exe error).
Click to expand...
Click to collapse
An application written in a new operating system will not work in the old operating system.
but an application written in the old operating system usually works in the new operating system.
Otherwise microsoft would have many very unhappy customers.
Windows Mobile (non core parts) are basically old applications...
levenum said:
Also, the fact that they are "releasing" the code does not make it open source. It will still require a ton of paper work to get and you will probably have to be a real company or at least an academic establishment to get it.
M$ already gives out a lot of code for previous embedded OSs under special license.
Click to expand...
Click to collapse
You can already download it
http://www.windowsembeddedkit.com/
levenum said:
So by the time someone leaks the code, figures out a way to patch together new kernel and additional required components from previous OS, plus reverse engineers and rewrite drivers for a given device not only that device will become obsolete but the whole CE line.
My guess is, a few years from now phone size devices will be powerful enough to run a normal OS like UMPCs do today.
Click to expand...
Click to collapse
This thing runs WINDOWS VISTA
http://www.htc.com/product/03-product_HTC_Shift.htm
Heres another one, running windows XP
http://www.sonystyle.com/is-bin/INT...AIONotebookComputers_UX_Series&Dept=computers
We will not know the true amount of work needed until someone tries.
And if it is not a lot of work it will make a few people quite happy.

Well...
Me, i can not see the point in a project like this... Why would you even want to re-do microsofts sh--t.
Use the manpower and resources for the UNI Linux project.. They are allmost done... Just a few glitches now...
I wanna get away from MS asap... but i like this HW...

Windows XP Embedded on HTC devices?

Hi folks
Recenty I got the Windows XP Embedded kit, and I was really satisfied and surprised with the performance of the directly built system on an old machine like a P1 @ 200 MHz with 64 MB of RAM, without a hard disk.
The main goal would be to run truly win32 apps on mobile devices, to give better functionality and compatibility.
Yet the builder supports x86 architecture only, but cannot be a big problem to port it to ARM pocessors.
What might be difficult are these things:
-Getting win32 drivers for built-in devices (ex. integrated SDIO/USB WLAN, BT adapter, touchscreen, and sound devices, and apps for them!)
-Saving user data on turning off (Ebmedded systems are designed for a workstation, like a cash register: prebuilt apps, and nothing more comfort ) like WM200x
If anybody has any suggestion are to get a warm welcome
bye

Yet the builder supports x86 architecture only, but cannot be a big problem to port it to ARM pocessors.
Click to expand...
Click to collapse
Are you kidding me?
This would mean reverse engineering and recompiling every binary in the OS.
Do you have any idea how many hours something like that would take?

yup, you're right, but in theory it's possibe. I've seen a running DOS on a Microchip micro-controller, or for example the Atmel STK 1000 is Linux based, also seen an mPlayer app operational on the demo board at the college.
as you see, i'm not an experienced programmer, but i'm not afraid to ask
Yeah, the basic low-level binaries must be recompiled, and once it's ok, it might be usable with regular win32 apps, until you run an old DOS app, wich directly access the hardware.
A few years ago i was able to port Z80 software to 8086, and it wasn't easy.
I don't really know these things, just want to see opinions, possibilities, and suggestions.

exe files are binarys which are instructions directly for the cpu
it's not parsed by the operating system
so compiling the os is not enough every application needs to be recompiled too

The programs you mentioned have source available in one way or another (since DOS is very old there are clones, like freeDOS).
If you have the full source for an app and the right compiler, porting it to another CPU is feasible.
But, this is not the case with embedded XP. Getting the full source is impossible which means most of the system will have to be rewritten from scratch.
Just look at the Wine project to see what it takes, and they "have it easy" - they are just trying to simulate the APIs not change processor architecture. (Lets make it clear - ARM instruction set is very different from x86).
And as Rudegar said it will not let you run any program that has not been specially compiled for ARM CPU.
I know it sounds like we are trying to kill you idea here but its nothing personal, unfortunately it just isn't feasible. We would all like to be able to run desktop apps on our devices, but simply having embedded XP on them would not accomplish that. Also while many old DOS apps can be run using various emulators like pocketDOS, almost all Win32 apps take more resources than our little gadgets can offer.
I am fairly sure though that in 5 -10 years that problem will be fixed.

<_< man hours or not, reveng'ing this will have a bigger impact than just winDOS Mobile devices. Desktops have a use for this, definitely (because the Vista-Only crap is starting to hit the market). Too bad they don't provide assembly in programming classes anymore, obviously because they don't want anyone else to reverse engineer anything and spoil their foisting fun. <_<
In any case, IIRC XP Embedded is missing the install/uninstall engine, so you can't customize it after it's flashed onto the board. This isn't quite a good start - XPLite or 98Lite are better for reverse engineering from scratch (but they're too powerful for mobile devices).
The other alternative is porting ReactOS, which is a reimplementation of W2K. Those guys are "having a lot of fun" getting things to work, tho. <_<

Maybye Windows CE6 yes, but Windows XP Embedded no, because they must run at 686-AT/X platform IMB. Sorry of my English

linux would be a path
with most linux programs you can compile them yourself
using good old
./configure
make
make install
of cause gui programs could have issues displaying correct
on such a small screen

You MIGHT be able to pull it off by installing a minimal (very!) WinMo firmware and then have it autorun Bochs, which is known to be able to run the PC version of XP.. A customised, thinned-down XPe image should run fine under Bochs.
--W5i2

[Q] Windows 8 on ARM

As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
- No native support for x86 apps on ARM, nor ARM apps on x86. Only .NET apps would work in both worlds.
But it is possible to create an emulator similar to DosBox that would run native x86 programs on WoA and, for example, I'm currently working in this direction.
- Though existing C++ apps can be recompiled for ARM from sources, it is not a 100% working solution. Current VS11 contains a rather limited set of ARM libraries - no DirectX libs earlier than 11, no import libraries for NtDll.Dll and similar DLLs.
I don't have access to any WoA builds, so I can't check whether these features are completely removed from ARM, or those LIBs are just not present in current VS11 build. But at least now we can compile test apps for ARM and analyze the code (though we don't have where to execute them yet).
- Native WoA programs use THUMB2 instruction set (ARMv7 and above). Though ARM instruction set would be supported too.
- According to "Microsoft Portable Executable and Common Object File Format Specification v8.2" WoA machine type in PE files would be 0x1c4, and some new relocations types are added (for example IMAGE_REL_BASED_ARM_MOV32T = 7). IDA understands such EXE files, though complains on relocs.
- SEH is implemented in a different way than on x86 (similar to x64, google for RtlAddFunctionTable to get the idea).
- WoA is more secure by default. For example TPM can be rarely found on x86, but it would be required on ARM.
- Most of existing drivers are source-code compatible with ARM (of cause if not using x86-specific stuff). But ARM would never allow to load unsigned drivers (unlike x86 Win7/8).
- As platform is completely new - all ARM drivers would be added to windows update site to simplify our life. Some obsolete hardware like 1394 is not implemented at all, so there would not be so many drivers for ARM llike for x86.
- All binaries would be the same for all SoC providers.
- No "native" ARM VisualStudio - developer tools are x86 only.
WoA requirements from different sources:
- 10.1” display with 1366x768 min resolution (though smaller screens may be supported with reduced functionality)
- Volume Control, Windows, Rotation, Lock power buttons
- Dual core CPU with hardware accelerated GPU
- at least 1 Gb RAM
- min 16 Gb fixed storage
- 100mW idle power in standby
- there are rumors that there would be standart "Phone call API" ("Apollo" UI)
Does anyone have access to ARM WDK? It would definitely contain a complete set of import libraries and would provide lots of info on WoA internals in headers/documentation. Seems that Windows 8 WDK on MSDN does not have ARM tools

so your bottom line says: no w8 on arm (ever)?

I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
The UEFI requirement is expected, and I doubt will be that much of a hurdle. UEFI is all open, and it should be pretty trivial to chainload a UEFI-compatible environment on top of the existing firmwares, provided that nvidia doesn't provide us with an implementation to start with, which I suspect they'll do.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two. A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Everything I could find relating to the TPM says that it's optional, but will be automatically utilized if available.
The rest is pretty inconsequental, at least to what I think most people here are interested in.
nvidia started a windows 8 development program for ARM (Clickey here), but I haven't seen anything else from it, has anyone else gotten anything?

mamaich said:
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
Click to expand...
Click to collapse
Actually they said it would continue to support BIOS for older devices.
See: Current machines dual-booting Windows 7 and Linux should be able to upgrade to Windows 8 without wiping out the Linux install. As Microsoft notes in the Building Windows 8 blog, “We will continue to support the legacy BIOS interface.” However, machines using UEFI instead of BIOS “will have significantly richer capabilities” including faster boot times and greater security. (from Arstechnica)

That's for x86. ARM was said to require UEFI. Besides, there is no real bios on Android tablets, at least not a common platform.

netham45 said:
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
Click to expand...
Click to collapse
I've got it in one of the "windows-on-arm" non-public documents dated the first half of this year. While UEFI,ACPI,TPM are an option for x86, they are required for ARM hosts.
So no custom WM8 bootloaders, drivers, patched kernel on ARM hosts (like "windows activators" do) until sign keys would be leaked or some backdoors would be found. Of cause this is good as this would make rootkit creation more difficult, and require device drivers signed by MS (so we'd get more stable OS) but I really don't think that this "protection" would last more than 1-2 months after WoA would be released.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two.
Click to expand...
Click to collapse
I'm already working on such tool. It emulates x86 instruction set with dosbox or bochs CPU emulation library (I'm using both of them for debugging purposes, while working on my own one that would be much more simple->faster), translates x86 WinAPI to "native" host WinAPI + emulates API that is not present or differently implemented on WoA. It is designed to be truly cross-platform, so just a recompilation + creating several thunks/stubs would be necessary when I'll get my hands to an ARM host running windows8.
Of cause programs that use heavy anti-debugging, self-modifying code, undocumented features and SEH tricks would not work. Currently it is rather far from being finished (I have to implement&debug WinAPI and COM thunks that cannot be automatically generated) but old games like "heroes of might and magic" are already working fine in a test environment.
A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Click to expand...
Click to collapse
Of cause I'm talking about "ultimate" VS11, as express is designed to target mostly .NET (though ARM compiler is present there too).
And WDK that it published on MSDN does not allow creation of ARM drivers. I'm currently in a process of renewing my company's MSDN subscription, so I can't prove that myself, but I've read that on OSR forums.

I am waiting to hack my iPad and put win8 on it

I would hope touchpad would be the next viable option. Hp could still make more and just dump W8 on it. Thanks all of you for working this thread. I will be reading your progress as it unfolds. Good Luck devs and if I can find anything you will be the first to know.
Sent from my mwp6985 / Trophy using XDA Windows Phone 7 App

Some information on Win8 "Apollo" is available. Apollo - is a name for a new "windows phone" OS from MS.
- Apollo is based on the same "desktop" code as Windows 8. No Windows CE at last!
- Apollo would provide the same user experience as old Windows Phone 7.x - Metro UI, People hub, builtin office apps, etc. Seems that software compatibility with WinPhone 7.x apps would be preserved, but this is just my own guess.
- All applications on Apollo are required to be signed, similar to Windows Phone 7.
- Device drivers can be written only by IHVs, MS and OEMs, not by ISVs. This would be a problem for antivirus vendors or tools like daemon-tools.
- There would be a "built-in" eMMC card with OS and vendor partitions, and maximum one SD card. eMMC supports NTFS, SD-card supports only FAT/exFAT.
Build-in eMMC would have C:\ drive letter, SD-card would be D:\ if present.
eMMC contains several partitions. Some of them would be made readonly during boot.
- Near Field Communication is built in.
- The same list of sensors as in WP7 Mango is supported.
- There would be BSOD like in a desktop OS
- Unproven, but it seems that only .NET ("Splash UI framework" and "Silverlight") APIs would be available to independent developers. So no native code again.
- Seems that x86 architecture is supported for Apollo too.

Windows 8 and the Death of the Command Line(?)

http://catholictechgeek.blogspot.com/2012/08/does-windows-8-and-winrt-mean-death-to.html
The article above has my full thoughts, but I wonder if there is a bit too much push for the graphical user interface in Windows 8 (and WinRT) and because of this, the survival of the command line in Windows (the thing that a bunch of the rom tools run on) is in jeopardy.

Given how worthless winRT is, useful programs like kitchens will never, ever appear on them. MS will have to keep the command line unless they want to lose everyone to linux/mac.
Even android phones have a working command line.

Just thought I would confirm that the Command line (cmd) is still present in Windows 8. As far as I'm aware there was never any talk about removing it.

they will never remove the command prompt, neither the new powershell....
on RT version, the final user will never use it.. but I think that will be present...

m0nkf1sh said:
Just thought I would confirm that the Command line (cmd) is still present in Windows 8. As far as I'm aware there was never any talk about removing it.
Click to expand...
Click to collapse
Correct, the command line is still there as well as PowerShell.
WinRT resembles Windows 8 in UI looks only. Nothing under that is the same as Win8.
It's like comparing an Android Device to a Desktop PC and wondering why you can't run the same programs on them.

Talderon said:
WinRT resembles Windows 8 in UI looks only. Nothing under that is the same as Win8.
hem.
Click to expand...
Click to collapse
actually it is still the NT kernel in WInRT adapted to ARM underneath I believe, similar to Windows phone, but yeah possibly no command line but i'd hope maybe powershell might be there...

And now the whole situation of "same program, different architectures" is back (after about 6 years).I remember back in the early days of Windows Mobile, you had the issue a developer releasing different builds of the some program for ARM, MIPS, and SH3. Eventually, ARM won out and program installation packages were (somewhat) standardized. Now, we have the issue between ARM and x86. Luckily, Microsoft has made this easier with the windows 8 store, so things aren't fragmented like before. This is probably why there is no real Desktop mode included in the ARM build of Windows 8.

Steven855 said:
And now the whole situation of "same program, different architectures" is back (after about 6 years).I remember back in the early days of Windows Mobile, you had the issue a developer releasing different builds of the some program for ARM, MIPS, and SH3. Eventually, ARM won out and program installation packages were (somewhat) standardized. Now, we have the issue between ARM and x86. Luckily, Microsoft has made this easier with the windows 8 store, so things aren't fragmented like before. This in probably why there is no real Desktop mode included in the ARM build of Windows 8.
Click to expand...
Click to collapse
I don't see an issue with ARM vs. x86 in this same context as the x86 tablet will run like an Ultra Mobile PC.
ARM will be treated the same as Mobile Phones of the same architecture as it is today.

>However, there is still no word yet on whether Microsoft will include the command line for the ARM build of Windows 8.
According to this presentation slide of PowerShell 3.0 (at TechEd 2012), PS3 will support Windows RT. If PS is present, by extension CLI is available.
http://video.ch9.ms/teched/2012/na/WSV414.pptx

e.mote said:
>However, there is still no word yet on whether Microsoft will include the command line for the ARM build of Windows 8.
According to this presentation slide of PowerShell 3.0 (at TechEd 2012), PS3 will support Windows RT. If PS is present, by extension CLI is available.
http://video.ch9.ms/teched/2012/na/WSV414.pptx
Click to expand...
Click to collapse
And there we have it folks!
I am still waiting on word on when we can pre-order the MS Surface. So far, from the Spec's everyone else has shown for their offerings, not much reason to jump ship to another brand. (yet)

Press Windows Key +X and you'll see two command prompts shortcuts...

this should be clarified - ROM tools in Windows RT aren't going to have a barrier in the shape of a command line so much as they'll have a barrier in that all current windows ROM utilities are either for x86 CPUs or Java (and java has no Windows ARM VM) and as such wouldn't run on WinRT's command line anyway.

I don't think an X86 emulator will be an option for Windows RT and the ARM architecture either.

The command line is actually alive and well in Windows 8 and Windows Server 2012. If anything Microsoft is moving the capabilities of the command line forward in recent years. The Power Shell allows to configure a huge part of Windows and Server Software based upon it (e.g. Exchange) that previously was not easily configurable through scripts.
Concerning Windows RT on ARM tablets the problems go much deeper than the command line. The RT-Apps won't be able to install device drivers for Smartphones to access them - this will also be true for official companion apps. Unless there is a class driver like for many printers, keyboards, etc. Windows RT simply won't support connection to those devices (again, this only applies to the ARM version).
For many reasons x86 isn't going anywhere and this limited support of peripherals is just one of them.

According to the Synofsky blog post, RT does support at least the v4 print class driver, but not v3. No mention is made for other peripherals, however.
http://blogs.msdn.com/b/b8/archive/2012/07/25/simplifying-printing-in-windows-8.aspx
It depends on what role MS sees for RT going forward. If RT is to be a limited OS to compete with Android/iOS, then printing support may be it. But if RT is to be a full counterpart of x86, other peripherals support will need to happen.
Looking long term, ARM will play a larger role than x86 in the trend of ever-smaller devices, with increasing emphasis on battery life. From this, my educated guess is that RT won't be the ugly duckling for long.
Let's face it, RT is a work-in-progress. Peripheral support is Windows' strongest card against the other mobile OS'es (and Linux). My take is that it will happen contigent to the above, but it won't be this initial iteration.
In short, don't take the limitations of this v1.0 as being cast in stone.

Talderon said:
Correct, the command line is still there as well as PowerShell.
WinRT resembles Windows 8 in UI looks only. Nothing under that is the same as Win8.
It's like comparing an Android Device to a Desktop PC and wondering why you can't run the same programs on them.
Click to expand...
Click to collapse
Actually, that is factually incorrect. Windows RT shares substantial code with Windows 8, as Microsoft has confirmed many times in the Windows 8/RT development blog.