Related
First, I am new to this forum and apologize if this is posted to the wrong topic.
Does anybody know of a way (either native setting/registry tweak or 3rd party app) that allows you to set up a timed activesync while also using the Direct Push technology? In my tests on my Cingular 8125 (upgraded to newer ROM than factory) I use Direct Push and it is WONDERFUL with the exception that it seems only the "inbox" folder is pushed. I use rules on Exchange that sort certain items into other folders. Although they sync when i manually start an activesync, they do not update through Direct Push. These items are not as important as my Inbox, but it would be nice if, say, the device could do an ActiveSync every hour or so. However, if I put the ActiveSync schedule to anything other than "As new items arrive" the Direct Push becomes disabled.
This cannot be very hard to code, because from my research there are new APIs available, specifically ActiveSyncStart and ActiveSyncStop in activesync.h which start and stop activesync manually from a 3rd party app. However, they are only available in Unmanaged code (ie, C++) and my Visual Studio only has VB.NET and I cannot figure out for the life of me any way to marshall those functions.
Anybody know of a little 3rd party app that can initiate activesyncs on a timed schedule while having DirectPush enabled? Or is anybody with VC++ and Mobile SDK up to writing one?
Solution
I figured out the solution to this problem (in case anybody is interested).
The documentation at MSDN appears to reference the wrong library (i can't even find an 'actsyncc' which is what is in the MSDN article). The DotNet P/Invoke for VB.Net should be...
Private Declare Function ActiveSyncStart Lib "aygshell.dll" () As Integer
Private Declare Function ActiveSyncStop Lib "aygshell.dll" () As Integer
From there, it's as simple as just creating a timer that fires up "ActiveSyncStart"
I may not know unmanaged C++, but I know my VB.Net.
I’ve just received a question from one of my blog readers about how the built-in Web browser in the Pocket PC / Windows Mobile operating system, Pocket Internet Explorer (PIE) / Internet Explorer Mobile (IEM) can be configured to request pages in different language than US English if you use an English language Windows Mobile operating system.
As this question is a very interesting one and very few people have the necessary HTTP- and actual programming (let alone offering a proxy server for free that does the trick!)-level knowledge to answer this question, I’ve decided to write a complete article on it.
What's the point? When can this be useful?
There are a lot of Web sites that offer their content not only in English but also in several other languages. The most important example is Google or, for example, many blogging engines. For example, b2evolution(the engine used in the Smartphone & Pocket PC Magazine Expert Blogs) returns English pages by default. However, if you configure your local Web browser to request Web pages in another language, you'll receive Web content in that language.
For example, if you set your referred language to, say, Finnish, you'll get this (Finnish language) page instead of this (English original) when you try to log in. And, the list continues - there are a LOT of other pages, frameworks, content management systems that do take into account what language the client prefers and return their Web content accordingly.
Making use of this capability can be of enormous advantage for people that don’t really have a good command of English and would like to prefer content or, at least, menus and dialogs in their native tongue.
How can you instruct desktop Web browsers to request Web pages in the language of my choice?
With Internet Explorer, go to Tools/Internet Options/ General and click Languages in the Appearance group. Then, just click the Add button and choose the language you prefer from the list. Make sure you move it up the list (with the Move Up button) so that it'll be your primary language.
As far as the desktop Opera browser is concerned, I'll elaborate on it later.
The desktop Mozilla/Firefox must be configured in exactly the same way as the Pocket PC version (screenshot) - see below.
OK; now, how I configure my Pocket PC Web browsers to do the same?
It's, unfortunately, a bit more complicated. Read on!
A bit geeky stuff: HTTP and Accept-Language
(Note that understanding this section is not needed if you aren't a tech / geek type of person. However, trying to digest it can be very useful to understand my HTTP request header screenshots and to understand how, for example, my proxy servers work.)
First, to understand how the HTTP servers (that is, Web servers) are able to decide in which language they should return the requested Web page, it's very important to know that the HTTP protocol (the protocol used in communicating between a Web server and a browser) uses so-called 'HTTP request headers'. These requests tell the Web server what resource to get, whether it's cached on the client (so that the server only needs to return the resource again if it's been changed in the meantime), whether the client has 'cookies' stored about the server to maintain Web sessions and so on.
One of these headers is called 'Accept-Language' and tells the Web server what language the client prefers (with, optionally, an additional country code and/or quality setting when there is a list of preferred languages). For example, if you'd prefer pages in Finnish instead of the default English, this header looks like the following:
Accept-Language: fi (or, Accept-Language: fi-FI - both are valid and can be used. The first, lowercase 'fi' stands for Finnish, the second, uppercase 'FI' stands for Finland. Note that, in general, the country code can also be lowercase; from now, on, I use lowercase letters to denote the country.)
If you'd prefer your preferred language to be Canadian French, you can use the following request header:
Accept-Language: fr-ca
And, as far as strictly US English is concerned, you'll often see this header:
Accept-Language: en-us
In order to be able to return a Web page tailored for your language preferences, the Web server MUST receive every HTTP request (Web page download) containing the Accept-Language header. If it doesn't receive it, it will in no way know what is your preferred language and will, in almost all cases, return the default one (English in most cases).
Does the system-wide Regional Settings have any effect on the preferred language?
Unfortunately, modifying the regional setting in Settings/System/Regional Settings doesn’t change the “Accept-Language” HTTP header sent out to the Web server (it’s based on this HTTP request header that most HTTP servers – except for Google, which uses a bit more sophisticated algorithm, which I’ll elaborate on later –, if they have content in more than one language, decide what language they should return their content in) – not even in the latest WM5 AKU2, as can also be seen in this screenshot. I took the screenshot on a Dell Axim x51v with the latest, AKU2 A12 ROM, after setting the regional setting to Germany (and rebooting). It certainly shows IEM sends out requests telling the Web server that it prefers U.S. English pages, no matter what the operating system setting is.
PIE AcceptLanguage in the Registry
Fortunately, WM2003SE+ IEM/PIE does store the language code in the Registry (and it, even more importantly, does use it) under HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International\ AcceptLanguage. How it is accessed under different operating systems, however, is varying.
First, under Pocket PC 2000 (the first Pocket PC operating system version), there is no International key at all as can also be seen in here. That is, it’s futile to create the above value in the Registry – it just won’t work.
Under Pocket PC 2002 and WM2003, this value does exist with the value “en-us” for devices with the (American) English ROM. These operating systems, however, do not take this value into account and don’t send out any Accept-Language header as can also be seen in this and this screenshots for PPC2k2/WM2003, respectively.
It’s only with WM2003SE+ operating systems (WM2003SE and WM5) that PIE copies the value of this string value to the HTTP request. However, interestingly, on English devices, the value, by default, doesn’t exist (unlike on Pocket PC 2002 / WM2003 devices, where, much as it does exist, its value isn’t used in the communication with HTTP servers in any way) – this is why I, at first, didn’t realize it’s there and usable. (I've tested this on four different WM5 devices (x51v, hx4700, Wizard, Universal) and on the WM2003SE PL720. None of them had this value, unlike, again, my Pocket PC 2002 Compaq iPAQ 3660 / WM2003 HP iPAQ 2210.)
(Note that there are two other places of the registry having PIE/IEM-related information: HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows\ CurrentVersion\ Internet Settings and HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Internet Explorer. There, however, is no language-specific information in there.)
All in all, if you have a WM2003SE+ Pocket PC, you can just create a String value named “AcceptLanguage” under the HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International key with the correct language code (with, when needed, also the country code if it’s necessary).
If you don’t want to create the value by hand, I’ve created a registry import file to do the job for you. It’s available HERE. All you’ll need to do is importing it with a Regedit5-compatible registry editor like Resco Registry Editor (please also see this roundup of registry editors for alternates / converting the file to REGEDIT4 format to be able to import with REGEDIT4-only registry editors like Kilmist and Tascal.) Don’t forget to change ‘en-us’ to your language first (for example, ‘ru’, ‘fi’, ‘fr’ etc.) Also, you may want to use some kind of associated quality value as is defined in section 14.4 of the official HTTP 1.1 header specification. (For example, to express "I prefer Danish the most, but will accept (preferably) British English and, finally, other types of English", use the string “da, en-gb;q=0.8, en;q=0.7”)
Do PIE/IEM plug-ins let for changing the language?
Unfortunately, PIE/IEM plug-ins like PIEPlus, MultiIE or Spb Pocket Plus (click the links for the latest reviews!) don’t let the user directly supply this vaue – ypu’ll need to directly modify the Registry in order to configure this value.
What about NetFront?
As far as alternate browsers are concerned, NetFront 3.3 sends out the ‘en’ language code by default . While it is supposed to have support for changing the request language, it, as with many other NetFront features, is buggy.
In order to test this yourself, you'll need to create a new User-Agent entry in (Menu/)Tools / Browser Settings / Misc (as the default entry can’t be modified). There, choose an empty (or, if you've already defined an alternate User-Agent setting, anything different from the default "NetFront v3.3 Standard" custom setting. In this screenshot, I show an example of selecting an empty entry - you'll see this before creating any new User-Agent record. After this, just click the Edit button on the right, give the new setting a new name (in the top "Title" textfield; in this example screenshot, I've called it "Finnish NetFront") and, in the bottom-most "language" input field, enter the language code (in this screenshot, "fi"). Now, click OK; the new entry will be selected as can be seen in here. Now, you can give the new settings a try; as can be seen in here, the language code sent out is still the default 'en'. (Note that in this example I've also changed the User-Agent to 'My custom Accept-Language tester User-Agent to show what U-A is sent out' from the default 'Mozilla/4.08 (PDA; NF33PPC3AR/1.0) NetFront/3.3' so that we can see Netfront indeed sends out the modified header.)
Note that NetFront has a “Base language” setting in View/Advanced Setting. The setting (which can’t be fine-tuned; for example, North-European languages are only a group and not individual languages), has no effect on anything (it only tells the browser the default encoding it should use when trying to render the page brought back) either.
What about Opera Mobile?
Opera 8.6 doesn’t send out any Accept-Language header at all (click the links to see the screenshots showing this!).
Note that, on the desktop, Opera supports this and it can even be freely redefined in the GUI. I’ve checked the desktop INI files to see whether it’s there that this information is stored (many desktop-based configuration options are also accepted and interpreted by the Pocket PC version of Opera Mobile). Unfortunately, that’s not the case.
NetFront and Opera Mobile – a summary
All in all,
unfortunately, as of their current versions (8.6 of Opera and 3.3 for NetFront) neither of these browsers look up/use the value of HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International\ AcceptLanguage
you can’t configure them either to do so: the built-in request language feature in NetFront doesn't work
In a later section, I'll elaborate on how you can still add/modify an/the Accept-Language header when using these two apps.
What about Thunderhawk?
Thunderhawk also sends out the english-by-default header. Unfortunately, it can't be modified in the Settings dialog, it doesn't take into account the PIE/IEM registry setting and, as Thunderhawk doesn't let you use proxy servers, you can't use external proxy servers either to modify this header. This means it's fully impossible to change the language preferences using Thunderhawk, as opposed to all the other browsers.
What about Minimo?
The (as of writing) latest (08-27-2006) Minimo nighly build offers seamless Accept-Language definition capabilities.
While it doesn't use the PIE/IEM registry value for overriding its setting, you can easily modify the header. To do this, enter the “about:config” URL in the address bar. You’ll be taken into the preference list screen. There, just enter ‘lang’ in the Filter field and, then, you’ll be taken right away to the intl.accept_languages property as can also be seen in this screenshot. Double-click intl.accept_languages and edit the value as you find it OK and press Enter. Then, in the config list, “default” will change to ‘user’ and the headers will indeed be correctly sent out.
Paragon Language Extender
Paragon Language Extender is a well-known language changer application (including HTTP request modifying capabilities) for all Pocket PC (and Handheld / Palm-size) operating systems prior to WM5 (there is no WM5 version and never ever try to install the Language Extender on a WM5 device – I’ve tested it on the WM5 Dell Axim x51v; I had to hard reset).
Among other things, WM2003+ versions of the Paragon Language Extender also support dynamic language change as can be seen for example in here:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
In this case, ‘de’ denotes I’ve installed the German extender; the screenshot also shows it has its own German-language dictionary.
Interestingly, the Paragon Extender doesn’t create HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International\ AcceptLanguage. It does “sit on” the operating system and inserts its own Accept-Language header into the outgoing PIE requests. (Note that if you do create HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International\ AcceptLanguage by hand, it’ll override that of Paragon).
Note that there are two major versions of Paragon Lang. Extender: and old, PPC2k/PPC2k2-compatible, 4.23 version still available for non-major languages (that is, not available for, say, German or French but available for, say, Finnish, Bulgarian or Arabic) and a new, WM2003/WM2003SE version (the latter is build 4710 for for example Finnish). Unfortunately, the former does NOT make the PPC2k2 PIE send out the correct header. That is, it’s not possible to make the Pocket PC 2002 PIE to send out the correct request with either using Paragon Lang. Extender or, as we’ve already seen, by directly overwriting HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International\ AcceptLanguage.
Finally, in WM2003SE, the Paragon app is not recommended over the “traditional” way of overwriting HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International\ AcceptLanguage – it's an overkill and I only recommend it for “plain” request language modification if you need its other capabilities too.
Note that if you don’t need your device to be fully translated, you won’t need to install the full version – the second, Compact setup (as can also be seen in here) will do just fine. The results after the setup will be as follows:
What can I do if I want to browse the Web with a Pocket PC 2002 / WM2003 PIE or with Opera Mobile / NetFront?
You have two choices.
if you have the capability of running a proxy server somewhere (even on your Pocket PC PDA with a suitable Java Virtual Machine (please read this article and search my blog for the word 'Java' for more info) - after all, it's multiplatform); for example, on a 24/7 online desktop PC,
with a client that can be configured to use an external HTTP proxy (in this regard, Thunderhawk is disqualified) and does send out the Accept-Language header (in this case, NetFront), you'll need to use an external proxy server to change the language code sent out to another one before sending the request further, to the target Web server. If you have a Java Virtual Machine (easily downloadable from here - select 'Java Runtime Environment (JRE) 5.0 Update X'), I’ve written an easily modifiable, open-source (source here) HTTP proxy server available here. You will only need to start it with the command
java HTTPProxyAcceptsLangHeaderRewrite portnumber languagecode
if you have a JRE (I’ve compiled the class with JDK 1.3, so, any JRE will do) installed on your PC (again, you can get it at the above-linked Sun page).
For example, the command
java HTTPProxyAcceptsLangHeaderRewrite 8080 cool-eh
will result in the following response from http://www.proxydetect.com/ (after you correctly set up your Pocket Internet Explorer / NetFront browser to use the proxy - please see for example this article on doing so):
This shows that indeed the (of course non-existing) ‘cool-eh’ language code was sent to the server.
If you, on the other hand, have a proxy-configurable client that does not send out the Accept-Language header (the case with PPC2k2 PIE and Opera Mobile), you’ll need to explicitly add the header to the headers relayed to the HTTP server. To do so, you'll need this Java class file (source here). Its usage is exactly the same as with the previous bullet.
The results of using this header-adding proxy server can be seen for example here (showing Opera Mobile).
[/LIST]
Mail the webmaster of the given webpage to do a dynamic country lookup depending on the client’s IP (internet) address instead of the Accept-Language header. Say, if you have a Thai client IP address, you would receive a page with Thai content even if your Web client sent out an Accept-Language header of ‘en-us’ (or no language code at all). Many Web sites do so – for example, even Google. Google, if it doesn't receive an Accept-Language header or the header (if it does exist) is the standard one requesting English pages, then, just looks up the country of the client and returns the content accordingly, in the local language of the country. If the Accept-Language header exists and it's set to something other than English, it'll return the page in that local(ized) language. This is what Web server administrators should strive for.
What about devices with non-English ROM's? If I, say, dump / sell my English Pocket PC and get a German one, will I get German pages instead of English ones?
Note that I wasn’t able to reliably test how and what Accept-Language headers the Web browsers on a Pocket PC with a non-English ROM send out. I don’t think the built-in PIE would request English pages on a Pocket PC with a German language ROM, but I may be mistaken (after all, PIE / IEM isn't the most sophisticated Web browser). The same (I don't know how it behaves on devices with non-English ROM's) stands for NetFront, which does send out the language header. Finally, as far as Opera Mobile is concerned, I seriously doubt it’d send out the correct header on any (non-English) Pocket PC – after all, it doesn’t seem to be sending out any kind of language header. (Incidentally, it has the ‘Accept-Language’ string once in opera.dll but there doesn’t seem to be any parameter to it.)
Acknowledgements
My blog reader ‘Begemot’ from Russia to point out the never-anywhere (give for example searching for “AcceptLanguage” a try on major PPC boards like PPCT, Brighthand, AximSite, XDA-Developers (and on Google) etc. Note that, on the latter, there will be some (false) hits because of the MMS handler app on WM PE devices) discussed (this is why I didn’t know of it before either – and, as the given AcceptLanguage value only exist under PPC2k2 / WM2003, I haven’t run into it in the Registry either) HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International\ AcceptLanguage. Without him, I wouldn’t have been able to write this tutorial in its present form. Thumbs up
The Netfront-related part of the article updated – along with a new Netfront bug I’ve just found. I’ve also slightly modified the PIE-related part with new, WM2003-related info.
Ok, I've seen numerous questions about the app called HTC Performance & have disassembled the executable. While my knowledge of these thing is by no means great, I have found some very interesting functions.
Maybe someone with more reverse engineering & code experience can take a look, but with IDA Pro there are some very interesting functions & strings.
Some of the calls & code are deprecated & no longer used in WM6 + but some of them are.
It is possible, especially for evB equiped roms, that this prgram acts like a server of sorts for some programs & processes. But being as it is initiated with Smartphone only functions I doubt it.
some of the more interesting functions in the HTC Performance app are:
SHInitExtraControls Which appears to be for Smartphone only
GetSystemMetrics WM6 Pro valid - Gets System Width & Heigth in pixels. Posible uses include program optimization based on the appropriate pixel returns
CreateMutexW - coredll - used to connect to core via net cf for obtaining device info- Usually eVB related apps use to call coredll info
memmove = takes more memory than memcpy but may be used to ensure unicode strings not used on odd memory addresses, this could increase speed on apps that incorrectly do this.
InterlockedCompareExchange, InterlockedDecrement, InterlockedExchange, InterlockedExchangeAdd, and InterlockedIncrement = functions provide a simple mechanism for synchronizing access to a variable that is shared by multiple threads. The threads of different processes can use this mechanism if the variable is in shared memory.
InterlockedCompareExchange = function performs an atomic comparison of the Destination value with the Comperand value. If the Destination value is equal to the Comperand value, the Exchange value is stored in the address specified by Destination. Otherwise, no operation is performed
YAXPAX = can speed up access of written C++ Code
ReleaseMutex = Mutex functions are used to release shared functions
EnumWindows = (..) to execute a task. EnumWindows (..) enumerates through all existing windows (visible or not) and provides a handle to all of the currently open top-level windows. Each time a window is located, the function calls the delegate (named IECallBack) which in turn calls the EnumWindowCallBack (..) function and passes the window handle to it. Not sure howthis is used though.
LoadAcceleratorsW = ??? Appears to be old CE function. Deprecated???
realloc = String Optimization
malloc = RAM Allocation
GetDeviceCaps = gets dev info, can be used to the optimize redraw based on device constraints already known
LocalReAlloc = This function changes the size or the attributes of a specified local memory object. The size can increase or decrease.
EnterCriticalSection = The threads of a single process can use a critical section object for mutual-exclusion synchronization. The process is responsible for allocating the memory used by a critical section object, which it can do by declaring a variable of type CRITICAL_SECTION. can grant exclusive access to memory
ReleaseDC = This function releases a device context (DC), freeing it for use by other applications. The effect of ReleaseDC depends on the type of device context.
Again, I am not a programmer, I know a few things, & am pretty competent with the lower operations of firmware, but the rest of the CE code is not my cup of tea. There are many more functions in HTC Performance. These are only a few functions found after a brief 20 minute peak.
But maybe, maybe, some of the function calls can help us to understand if this app can be moddified to properly function on the Kaiser.
It is possible that on some evB enabled apps, that maybe some of the HTC Performance app are retained & possibly function, that is pure speculation though, & again I doubt it.
Any CE code experts out there wanna take a look? I have, & based on what I've seen, I'll have to say FICTION!
Info
Hi,
Since I haven't really had time to see whats new and all I haven't the foggiest idea what HTC Performance is/what it is supposed to do.
But I can tell you that the functions you listed are not special in any way. Most of them would appear in every application that displays anything on the screen. For instance getting system metrics is required for any application displaying scroll bars, etc. All the interlocked and critical section stuff is just thread synchronization.
But that's OK, the use of windows APIs really doesn't mean much, other than the application runs on Windows...its the non-API stuff that defines an application. If the application you're looking at writes changes to registry keys, etc. you may want to look into that as those would be the lasting changes to the device.
Cheers,
Why is there concurrency related stuff in there? Surely that should all be handled by the operating system, rather than a running application? (That said, most of my concurrency knowledge is either theoretical or based at a high level, so I could be wrong here).
High Performance Cab
You can also check this thread...
http://forum.xda-developers.com/showthread.php?t=366792
Quentin- said:
Hi,
Since I haven't really had time to see whats new and all I haven't the foggiest idea what HTC Performance is/what it is supposed to do.
But I can tell you that the functions you listed are not special in any way. Most of them would appear in every application that displays anything on the screen. For instance getting system metrics is required for any application displaying scroll bars, etc. All the interlocked and critical section stuff is just thread synchronization.
But that's OK, the use of windows APIs really doesn't mean much, other than the application runs on Windows...its the non-API stuff that defines an application. If the application you're looking at writes changes to registry keys, etc. you may want to look into that as those would be the lasting changes to the device.
Cheers,
Click to expand...
Click to collapse
No, registry would not necesarily be the place to look. For this application the registry will only report whether or not the App is running or not. It is supposed to be a speed optimization application. My thought were that it could possibly be acting as a server of sorts, handling some thread optimization & resource allocation. Correct though, most of those API's are importing device info, beyond that, I am lost as to how it handles it, if it does at all. That said, there are many things that don't show up in the registry & many things can't be altered via the registry b'c they are set or handled before initialization or loading of the registry, possibly thru the OAL. Even tougher to say in a two chip device with as little known info as the msm7xxx processors. If anyone with real coding knowledge could take a look at the executable & see just what it's doing with the info, that would be great.
dperren said:
Why is there concurrency related stuff in there? Surely that should all be handled by the operating system, rather than a running application? (That said, most of my concurrency knowledge is either theoretical or based at a high level, so I could be wrong here).
Click to expand...
Click to collapse
That is indeed the center of my question & also what leads me to question how the app functions. Is it playing a role in thread priority optimization, & possibly redraw based on the polls, or is it just a partially gutted application miising a ton of registry data that never worked?
The project is abandoned.
As I no longer own a Windows RT device and I'm not willing to use Windows RT anymore, unless Microsoft would make it more open (at least to run your own desktop apps) - I've decided to stop working on this project.
As usual I'm publishing complete sources of this tool. Feel free to use them in your own projects or to continue developing this one - only leave my copyrights somewhere.
Don't ask me how to build the sources or to explain anything in them. Figure that out yourself.
The project is abandoned. Sorry.
I'm presenting a tool that allows running a set of x86 Windows applications on Windows RT (ARM) tablets. Its goal is to support all apps except for those that:
- require much CPU power,
- use complex features that were cut out from WinRT like D3D9 extensions or OpenGL,
- require drivers or specific services,
- make heavy use of COM interfaces,
- use undocumented windows internals,
- apps that use .NET framework,
- x86 Metro apps,
- 16 or 64 bit Windows programs,
- buggy apps that require special workarounds.
The tool is currently on a beta stage, so don't expect much from it. It is far from being complete, but at least it runs something.
Current version: 0.061
Just a minor update. The project is not dead, I just had no time to continue the development.
Attached the fixed ntdll.nt.dll that works under Windows RT 8.1 (Microsoft removed some NTDLL exports, so I had to add more stubs). This fix is not needed on RT 8.0.
To install it: extract the attached 0.061-ntdll.nt.dll.zip to c:\x86node\windows\SystemNT\ overwriting the existing file.
Autostarting x86 programs does not work on RT 8.1 ("can't install CreateProcessInternal hook"). I'll look on this later.
Don't ask on jailbreaking the 8.1 beta in this thread - there is a good progress on it, more info would be on release (in october or when WZOR would leak the RTM).
Current version: 0.06
Seems that archive is too big to be attached, so I've uploaded it to google drive and here
Installation: extract the archive on your unlocked Windows RT device, run the MSI file and follow the instructions.
Note: Uninstall the previous version before installing a new one.
List of compatible apps is in this post: http://forum.xda-developers.com/showthread.php?p=40924456
Trademarks
Windows is a registered trademark of Microsoft Corporation. ReactOS is a registered trademark or a trademark of ReactOS Foundation. All other trademarks are the property of their respective owners.
Disclaimer
This software is provided "as is". Use it on your own risk. I make no warranties as to performance, merchantability, fitness for a particular purpose, or any other warranties whether expressed or implied. No oral or electronic communication with me shall create a warranty of any kind. Under no circumstances should I be liable for direct, indirect, special, incidental, or consequential damages resulting from the use, misuse, or inability to use this software, even if I has been advised of the possibility of such damages.
I'm trying my best to make the software working, but I can't guarantee that it is free from defects.
All beta versions of this tool would be freeware. You may freely use it for your own, embed it into your tool, but you can't use it commercially without my confirmation. You can disassemble, analyze or modify this tool for yourself - later I'll provide SDK and document its internals. The only thing that is prohibited is changing embedded copyright notices. I reserve the right of making the project commercial, but this does not mean that this would ever happen.
This software contains unmodified binaries from the ReactOS project: a registry editor, cmd.exe, ole32.dll to name the few. Those binaries are left unmodified and are covered by LGPL license. Future versions may contain redistributable binaries provided by Microsoft and/or other companies.
Some more information may be found in my blog. If you want to support development - use the link or press the button on the left side of the post.
Changes:
15 may 2013: DInput and DInput8 changes for Fallout2 keyboard compatibility.
12 may 2013: A minor update. Fallout 2 now works, tested on Russian version from 1C.
01 may 2013: Added the ability to automatically launch x86 applications. Added the shell32 interfaces - so that installers now work (at least NSIS and InstallShield installers are known to be working).
05 apr 2013: Fixed a few bugs.
04 apr 2013: Uploaded a new build after a long delay. Now emulator supports 256-color modes. But due to a limitation on an updated Nvidia driver - 640x480 and 800x600 display modes are no longer supported on Windows RT. You'll see the black lines to the right and bottom of the screen if the program tries to set such mode.
25 feb 2013: The tool now outputs its version to log. Now one x86 program may launch another - so some of the installers and, for example, 7Z GUI frontend can now run under emulation. Added ~80 DLLs. Some of them are stubs (like D3D9.DLL), others are mostly untested. I have not done all that I've planned for this build, publishing it just as an update to show that the work is going on. Do not expect it to run much more than the previous build.
13 feb 2013: more informative errors from launcher. Emulator now supports program paths with spaces. EXE files with relocations are now processed correctly. Some bugfixes in kernel32 and advapi32.
11 feb 2013: fixed a typo in winmm.dll emulation, now pinball has sound. Also updated the launcher.
10 feb 2013: now the program reached the beta stage.
Known problems
No D3D and most of COM interfaces. Lots of programs would crash, don't run or have different issues.
Notes:
The program keeps its settings in the HKCU\Software\x86node\Settings registry key. Supported REG_SZ (string) values are:
DosboxCore: "dynamic", "simple" or "normal". Dynamic is the default as it is the fastest, but the most buggy core.
LogFile: path to the log file. If not present - log file is %temp%\win86emu.log
Supported REG_DWORD values:
LogLevel: 0=no log (default), 4=max logging
added 13 feb 2013: now default log level is 2: warnings+errors, so you don't need to edit registry
There are several compatibility hacks that may be useful. Compatibility settings are stored in HKCU\Software\x86node\Compatibility\[filename.exe] key. "filename.exe" - a name of the emulated EXE file without path. All values are DWORD:
SetProcessAffinityMask = bitmask. Specify which CPUs to use for running a program, read SetProcessAffinityMask description in MSDN. 0 or unset == run on all cores.
NoRaiseException = 1. RaiseException would just return. Now exceptions are emulated correctly, so this hack is no longer needed.
UseDirectRegistry = 1. Do not redirect emulated registry keys to HKCU\Software\x86node. Be careful when using it.
MaxProcessorFeaturePresent = max processor feature number that is "supported". See the IsProcessorFeaturePresent function in MSDN. All requests for the value above specified would return 0. Default: 0 (IsProcessorFeaturePresent always returns 0).
SimulateAdminRights = 1. Lie to installers that call OpenSCManager function to determine that it is running as administrator, allowing these programs to run without elevation. Redirect the "common start menu" and similar folders to the per-user folders.
You can fake the OS version to a running program. Default XP SP3:
OSVersionLo=dword:00000001
OSVersionHi=dword:00000005
OSVersionBuild=dword:00000a28
OSServicepackLo=dword:00000000
OSServicepackHi=dword:00000003
Some information on the project internals may appear in my blog: http://mamaich-eng.blogspot.ru, but this thread on XDA would be the main discussion place.
I may be missing something...but this won't run for me. The exe just tells me it can't be run like normal exe does. I am jailbroken and can run arm compiled exe.
That is very impressive, mamaich.
lucas.scott said:
I may be missing something...but this won't run for me. The exe just tells me it can't be run like normal exe does. I am jailbroken and can run arm compiled exe.
Click to expand...
Click to collapse
Reread the directions ?
I don't have an ARM tablet to test this on, but this type of development is what will get me onto an ARM tablet for the next go-round. I love my S7S, but I really hated paying the price.
dan-htc-touch said:
Reread the directions ?
Click to expand...
Click to collapse
ugh...embarassed.
Great work mamaich. Thank you!
Notepad from Windows 95 seems to run too.
wow,this is an awesome project!
Amazing! Thank you!!!!!!!
Would you mind giving a technical explanation?
mamaich said:
I'm presenting a prototype of a tool that allows running Windows programs compiled for a desktop PC (x86) on an unlocked Windows RT (arm) tablet. The tool emulates x86 instructions and passes Windows API calls to WinRT kernel with necessary modifications.
This build is an early alpha version. It can run only very simple apps that use rather small subset of Win32 API that I've already implemented. Archive contains clock.exe from NT4 distribution as an example of such app. As I'll continue work on the project - the list of supported applications would grow up.
This tool would support only 32-bit windows native applications. It would not allow running drivers or .NET apps that were written for old .NET versions nor Win16 or DOS apps. And current version supports emulation only of EXE files that contain relocations section (this would be fixed later).
Instructions:
1. Unlock your device with this tool: http://forum.xda-developers.com/showthread.php?t=2092158
2. Unzip the archive to any directory
3. Run _start_clock.cmd
This would execute the clock.exe from NT4 in the emulation mode.
This post would be updated as I'll make more progress.
Note: This is an early alpha version, and do not expect that it would run anything except the provided file. Do not ask me what programs would be supported and when the next builds would appear - I don't know, as I work on this project only on spare time. I would not publish the complete sources of the tool, but it would be extensible by users, and some plugins (at least bochs/dosbox emulation engines and some of the API wrappers) would be opensource.
"Yact" in the file names stands for "yet another code translator", it was the original name of the project.
Edited 13.01.2012:
- added a few ARM WinAPI workarounds, added calc.exe as a second example (run _start_calc.cmd).
Click to expand...
Click to collapse
heh, is this a port of the app you showed off back in the CE days? -awesome getting that ported over
This is great, really opens up a lot more things and means that we don't need to recompile everything either.
heh, is this a port of the app you showed off back in the CE days? -awesome getting that ported over
Click to expand...
Click to collapse
Not exactly a port, it is a clean remake based on the old ideas.
clrokr said:
Would you mind giving a technical explanation?
Click to expand...
Click to collapse
The idea is very simple:
- a PE file loader (load files, process relocs, run TLS callbacks in an emulation mode). Support import loops (DLL A imports B while B imports A), ordinals, etc.
- a set of wrapper x86 DLLs (kernel32_stub.dll and so on) that "look like" the corresponding Win API functions for an emulated program:
Code:
#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.
...
- a 32-bit x86 emulation engine (currently 2 engines: from bochs and from dosbox, planning on adding my own) that intercepts the command "in eax,0xe5", determines which API is needed by a program and passes it to a handler.
- native (arm) API handler DLLs (kernel32_yact.dll and so on). They are mostly autogenerated too:
Code:
#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
Some of the functions require complex emulation due to their absence in ARM or due to the callbacks to x86 code:
Code:
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;
}
Some of the COM interfaces are already implemented, for example DirectDraw and DirectSound, though not heavily debugged. On a desktop emulator build I can already run "Heroes of might and magic 3" and old WinRAR, but there are several RT-specific OS limitations I need to bypass before making them run on ARM. Current work in progress is: overcoming the RT limitations, manually implementing the API functions that callback to a program code (like CreateThread, RegisterClassA and so on), adding stubs for other system DLLs/COM objects.
Manually thrown SEH exceptions are fully supported, but access violation, int3 and similar OS-generated exceptions would cause program to crash. Some of the TEB fields (TLS and the fields required by the Borland compilers) are implemented too.
I don't make pointer translation in an emulated code nor make parameter checks passed to API. As a side-effect - the emulated program may trash the emulator in memory, but this greatly increases speed.
Most of the x86 EXE files don't contain relocations section and need to be loaded on the specific addresses (typically 0x400000). This is not a problem on a desktop, as I can rebase my emulator's EXE to any address I need, and free the corresponding RAM addrs for emulated program, but on ARM - this is a main problem. So currently only EXEs with relocs are supported for emulation, but there are ways to overcome this problem. And some EXEs produced by old Borland compilers contain "broken" relocs, this is a small problem too.
HI mamaich, sorry for disturbing you, may i know how do you compile visual studio project for arm ?, i already change windowsarmdesktop to true. But i can't find arm options in build settings. Any suggestion ?
rheza02 said:
HI mamaich, sorry for disturbing you, may i know how do you compile visual studio project for arm ?, i already change windowsarmdesktop to true. But i can't find arm options in build settings. Any suggestion ?
Click to expand...
Click to collapse
This is completely unrelated to the topic and has been covered in at least 3 threads, multiple times in each, in the past couple days. Use the search function.
netham45 said:
This is completely unrelated to the topic and has been covered in at least 3 threads, multiple times in each, in the past couple days. Use the search function.
Click to expand...
Click to collapse
Yes, and I've answered it here: http://forum.xda-developers.com/showpost.php?p=36644799&postcount=131
Wow, this is awesome work! While recompiling (for native speed, lower memory footprint, launch time, lower battery usage, script transparency, etc.) is still obviously preferred, this finally offers a way to run closed-source or otherwise un-recompilable legacy apps. Well done; I'll be watching this closely.
A thought for making it easier to run the apps (including the aforementioned script transparency): Windows (at least on x86 and x64, and I'm pretty sure on ARM too) supports specifying executable names that, when they would be executed, are instead passed as a parameter to another executable. This is usually used for testing or debugging purposes (for example, always load a given app under a debugger or have Application Verifier hook into it at launch) but it can be used for other purposes too. One, which would be fantastic here, is to always run a program through a compatibility layer... I've never before seen it used for a full instruction set translation compatibility layer, but why not?
Create the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<IMAGE FILE NAME>
i.e. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\starcraft.exe
Then create a REG_SZ (String) value under that key called "Debugger" and set the value to the full path of the program you want to host the executable.
i.e. C:\Program Files\x86_peldr\peldr.exe
Source: http://support.microsoft.com/kb/824344
I can't promise that this will work for executable images that wouldn't be loadable normally, but it's probably worth a shot. Another, slightly less seamless option: change the extension of the executables (for example, starcraft.ex86) and register your app as the handler for that file type.
GoodDayToDie said:
Wow, this is awesome work! While recompiling (for native speed, lower memory footprint, launch time, lower battery usage, script transparency, etc.) is still obviously preferred, this finally offers a way to run closed-source or otherwise un-recompilable legacy apps. Well done; I'll be watching this closely.
A thought for making it easier to run the apps (including the aforementioned script transparency): Windows (at least on x86 and x64, and I'm pretty sure on ARM too) supports specifying executable names that, when they would be executed, are instead passed as a parameter to another executable. This is usually used for testing or debugging purposes (for example, always load a given app under a debugger or have Application Verifier hook into it at launch) but it can be used for other purposes too. One, which would be fantastic here, is to always run a program through a compatibility layer... I've never before seen it used for a full instruction set translation compatibility layer, but why not?
Create the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<IMAGE FILE NAME>
i.e. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\starcraft.exe
Then create a REG_SZ (String) value under that key called "Debugger" and set the value to the full path of the program you want to host the executable.
i.e. C:\Program Files\x86_peldr\peldr.exe
Source: http://support.microsoft.com/kb/824344
I can't promise that this will work for executable images that wouldn't be loadable normally, but it's probably worth a shot. Another, slightly less seamless option: change the extension of the executables (for example, starcraft.ex86) and register your app as the handler for that file type.
Click to expand...
Click to collapse
What I was thinking of for doing that was hooking the 'This doesn't run on this PC' error that explorer gives and making it call this instead of the error.
Nice... but that doesn't cover things like launching a program from the command line (script or manually), or one program launching another, or launching Windows services (although I'm not sure you'd want to emulate those anyhow... the battery hit would suck), or so on. Still an interesting goal.
One other thought for the "it'd-be-awesome" list (not even really a wish-list): support doing this for DLLs loaded into other processes (i.e. somehow get between LoadLibrary and the x86 binary, and interpose your translator). Why, you ask? Plugins. Browser plugins, media codecs (which are DLLs, whatever their extension), Control Panel files, COM objects in general, etc.
Hi all,
As part of a class I'm doing, we are required to post some content to a forum to engage in discussion on security:
.
Cross Site Scripting (XSS)
OWAPS describes Cross Site Scripting (XSS) where a website has been marked as a trusted website, which for some reason, can run malicious code or scripts through inputs such as forms. As the end user’s browser sees this site as trusted, it allows the malicious script or code to execute, which can give access to client side information before it is encrypted (such as usernames, passwords, session IDs, cookies, etc).
In PHP for example, a normal input box where a user would enter their name, would be able to enter the following:
When PHP prints this back out after submission, it will execute the script between the script tags (In this case, just a simple popup).
In this scenario, this can be solved by wrapping the input value with htmlentities:
This would print any script as literal text rather then executing it.
In Java,
XSS is still a major issue, both due to some sites not implementing simple work around such as htmlentities or htmlspecialchars, or for reasons where these cant be used. XSS affects PHP applications by as much as 86% - its PHPs biggest vulnerability.
In Java, the easiest method is to simply validate inputs and to encode special characters (<>[email protected]#$%^&*). Alternativley, OWASP have a XSS class which includes easy methods to best prevent against certain types of XSS.
Code Injection
Code injection is where using the sites scripting language, you can inject (rather, have the site pull) code from somewhere else.
For example, php can call one of its own pages like so:
however, if we replace the contact.php page with an external hosted script:
This will cause the enduser to execute that script. This all comes down to PHP validation which is coded within the PHP to ensure only valid respsonses are accepted.
This is unlike command injection. Command Injection is an attack which is designed to execute commands on the PHP hosted system (server). This can be done where most parameters are passed (headers, input boxes, etc) and will typically display any output on the returned webpage.
For example, to return a password for a certain user, you could use a command like:
Typically, to prevent such commands from executing, a whitelist of command can be made, whereby only those listed are allowed to be executed on the server. Alternativly, it is recommend where the application needs to invoke system side commands, to do this through local python scripts, rather then PHP calling the commands.
CRLF injection
CRLF injection comes from the elements CR (Carriage Return) and LF (Line Feed) – together (CRLF) this denotes a new line (done simply by pressing the enter button). If a website for example, allows you to upload a file, an attacker may name this file as follows:
This would result in a system command being carried out to delete everything in the /bin folder.
It also allows an attacker to write to the log file, by creating it own new line. If the logs are configured in such a way that they will email out any WARNINGS or ERRORS, an attacker may add these to a new log line repetitively, backing up the email and bandwidth.
The simple way around this is for JAVA to sanitise any input strings, either through substituting known commands, or through methods such as
SQL Injection
.NET SQL Injection allows an authorised SQL command to be sent to the SQL server and executed.
An SQL string may be built using inputs from a form. A possible example of this is:
Code:
SELECT email, passwd, login_id, full_name FROM members WHERE email = 'formemail';
where the red is the text from an input field.
However, we can modify this string which can allow some malicious stuff to happen:
Code:
SELECT email, passwd, login_id, full_name FROM members WHERE email = 'formemail'; DROP DATABASE members --';
Adding the red text to the email input box, would allow us to delete the whole table, or alternatively insert a new record into a table, or possible delete records, modify records (change passwords), or even delete whole tables.
To prevent this, you can limit the damage an SQL injection can do you using proper database permissions (deleting records, tables, etc), and to also use good sanitisation – look for -- or ; in any field and invalidate the data if it has these characters.
Directory Traversal
Directory traversal can also be referred to as a “dot dot slash” attack.
In php, a resource (page) can be called as follows:
However, it may be possible to get other files, not even part of the web directory using the following examples:
The easiest way to prevent this is to assign proper permission on the server itself. However, many web developers do not own the server, therefore, another layer of protection is fully qualify the file path, with the root being where the webpage sits.
Connection String Injection
Also known as connection string pollution, it is possible for an attacker to inject parameters into a connection string to a database. Typically a connection string is built by delimiting each value with a comma. In an injection attack, strings can be built using semi colons as a delimiter.
A typical connection string to a windows SQL server may look like the following:
Code:
Data source = SQL2005; initial catalog = db1; integrated security=no; user id=+’User_Value’+; Password=+’Password_Value’+;
However, if an attacker places a rouge windows SQL server on the internet, and then uses a connection string like follows:
Code:
Data source = SQL2005; initial catalog = db1; integrated security=no; user id=;Data Source=Rogue Server; Password=; Integrated Security=true;
This allows the target windows SQL server to connect to the rouge server using its own Windows credentials, exposing much data.
Backdoors
Backdoors can be common within applications and web applications and can occur across many types of frameworks, however, it’s the security around the knowledge of backdoors, and what they allow, which can be of concern. All modems, routers and some managed network infrastructure have administrator usernames and passwords. However, sometimes, the network vendor (CISCO, NETGEAR, etc) or ISP may choose to put a backdoor access onto these devices. This may be in case a user forgets their administrator credentials, for automatic firmware updates, or for remote troubleshooting. Some of these backdoors may allow for more settings then what is normally shown to an end user.
For example, some older Optus supplied modems had the hidden user: Admin, and a password of: Y3S0ptus. This was standard across thousands of supplied modems. The problem was, the end user had no way of changing the default setting for remote web access from Enabled to Disabled, which meant anyone that knew of their IP address or domain name, could now remote access their modem router, add port redirects, and now connect to devices within their LAN.
In the case of ISP provided modems, it might be safer to simply by something else, not supplied by the ISP.