Trying to run Slender x86, it say that i miss Opengl32.dll
What can i do?

Its quite simple really. Slender uses OpenGL. Windows RT does not support OpenGL or OpenGL ES. I believe in the porting apps thread someone mentioned a theoretical workaround to have software OpenGL but that would be incredibly slow.

The effective speed of this emulator is only about 90MHz. Far far below what sims requires (and slender as mentioned above actually). Would probably take ages to get to the main menu, wont ever be playable. Hell, the first sims wasnt very playable on my old 800MHz machine (although it did only have an ancient fastvoodoo GPU)

This is probably an extremely dumb question, so forgive me for asking, but theoretically with this would I be able to use it on my Surface to play Morrowind? Don't need it to be highest or even medium settings, low at 640x480 would be enough, but I'm assuming it's possible, right? If not, maybe one day?

In an effort to curtail the sudden deluge of "what can I run?/Why can't I run.../It doesn't work!" posts on here (which I admit I may have contributed to), it may help to start up a second thread for win86emu app compatibility.

It is a good idea to open the thread where to post not only the list of working apps, but also the instructions on getting them running. I was planning to open such thread later, when the list of the supported apps would become too big to fit into the first post here.

The next public build would be delayed for about a week or two, as I have to make an additional tool. I'm trying to automate the generation of wrapper DLLs using header files from windows SDK, and now looking for a good C++ parser. Or for a good database of WinAPI functions with all parameters. Or maybe I'll parse the web site of http://www.pinvoke.net. Or maybe I'll get my hands on the AST generated by LLVM clang compiler, or maybe something else. I thought about using PDB files, but I can't get function args as all type information is striped from them.

Regarding the speed.
I think on making my own x86 CPU emulation core instead of using DosBox and Bochs. That core would be optimized only for 32 bit x86 code, linear memory, no PF and AF CPU flags (they are not used in windows apps, only small subset of FPU flag testing functions are using them), for other flags - I'd try to use native CPU flags as much as possible. The translation process would be using all of the CPU cores you have to pregenerate needed code before its execution. I may store the generated code in some intermediate form on disk so that it may be more heavily optimized later when the program is not running. The engine would support self-modifying code, but the speed would be optimized for programs that don't modify themselves. This would give a good speed, much faster than the dynamic DosBox core.

The work on that engine would not start earlier than at the end of this year. Currently I'm working on the WinAPI - the stability and completeness are the first goals.

@mamaich: That is fantastic. For myself, I'd usually recommend using the Clang C/C++ parser for this kind of thing; it's much better documented and easier to extend than GCC, and also has a very clear compilation pipeline that makes it easy to pull out the specific layer of the process that you want to use and pipe it into another codebase. TCC (Tiny C Compiler, originally by Fabrice Bellard*) is another possibility, though I don't know if it supports all the calling convention "keywords" used in MSVC sources correctly (which you would obviously need). It's smaller than Clang though, which may make using it for a specialized purpose easier.

As for writing your own DynRec engine, that would be an incredible project - one which I would truly love to see, and which I would strongly recommend that you open-source for collaborative development - but I'm glad to see you've got a good plan for compatibility first. While gaming would be (already is, actually - I love HoMM3 as well) a great acheivement, most of the programs that I want to run are simply small utilities that were never open-sourced, or possibly even some that are too much hassle to port. With those, perf is much less of an issue. Maybe I'm in the minority, there, though. Regarding the project itself, self-modifying code or even anything using JIT compilation sounds very tricky (offsets constantly changing due to different instruction sizes, probably needing to use copy-on-write for modifying code and then recompiling the written instructions and fixing the offsets) but it occurs to me that one of the huge improvements it could give is to take advantage of the processor-specific optimizations already present on the Tegra 3 (and any other chips you target). Even with a nominally RISC ISA (like ARM), some instructions will be more expensive than others and using more efficiently selected instructions may improve speed over straight transliteration of the x86 code.

* himself an excellent hacker who once wrote a full x86 emulator using JavaScript and hosted a website that allowed running Linux in the browser. It even works on RT (or my WP7 phone, for that matter) but It's uselessly slow for this purpose. http://bellard.org

@SixSixSevenSeven: Please don't take the "90 MHz" statement as gospel. For one thing, it's an incredibly rough approximation based largely on numbers pulled from my ass. For another, that was based on "will it run SC?" not "what is the actual emulated speed?" so while it's a reasonable statement that "it will probably be possible to run SC even if not quickly, and the requirements for AoE are about the same", it's probably not accurate to say "the emulated CPU runs at this speed."

Also, CPU clock speeds only tell a portion fo the story. As I mentioned above, some instructions are faster than others, and this largely depends on the CPU being used. The Core iN series of Intel CPUs often run at a lower clock rate, per core, than most Pentium 4 chips did. However, they are far, far faster than the P4 at real-world operations, because the P4 architecture ("netburst") was very poorly optimized for certain operations, such as branching; if it "guessed" wrongly at the outcome of an "if" statement, it had to throw away potentially dozens of clock cylces of work to refill the pipeline with the other branch's instructions. Since the performance of win86emu isn't going to exactly duplicate any Intel or AMD CPU, you can't really make a statement of "it runs at the speed of an X CPU at Y MHz" even if we had a proper way to measure that.

Speaking of which, though, it may be good to get some additional benchmarking tools to run. 7Z uses a fairly simple set of instructions, and while it's interesting as a data point, it's not an ideal indicator of how fast many other types of program (games, audio decoders, OpenGL emulation in software, any kind of AI, anything heavy on floating-point, anything that makes a bunch of system calls through the win86emu stub DLLs, etc.) will run.

XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality.Are you a developer?