Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[Beta] Win86emu: Running x86 apps on WinRT devices

OP mamaich

16th February 2013, 11:54 AM   |  #101  
Senior Member
Thanks Meter: 325
 
1,620 posts
Join Date:Joined: Dec 2012
Quote:
Originally Posted by francesco.piccia

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.

---------- Post added at 10:54 AM ---------- Previous post was at 10:50 AM ----------

Quote:
Originally Posted by WizardCM

Would it be possible to support The Sims 1/2 in the future?

HTML Code:
[092DF098]W: 051B0000-05201000 : D:\The Sims 1\IMM32.dll
[092DF0A7]E: Import User32InitializeImmEntryTable not found in C:\Program Files\win86emu\System32\USER32.86.dll
[092DF0A7]E: Import WCSToMBEx not found in C:\Program Files\win86emu\System32\USER32.86.dll
[092DF0D6]W: 05210000-05214000 : D:\The Sims 1\API-MS-Win-Core-LocalRegistry-L1-1-0.dll
[092DF0E6]E: PeLdr can't open file: API-MS-Win-Security-Base-L1-1-0.dll
[092DF0E6]E: Import dll API-MS-Win-Security-Base-L1-1-0.dll not found
[092DF0E6]E: Import dll IMM32.dll not found
[092DF0F6]E: Error loading program: 1168
[092DF0F6]   Logger unloaded

Ignore those errors for now. There is a greater issue.

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)
16th February 2013, 10:05 PM   |  #102  
Junior Member
Thanks Meter: 2
 
24 posts
Join Date:Joined: Nov 2012
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?
16th February 2013, 11:20 PM   |  #103  
Senior Member
Thanks Meter: 325
 
1,620 posts
Join Date:Joined: Dec 2012
Too demanding. Requires a 500MHz CPU. This has been estimated at 90 I think someone said.
17th February 2013, 11:41 AM   |  #104  
OP Recognized Developer
Thanks Meter: 214
 
1,150 posts
Join Date:Joined: Apr 2004
Donate to Me
Quote:
Originally Posted by GoodDayToDie

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.
The Following User Says Thank You to mamaich For This Useful Post: [ View ]
17th February 2013, 12:20 PM   |  #105  
OP Recognized Developer
Thanks Meter: 214
 
1,150 posts
Join Date:Joined: Apr 2004
Donate to Me
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.
Last edited by mamaich; 17th February 2013 at 12:32 PM.
The Following 2 Users Say Thank You to mamaich For This Useful Post: [ View ]
17th February 2013, 02:58 PM   |  #106  
Junior Member
Thanks Meter: 2
 
24 posts
Join Date:Joined: Nov 2012
Quote:
Originally Posted by SixSixSevenSeven

Too demanding. Requires a 500MHz CPU. This has been estimated at 90 I think someone said.

Yeah, but I'm wondering if it'd be possible with future, more optimised builds. Surely 90MHz isn't the highest that it's physically possible to go?
17th February 2013, 03:20 PM   |  #107  
Senior Member
Thanks Meter: 325
 
1,620 posts
Join Date:Joined: Dec 2012
Quote:
Originally Posted by Warmijwilf

Yeah, but I'm wondering if it'd be possible with future, more optimised builds. Surely 90MHz isn't the highest that it's physically possible to go?

As said in the post before yours it can probably be improved a little. 90MHz, not amazing but it is a considerable improvement on not being able to run x86 at all.



Mamaich. Keep up the excellent work. If you can complete a more optimised core then thats great. If not then you have already done an excellent service to the community.
17th February 2013, 05:23 PM   |  #108  
Member
Thanks Meter: 3
 
32 posts
Join Date:Joined: Mar 2012
Support Thread
Is their a thread that shows compatibility of apps/games with your emulator? does age of empires currently work at all?
17th February 2013, 05:58 PM   |  #109  
Senior Member
Thanks Meter: 325
 
1,620 posts
Join Date:Joined: Dec 2012
Quote:
Originally Posted by lebow

Is their a thread that shows compatibility of apps/games with your emulator? does age of empires currently work at all?

I think a thread is planned.

Age of empires might *just* work. Its bare minimum is a pentium 90 CPU.
17th February 2013, 10:37 PM   |  #110  
Recognized Developer
Flag Seattle
Thanks Meter: 2,763
 
5,810 posts
Join Date:Joined: Jan 2011
More
@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.

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes