Published the updated build. It adds some more DLLs, but still can't run most of the complex installers. Simple ones like 7Zip work fine.
your plan was to play age of empires on windows RT is this possible now??
Published the updated build. It adds some more DLLs, but still can't run most of the complex installers. Simple ones like 7Zip work fine.
Tried some torrents with new version of your tool, got a bunch of new errors, most of them are similar and are pointing at i<len error(what?). Also, foobar2000 worked. Well, almost..
I have an ancient modded foobar2k v.0.9.5 build called foodora. Default UI is not working, choosing "add folder" immediately crashes loader, "add files" just freezes like on screenshot.Could u please share your version of the app? I tried 1.0.3 and it installed however after running of exe file it crashes (
@Мамаич, плиз добей фубар, ну очень не хватает. Спс!
There's a store app for mail.ru, at least I think, that ICQ by mail.ru should support it. 2gis is not working, I tried it. Also, you may try recompiled Miranda IM client - there's a plugin for mail.ru.Mamaich (or other Guru), explain me please, should I use portable version of x86 programs or installable versions (.exe, .msi) with full installation process in your author's application? Tablet (ASUS TF600) is used by my wife. She wants native agent.mail.ru and 2Gis (not online versions!!!), but stupid mail.ru & Gis stuff didn't release versions of those programs for WinRT, as they promissed ((( So, I forced to find the way, to make agent.mail.ru & 2Gis run in WinRT. The solution I see is to run those programs in desktop mode using your author's application. But I don't know what variant of x86 soft do I need - portable or installable...
There's a store app for mail.ru, at least I think, that ICQ by mail.ru should support it. 2gis is not working, I tried it. Also, you may try recompiled Miranda IM client - there's a plugin for mail.ru.
Well, too bad for you, because 2gis is not working with "Can't reserve memory (file is too big or invalid format)" error, and I haven't tried mail.ru client, because I don't use it. WinRT apps like 2gis and mail.ru aren't happening any time soon - 2gis team has been promising an app for wp7 for like, more then a year now, and guess what? There's still no app. It's because people in russia seem to ignore whole wp and winrt platforms, why should developers care then? Best you can get now is 2gis online/yandex maps online, and something like miranda/IM+ for mail.ru. You may try to install it, though, but I'm pretty sure it won't work.So, I forced to find the way to make those apps to work in WinRT )))
Well, too bad for you, because 2gis is not working with "Can't reserve memory (file is too big or invalid format)" error, and I haven't tried mail.ru client, because I don't use it. WinRT apps like 2gis and mail.ru aren't happening any time soon - 2gis team has been promising an app for wp7 for like, more then a year now, and guess what? There's still no app. It's because people in russia seem to ignore whole wp and winrt platforms, why should developers care then? Best you can get now is 2gis online/yandex maps online, and something like miranda/IM+ for mail.ru. You may try to install it, though, but I'm pretty sure it won't work.
Sorry. I just discovered this thread.Not this question again...
Just use office for windows RT.Office 2010 will not run on the surface under x86 emulation, too slow.
Guess it's about time to add "Office 2010/2013 is not supported " to the first post on this topic, along with your excellent explanation on why Office emulation is not viable.Not this question again...
Just use office for windows RT. Office 2010 will not run on the surface under x86 emulation, too slow.
Or possibly just "yo, this forum has a search feature; use it before posting!"
office "x86 apps on WinRT" site:xda-developers.com
Here's some food for thought.
I've been trying to get Dropbox working via the x86 emulator, and after adding the missing DLLs to the x86 emulator's library, I noticed the following runtime errors
R6034 - An application has made an attempt to load the C runtime library incorrectly
R6016 - not enough space for thread data
Just thought i'd throw it out there for anyone who knows more about this and considers diving deeper for compatibility to allow offline syncing on RT
Not exactly a port, it is a clean remake based on the old ideas.heh, is this a port of the app you showed off back in the CE days? -awesome getting that ported over
The idea is very simple:
#define DEFINE_FUNC1(name) \
static const ModuleDef str_##name={DLL_NAME,#name}; \
EXTERN_C DW STUB_EXPORT stub_##name(DW p1) \
{ \
DW *p=&p1; \
__asm { mov eax,p } \
__asm { jmp f1 } \
__asm { mov eax,offset str_##name } \
f1: __asm { in eax,0xe5 } \
__asm { mov p,eax } \
return (DW)p; \
}
.....
#define DEFINE_FUNC3(name) \
static const ModuleDef str_##name={DLL_NAME,#name}; \
EXTERN_C DW STUB_EXPORT stub_##name(DW p1,DW p2,DW p3) \
{ \
DW *p=&p1; \
__asm { mov eax,p } \
__asm { jmp f1 } \
__asm { mov eax,offset str_##name } \
f1: __asm { in eax,0xe5 } \
__asm { mov p,eax } \
return (DW)p; \
}
....
DEFINE_FUNC1(AddAtomA)
DEFINE_FUNC1(AddAtomW)
DEFINE_FUNC7(CreateFileA) -- number in macro == number of parameters to a __stdcall WinAPI function.
Compiler automatically generates "ret N*4" at the end of such function.
I've decided to use such c+asm approach instead of making a tiny assebler stub,
as I can easily implement some of such functions in C directly in a stub DLL plus it
simplifies debugging. And the functions have a usual C prologue/epilogue, so that
the emulated program may even patch them in runtime, for example for hooks.
...
#define DEFINE_FUNC1(name) \
EXTERN_C DW STUB_IMPORT name(DW); \ -- this behaves like a function prototype to compiler
EXTERN_C DW STUB_EXPORT yact_##name(DW *R) \ -- R - pointer to the x86 stack
{ \
DW r=name(p1); \ // call the func passing it paramers from the emulated stack, p1==R[0], p2==R[1] and so on
LEAVE(1); \ // empty macro, as the stack is unwinded in x86 stub DLL now
return r; \
}
...
#define DEFINE_FUNC3(name) \
EXTERN_C DW STUB_IMPORT name(DW,DW,DW); \
EXTERN_C DW STUB_EXPORT yact_##name(DW *R) \
{ \
DW r=name(p1,p2,p3); \
LEAVE(3); \
return r; \
}
...
DEFINE_FUNC1(AddAtomA)
DEFINE_FUNC1(AddAtomW)
DEFINE_FUNC7(CreateFileA) // as you see - implementation part is identical to an x86 stub, so I can use the same stub-generator tool
static DWORD WINAPI ThreadProc(
LPVOID lpParameter // [0] == orig func, [1] == orig param
)
{
__EXCEPTION_REGISTRATION_RECORD R;
DWORD *Parm=(DWORD*)lpParameter;
DWORD *TEB=(DWORD*)PeLdrGetCurrentTeb();
R.Next=(__EXCEPTION_REGISTRATION_RECORD*)-1;
R.Handler=(void*)CbReturnToHost();
TEB[0]=(DWORD)&R; // in case of unhandled exception - just return
PeLdrNotifyNewThread(NULL,DLL_THREAD_ATTACH);
DWORD Ret=EmuExecute(Parm[0],1,Parm[1]); // 1 == number of parameters to the emulated function
delete Parm;
return Ret;
}
EXTERN_C DW STUB_EXPORT yact_CreateThread(DW *R)
{
DWORD* Parm=new DWORD[2];
Parm[0]=p3; // TODO: no out-of-memory checking for now
Parm[1]=p4;
DWORD StackSize=p2;
if(StackSize)
StackSize+=1024*1024; // I reserve some space for my own needs (debugging)
else
StackSize=2*1024*1024; // TODO: I don't support autogrow stacks, so reserve 2 Mb
DWORD t=(DWORD)CreateThread((LPSECURITY_ATTRIBUTES)p1,StackSize,ThreadProc,Parm,p5,(LPDWORD)p6);
LEAVE(6);
return t;
}