Database Info

Windows 8 phone? The ultimate phone?

Now that Windows 8 will support ARM and have a tablet touch interface, will it be possible for a company to make a Windows 8 phone? Just would need supported hardware buttons and ability to make calls and take a SIM card. Likely/unlikely?
This would be a boon for Windows Mobile users who will not have to wait for Windows Phone 9 for all their old features to come back. In fact they would have something more powerful by a long way than any phone ever made.
(Of course some people claim Windows Phone 7 will be based on Windows 8 anyway... but even if it is it may be limited in important ways.)

you won't like a phone based on a desktop ui.
sorry, but the mouse is antiquated.

ohgood said:
you won't like a phone based on a desktop ui.
sorry, but the mouse is antiquated.
Click to expand...
Click to collapse
Windows 8 has an optional tablet UI than does not require a mouse to do anything.

I think it will eventually be the same OS on your PC, Tablet & Phone yes. PC & Tablet are in Windows 8, and maybe not WP8 but perhaps the next one will be the same OS with a layout for the phone like you see now, and be dockable (like the Moto Atrix, only actually functional).

No need for WP8 as Windows 8 already has a touch based interface and the ability to turn off unneeded features automatically (not just programs but also under the hood operations), saving ressources and making it available on ARM powered devices.
Sent from my Nexus S using XDA App

Now some more information is out.
It looks like Windows 8 will have phone calling in the Metro interface:
http://www.istartedsomething.com/20110918/windows-8-to-include-phone-calling-capability/
So Windows 8 (Metro) will be useable as-is as a phone system.
The issue may be hardware. Processor speed, memory, GPU will be fine, but the problem is the minimum resolution.
Windows 8 Metro apps require 1024x768 resolution:
http://www.winmatrix.com/forums/ind...o-apps-require-1024-x-768-minimum-resolution/
For a phone 768 pixels on the smaller dimension is excessive. The Apple "Retina display" is 960x640 and Toshiba's upcoming(?) display is 1,280x720, still not enough:
http://www.pcmag.com/article2/0,2817,2385574,00.asp#fbid=I7vQ_5t19x6
So unless Windows 8 changes requirements (which seems quite likely to me) this will be the main problem.

When windows phone 8 comes out we have the best camera and other few changes lets hope wp8 will be awesome

Probably possible but I doubt it would ever be supported by major carriers.

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

Boot from SD card

Boot from SD card
This is a placeholder for some work I was doing on booting and alternate copy of Windows RT from SD card
by adding extra entries in the bcd store and a ‘copy’ of windows on the SD card
(or a reinstalled version of Windows RT installed onto the SD card)
Note it actually still boots from the system partition on the internal flash but tries to boot an alternate Windows installation from \windows on the SD card
However having problems getting it to find the SD card volume at boot time
Still working on that
and on how to use the recovery environment to install the OS onto SD card
Best to have a Class 10 SD card
But now moved on to dual booting Windows RT and RT 8.1 (both from internal flash)
http://forum.xda-developers.com/showthread.php?p=43062190#post43062190
Also working on booting a full OS from USB stick

That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.

Myriachan said:
That'd be quite cool. It'd also be an important part of a Linux or Android port to Surface RT. You could make an extremely-stripped-down Windows RT installation that boots just enough to run some exploit automatically. The exploit could load a kernel driver to do the equivalent of kexec() into Linux.
Such an installation on a USB stick could be a bootable Linux live "CD" as well.
Click to expand...
Click to collapse
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.

southbird said:
Someone just needs to actually come up with that exploit first. I'd totally convert my surface to a Linux device if it was available ... Windows is nice and all, but I love that warm, fuzzy feeling of having full control of hardware I own. I got CyanogenMod on just about every Android device I have, and getting out of the restricted RT arena would be awesome.
Click to expand...
Click to collapse
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.

Myriachan said:
The general idea behind netham45's exploit (which originates with a Google guy) would actually work for this. If you control the entire boot image, you can make cmd.exe start a script and cdb very early. There exists a modification to the technique to do the exploit without the two-minute instability problem.
If Microsoft doesn't lock out the 8.0 bootarm.efi, this would keep working after 8.1's release--just boot 8.0 to do this part.
The difficult part of this entire thing to me is how the hell to write Linux drivers for hardware we know nothing about.
Click to expand...
Click to collapse
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.

SixSixSevenSeven said:
Linux for tegra might be a start, think that is now upto tegra 3 specs. But there are still several unknowns like you say. Some disassembly might clear up a few more unknowns (is the screen DSI or LDVS, which interface is used for the storage as there is more than one which would be capable for eMMc usage).
We do know that all the sensors are i2c devices at least.
But yeah, there is alot of work for a community to do in order to port linux to the surface. Not unless microsoft release a few datasheets which they have no reason to. Making matters worse, not all RT devices would be the same so the surface RT would need a different port than dells qualcomm based tablet. Even the tegra based tablets might need a different BSP to each other.
I do think though that if there was linux on the surface RT then I would probably consider getting one. Would at least double the chances at any rate.
Click to expand...
Click to collapse
I'd imagine focusing on one at a time would keep you from getting overwhelmed, and I would think the stock Microsoft Surface RT is the one that makes the most sense to start with, at least get a proof of concept working. As far as "hardware we know nothing about", the Tegra itself is pretty well documented and I imagine it operates essentially the same as it does anywhere else.
I would imagine stages to doing this:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device.
3) If you get this far, obviously now it's all about getting the magic mix of drivers...
With an actual kernel running, most likely a lot of hardware would become more easily identifiable, and we could at least figure out where we stand. Of all these things, I imagine #1 is the most difficult to overcome, but there's been some suggestions.

southbird said:
2) Once this has been accomplished, start playing with ARM-based Linux bootloaders, with console output happening over I2C or whatever else works. This can allow for just trying to get the kernel to run, even if at first this renders a completely non-interactive device..
Click to expand...
Click to collapse
I dont think anyone knows the exact pinout but there is i2c on the connector for the touch/type covers, they are themselves i2c devices. If someone knew the pinout, theres your access. Stick some magnets on some card with a few pieces of wire sticking out of it, should be able to hold against the connector. But that doesnt matter so much.
I've heard of linux consoles being accessed over UART (infact I have done this with a raspberry pi) but not i2c. The tegra does have at least 1 UART though (I have a feeling it might have 3 or 4). Whehter you would have to tear a surface apart to get at it though is another matter. I know that several devices actually make the uart externally accessibly via either the USB or audio jacks with a quick pinmux. A nexus 4 for example you stick a certain resistor between the mic and ground channels on its audio jack and I think the left audio channel becomes Tx and right Rx or vice versa. A few android tablets (I think HTC are big on this) use the microUSB, certain resistor value between the sensor and ground lines as is often used for enabling USB host triggers D+ and D- to become Tx and Rx instead. No microUSB on the surface though. My guess if they ran one externally it would either be on the cover connector (there are 5 connected contacts yet only worked out a purpose for 4 of them, then there is 1 pin not connected to anything for some reason, probably future expansion, perhaps this 5th pin enables a UART instead of i2c???) or the audio jack, there might well not be one accessible externally at all :/
I would assume the surface screen is either LDVS or DSI, the prior is more likely to be documented than the latter (DSI isnt even fully standardised, in theory it is but in practise DSI devices are rarely compatible even with the same res, colour depth etc). May well be possible to output direct to that initially.
With the keyboard being i2c it may well be possible to write a driver to use it on linux on an existing device, not sure how well USB-i2c adaptors work but the pi has 2 native i2c buses.
I do agree that the surface is the logical starting point. Its probably sold the most units at any rate and is the first thing people think of when you say windows RT. Other tegra devices would be the most logical to follow on with, qualcomm would perhaps be able to reuse step 1 but step 2 you would likely have to start from scratch all over :/
Oh well, 1 hurdle at a time. Honestly though, the existance of a functioning linux port for the surface would make me tempted to buy one. That or microsoft unlocking RT to literally be windows 8 on ARM not windows 8 stuck in a cage.

southbird said:
1) Figure out the exact sequence to stop Windows and disengage the kernel, watchdogs, or whatever else in a stable way to start executing arbitrary code in RAM, with some kind of POC demo, e.g. getting data out over I2C or something, which we ultimately will need to debug a kernel.
Click to expand...
Click to collapse
There is already a method of running any unsigned EFI file (for example a GRUB loader). But it works only on Asus tablets and requires USB stick inserted on boot and Bitlocker turned off in Windows (as the "trusted boot environment" is broken). I'll publish it later - probably after 8.1 official release, as it can be easily closed by Asus in a next firmware update that may be required for 8.1.

windows 95 running on surface rt

start windows 95 Help on surface rt, really need the program electronic workbench 5.12, via an x 86 emulator, it is not.
I will use bochs, downloaded the BIOS file and VGA in tab CPU put the bad CPU, but still does not work. The configuration file can only be downloaded in the format of the bxrc format, the txt he does not understand. If that happens, put Please setup and working windows 95 image

I kind of doubt anybody else is going to bother with the effort needed to get Win95 running (it would run very slowly, although I suppose it was intended to run on very slow CPUs...) on a first-gen Surface RT, but hey, maybe I'm wrong.
Anybody familiar with Bochs configuration want to weigh in on the configuration issue? I never really did much with it.

GoodDayToDie said:
I kind of doubt anybody else is going to bother with the effort needed to get Win95 running (it would run very slowly, although I suppose it was intended to run on very slow CPUs...) on a first-gen Surface RT, but hey, maybe I'm wrong.
Anybody familiar with Bochs configuration want to weigh in on the configuration issue? I never really did much with it.
Click to expand...
Click to collapse
I really need the electronic workbench 5.12 "want to run it in any way, it is not a resource, the minimum requirements in the area of pentium 200 MHz

You'll be lucky if you get that equivalent of speed, actually. Typical estimate is order of 10x overhead for emulation, which means each core of the Surface RT is basically like a 130MHz x86 chip. Unless the emulator runs across multiple cores and the program does too (unlikely), you probably won't get much.
Have you considered running it on a real PC and just having the Surface remote desktop into it? Unless you're somewhere without an Internet connection, that's at least a little more likely to work.

Deleted due to forum software screwup

If they can run windows 95 on Android wear, Surface RT is certainly capable. If that's what you want to do, and have the ability to get it done knock yourself out.
https://www.youtube.com/watch?v=GZx-LJH5J_I

Whether or not it's *possible* to run 95 wasn't really in question - people have, in fact, booted later versions of Windows via emulators - but rather whether it's a practical way to run even a very old program.
If anybody were still maintaining the RT x86 dynamic recompilation layer, I'd say to work on getting it working in that; the performance is a lot better when you don't have to support an entire OS and can execute OS library code in native instructions rather than emulating even the low-level functions. However, I don't think even the source code for that program was ever released. :-/

Weigh in here
Deleted due to forum software screwup
Click to expand...
Click to collapse
What happened? HAHA
Also I would like to weigh in here. You (mickel2255) should have done a simple forum search. Gooddaytodie has a list and in it is an x86 emulator that I tested with electronic workbench 5.12 and it works no problem.
List of desktop apps for hacked RT devices http://forum.xda-developers.com/showthread.php?p=36534446
Click to expand...
Click to collapse