yashsingh1/xdaforums huggingface dataset:
[Windows RT Development and Hacking] SixSixSevenSeven:
technically feasible: yes.

Realistically: never.

If we got a java runtime on RT and OpenGL drivers then yes, it would work on RT. But even running natively it might be pretty slow. Via x86 emulation java itself would probably be unusably slow if it even launched, LWJGL (the java library minecraft uses) wouldnt work (as it uses OpenGL and we dont have that) and as a result you wont ever be running minecraft via the x86 emulator.

Java on windows RT is theoretically possible but the open source JVMs capable of running minecraft under more normal circumstances rely on GNU compiler tools, we dont have any which target windows RT yet. We do have IKVM which is a java runtime which works on windows RT, but IKVM doesnt load any libraries with native code which includes LWJGL (and thats on a full windows computer, not windows RT).

Even once java is here. LWJGL will stand in the way, LWJGL is an OpenGL wrapper which is great and all that, but the RT doesnt have openGL. To write an OpenGL driver ourselves would be almost impossible, few people have the knowledge to even get started, let alone finished, and none of those people likely have the time and resources to make a start, it would be a collosal undertaking for which even if the whole community pooled in it wouldnt get done. You need professionals to be paid to do it, and that would be microsoft + Nvidia/qualcomm. Probably not going to happen. Its rumored windows blue might include OpenGL ES so it might be technically feasible to modify LWJGL to use OpenGL ES rather than OpenGL.
[Windows RT Development and Hacking] domini99:
Aaaawwwwww :(

WINDOW RT SUCKS JUST AS 8 DOES

No jk. But rt does kinda sucks. Win8 on tab = Ok

Sent from my tabing thing..

STICKPLANT COMPANY (r)
[Windows RT Development and Hacking] GoodDayToDie:
.NET 3.5 is not included on RT (or, I think, on Win8 by default; it will install on first use). The problem is that there are incompatibilites between major .NET versions, for example some of the APIs included in .NET 1.1-3.5 are not present in .NET 4.x, and therefore any app which calls those APIs won't work even if you edit it to claim it doesn't require the old version specifically. Even a simple recompile wouldn't work; you'd get complaints about missing functions or even classes. Porting to the newer versions is usually easy; I've done a few times, in a few hours for about 10MB of C# source code, but it does need to be done.

That said, decompiling the app (using any of the many free and easy-to-use decompilers for .NET) and updating the deperecated APIs, then recompiling, should make it work on RT just fine. I agree with Mamaich's priorities here; focus on Win32 native code, and don't worry about .NET.
[Windows RT Development and Hacking] hisoft:
About the program code. I contact developer and he said if he change .NET version to newer it will cause the problem to many user.

For now to decompiling program maybe become my only choice. The program itself update from time to time but if I can done it one time I think it no problem for next time.

Thank you very much GoodDayToDie. :good:
[Windows RT Development and Hacking] lilstevie:
Java on ARM is really poorly managed, ARM CPUs for a while now have supported methods of accelerating java, either through Jazelle DBX (Direct Bytecode eXecution) which is now deprecated, or Jazelle RCT (Runtime Compilation Target) commonly known as ThumbEE, these technologies are seeminly disappearing in ARM, but had they have been utilized we would probably have a far better JVM for embedded systems.

LWJGL already supports OpenGL ES 2.0, it would just be a matter of having a) a JVM that works efficiently on our hardware, and b) having OpenGL ES 2.0 drivers in Windows RT.

OpenGL ES drivers are rumoured to be coming to Windows Blue, and we can only hope that is the case. The hardware supports GLES, as do nVidia (on android and linux)
[Windows RT Development and Hacking] netham45:
LWJGL's OGLES support is experimental last I checked and uses different java-side code to invoke the OGLES methods. Even if LWJGL was ported it would still require a partial rewrite of Minecraft's rendering code.
[Windows RT Development and Hacking] mamaich:
I have not thought about mono, 3.0.10 version currently does not work. Mono may work in the future, when more COM interfaces would be implemented. But it may be better to make a native mono port, so that we'll get the complete .NET on RT.
[Windows RT Development and Hacking] mamaich:
Every 5 seconds. This can be avoided in the future - remember that this is just a first attempt to hook x86 executables, and everything would be improved later. Anyway autohook currently does not stop your device from sleeping when not used, so it should not have noticeable effect on the battery life.

To run an x86 program you need - you may use c:\x86node\Windows\lauch86.cmd (for GUI programs) or lauch86c.cmd (for console) and specify EXE name as a parameter. Look at the "x86 command prompt" and "x86 registry editor" shortcuts for an example.
[Windows RT Development and Hacking] hisoft:
Thank you. I notice this launch method after post. now I can use drag & drop and shortcut while waiting for improved auto-hook. ;)
[Windows RT Development and Hacking] FearL0rd:
Can you make this work with windows phone 8?
[Windows RT Development and Hacking] C-Lang:
Windows Phone 8 may have a similar framework for "Modern" apps, but it doesn't have all of the framework for .exes that Windows RT does. Possible? Very dubious maybe with a completely rewritten framework. Realistic? Not at all.
[Windows RT Development and Hacking] mamaich:
It would be really hard to do, as windows phone lacks the needed Win32 API. It has some subset of Win32 API present, but it is far less than we have in RT.

It is possible to reimplement the needed API, but this would require lots of time.
[Windows RT Development and Hacking] SixSixSevenSeven:
We talking running the x86 emulator on windows phone 8 or running windows phone 8 apps on RT?
[Windows RT Development and Hacking] FearL0rd:
Maybe Blue will give us extra API's

---------- Post added at 06:51 AM ---------- Previous post was at 06:48 AM ----------

Maybe Blue will give us extra API's
[Windows RT Development and Hacking] mamaich:
I'm talking about running this emulator on WinPhone 8.

Regarding newer versions of WinPhone 8 - it would never contain complete win32 API, as MS really don't need it on phones as there is no need of classic "desktop" mode on them. There is no need on complete DirectX interfaces, full GDI and WinUser and other things not used in Metro. Some parts of such APIs are present, for example, to make MS Office and IE porting easier, but even those functions are probably suited only for the needs of the specific apps - they don't contain all those legacy compatibility tricks the existing third-party x86 apps depend on.

So I can say that though it is possible, at least in theory, to make my tool work on Windows Phone, and even on Android and iPhone - but this would require too much work and I would not even try to do this.
[Windows RT Development and Hacking] SixSixSevenSeven:
It is not likely that blue for WP8 will add the missing parts

Windows phone 8 has almost 0 relation to windows 8 and windows RT apart from using the windows NT kernel and being called windows.
[Windows RT Development and Hacking] GoodDayToDie:
Well, the phone also uses the WinRT APIs, but a slightly different set of them (much the way that CE implemented a slightly different set of Win32 than 9x and NT did). But yeah, not a lot of other similarities known at this point.

Breaking open the phone OS for running third-party non-sandboxed code would be the first step in any case, though. Doing that took a long time (well over a year) on WP7, and at this point after release we had more access into WP7 than we have into WP8 right now, so it could easily take even longer to get arbitrary code execution.
[Windows RT Development and Hacking] mamaich:
There was at least one method of running the unsigned code at high privileges on WP7 that was unpublished (it was workig since WM 5). Hint: provisioning sms. I don't have WP8 device to test, but it

may

be still working with modifications (for example after adding trusted certificates with provsms).
[Windows RT Development and Hacking] mamaich:
Updated the first post with the 0.06 version. It is a minor update - the keyboard should now work in Fallout2 and maybe some other games that are using DirectInput.
[Windows RT Development and Hacking] ausshir:
The update works great with Fallout 1 as well, but it broke Roller Coaster Tycoon.

The game installs fine from a mounted .iso, but now upon launching it says it cant reserve memory because the file is too big or corrupted. Used to run well in windowed mode (except for right clicking, which was broken).

Might have something to do with these log items:

[ 4964]E: Error 126 loading 'hid.nt.dll'
[ 4964]E: Func HidD_GetHidGuid not found in hid.nt.dll
[Windows RT Development and Hacking] hisoft:
You say minor update. But why the size increase to more than twice?
[Windows RT Development and Hacking] mamaich:
I've added almost all DLLs from MS DirectX 9 SDK redistributable.

Regarding Roller Coaster Tycoon - I'll look for it for testing. But I can't tell when the bug would be fixed - the real life takes too much time sometimes :).
[Windows RT Development and Hacking] hisoft:
:good: Looking for the future update. :victory:

I have some dll that include in Win86emu, same name as what program need to run, but not the same as program need. What I need to do in this case?
[Windows RT Development and Hacking] Jimm98y:
It seems the Autohook.exe is the reason why the WinRT app remote debugger stopped working. When I kill the process, I can debug WinRT apps remotely, but with it running get an error. Could you please look into it?
[Windows RT Development and Hacking] danthekilla:
I have tried to play 3 versions of fallout 2 but all of them give the same error (failure initializing input devices) and also all the installers fail (even the good old games one. I have tried versions 0.05 and 0.06.
[Windows RT Development and Hacking] ausshir:
Its staggering how much you have done with this so far! Rock on!
[Windows RT Development and Hacking] Jimm98y:
I am using the steam version with the unofficiall killian's patch and it works. I had a simillar error as you describe, the unofficial patch resolved it.
[Windows RT Development and Hacking] williams37:
Not a programmer of any sort, just trying techniques from other successful emulated x86 programs but running out of steam. I am trying

to run Sketchup 2013 on this tablet, but regardless of anything cant get a boot. Instructions for this are seemingly vacant, but if anyone

has any advice I'd appreciate it.
[Windows RT Development and Hacking] chris3ds:
Sketchup looks too CPU intensive to be suitable for x86 on ARM emulation, and since it's not open-source the option of an ARM port isn't a possibility either. Your best bet if you absolutely need to run Sketchup on a tablet would be to get an x86 tablet instead, Surface Pro would handle it fine, and you may even be able to run it on an Atom-based Windows 8 tablet - but it's unlikely there will ever be an option that would run the current x86 version of Sketchup on Windows RT.
[Windows RT Development and Hacking] SixSixSevenSeven:
Sketchup just about runs on an atom netbook I have access too, albeit VERY poorly. maxes the CPU just panning the camera.

Same goes for my 2ghz celeron single core laptop, it doesnt quite max the CPU when panning the camera but it is hardly the most responsive application.

This emulator on the other hand can be guestimated at 100MHz/0.1Ghz. Sketchup will never work.
[Windows RT Development and Hacking] williams37:
Gotcha. Unfortunately I couldn't wait for the 32 bit tablet to come out and jumped on the surface. I love it regardless, but was curious about the potential of this emulator. Just hoping that app store explodes sometime soon, we need it.
[Windows RT Development and Hacking] GoodDayToDie:
"32-bit" - that does not mean what you think it means.

Surface RT is 32-bit (check Computer Properties).

Surface Pro is 64-bit.

The important point is that Surface RT is ARM instruction set architecture (like a phone)

Surface Pro uses the 64-bit extensions to Intel's x86 architecture (sometimes called x64) like most PCs.
[Windows RT Development and Hacking] netham45:
Here's a more in-depth explanation to 32-bit vs 64-bit.

32-bit has, well, 32 bits for the word length*1. 64-bit has 64 bits for it. The length of a word can be shared across processors (Ex. ARM and x86 both use 32-bit words, IA64 and x86-64 both use 64-bit words)

That's important because a word is the largest value that a CPU can use for things like memory access.

32-bit: 1111 1111 1111 1111 1111 1111 1111 1111

64-bit: 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111

32-bit maximum value: 4,294,967,295d, or 0xFFFFFFFF, or 4 Gigabytes of allocation (This is why a 32-bit system can only allocate a maximum of 4GB of RAM)

64-bit maximum value: 18,446,744,073,709,551,615 or 0xFFFFFFFFFFFFFFFF, or 16 Exabytes of allocation *2

The bitness (32-bit Vs. 64-bit) does not determine the processor architecture. ARM, for example, is traditionally 32-bit (I believe that there is a 64-bit ARM, but I've never seen it in the wild), whereas most modern Intel/AMD CPUs are 64-bit, using the AMD64 instruction set.

THUMB2*3, which is what Windows RT uses, is an extension on the THUMB architecture. THUMB was originally 16-bit, and THUMB2 added 32-bit extensions to it. A lot of what THUMB2 does is only 16-bit (mov/movs for example move 16 bytes into the upper and lower halfwords for a certain register; the MOV32 instruction in MS's ARM assembler is simply a macro that does a mov then a movs), but it does have full support for 32-bit. Opcodes in THUMB2 mode are also a fixed length, unlike ARM.

1: PAE increases the length of a word to 36 bits on older CPUs that are still traditionally considered 32-bit processors.

2: 16 Exabytes of /theoretical/ storage, current hardware doesn't really allow for that. I also want to say that x86-64 has a limitation somewhere around 4TB, but I could be wrong.

3: THUMB/THUMB2 traditionally accompany the ARM instruction sets. The Tegra 3 supports both ARM and THUMB2 hardware wise, but due to THUMB2 being smaller (on account if it only having 16-bit opcodes) with a negligible speed hit MS chose to make WIndows RT only handle THUMB2. They also include what I believe to be a poorly written interrupt handler that always returns back in THUMB2 mode, so, while it's possible to run ARM code the CPU will switch back to THUMB2 at random, as far as your program is concerned.
[Windows RT Development and Hacking] SixSixSevenSeven:
The reason you haven't seen 64 bit arm in the wild is because it doesn't exist in the wild. Its an optional extension to ARMv8 chips. Tegra 3, tegra 4, enoxys, Qualcomm snapdragon etc are all ARMv7. So far I think only AMD (of all people) have licensed to manufacture ARMv8 in early 2015.
[Windows RT Development and Hacking] allymonty:
Had a look but couldn't see it answered or asked yet but I don't suppose anyone has tried getting football manager or similar running?
[Windows RT Development and Hacking] SixSixSevenSeven:
so the fact that we are essentially emulating at 0.1ghz meant nothing to you. Football manager needs closer to 2ghz.
[Windows RT Development and Hacking] jessenic:
The automatic exe loader mistakes AnyCPU .NET apps as x86 and tries to load them. Here's one for example:

http://xdaforums.com/attachment.php?attachmentid=1993479&d=1369597486 from http://xdaforums.com/showthread.php?t=2265773
[Windows RT Development and Hacking] mamaich:
Yes, this is a known bug. Would be fixed in the next build, but I can't tell when it would be ready.
[Windows RT Development and Hacking] calebrocca:
If you can use x86 apps then cant you make a 32bit emulator?
[Windows RT Development and Hacking] SixSixSevenSeven:
What?

Number of bits != system architecture.

ARM is 32 bit. x86 is 32 bit. It is just a trait of particular CPU types whether it uses a 32 bit word width or a 16 bit or a 12 bit or even 21 if you want to be weird and exotic (it exists).

If you meant running full windows 8 applications on windows RT. Then that is exactly what this already does.... Just slowly.
[Windows RT Development and Hacking] turilo:
Well I almost passed on the surface rt until I found this thread :D so hows it going so far? Is it worth getting the surface rt?
[Windows RT Development and Hacking] Chuckles34:
For those who are now going to buy an RT tablet because of this, you do realise there are atom (an x86 cpu) based tablets out there running windows8 for the same prices as RT tablets.....
[Windows RT Development and Hacking] netham45:
Please see this post that's literally on the previous page of the thread.

As far as x86 emulators, BOCHS was one of the first apps that was ported. It's just so slow that it's not worth it to use. DOSBOX has also been ported, which more or less emulates x86.
[Windows RT Development and Hacking] calebrocca:
In the future, could we use an emulator (or something) like this to run any program we download off the internet?
[Windows RT Development and Hacking] hisoft:
Even if we have high performance ratio and high compatibility emulator. But ARM and x86-64 CPU have many difference that make ARM CPU can't compare to the other one.

We have a slow ARM emulator on speed x86-64. If we try to emulate x86-64 on slow ARM we maybe get very very slow x86-64. :crying:

Don't misunderstand me. I don't care if it slow. The slow one were better than cannot open for sure. :D
[Windows RT Development and Hacking] calebrocca:
Thanks.

That cleared up my understanding a little.:laugh::silly:
[Windows RT Development and Hacking] GoodDayToDie:
I honestly can't parse what hisoft said, but the idea of "be able to run any program you download off the web" is more-or-less the end goal of this project. It's a long way from there, though, and most programs will still be too slow to be usable. Additionally, certain types of programs (such as those that require installing drivers) are not planned o ever be supported by this project.
[Windows RT Development and Hacking] hisoft:
Sorry for my bad English. :crying:
[Windows RT Development and Hacking] SixSixSevenSeven:
My understanding of what hisoft said is that x86 is a fast architecture. Arm is a slow one. Emulating a fast architecture on a slow architecture results in super slow speeds of the emulated architecture (x86).

I guess that's correct enough on a basic level. There is of course a lot more to it than that but it will do I suppose.

As for a faster emulator in future. Its possible to improve the speed. Its also very difficult, you guys are lucky enough to have it in the first place. Improvements were planned but the developer is a busy person. Even so, we're probably talking an emulated speed of approximately 0.2ghz as opposed to the current 0.1 (again, simplified, there is a lot more too speeds than the clock speed in GHz, but it gives a general idea at least).

Best bet is for a native ARM port of whatever game you want to play and chances are, if you paid a single penny for the game, it can never be ported. Open source only and at the moment only a subset of those. C, C++, c# or VB.net with visual studio solutions is about all you can port.
[Windows RT Development and Hacking] GoodDayToDie:
Well, you could always ask for ports... but yeah.

It's worth pointing out that ARM chips are getting faster, too. The Xbox 360 was able to quite comfortably emulate 500MHz (0.5 GHz, single core) x86 CPU on PPC (at 3.2GHz, 3-core with hyperthreading) 8 years ago; that's how all legacy Xbox games are supported. PPC is pretty efficient in terms of instructions per clock cycle, and the 360 had a ton of power to burn (compare its power brick to that of a Surface RT) and used a physically larger chip set at a much higher clock speed, but that was also 4+ iterations of Moore's Law back. The next generation of ARM chips are already much faster than the Tegra 3 used in Surface RT and most others of its generation. That speed boost will also improve the emulated speed. It will never catch up to then-current native performance, but (assuming RT sticks around this long) it *might* eventually catch up to today's x86 performance. That's a decade+ away, most likely, though.
[Windows RT Development and Hacking] jimmng:
finally

I've been lurking around these jailbreak threads for ages now. Finally decided to write ten posts so I can post here :)

anyways,

I've been really desperate to get my Logitech Setpoint software working on my Surface RT, as I have recently bought a t650 track/touchpad.

The device works great on RT, plug&play, press to click, scrolling works, charm/taskbar gesture works. Only problem bugging the heck outta me is that tap to click does not work! Thus I can't click when placing it on a soft surface as the buttons are on the bottom of the trackpad. And who wants to press click when they can tap-click anyways.

As I've read in previous posts that driver related software won't work, but i'm pretty sure this is pure software as the "touch to click" function only works when the setpoint program fully starts up on my win7 desktop.

I've gotten to the point where the setpoint software does actually start up by using the emu on the administrator account, but the window that pops up is just completely blank - white, I've tried pressing enter ; leaving it overnight cause it might be loading but nothing works.

I would greatly appreciate it if someone could get it ported/working with the emu.

I'll even give cookies and a 10 dollar aussie note if someone can get it working.

--update--

I've tried copying win7 installation folder and ran setpoint.exe it runs into errors seen in the log below.

00400000-00623000 : C:\Users\Jim\Desktop\SetPointP\SetPoint.exe

[ 9112]W: 04CB0000-04CC4000 : C:\x86node\Windows\System32\VERSION.86.dll

[ 9112]W: 04D00000-04D33000 : C:\x86node\Windows\System32\KERNEL32.86.dll

[ 9112]W: 04CD0000-04CE9000 : C:\x86node\Windows\System32\supp.86.dll

[ 9112]W: 04D40000-04D63000 : C:\x86node\Windows\System32\ADVAPI32.86.dll

[ 9112]W: 04D90000-04DA9000 : C:\x86node\Windows\System32\WINMM.86.dll

[ 9112]W: 04DB0000-04DC6000 : C:\x86node\Windows\System32\WSOCK32.86.dll

[ 9112]W: 04DD0000-04DF5000 : C:\Users\Jim\Desktop\SetPointP\KemUtil.dll

[ 9112]E: PeLdr can't open file: mfc90u.dll

[ 9112]E: Import dll mfc90u.dll not found

[ 9112]E: Import dll KemUtil.dll not found

[ 9112]E: Error loading program: 1168

Then I tried downloading the .dlls and chucked it in the x86node sys32 folder;

Got these errors

Many thanks,

Jim

tldr; need Logitech setpoint software on RT
[Windows RT Development and Hacking] SixSixSevenSeven:
It isn't open source so won't be ported, unless Logitech do it. No tap to click is very odd, I always thought it was a windows thing not a device thing.

You have had a peek in the mouse settings in control panel quickly?
[Windows RT Development and Hacking] jimmng:
Yep, no settings for tap to click.. and I doubt Logitech devs would create a setpoint RT program just for me.
[Windows RT Development and Hacking] sid8810:
I tried installing firefox, it installed but .. it wont start up. I try to uninstall it...says its running in the background i need to close it. So i cant uninstall this...any help? after a reboot does this hack go...the program doesn't start up. (win86emu)

done it, just deleted the firefox folder from where it installed. Any list of the exe files can you actually install with this ???

i really regret buying this RT surface, should have waited for the pro. I was so para about someone else buying it before me in my house...i went and bought it. I hope Imate release the windows 8 pro smartphone....it will be much better than this ...even if its 4.7 inch .
[Windows RT Development and Hacking] lostmsu:
Tried the patch on GoG version, still have Failed to initialize input error