Related
Hi folks
Recenty I got the Windows XP Embedded kit, and I was really satisfied and surprised with the performance of the directly built system on an old machine like a P1 @ 200 MHz with 64 MB of RAM, without a hard disk.
The main goal would be to run truly win32 apps on mobile devices, to give better functionality and compatibility.
Yet the builder supports x86 architecture only, but cannot be a big problem to port it to ARM pocessors.
What might be difficult are these things:
-Getting win32 drivers for built-in devices (ex. integrated SDIO/USB WLAN, BT adapter, touchscreen, and sound devices, and apps for them!)
-Saving user data on turning off (Ebmedded systems are designed for a workstation, like a cash register: prebuilt apps, and nothing more comfort ) like WM200x
If anybody has any suggestion are to get a warm welcome
bye
Yet the builder supports x86 architecture only, but cannot be a big problem to port it to ARM pocessors.
Click to expand...
Click to collapse
Are you kidding me?
This would mean reverse engineering and recompiling every binary in the OS.
Do you have any idea how many hours something like that would take?
yup, you're right, but in theory it's possibe. I've seen a running DOS on a Microchip micro-controller, or for example the Atmel STK 1000 is Linux based, also seen an mPlayer app operational on the demo board at the college.
as you see, i'm not an experienced programmer, but i'm not afraid to ask
Yeah, the basic low-level binaries must be recompiled, and once it's ok, it might be usable with regular win32 apps, until you run an old DOS app, wich directly access the hardware.
A few years ago i was able to port Z80 software to 8086, and it wasn't easy.
I don't really know these things, just want to see opinions, possibilities, and suggestions.
exe files are binarys which are instructions directly for the cpu
it's not parsed by the operating system
so compiling the os is not enough every application needs to be recompiled too
The programs you mentioned have source available in one way or another (since DOS is very old there are clones, like freeDOS).
If you have the full source for an app and the right compiler, porting it to another CPU is feasible.
But, this is not the case with embedded XP. Getting the full source is impossible which means most of the system will have to be rewritten from scratch.
Just look at the Wine project to see what it takes, and they "have it easy" - they are just trying to simulate the APIs not change processor architecture. (Lets make it clear - ARM instruction set is very different from x86).
And as Rudegar said it will not let you run any program that has not been specially compiled for ARM CPU.
I know it sounds like we are trying to kill you idea here but its nothing personal, unfortunately it just isn't feasible. We would all like to be able to run desktop apps on our devices, but simply having embedded XP on them would not accomplish that. Also while many old DOS apps can be run using various emulators like pocketDOS, almost all Win32 apps take more resources than our little gadgets can offer.
I am fairly sure though that in 5 -10 years that problem will be fixed.
<_< man hours or not, reveng'ing this will have a bigger impact than just winDOS Mobile devices. Desktops have a use for this, definitely (because the Vista-Only crap is starting to hit the market). Too bad they don't provide assembly in programming classes anymore, obviously because they don't want anyone else to reverse engineer anything and spoil their foisting fun. <_<
In any case, IIRC XP Embedded is missing the install/uninstall engine, so you can't customize it after it's flashed onto the board. This isn't quite a good start - XPLite or 98Lite are better for reverse engineering from scratch (but they're too powerful for mobile devices).
The other alternative is porting ReactOS, which is a reimplementation of W2K. Those guys are "having a lot of fun" getting things to work, tho. <_<
Maybye Windows CE6 yes, but Windows XP Embedded no, because they must run at 686-AT/X platform IMB. Sorry of my English
linux would be a path
with most linux programs you can compile them yourself
using good old
./configure
make
make install
of cause gui programs could have issues displaying correct
on such a small screen
You MIGHT be able to pull it off by installing a minimal (very!) WinMo firmware and then have it autorun Bochs, which is known to be able to run the PC version of XP.. A customised, thinned-down XPe image should run fine under Bochs.
--W5i2
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
- No native support for x86 apps on ARM, nor ARM apps on x86. Only .NET apps would work in both worlds.
But it is possible to create an emulator similar to DosBox that would run native x86 programs on WoA and, for example, I'm currently working in this direction.
- Though existing C++ apps can be recompiled for ARM from sources, it is not a 100% working solution. Current VS11 contains a rather limited set of ARM libraries - no DirectX libs earlier than 11, no import libraries for NtDll.Dll and similar DLLs.
I don't have access to any WoA builds, so I can't check whether these features are completely removed from ARM, or those LIBs are just not present in current VS11 build. But at least now we can compile test apps for ARM and analyze the code (though we don't have where to execute them yet).
- Native WoA programs use THUMB2 instruction set (ARMv7 and above). Though ARM instruction set would be supported too.
- According to "Microsoft Portable Executable and Common Object File Format Specification v8.2" WoA machine type in PE files would be 0x1c4, and some new relocations types are added (for example IMAGE_REL_BASED_ARM_MOV32T = 7). IDA understands such EXE files, though complains on relocs.
- SEH is implemented in a different way than on x86 (similar to x64, google for RtlAddFunctionTable to get the idea).
- WoA is more secure by default. For example TPM can be rarely found on x86, but it would be required on ARM.
- Most of existing drivers are source-code compatible with ARM (of cause if not using x86-specific stuff). But ARM would never allow to load unsigned drivers (unlike x86 Win7/8).
- As platform is completely new - all ARM drivers would be added to windows update site to simplify our life. Some obsolete hardware like 1394 is not implemented at all, so there would not be so many drivers for ARM llike for x86.
- All binaries would be the same for all SoC providers.
- No "native" ARM VisualStudio - developer tools are x86 only.
WoA requirements from different sources:
- 10.1” display with 1366x768 min resolution (though smaller screens may be supported with reduced functionality)
- Volume Control, Windows, Rotation, Lock power buttons
- Dual core CPU with hardware accelerated GPU
- at least 1 Gb RAM
- min 16 Gb fixed storage
- 100mW idle power in standby
- there are rumors that there would be standart "Phone call API" ("Apollo" UI)
Does anyone have access to ARM WDK? It would definitely contain a complete set of import libraries and would provide lots of info on WoA internals in headers/documentation. Seems that Windows 8 WDK on MSDN does not have ARM tools
so your bottom line says: no w8 on arm (ever)?
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
The UEFI requirement is expected, and I doubt will be that much of a hurdle. UEFI is all open, and it should be pretty trivial to chainload a UEFI-compatible environment on top of the existing firmwares, provided that nvidia doesn't provide us with an implementation to start with, which I suspect they'll do.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two. A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Everything I could find relating to the TPM says that it's optional, but will be automatically utilized if available.
The rest is pretty inconsequental, at least to what I think most people here are interested in.
nvidia started a windows 8 development program for ARM (Clickey here), but I haven't seen anything else from it, has anyone else gotten anything?
mamaich said:
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
Click to expand...
Click to collapse
Actually they said it would continue to support BIOS for older devices.
See: Current machines dual-booting Windows 7 and Linux should be able to upgrade to Windows 8 without wiping out the Linux install. As Microsoft notes in the Building Windows 8 blog, “We will continue to support the legacy BIOS interface.” However, machines using UEFI instead of BIOS “will have significantly richer capabilities” including faster boot times and greater security. (from Arstechnica)
That's for x86. ARM was said to require UEFI. Besides, there is no real bios on Android tablets, at least not a common platform.
netham45 said:
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
Click to expand...
Click to collapse
I've got it in one of the "windows-on-arm" non-public documents dated the first half of this year. While UEFI,ACPI,TPM are an option for x86, they are required for ARM hosts.
So no custom WM8 bootloaders, drivers, patched kernel on ARM hosts (like "windows activators" do) until sign keys would be leaked or some backdoors would be found. Of cause this is good as this would make rootkit creation more difficult, and require device drivers signed by MS (so we'd get more stable OS) but I really don't think that this "protection" would last more than 1-2 months after WoA would be released.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two.
Click to expand...
Click to collapse
I'm already working on such tool. It emulates x86 instruction set with dosbox or bochs CPU emulation library (I'm using both of them for debugging purposes, while working on my own one that would be much more simple->faster), translates x86 WinAPI to "native" host WinAPI + emulates API that is not present or differently implemented on WoA. It is designed to be truly cross-platform, so just a recompilation + creating several thunks/stubs would be necessary when I'll get my hands to an ARM host running windows8.
Of cause programs that use heavy anti-debugging, self-modifying code, undocumented features and SEH tricks would not work. Currently it is rather far from being finished (I have to implement&debug WinAPI and COM thunks that cannot be automatically generated) but old games like "heroes of might and magic" are already working fine in a test environment.
A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Click to expand...
Click to collapse
Of cause I'm talking about "ultimate" VS11, as express is designed to target mostly .NET (though ARM compiler is present there too).
And WDK that it published on MSDN does not allow creation of ARM drivers. I'm currently in a process of renewing my company's MSDN subscription, so I can't prove that myself, but I've read that on OSR forums.
I am waiting to hack my iPad and put win8 on it
I would hope touchpad would be the next viable option. Hp could still make more and just dump W8 on it. Thanks all of you for working this thread. I will be reading your progress as it unfolds. Good Luck devs and if I can find anything you will be the first to know.
Sent from my mwp6985 / Trophy using XDA Windows Phone 7 App
Some information on Win8 "Apollo" is available. Apollo - is a name for a new "windows phone" OS from MS.
- Apollo is based on the same "desktop" code as Windows 8. No Windows CE at last!
- Apollo would provide the same user experience as old Windows Phone 7.x - Metro UI, People hub, builtin office apps, etc. Seems that software compatibility with WinPhone 7.x apps would be preserved, but this is just my own guess.
- All applications on Apollo are required to be signed, similar to Windows Phone 7.
- Device drivers can be written only by IHVs, MS and OEMs, not by ISVs. This would be a problem for antivirus vendors or tools like daemon-tools.
- There would be a "built-in" eMMC card with OS and vendor partitions, and maximum one SD card. eMMC supports NTFS, SD-card supports only FAT/exFAT.
Build-in eMMC would have C:\ drive letter, SD-card would be D:\ if present.
eMMC contains several partitions. Some of them would be made readonly during boot.
- Near Field Communication is built in.
- The same list of sensors as in WP7 Mango is supported.
- There would be BSOD like in a desktop OS
- Unproven, but it seems that only .NET ("Splash UI framework" and "Silverlight") APIs would be available to independent developers. So no native code again.
- Seems that x86 architecture is supported for Apollo too.
HI, I saw some apps on play store and WP market. I found that many apps on WP are smaller in size as compared to the same app on Android.
Examples:
Official Twitter app: By Twitter
Android : 6 MB
WP : 2 MB
Facebook app:
Android (official) : 13 MB
WP ( by Microsoft) : 4 MB
LinkedIn app (Official)
Android : 5MB
WP : < 1 MB
NY Times (Official)
Android : 2.3 MB
WP : 1 MB
Whatsapp : By Whatsapp
Android : 8 MB
WP : < 1 MB
Foursquare (Official)
Android: 10MB
WP: 5 MB
Angry Birds Star Wars
Android: 38 MB
WP : 20 MB
Angry Birds Space
Android : 36 MB
WP : 15 MB
Anyone viewing this thread, please post apps sizes if you also find same thing for any other app.
So, how do will explain this small app sizes on WP compared to Android.
Is WP OS more CODE efficient than Android
Does this efficiency contribute to smoothness of apps. Please share your thoughts.
As a developer, I can say for certain several things
1) Yes, the OS is way, way more "code efficient" than Android
2) The code is downloaded and compiled only once. I will not get into details as to why this is happening, but on Android, as far as I am aware, JIT occurs everytime you run the application.
Also, Visual Studio is able to create far smaller binaries when compared to Eclipse.
Bytecode(android+eclipse) tends to produce really large "binaries" while the IL(WP+VS) tends to create very effective "binaries".
My game, which contains around 100 graphical assets only eats around 5.53 MB of space. So yes, C#/C++/VB handle assets and binary size better than Java.
There's been some talk lately about porting Android to use C# instead of Java. Some tests were done as far as performance is concerned. Really interesting results
http://www.cnx-software.com/2012/05...-massive-performance-improvement-over-dalvik/
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Then there is also the problem of hardware variety. Windows Phone basically runs on the same chipsets and only has a few supported resolutions, whereas on Android, there are great many chipsets, each with their own sets of hardware assets and many possible resolutions. Developers need to write more code to make sure their apps work fine on as many phones as possible.
mcosmin222 said:
As a developer, I can say for certain several things
1) Yes, the OS is way, way more "code efficient" than Android
2) The code is downloaded and compiled only once. I will not get into details as to why this is happening, but on Android, as far as I am aware, JIT occurs everytime you run the application.
Also, Visual Studio is able to create far smaller binaries when compared to Eclipse.
Bytecode(android+eclipse) tends to produce really large "binaries" while the IL(WP+VS) tends to create very effective "binaries".
My game, which contains around 100 graphical assets only eats around 5.53 MB of space. So yes, C#/C++/VB handle assets and binary size better than Java.
There's been some talk lately about porting Android to use C# instead of Java. Some tests were done as far as performance is concerned. Really interesting results
http://www.cnx-software.com/2012/05...-massive-performance-improvement-over-dalvik/
http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html
Then there is also the problem of hardware variety. Windows Phone basically runs on the same chipsets and only has a few supported resolutions, whereas on Android, there are great many chipsets, each with their own sets of hardware assets and many possible resolutions. Developers need to write more code to make sure their apps work fine on as many phones as possible.
Click to expand...
Click to collapse
Oh boy. Where to start.
Firstly, the WP OS is not more efficient than Android. Android consists of Java in the form of the Davlik virtual machine running on linux. In no way is this less efficient than C# running on the WP8 virtual machine on the NT kernel.
Bytecode is not Android + eclipse. Eclipse is an IDE, like visual studio. Bytecode is the compiled output from the Java compiler in the form of .class files. You can use any IDE (or none) to develop Android applications.
The size of a binary bears very little relation to it's efficiency. It all depends on the environment it runs under. For example, a single API call may, in one environment, relate to, say, 20 calls into some framework that is bundled with the app - therefore making the binary bigger. In another environment the single call may result in a single call into a function provided by the virtual machine. The end result is that roughly the same amount of code is executed. Also, part of the reason why Android binaries are larger is because they contained a cached version of the app for quicker startup.
Besides code, a binary may contain other artefacts, like graphic files or different resolutions, which will make the binary bigger.
The idea of using C# on android is absurd. C# is not supported on Linux (by Microsoft). There is, however, the mono open source version of C# (always guaranteed to be out of date) but the android libraries provided by Google are written in Java and there is no way they will use a proprietary language, like C#, as it will require the use of Microsoft technologies to run and that means they will have to pay Microsoft a license fee.
Why on earth would the leader in smartphone abandon their existing technologies to adopt one that will require a complete redevelopment of Android and, in addition, pay a license fee to Microsoft? Answer == they won't. Ever.
Dr.Paul said:
Oh boy. Where to start.
Firstly, the WP OS is not more efficient than Android. Android consists of Java in the form of the Davlik virtual machine running on linux. In no way is this less efficient than C# running on the WP8 virtual machine on the NT kernel.
Bytecode is not Android + eclipse. Eclipse is an IDE, like visual studio. Bytecode is the compiled output from the Java compiler in the form of .class files. You can use any IDE (or none) to develop Android applications.
The size of a binary bears very little relation to it's efficiency. It all depends on the environment it runs under. For example, a single API call may, in one environment, relate to, say, 20 calls into some framework that is bundled with the app - therefore making the binary bigger. In another environment the single call may result in a single call into a function provided by the virtual machine. The end result is that roughly the same amount of code is executed. Also, part of the reason why Android binaries are larger is because they contained a cached version of the app for quicker startup.
Besides code, a binary may contain other artefacts, like graphic files or different resolutions, which will make the binary bigger.
The idea of using C# on android is absurd. C# is not supported on Linux (by Microsoft). There is, however, the mono open source version of C# (always guaranteed to be out of date) but the android libraries provided by Google are written in Java and there is no way they will use a proprietary language, like C#, as it will require the use of Microsoft technologies to run and that means they will have to pay Microsoft a license fee.
Why on earth would the leader in smartphone abandon their existing technologies to adopt one that will require a complete redevelopment of Android and, in addition, pay a license fee to Microsoft? Answer == they won't. Ever.
Click to expand...
Click to collapse
Uhh...
Where do I start?
I know bytecode is NOT android+eclipse, I only mentioned the IDE and System, just as IL si not visual studio.
The size of the binary is influenced by how good the compiler is. Although it is not the only the only thing to take into consideration, the compiler does have a role in this.
C# on Linux/Android/Mac/iOS IS supported by Microsoft under the community promise license, so everybody can port C# and .NET to any system as long as they don't use this on windows, WITHOUT having to pay Microsoft anything... I suggest you get some documentation on what Mono and Dalvik are.
C# is just as open source as C on any platform apart from Windows.
As a matter of fact, porting Android to C# would benefit the platform greatly, as google has some issues with Oracle regarding the usage of Dalvik and Java on Android.
Oh, did I mention android has to code MORE due to variety of code...hmm...
No. You cannot judge the efficency of the compiler based on the resultant code size unless you are comparing like for like. You cannot compare two languages running on two different platforms like this and come to the conclusion that because the bytecode is smaller it must be more efficient.
I expect you are too young to remember the CISC vs. RISC debate some 20 or so years ago. RISC processors generated far more instructions than a CISC processors to perform the same operation, and hence had far larger binaries. However, RISC machines were far faster. So the complete opposite of what you are saying.
Different compilers may well generate different size binary files if one were to compare compilers compiling the same language. But again this does not mean the code in the smaller file will run quicker. Indeed it may actually run slower.
Code size is no indicator of efficiency.
As far as c sharp is concerned, only the language is free to use. None of the frameworks are. And Microsoft do not provide a c sharp compiler on any system besides windows.
There is not a chance in hell that Google will adopt it. If they were to change from java they will either use one of the languages they have developed or develop something new
I used the appropriate quotation marks when writing "code efficient", as it is a very broad term and comparisons over who is code efficient and who is not.
The way I understand it, a code efficient system is a system that has very high performance, such as windows phone, not that it has anything to do with size of binaries, but the OP asked if WP is a "code efficient" system, so i answered xD
.Net framework is also free to reverse engineer. You still have to pay for compilers however.
Interesting sidebit: in internal Google E-Mails that got published during the Oracle vs. Google trial over Java it was actually mentioned that using C# instead of Java would have been an option due to the fact that there are less licensing hassles attached to it's core library (which actually is standardized with ECMA) as compared to Java. They decided not to go that route as it would have taken a year to adapt Android and instead risk getting sued by Sun (which was later acquired by Oracle). So: yes, C# would have been just as good an option. Using something like Google Go wouldn't have simply because there was no developer community and it's a lot easier to get people working on your platform if they don't have to learn a new language first.
That aside: most likely the binary size isn't all that much relevant for how big the downloaded files are. And I won't even go into the fact that some of those Apps aren't written in Java on Android but use the NDK (at least Facebook and the Angry Birds games do on Android, most likeley the later do it on WP8 too).
So in the end it's most likely down to the embedded Audio and Graphics resources. As was already mentioned Android devices have to support a lot more resolutions which makes it likely that LowRes graphics are included as well to not tax slower devices with high-res graphics for no reason (given that you won't see the difference on LowRes displays). Another reason for this with regular Apps is that WP takes a chromeless-design-approach so you rarely have graphics included that serve as UI chrome.
Another reason might be that Microsoft put quite some effort into driving home the point that resources should not be included or used in a higher resolution than what they are intended to be displayed at. The reason was that it might have led to troubles with the memory-constrained Tango-devices which only have 256 MB of RAM. At least for high-profile developers that work together with Microsoft it's likely that those optimized their Apps for it.
Lastly and also already mentioned: third party libraries. Historically Microsoft has always packed a lot of functionality directly into it's system frameworks. So it's entirely possible that WP devs use third party libraries less often. Case in point: database functionality: many Android Apps use SQLite and include their own binaries for it. WP provides SQLServer CE which can simply be used by any App that needs it. This might change though as for W8/WP8-cross platform Apps Microsoft themselves suggest including SQLite given that there is no SQL CE Support for WinRT-Apps.
And for the finishing lines something on compilers and code size. Intels C++ compilers regularly produce bigger binaries because of optimization techniques like loop unrolling, etc. They also normally outperform competing compilers in performance benchmarks. But it's not that easy if you look not at a single App's performance but at the whole system. Having an App take up more memory means that other Apps will have to be terminated sooner to avoid an out-of-memory scenario and it is more taxing on the memory controller, which depending on the chipset used might lead to additional performance problems down the road (the Nvidia Tegra 3 is said to be severely limited by its memory controller). But especially with Managed Code like C# or Java the code size of the IL does not really mean too much in that regard as the code is compiled anyway before being executed. So the memory actually taken up during execution is a lot different from what gets downloaded.
A more interesting comparison though would be wether the WP8 compiled XAPs are smaller than their WP7 counterparts, given that WP8 does precompile the IL in the cloud. Might be interesting to see which of those is smaller.
Just did some comparisons on size of binaries between 7.5 and 8
1) XAP compiled for 7.5 is 5.53 MB
2) XAP compiled for 8 is 5.76 MB
Seems the 8 version is actually bigger, although not by much.
I love this thread!
Sent from my RaZr on MIUI.
I know about the comparison between Android and Windows Phone 8 from users who have made the switch.
I'd like to port a JIT script engine to WP8 but found no kernel32.dll in System32 and is it possible to use JIT on WP8 after Interop Unlock?
And am I able to call some system functions by DllImport ? (Simply add the unsafe code support to a WP8 C# project by editing the csproj file)
The user-mode kernel entry points have been split into a few different libraries, kernel32legacy.dll and kernelbase.dll. Both of these are in System32 on the phone.
I don't know why you think JIT would have anything to do, on e way or another, with interop-unlock. The basic process of JIT compilation doesn't require any special permissions at all (and that's pretty much all that Inteorp-Unlock gives; access to some extra permissions). Now, whether you can do anything useful with those scripts... IU can help there, if the app which contains them contains the appropropriate capabilities. Bear in mind that I still haven't managed to fully "root" a phone, although I have more ideas as to how to go about it.
GoodDayToDie said:
The user-mode kernel entry points have been split into a few different libraries, kernel32legacy.dll and kernelbase.dll. Both of these are in System32 on the phone.
I don't know why you think JIT would have anything to do, on e way or another, with interop-unlock. The basic process of JIT compilation doesn't require any special permissions at all (and that's pretty much all that Inteorp-Unlock gives; access to some extra permissions). Now, whether you can do anything useful with those scripts... IU can help there, if the app which contains them contains the appropropriate capabilities. Bear in mind that I still haven't managed to fully "root" a phone, although I have more ideas as to how to go about it.
Click to expand...
Click to collapse
I think you can not do JIT, because WP8 will not give you permission to change the executate bit for malloc memory.
felixlong said:
I think you can not do JIT, because WP8 will not give you permission to change the executate bit for malloc memory.
Click to expand...
Click to collapse
Well I wouldn't go changing the permissions for memory allocated through malloc, but yes VirtualAlloc and VirtualProtect, both necessary for a JIT should be contained in kernel32.dll on any other NT system. I would be very interested in what you find.
Pretty sure there's nothing stopping you from calling VirtualAlloc and VirtualProtect, aside from the fact that they are "unofficial" (non-WinRT) APIs. If you want to do some research into using them (and possibly produce a library to make accessing them easy), that would be cool and potentially useful!
GoodDayToDie said:
Pretty sure there's nothing stopping you from calling VirtualAlloc and VirtualProtect, aside from the fact that they are "unofficial" (non-WinRT) APIs. If you want to do some research into using them (and possibly produce a library to make accessing them easy), that would be cool and potentially useful!
Click to expand...
Click to collapse
I did a bit of poking around and was able to call both VirtualAlloc and VirtualProtect from a standard app in the emulator. The biggest problem I'm having is despite successfully allocating pages with PAGE_EXECUTE_READWRITE permissions, I get 'Access Violation' when calling within the page. I've also tried allocating as PAGE_READWRITE then using VirtualProtect to switch to PAGE_EXECUTE but to the same effect. Finally, VirtualProtect confirms that the permissions I ask for are being applied to the page, there must be something else preventing execution.
Also, all these functions were found in kernelbase.dll
Ok so it turns out I was messing up my x86 JMP's and causing a whole heap of pain. It turns out we do not have any restrictions when it comes to allocating and using executable memory, I've been able to both patch an existing function and roll my own.
Attached is the header, lib and dll for the emulator as well as an example test solution if anyone without experience wants to experiment. I plan to export all available function from kernelbase.dll, but here is a good start.
Cool! Of course, we'd need an ARM (THUMB-2 actually) version if we're going to use it on the phone, but that shouldn't be hard at all. Thanks for sharing your work!
Spent a bit more time on it this afternoon and have now added support for ARM, as well as expanding the libraries to cover all exported functions from kernelbase.dll. The header is essentially the same, I think an add on demand system for it is a decent approach, as there were over 1300 functions that require prototypes.
Preliminary testing showed that at least VirtualProtect and VirtualAlloc were calling and seemed to be working on my 920, after struggling to write a simple branch I am going to have to leave proper testing to someone a bit more versed in ARM opcodes, unless someone has some decent documentation so I can dive in myself
oZed said:
Spent a bit more time on it this afternoon and have now added support for ARM, as well as expanding the libraries to cover all exported functions from kernelbase.dll. The header is essentially the same, I think an add on demand system for it is a decent approach, as there were over 1300 functions that require prototypes.
Preliminary testing showed that at least VirtualProtect and VirtualAlloc were calling and seemed to be working on my 920, after struggling to write a simple branch I am going to have to leave proper testing to someone a bit more versed in ARM opcodes, unless someone has some decent documentation so I can dive in myself
Click to expand...
Click to collapse
..does it mean that we could have some sort of webkit/blink on the phone, if only devs would be so polite to spend some time on it?
oZed said:
Spent a bit more time on it this afternoon and have now added support for ARM, as well as expanding the libraries to cover all exported functions from kernelbase.dll. The header is essentially the same, I think an add on demand system for it is a decent approach, as there were over 1300 functions that require prototypes.
Preliminary testing showed that at least VirtualProtect and VirtualAlloc were calling and seemed to be working on my 920, after struggling to write a simple branch I am going to have to leave proper testing to someone a bit more versed in ARM opcodes, unless someone has some decent documentation so I can dive in myself
Click to expand...
Click to collapse
I didn't have much time to work on this but I have been able to get the address of any given method when running your demo on an actual device (ARM). If I get more time, I'll complete your entire demo for ARM (which shouldn't be too too complicated now that I figured out the opcodes used for "jumps")...
In the mean time, if you want to work on it yourself, here are the opcodes used:
MOVW R12, #<address_low>
MOVT.W R12, #<address_high> ;after this, R12 will contain the full 32-bit address of the method
BX R12
All you have to do is read the address low and address high and combine them in a 32-bit int to get the address of the method. Also note that the MOVW and MOVT.W are 32-bit instructions (hence the W) while the BX is a 16-bit instruction. I found this document to be very useful: http://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARMv7-M_ARM.pdf
Cheers!
Don't forget to call FlushInstructionCache once you're done writing to memory before you jump to it. ARM CPUs are not x86's - they don't maintain coherence between the data and instruction caches like x86 processors do.
Melissa
---------- Post added 15th November 2013 at 12:03 AM ---------- Previous post was 14th November 2013 at 11:54 PM ----------
sireangelus said:
..does it mean that we could have some sort of webkit/blink on the phone, if only devs would be so polite to spend some time on it?
Click to expand...
Click to collapse
The exception and interrupt handlers of the Windows RT and Windows Phone kernels always set the Thumb bit of the CPSR register in the frozen thread's context. This means that if the interrupted thread was running ARM code, when it resumes, it will crash.
Chrome's V8 generates ARM code, not Thumb-2, as does Firefox's code generator. This is a massive reason why these browsers haven't been ported to Windows RT, let alone Windows Phone.
This can be fixed with kernel patches, but this would require jailbreaking Windows RT or Windows Phone, and defeating PatchGuard.
Melissa
cpuguy said:
I didn't have much time to work on this but I have been able to get the address of any given method when running your demo on an actual device (ARM). If I get more time, I'll complete your entire demo for ARM (which shouldn't be too too complicated now that I figured out the opcodes used for "jumps")...
In the mean time, if you want to work on it yourself, here are the opcodes used:
MOVW R12, #<address_low>
MOVT.W R12, #<address_high> ;after this, R12 will contain the full 32-bit address of the method
BX R12
All you have to do is read the address low and address high and combine them in a 32-bit int to get the address of the method. Also note that the MOVW and MOVT.W are 32-bit instructions (hence the W) while the BX is a 16-bit instruction. I found this document to be very useful: http://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARMv7-M_ARM.pdf
Cheers!
Click to expand...
Click to collapse
Thanks for the link! Got it to work, but is a little hackish getting the instruction alignment right. I've got both function patching and memory allocation methods working just like on X86, it appears that extracting information from and building opcodes is far more expensive on ARM than X86, ie this is what I was using:
Code:
#define MOVW(x, Rd) \
(0x0000F240 | \
((x & 0xF000) >> 12) | \
((x & 0x0800) >> 1 ) | \
((x & 0x0700) << 20) | \
((x & 0x00FF) << 16) | \
Rd << 24)
#define MOVTW(x, Rd) (MOVW(x, Rd) | 0x00000080)
#define BX(Rm) (0x4700 | (Rm << 3))
int inline FuncPtrToFuncAdr(void * ptr)
{
#if defined(_M_IX86)
char * instruction = (char *)ptr;
return (int)ptr + *(int *)(instruction + 1) + 5;
#else
#define EXTRACT(x) (\
((x & 0x0000000F) << 12) | \
((x & 0x00000400) << 1 ) | \
((x & 0x70000000) >> 20) | \
((x & 0x00FF0000) >> 16) )
int * instruction = (int *)((char *)ptr - 1);
return EXTRACT(instruction[1]) << 16 | EXTRACT(instruction[0]);
#endif
}
Myriachan said:
Don't forget to call FlushInstructionCache once you're done writing to memory before you jump to it. ARM CPUs are not x86's - they don't maintain coherence between the data and instruction caches like x86 processors do.
Melissa
---------- Post added 15th November 2013 at 12:03 AM ---------- Previous post was 14th November 2013 at 11:54 PM ----------
The exception and interrupt handlers of the Windows RT and Windows Phone kernels always set the Thumb bit of the CPSR register in the frozen thread's context. This means that if the interrupted thread was running ARM code, when it resumes, it will crash.
Chrome's V8 generates ARM code, not Thumb-2, as does Firefox's code generator. This is a massive reason why these browsers haven't been ported to Windows RT, let alone Windows Phone.
This can be fixed with kernel patches, but this would require jailbreaking Windows RT or Windows Phone, and defeating PatchGuard.
Melissa
Click to expand...
Click to collapse
Thanks, while I didn't experience any problems so far I've switched to using it, if only for good practice! It's a shame we are only limited to Thumb-2, but if we find a hack for RT hopefully we'll be able to cross-pollinate and get in working on WP and vise-versa.
Myriachan said:
Don't forget to call FlushInstructionCache once you're done writing to memory before you jump to it. ARM CPUs are not x86's - they don't maintain coherence between the data and instruction caches like x86 processors do.
Melissa
---------- Post added 15th November 2013 at 12:03 AM ---------- Previous post was 14th November 2013 at 11:54 PM ----------
The exception and interrupt handlers of the Windows RT and Windows Phone kernels always set the Thumb bit of the CPSR register in the frozen thread's context. This means that if the interrupted thread was running ARM code, when it resumes, it will crash.
Chrome's V8 generates ARM code, not Thumb-2, as does Firefox's code generator. This is a massive reason why these browsers haven't been ported to Windows RT, let alone Windows Phone.
This can be fixed with kernel patches, but this would require jailbreaking Windows RT or Windows Phone, and defeating PatchGuard.
Melissa
Click to expand...
Click to collapse
why should we need to patch the kernel, as i said, if developers were to port the code from arm to thumb-2 everything would be fine. I'm starting to think that the "they won't port over for political reasons" it's not completely untrue.
Modifying a Just-In-Time compiler to emit a different instruction set is not a trivial operation. Porting the browser itself is *relatively* easy (still a colossal task for one person, but possible), but it's kind of like porting some desktop C compiler to RT or WP8. You'd get a C compiler that runs THUMB2 code, yeah... but it would still generate x86 binaries.
I have with experience in VLSI, shell scripting (bash, windows powershell) and basic programming languages like C and Python (Matlab too, which uses a similar syntax).
I want to get into app development but I am completely new to this and unfamiliar with the whole structure - the IO libraries, rendering libraries especially. I mainly like to develop it for Windows 11 (but would be nice if I could make it cross platform, say using something like Vulkan as rendering library).
I wish to make a stylus based note making app (similar to one note, drawboard pdf etc). I wish to know about the libraries available for taking input from surface pen (or other pens). I found that there are a few API available for windows - RealtimeStylus, Windows Ink, etc but I am unable to find anything cross platform. I would like to know if there are open source, or cross platform alternatives. Alternately, I would like to know if it is possible to bypass these and create a custom API myself (including my own algorithms for tracing curves and predicting handwriting etc, at present I am left to use whatever was done in these APIs I think), also possibly making it lower latency within the app. To some extent I realized that pen position is very similar to trackpad input (on the data input to pc side) and then we have tilt and pressure sensitivity data which I'm not sure how it is accessed and used. I remember reading a little about libsdl sometime ago. I would like to know if there are alternatives to libsdl, or if Vulkan supports any alternate libraries.
I would like to know how I could code a program that works on both x64 and aarch64 on windows 11 (Not into 32 bit as I belive my tool will use more than 4GB RAM anyway, as a priority), and as mentioned above, it would be fantastic if I could make it cross platform. What I got from this page is that ( https://docs.microsoft.com/en-us/windows/arm/ ) if I write my program in C++ it should be possible to compile it for both x64 and aarch64 (and make possible optimizations for each of them separately). I am not sure how the whole development environment works - what is dotnet, what is unity, what is xamarin, and differences between each. I found a few code macros in dotnet that help in rejecting certain inputs (could be useful for palm rejection etc) : ( https://docs.microsoft.com/en-us/do...s.uielement.isinputmethodenabled?view=net-5.0 ) (https://docs.microsoft.com/en-us/dotnet/api/system.windows.uielement.ishittestvisible?view=net-5.0 ). As far as I am aware dotnet is cross platform. I might want to make instruction level optimizations to the software (like SSE, AVX, certain 64 bit instructions etc if that gives any hint) and would like to know if the dotnet environment/toolkit has sufficient low level coding possibility to access these. Also, I am curious if it supports vulkan or opengl. Vulkan is written in C++ and supports multiple platforms so I am more inclined to try it.