In April, Microsoft released a preview of a framework for Windows Store apps that would convert .NET assemblies into the compiled native binaries of the target architecture (x64/ARM for now) in order for application optimization. This tool was named, .NET Native.
This tool itself will help protect your code and IP (a.k.a make it even harder for people to reproduce your code, but not impossible) and also increase the application's performance.
Getting Started:
To download .NET Native, Go to the home page and register/download the preview. Close all instances of Visual Studio 2013 (VS 2013 Update 2 is required) then run the installation package.
The .NET Native tools are configured to purely work with Windows Store apps only, but I figured that it SHOULD work with Windows Phone 8.1 projects since they both use WinRT (mostly). I decided to come up with a solution that would enable .NET Native for Windows Phone 8.1 projects manually since there's no way to enable it from Visual Studio.
Here's the PowerShell script that runs this. BE SURE TO RUN AS ADMINISTRATOR
I've tested this with VS 2013 Ultimate Update 2 running on Windows 8.1 Update 1 with the English language.
The syntax is as follows:
./enableProjectN.ps1 -solution "c:\pathtovsproject\wp81solution.sln"
The script will go through and determine whether you have VS 2013 installed, and whether the projects in your solution are WP 8.1 projects. It will then add the project config nodes that enable .NET Native.
For this to work, you MUST target your projects to the Release|ARM configuration in Configuration Manager.
The building of your project will take a little longer since it is running all of the tools to compile your C# into the native binaries . The file size will go up exponentially, but the app will run faster.
Read through the Compiling for .NET Native page for complete information on how the .NET Native technology works and for any gotchas.
Happy compiling.
EDIT: I've noticed that my test app doesn't work. It wasn't the initial app I was testing with, but I found out why people are getting dependency errors during deployment. You have to include a C++ WinRT Universal Component in your solution and reference it from your main app, then the build will link up the dependencies needed and allow you to push it to your device.
Found a tiny issue with my .NET Native script for WP 8.1 You HAVE to run powershell from within the Developer Command Prompt for VS 2013, THEN run the powershell script. I didn't realize that I had made this script from within that environment and noticed that the essentially environment variables that I am using weren't there when calling PS regularly.
Nice share! Will try this at home tonight.
FabricioGS said:
Nice share! Will try this at home tonight.
Click to expand...
Click to collapse
Awesome! One thing to note for now. This will only work for projects that are sideloaded . The Store doesn't accept some of the DLL Imports that are added by the generated dlls.
snickler said:
Awesome! One thing to note for now. This will only work for projects that are sideloaded . The Store doesn't accept some of the DLL Imports that are added by the generated dlls.
Click to expand...
Click to collapse
Anything in particular?
Sunius1 said:
Anything in particular?
Click to expand...
Click to collapse
{
"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"
}
I am sorry but isn't ahead of time compilation the way .net apps have compiled to native on windows phone since 2011?
The compiler does produce MSIL assemblies, but these are compiled to native upon deployment, unless the dev side loads it and the package is created for JIT.
Has something changed in wp8.1?
As far as i know, .net native is only designed for windows store apps.
mcosmin222 said:
I am sorry but isn't ahead of time compilation the way .net apps have compiled to native on windows phone since 2011?
The compiler does produce MSIL assemblies, but these are compiled to native upon deployment, unless the dev side loads it and the package is created for JIT.
Has something changed in wp8.1?
As far as i know, .net native is only designed for windows store apps.
Click to expand...
Click to collapse
This completely makes Native binaries using a compiler that's just like C++. No .NET code whatsoever. The DLL that's generated contains the bulk of the code and the EXE just loads the entrypoint of the .DLL.
Yes, for now .NET Native is designed for Windows Store apps, but since WP 8.1 just happens to use the WinRT assemblies that .NET Native needs, it will actually work for WP 8.1 apps. The Store doesn't accept the particular native functions that were listed in the post above yet though.
I've attached a blank WP 8.1 project that I've .NET Native compiled. Peer into the .DLL using IDA Pro and you'll see what they did. Notice that none of these files are .NET assemblies, they are pure ARMv7 compiled PE files. The .NET Native precompiles to pure Native binary, not doing optimization on an assembly for the specific architecture.
Check out the .NET Native links I put in the first post as they explain more of what's going on.
I know what .net native is and how it is different from the usual .net compilation, I am just not so sure it is of any actual use on windows phone. I know a lot of people would kill to get this on desktop (well, they technically do, with ngen), but on windows phone, i really don't see the need.
It'll be faster to run, no memory overhead with the compilation and better protection of your code. I see it as very useful for those who want to code in C#, but have it fully compiled to native binary for the speed and execution time without having to use C++. I don't really see how it couldn't be useful, but to each their own I guess .
I just posted this because it was a cool tweak that I've seen some interest from in others.
Well, it's undeniably a cool find. I'm unsure of its usefulness, though.
Normal phone apps, even from the Store, still have the CIL binary code in them. This makes them much easier to reverse engineer, among other things.
On the other hand, a JIT (from CIL to native) can perform some platform-specific optimization, which may produce a faster-running binary than one which is compiled for a generic target. With that said, I don't believe that the Store apps actually get JITed on the phone - I *think* they are instead pre-compiled to native for each processor that is in common use, and the correct one is installed - so this performance improvement may already be present. On the flip side, while .NET Native does allow you to bypass the JIT startup time (I assume that's what you meant by "speed and execution time" since it still performs the other things, like dynamic memory management and so on, that slow down managed code...), so does the precompiled-at-the-store approach.
A clear downside of .NET Native is the large binaries it produces. That wastes space with a lot of install footprint, and may also cost memory (assuming the phone kernel retains the page combining feature of NT6.2 and higher on the desktop, this impact could be minor or it could be massive depending on whether the chunks of code from the .NET framework are compiled in aligned on page boundaries and thus suitable for combining). On the other hand, there's no need to keep both the CIL and the native code in memory at once, so it could save some RAM too.
Anyhow, you're getting something that may actually run slower (all the downsides of managed code at runtime, none of the advantages of JIT) without any faster startup than is already available from the Store. It makes bigger downloads and uses more install space, and may also cost extra RAM at runtime (or may not). Unless you really want to use a managed language in a hard-to-reverse-engineer way - which is admittedly a common goal, as evidenced by all the obfuscators out there - this doesn't seem like an advantage over the existing options.
GoodDayToDie said:
A clear downside of .NET Native is the large binaries it produces. That wastes space with a lot of install footprint, and may also cost memory (assuming the phone kernel retains the page combining feature of NT6.2 and higher on the desktop, this impact could be minor or it could be massive depending on whether the chunks of code from the .NET framework are compiled in aligned on page boundaries and thus suitable for combining). On the other hand, there's no need to keep both the CIL and the native code in memory at once, so it could save some RAM too.
Click to expand...
Click to collapse
^^ This was my only big concern.. The immense binaries.
Does this actually work for you on the device? For me, it adds bunch of references to Kernel32.dll, which obviously doesn't exist on the phone and in result it fails to even start.
Sunius1 said:
Does this actually work for you on the device? For me, it adds bunch of references to Kernel32.dll, which obviously doesn't exist on the phone and in result it fails to even start.
Click to expand...
Click to collapse
It worked for me when I tested on my phone (Lumia 1520/Cyan). I made this thread only after having it work on my device first. I tried it without the Cyan firmware first though.
snickler said:
It worked for me when I tested on my phone (Lumia 1520/Cyan). I made this thread only after having it work on my device first. I tried it without the Cyan firmware first though.
Click to expand...
Click to collapse
Strange. If I download your attached "Empty" app, and open the main .dll in Depends.exe, I can clearly see 2 references to kernel32.dll and one to ole32.dll.
Sunius1 said:
Strange. If I download your attached "Empty" app, and open the main .dll in Depends.exe, I can clearly see 2 references to kernel32.dll and one to ole32.dll.
Click to expand...
Click to collapse
Hmm, does it actually deploy and run for you though?
snickler said:
Hmm, does it actually deploy and run for you though?
Click to expand...
Click to collapse
Well, you posted naked files, not an app package. Making a package with makeappx and trying to deploy it with the AppDeploy.exe fails the deployment fails due to dependency check.
Sunius1 said:
Well, you posted naked files, not an app package. Making a package with makeappx and trying to deploy it with the AppDeploy.exe fails the deployment fails due to dependency check.
Click to expand...
Click to collapse
that IS the package made via Visual Studio when you click to prepare a Store app (which uses makeappx to generate the appx project). You're probably missing the VCLibs dependency on your phone (somehow).
Packaging doesn't INCLUDE the dependencies with the package manually. The VCLibs appx is on the file system if you have the 8.1 SDK though.
/facepalm. Since you posted it as a zip file, I actually thought you zipped up output folder, instead of building app package and then renaming.
However, it will still not deploy for me. I do have VCLibs, and even putting them next to the appx file fails the deployment process. Anyway, I'll try some more stuff to see if I can get it to work.
Related
I have a little experience in using C, C++, Visual C#, VB6 and Macro Media AS. Now I want to explore programming appz for PPC.
What is the best programming language for developing PPC app that I can use.
Hi, greate!
Except for Macro Media all the languages you mentioned have compilers for PPC and some are even free.
As for which one is the best, well that depends on what you want from it.
My personal favorite is C++ because:
a. it’s the most powerfulpowerful (easy access to system APIs)
b. it runs faster (no interpreter)
c. you can download a compiler from Microsoft for free. (eMbedded visual C++ 4)
The only down side is that it's not a real visual language so you will have to do more work then in VB.
c# has the all the advantages of .NET but you need Visual Studio 2005 to make PPC specific apps + they take a while to load.
As for Visual Basic there are several compilers including eMbedded Visual Basic 3 from Microsoft (free), but I read the apps written in it are slower. Still it’s a fully visual language.
This is my opinion. You should search for other postings in this forum (there were a couple more on this subject) if you haven’t done so already.
Good luck!
I asked the same question 2 years ago!
I started developing PPC software about 2 years ago - I too needed to find out whuch was the best language - so I tried them all!! - I tried Java - C# - Creme - and C/C++.
Without any doubt at all C/C++ is best - it is native, fast and relativly streight forward. You can use MFC if you like. You can download the compiler free from Microsoft and the support is actually quite good. The Compiler IDE is quite good also.
Just to revive this thread. I thought of starting to write something for PPC. I thought the best place to start is to get the Windows Mobile SDK from Microsoft. However, it seems that the SDK require Visual Studio 2005+ to be installed before I can have the SDK installed. Is there another way to get it started (preferably with SDK and examples) without having me to get a Visual Studio 2005.
Additional info about me: I used to be good in C++ for DOS/Windows, but the current works requires me to work in Java (multi platform). So, just give me a vague idea and I'll find my own way
Hanmin - download the SDK for WinMob 2003, not WM5. EVC supposed to only be compatible with WM2003 SDK. VS2005 for WM5 stuff. The download is a lot smaller too!
V
hands down c/++
normal basic is evil
basic .net is just c# with an evil syntax
c# is nice enough but slow ever so slow
java dont have as nice a platform as on symbian or pc's or well anything else then pocketpc's
with mfc some work is done so you dont need to do manualy for every app
but doing it pure win32 is faster though but have a higher learning curve
I had downloded the embedded VC and installed the SDK for WM2003. I'm trying to write a software to determine the remaining life time of a battery in terms of hours and minutes.
This is what I found out. To get the battery status, I can get it from
SYSTEM_POWER_STATUS_EX
which quite a few properties, but of the few, the interesting ones are:
BYTE BatteryLifePercent;
DWORD BatteryLifeTime;
For BatteryLifePercent, it is Ok. I get to print out the percentage based on
wsprintf(szTextBuffer, TEXT("Battery: %i%%"), g_bBatteryPercentage);
where I assign BatteryLifePercent into BTYE g_bBatteryPercentage
However, for BatteryLifeTime, I seems to be having some problems. I have the code
Code:
if (g_dBatteryLifeTime == BATTERY_FLAG_UNKNOWN){
wsprintf(szTextBuffer, TEXT("lifeTime: unknown"));
} else {
wsprintf(szTextBuffer, TEXT("lifeTime: %hu"), g_dBatteryLifeTime);
}
and I get the value "65535", which if that represent seconds, I should have 18 hours of battery life left. However, I think I have less than that. And consider 65535 is a '2'-base number, it looks more like it is either overloaded or it is a reserved flag.
Anyway, my questions:
(a) other than %hu, whatelse can I used for g_dBatteryLifeTime, which is a DWORD. I tried %lu and %i, where the first gives me nothing, the second one hang my machine.
(b) is this `BatteryLifeTime` working or not?
%d is the normal switch to get a nr
There's a constant BATTERY_FLAG_UNNKOWN that you should test against, also. If that's set, the life time isn't valid. Otherwise, like it or not, that's how long the phone thinks it has left. Keep in mind that the value is probably going to vary wildly as power usage can vary pretty wildly. As mentioned above, you should do something like:
SYSTEM_POWER_STATUS_EX sps;
TCHAR sz[ 64 ];
GetSystemPowerStatusEx( &sps, TRUE ); // Use real time, not cached
wsprintf( sz, _T( "Time: %d" ), sps.BatteryLifeTime ); // in seconds
Oh....and as I recall, little of that stuff actually worked except percentage last time I checked so don't be too surprised if all that's valid is percentage.
Actually it all depends on the battery driver. I had a chance to work with some devices that didn't even report percentage, only voltage and I doubt there is a PPC out there that can accurately report time.
If you really want to determine the time you will need some sort of learning mechanism that will measure up time and battery percentage to calculate remaining time.
Guys, this is offtopic. You want me to make a new thread and move the posts?
V
PPL(Pocket Programming Language)
i found a new programming language its PPL(Pocket Programming Language)
you can install it on your ppc this have compiler ,interpreter and others you can write a program on your ppc and compile it to exe
but C++ is a boombastic language for me,you,
VJ: No problem. I think it stopped. Actually, I've stopped the programming front, I'm skinning these days
accepted: It looks alright, but as it is not a standard language, the stuff you learned from it will go as the PPL disappeared, but with C++, it will stays quite a while. I used to be a C guy and now I'm more of a Java guy which I think C will end as Java rule the world.. but C stands up very strong (thanks to M$). Anyway, you can try the embeded version with tutorial and stuff, easy to start but quite difficult to do a full scale program with it (for beginners). If yuou want quick and dirty method of writing limited number of programs, yeah, I think PPL will takes you on a while.
PPL
Write software for your PocketPC and PC in minutes using our new programming language. PPL is a fast and easy-to-learn programming language that is fully object-oriented. PPL runs on all Pocket PC using PocketPC 2000, 2002, Windows Mobile 2003, 2003SE, and 2005 (VGA compatible). PPL also runs on Windows 2000, XP, 2003 Server desktop computers. Programs written for one system are 100% compatible with the other.
Write high quality games in no time using our easy-to-use GameAPI that incorporates physics, isometric display support, pixel-perfect collision detection and so much more...
Design forms visually on your PDA or desktop computer with the visual form builder. Edit components properties and code events within the same interface. PPL is a complete development environment.
{
"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"
}
The main interface for PPL on the PocketPC. It has been written entirely in PPL and the source code is provided.
Write programs on the road. The editor on the PocketPC. It has been written entirely in PPL and the source code is provided.
Create nice forms on the road. The Visual Form Builder on the PocketPC. It has been written entirely in PPL and the source code is provided.
Get a complete report with statistics on compiling even on the PocketPC.
SDK<Software Development Kit> Edition Features
Windows API support
Visual form design
Linked-List support
Object-Oriented syntax
Powerful matrices
Tools to develop on PPC
String compression
GameAPI
COM and ActiveX
Regular expressions
Enhanced versions of PIDE
Physic & particles engine
File Packaging
Compile to .exe
PPL Assembler (PASM)
Code Profiler
Memory Leak Analyzer
Extended functions
Full version of PIDE
SDK libraries
What is the SDK version of PPL?
The SDK version is a simple module that you include with your project to allow for scripting capabilities. You can also integrate your own functions inside the PPL language. It comes with a pplsdk.dll file (for the PC and PocketPC) and header files for C, Visual Basic and Delphi. The SDK comes with the Pro version of PPL
Acronyms
SDK = Software Development Kit
API = Application Programming Interface
PPL = Pocket Programming Language
PPC= Pocket PC
PIDE = PPL Integrated Development Environment
VGA = Video Graphic Adapter
PDA = Personal Digital Assistant
PC = Personal Computer
Code:
http://www.arianesoft.ca/
it's very very portable language
Rudegar said:
java dont have as nice a platform as on symbian or pc's or well anything else then pocketpc's
Click to expand...
Click to collapse
what about SuperWaba? maybe it could satisfy hanmin's requirments.
I use ppl too. The IDE is really comfortable. You get good results very quickly...
Recently, i came across a binary file that ran on PC as well as Pocket PC. i cant quite get myself to recollect where i saw, but i do remember something like a 'pure .net' application.
i was wondering if someone could point me to a place where i could get more information about development of such a application.
Thanks
As you may know, PPC Binaries are ARM based (most of the time) and PC binaries are X86 code, so it shouldn't be possible to easily swap from one to the other.
BTW, .Net binaries (which differs from real binaries) are intended to run on whatever plateform, as long as there is a Common Language Runtime accessible.
So an application designed for the .Net Compact Framework should be able to run on the .Net Framework under Windows (with MSIL Code) .
'Hello world' application?
so could you possible send in a 'Hello world!' application of some sorts.. ?
foxenesys said:
So an application designed for the .Net Compact Framework should be able to run on the .Net Framework under Windows (with MSIL Code) .
Click to expand...
Click to collapse
Confirmed. I did it.
However, I was unable to do it again recently. Maybe the application I succesfully wrote and ran on both the PC and the PPC was made using the .NET Compact Framework v1, while the applications I write actually use the v2.
Lieutenant said:
Confirmed. I did it.
Click to expand...
Click to collapse
what project was it? what did the application actually do? how was it developed??
Here's some information: http://msdn.microsoft.com/msdnmag/issues/07/07/ShareCode/default.aspx
The app was indeed likely a .NET (Compact) application, it will run on any device that has the .NET Compact framework installed (most older phones have v1 (WM5), my Kaiser has v2 installed(WM6)). Note that if you start writing like that, you will most likely be writing for v2, and for a large number of PPC that means the user will also still have to install .NET Compact Framework v2 which may take up to 25mb.
Though the idea behind .NET is nice, and on PC's there's hardly a noticable different between a natively compiled application and a .NET application, on a PPC you do really notice the difference. The .NET apps are very noticable slower in operation and slower in load and take more memory than the natively compiled apps. On the other hand, they usually are only a few KB in size, but that's because all the magic happens in the .NET Compact Framework which is a seperate install (comes preloaded with WM6).
Also, when developing with .NET Compact Framework I have also noticed it is very limited, compared to the normal .NET Framework, and even more limited compared to native applications.
Personally, I use the FreePascal compiler (which can create binaries for pretty much every platform out there, from Windows to Linux to Windows Mobile to Nintendo DS)
Chainfire said:
Personally, I use the FreePascal compiler (which can create binaries for pretty much every platform out there, from Windows to Linux to Windows Mobile to Nintendo DS)
Click to expand...
Click to collapse
But it wont compile a same binary file that will run on x86 architecture and ARM architecture will it..?
what i had in mind was a application when run on my PDA will act as a normal application and when the same file was opened on my desktop computer will run like a normal win32 application, without throwing the '... not a valid Win32 application' error.
tomjan said:
But it wont compile a same binary file that will run on x86 architecture and ARM architecture will it..?
what i had in mind was a application when run on my PDA will act as a normal application and when the same file was opened on my desktop computer will run like a normal win32 application, without throwing the '... not a valid Win32 application' error.
Click to expand...
Click to collapse
Indeed you would need two different executables for it my way, but IMHO compared to your slower, less responsive and more limited version that only needs one executable it is still a much better option.
Chainfire said:
Indeed you would need two different executables for it my way, but IMHO compared to your slower, less responsive and more limited version that only needs one executable it is still a much better option.
Click to expand...
Click to collapse
Peace...
the point is, there could be scenarios where a cross platform application could be helpful even though it might suffer from serious perfromance issues.
like offhandedly, if you consider PIMBackup application, if if had the ability to display the backedup file on your PDA and your PC, viola.. the phone could act like a 'Portable' outlook, with no requirement of active sync to be installed.
all said and done.. this is no an argument about native vs. .net, because i have NO experience at all with mobile application development. just thought it was cool to be able to run a a same file on two entirely different architectures / platforms / blah blah...
Thanks
Rhapsody said:
Here's some information: http://msdn.microsoft.com/msdnmag/issues/07/07/ShareCode/default.aspx
Click to expand...
Click to collapse
Thanks Rhapsody, this should keep me occupied for some time.
That's an app to help you lock screen and adjust volume with tiles. It calls functions in ShellChromeAPI.dll . Finally, it got published with English version.
link: http://www.windowsphone.com/en-us/store/app/quick-tiles/1725cca2-2349-4d33-b5d5-8b04e7810c04
(You may need to switch your phone language to English to download the English version. otherwise, the Chinese version will be shown. Forgive me for my tight schedule and I have to split different languages into different XAPs, for I only spent 2 hours developing this app...)
I've found two ways to pass the marketplace API detect, one is to use P/Invoke and the other is to load LoadLibraryExW without extern that from the lib provided by Microsoft.
both methods will be provided here in a month, and I may provide write some wrappers or static libraries.
Notice that I only found ways to access restricted API, but get higher privilege is not possible.
By this way, I think @GoodDayToDie 's HTTP Server with registry browser can be published with some simple modify. Even publishing the samsung interop unlock guide, which launches the toast using undocumented, is possible. Maybe we should try to find more useful functions which can be called without privilege in different dlls.
hjc4869 said:
That's an app to help you lock screen and adjust volume with tiles. It calls functions in ShellChromeAPI.dll . Finally, it got published with English version.
link: http://www.windowsphone.com/en-us/store/app/quick-tiles/1725cca2-2349-4d33-b5d5-8b04e7810c04
(You may need to switch your phone language to English to download the English version. otherwise, the Chinese version will be shown. Forgive me for my tight schedule and I have to split different languages into different XAPs, for I only spent 2 hours developing this app...)
I've found two ways to pass the marketplace API detect, one is to use P/Invoke and the other is to load LoadLibraryExW without extern that from the lib provided by Microsoft.
both methods will be provided here in a month, and I may provide write some wrappers or static libraries.
Notice that I only found ways to access restricted API, but get higher privilege is not possible.
By this way, I think @GoodDayToDie 's HTTP Server with registry browser can be published with some simple modify. Even publishing the samsung interop unlock guide, which launches the toast using undocumented, is possible. Maybe we should try to find more useful functions which can be called without privilege in different dlls.
Click to expand...
Click to collapse
What restricted API's possible to upload ?
ngame said:
What restricted API's possible to upload ?
Click to expand...
Click to collapse
you can load any API functions. but only some of them can be called and only a few is really useful.
I only tested the following functions
BOOL Shell_IsLocked()
void Shell_TurnScreenOn(BOOL)
void Shell_AdjustVolume(int)
hjc4869 said:
That's an app to help you lock screen and adjust volume with tiles. It calls functions in ShellChromeAPI.dll . Finally, it got published with English version.
link: http://www.windowsphone.com/en-us/store/app/quick-tiles/1725cca2-2349-4d33-b5d5-8b04e7810c04
(You may need to switch your phone language to English to download the English version. otherwise, the Chinese version will be shown. Forgive me for my tight schedule and I have to split different languages into different XAPs, for I only spent 2 hours developing this app...)
I've found two ways to pass the marketplace API detect, one is to use P/Invoke and the other is to load LoadLibraryExW without extern that from the lib provided by Microsoft.
both methods will be provided here in a month, and I may provide write some wrappers or static libraries.
Notice that I only found ways to access restricted API, but get higher privilege is not possible.
By this way, I think @GoodDayToDie 's HTTP Server with registry browser can be published with some simple modify. Even publishing the samsung interop unlock guide, which launches the toast using undocumented, is possible. Maybe we should try to find more useful functions which can be called without privilege in different dlls.
Click to expand...
Click to collapse
Interesting. But almost useless cause now all can freely make a developer unlock. Store apps can use RPC but this requires InteropServices CAP.
-W_O_L_F- said:
Interesting. But almost useless cause now all can freely make a developer unlock. Store apps can use RPC but this requires InteropServices CAP.
Click to expand...
Click to collapse
yes I tried it before in beta app .
ID_CAP_INTEROPSERVICES , Xbox live and exe files in xap are unable to upload !
And those APIs work without having the restricted capabilities in the manifest file?
After the update, it went back to Chinese... it would be nice if you set English as the default language, at least for European and American countries
mcosmin222 said:
And those APIs work without having the restricted capabilities in the manifest file?
Click to expand...
Click to collapse
Yes.
-W_O_L_F- said:
Yes.
Click to expand...
Click to collapse
Hmmm
This looks interesting.
P/Invoke? How did you manage to use it? I thought it was not available for Silverlight?
pinvoke is possible with silverlight, but according to microsoft it is illegal on the marketplace.
which is half true. you cant pinvoke a native dll compiled for arm, but the wp8 own dlls seem to make an exception
mcosmin222 said:
you cant pinvoke a native dll compiled for arm, but the wp8 own dlls seem to make an exception
Click to expand...
Click to collapse
What is the difference?
Useless guy said:
What is the difference?
Click to expand...
Click to collapse
Go ask microsoft.
If you scroll down you will find that p/invoke is not allowed in wp8 sdk
http://msdn.microsoft.com/en-us/lib...jj206940(v=vs.105).aspx#BKMK_Appcompatibility
however, the OP seems to have managed to do it with a DLL contained in the WP8 system.
I never actually tried to p/invoke something on the marketplace. Maybe this needs additional research to see if arm compiled third party dlls can be used.
I remember some guy on the forum trying to p/invoke a native ARM dll and got type load exceptions.
by native i mean something which is not compiled with C++/CX for windows phone. As in pure C/C++ targeted for ARM.
mcosmin222 said:
Go ask microsoft.
If you scroll down you will find that p/invoke is not allowed in wp8 sdk
http://msdn.microsoft.com/en-us/lib...jj206940(v=vs.105).aspx#BKMK_Appcompatibility
however, the OP seems to have managed to do it with a DLL contained in the WP8 system.
I never actually tried to p/invoke something on the marketplace. Maybe this needs additional research to see if arm compiled third party dlls can be used.
I remember some guy on the forum trying to p/invoke a native ARM dll and got type load exceptions.
by native i mean something which is not compiled with C++/CX for windows phone. As in pure C/C++ targeted for ARM.
Click to expand...
Click to collapse
I know what pinvoke is perfectly, don't send me to msdn as long as I'm able to find it by myself.
Both an unmanaged dll and a WinRT component are native. CLR wraps every COM\WinRT object in the Runtime Callable Wrapper, but the object itself stays in the unmanaged heap.
If you think that WinRT or C++/CX are not native, you're wrong.
To @hjc4869
How did you manage to bypass marketplace analysis using P\Invoke? I'm fairly certain that MS checks metadata for DllImport attribute.
I'm going to try the second way, thanks!
Useless guy said:
I know what pinvoke is perfectly, don't send me to msdn as long as I'm able to find it by myself.
Both an unmanaged dll and a WinRT component are native. CLR wraps every COM\WinRT object in the Runtime Callable Wrapper, but the object itself stays in the unmanaged heap.
If you think that WinRT or C++/CX are not native, you're wrong.
To @hjc4869
How did you manage to bypass marketplace analysis using P\Invoke? I'm fairly certain that MS checks metadata for DllImport attribute.
I'm going to try the second way, thanks!
Click to expand...
Click to collapse
never said you don't know what p/invoke is.
I just wanted to show you that it is illegal in wp8 SDK (which that link leads to).
And if you actually read that link, you would see that invoking winRT or C++/CX (compiled for WP8) is allowed. This is probably due to the fact that these methods still execute in a sandbox. While MS won't allow arm compiled dll without the WP8 SDK because it can't verify its security.
mcosmin222 said:
And if you actually read that link, you would see that invoking winRT or C++/CX (compiled for WP8) is allowed. This is probably due to the fact that these methods still execute in a sandbox. While MS won't allow arm compiled dll without the WP8 SDK because it can't verify its security.
Click to expand...
Click to collapse
What does it mean - compile for WP8? I can add to the package any dll that uses Win32 (non-restricted) and compiled for ARM. The library will work on both WP and W8 without recompilaton.
Useless guy said:
What does it mean - compile for WP8? I can add to the package any dll that uses Win32 (non-restricted) and compiled for ARM. The library will work on both WP and W8 without recompilaton.
Click to expand...
Click to collapse
Will it? When you compile a C++ dll for desktop, it references kernel32.dll and unless you explicitly exclude it from the linker, it couldn't possible work on WP8 since there's no kernel32.dll.
Hi all
Trying to play with this method, but it seems LoadLibraryExW is not available. The only function available is LoadPackagedLibrary and when I try to run it, I've got C00000D error which is STATUS_INVALID_PARAMETER.
---------- Post added at 01:03 PM ---------- Previous post was at 12:49 PM ----------
It seems LoadPackagedLibrary only loads .dll from installation folder of application and do not allows full path in name. Thats why I got invalid argument error
Useless guy said:
What is the difference?
Click to expand...
Click to collapse
Code signature.
Sunius1 said:
Will it? When you compile a C++ dll for desktop, it references kernel32.dll and unless you explicitly exclude it from the linker, it couldn't possible work on WP8 since there's no kernel32.dll.
Click to expand...
Click to collapse
Kernel32.dll is the huge part of Win32 and it exists on both WP and Windows. WPSDK doesn't include kernel32.lib, but I'm pretty sure it can be easily generated from dll file.
#define WINAPI_PARTITION_DESKTOP and kernel32.lib should work, I think.
UPD:
I forgot, kernel32 could be removed as it's just the compatability layer for kernelbase.dll and new windows 8 api sets (api-ms-*.dll).
clrokr said:
Code signature.
Click to expand...
Click to collapse
DLLs are signing on certification process.
This program is found in the depths of the internet, and would like to share with you, because it deserves attention.
I hope the author will not be offended.
{
"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"
}
View attachment Process.Viewer.WP8.xap
spavlin said:
View attachment 2635723
Click to expand...
Click to collapse
So nice . well done .
no Interop Unlock Needed and works very smooth and very fine .
Tested on Lumia 920 RM-821 .
Whoa, very cool! Mind sharing the source, or at least the technique used? I tried this months ago and concluded that apps could only see processes running in their own chamber. Even adding ID_CAP_FOREGROUND_TASK_MANAGER only helped a little (let me see the debugger when it was running, not much else). You managed to get a *ton* of info using only completely ordinary capabilities, and I'd really like to know how!
Thanks for sharing the app, though.
Oh, and however you're managing to open handles to system processes, how much access do those handles have? In particular, can you use debug APIs? I really doubt it, but it's totally worth trying... because if it is, we've got arbitrary root.
GoodDayToDie said:
Oh, and however you're managing to open handles to system processes, how much access do those handles have? In particular, can you use debug APIs? I really doubt it, but it's totally worth trying... because if it is, we've got arbitrary root.
Click to expand...
Click to collapse
reker written this programm)
...:laugh:
Working with my Lumia 925 :good:
Long time i've not been around, and suddenly found this really interesting thread (i'm playing with a lumia 920) i've been able to rebuild the application (generate source from xap) and found some interesting things, there are 2 dll that contain the process tools, one wrapper for them and one dll that is used to "protect" the application:
Win32ProcessWrapper_RT.winmd: wrapper for: WP8ProcessUtils.dll and WP8NativeShellHelper.dll
Win32ProcessWrapper_RT.dll : checks for the publisher id and application id (without that, it disables the dll call's
But the really really interesting part is that there are some functions not added in the wrapper but available on the WP8ProcessUtils.dll, not sure if it's due to elevation required or maybe for another reason (as far as i can see it is able to gain access out of the sandbox so elevation should not be an issue, but who knows, i'm not an expert on that)
here are the functions inside the WP8ProcessUtils.dll
and as you can see, they are not present in the wrapper:
I've attached the VS solution reconstructed from the xap (code is not something to say "ohhh" but it works ), maybe someone can take a look and see if the wrapper could be rebuilt to use the missing functions.
Salu2!
Interesting! I'd looked at the exports, but I hadn't caught the same things you had. The WP8_* functions are odd; Win32 doesn't use the "FindFirst/FindNext" paradigm for processes, so far as I can tell. However this app enumerates processes, it's doing something funky. It doesn't even call EnumProcesses, not that this surprises me terribly (since that API won't return any processes outside your AppContainer). The presence of multiple Open* (as in, WP8_OpenThread, WP8_OpenThread2) functions is intriguing. One can safely presume that one of them is the standard Win32 APIs (OpenProcess, OpenProcessToken, and OpenThread are all imported from kernelbase.dll). The question is, what are the other ones? Even "guessing" process IDs doesn't let you use OpenProcess on them...
All the interesting stuff seems to be in the native code (no big shock there, really). Gotta get that source...
Apologies for failing to notice the bit about finding (rather than writing) this app. I've emailed the dev.
GoodDayToDie said:
Interesting! I'd looked at the exports, but I hadn't caught the same things you had. The WP8_* functions are odd; Win32 doesn't use the "FindFirst/FindNext" paradigm for processes, so far as I can tell. However this app enumerates processes, it's doing something funky. It doesn't even call EnumProcesses, not that this surprises me terribly (since that API won't return any processes outside your AppContainer). The presence of multiple Open* (as in, WP8_OpenThread, WP8_OpenThread2) functions is intriguing. One can safely presume that one of them is the standard Win32 APIs (OpenProcess, OpenProcessToken, and OpenThread are all imported from kernelbase.dll). The question is, what are the other ones? Even "guessing" process IDs doesn't let you use OpenProcess on them...
All the interesting stuff seems to be in the native code (no big shock there, really). Gotta get that source...
Click to expand...
Click to collapse
You are right, there is some sort of "voodoo" hidden in that dll, but based on the level of "protection" the application has (for a lack of other term) i'm not pretty sure the dev would be willing to release that portion of the code (he wrote one wrapper to interface a dll that checks developer id in order to allow the app to use the exports, too much work for something that you are willing to release, and also a very good strategy to prevent MS/Nokia to patch it)
Maybe our best shoot is with someone with better ida - hex ray experience (for sure any experience is better than mine )
Cheers
---------- Post added at 03:47 AM ---------- Previous post was at 03:34 AM ----------
GoodDayToDie said:
Whoa, very cool! Mind sharing the source, or at least the technique used? I tried this months ago and concluded that apps could only see processes running in their own chamber. Even adding ID_CAP_FOREGROUND_TASK_MANAGER only helped a little (let me see the debugger when it was running, not much else). You managed to get a *ton* of info using only completely ordinary capabilities, and I'd really like to know how!
Thanks for sharing the app, though.
Click to expand...
Click to collapse
Btw, as i said, i'm not an expert on wp applications (just got the wp8 a couple of weeks ago) i've tried to add that capability on the application but says "invalid" is there other way to add it besides WMAppManifest? (additional files, etc.)
Thanks!
No. You can use it on capability-unlocked phones, but not on standard dev-unlock.
I'm not great with IDA but I can use it. It'll just take longer :/
Pretty sure most of the code isn't that exciting anyhow - I've written apps that get all that info once given a process handle - but getting those handles (to anything but your own process) is the hard part. We Shall See.
GoodDayToDie said:
No. You can use it on capability-unlocked phones, but not on standard dev-unlock.
Click to expand...
Click to collapse
I only have development unlock and the app worked on my WP8.1 Nokia.
GoodDayToDie said:
I'm not great with IDA but I can use it.
Click to expand...
Click to collapse
I'm good at IDA but don't know ARM assembly at all
GoodDayToDie said:
getting those handles (to anything but your own process) is the hard part.
Click to expand...
Click to collapse
Looks like to enum processes, this app just tries sequential process IDs, tries to open it, checks for status code.
Why snapdragon s4 has only 1.2 GHz clock??
What does that have to do with this thread, and why'd you post in a six-months-dead thread anyhow?
because i have joined, this forum 6 day ago
DOWNLOAD HERE: https://github.com/lavacano201014/tilandis/releases
Tilandis
A drop in replacement for TileCreator Proxy
{
"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"
}
Overview
TileCreator is one of several UWP apps designed to allow you to pin custom tiles to your start menu. The way these apps work is they launch a companion app (in TileCreator's case, TileCreator Proxy) that's associated with a specific protocol, and that companion app is what actually launches programs.
The problem is, while TileCreator itself works well, TileCreator Proxy is terrible. This isn't intended to be a jab at the developer, but let's be real - having to use .lnk or .bat files for half your programs isn't exactly the best experience.
The base problem here is working directories: Many programs assume their working directory will always be the directory they've been installed to. In most cases, they're right, since Windows shortcuts (.lnk) use the directory of the executable as the default working directory. TileCreator Proxy, however, launches processes within its own working directory, which is some space directory in the middle of absolutely nowhere sensible. I've mentioned this to the developer, and it hasn't been fixed, and now that developer hasn't logged in since November. It's incredibly likely that the developer has real life problems that he's prioritized over his development work. And I can't blame him. But this problem needed fixing, so Tilandis is here to fix it.
Project Status
What Works:
Link management
Creating links
Deleting links
Replacing existing links (with -f)
Launching links
Protocol registration (so you can use it with TileCreator)
Arguments and working directories (including automatically defaulting to executable's directory)
Command line interface
Automatically closing TileCreator behind you (at the moment, ONLY TileCreator - planning to make this configurable)
Running links as administrator
The GUI
What's Planned (but doesn't work yet)
Link validation (at the moment, Tilandis just accepts stuff willy nilly, which includes a few characters that aren't legal for filenames or link names. For now, it's up to you not to include the : or / characters in your link names.)
Live tile companionry (waiting for a UWP implementation first)
Installation
Go to the link at the top of the post, and download the latest version's installer.
Run said installer.
That's it. Next section.
Usage
The basic procedure:
Open a command prompt (this one doesn't need to be administrator) and navigate to where you put Tilandis. If you put it in C:\Users\Your_Name_Here, this may done for you if you use PowerShell.
If you need to specify arguments, you can specify them with -a (e.g. `-a "-sw -noborder"`). If you need to specify a working directory that differs from the default (if you're not sure, then no you don't), you can specify that too, with -w (e.g. `-w "C:\Program Files"`). These options go alongside the basic command line.
FAQ&FSS (Frequently Asked Questions and Frequently Said Statements)
Why should I use this over TileCreator?
You misunderstood the post. Read it again.
Can I use this with some other UWP app, like Better StartMenu?
Yes! Simply install the app, launch a tile with it, and see what Windows spits out. It should come up with "You'll need a new app to open this <something>." That "something" is the protocol you tell Tilandis to register with:
Code:
tilandis -r <something>
Why should I use this (alongside something like TileCreator) over some program that uses visualmanifests.xml?
VisualManifests.xml doesn't support wide or large tiles. Also, although no working implementation currently exists, the UWP app method is capable of displaying "live" tiles (meaning they update every so often, like official Windows store apps).
Are you going to make a UWP (Metro) app to go with Tilandis?
Doubtful. In my opinion, the UWP side of things is already well covered as it is, for being this early on in Windows 10's life. However, I might later just for the laughs, or if nobody ever gets around to implementing live tiles. If I do implement one, I'll look into throwing in jump lists too while I'm at it (because hey, jump lists).
Is it buggy?
I've been using release builds alongside TileCreator as my daily driver for start tiles since I first got link launching to work. I've had no problems. That said, I have no extra-paranoid security software, and do not currently test the automatic replacement of existing TileCreator Proxy installations.
I'm getting an error (or maybe more than one) about some MS or VC DLL missing.
You're missing the 2015 VC++ redist. Make sure you install the 64 bit one, this is a 64 bit application.
Wait what? Why is it a 64 bit app?
It's 2016. If you're on a 64 bit processor, you should be running a 64 bit OS by now. 32 bit emulation is 1:1 perfect, and Windows hasn't had 16 bit applications since it ran on top of DOS, so there's no reason you should need a 32 bit OS on a 64 bit processor. If your processor is only 32 bit, you're officially retrocomputing.
I've actually got some reason to be running a 32 bit OS.
The source is on GitHub, under the MIT license unless I find one I like better. It's the whole solution, just clone the repo, open it in Visual Studio 2015, set it to x86 and press F7. I don't do anything bizarre with my solution or toolchain, should just spit out a 32 bit Tilandis.exe. You can even build it on a 64 bit computer for a 32 bit system.
Please note that bugs that only occur when running a 32 bit build of Tilandis will not be fixed. They are, however, extremely unlikely.
Does it support URLs? Non-executable files?
Yes. Internally, it just feeds the path, args, and working directory to ShellExecute(), so it should be able to launch nearly anything you can double click on in File Explorer with its appropriate program, or open any URL you feed it.
As an example, to launch TF2 through Steam:
I looked at your source code, it's terrible.
I never claimed it was good code, I just claimed I had better functionality. But C++ is definitely not my forte, since my native programming language is Python. And I was stoned for a lot of this project. But it works, and I'm honest about it (even though it's only my word for it), so in the end I still get at LEAST a C+ for this.
I can't seem to get past the fourth step of installation. I've moved the file into multiple locations, used both powershell and command prompt, but I never get a response after typing the command. Running it as an administrator has no noticeable effect on either command prompt or powershell.
Any idea what could be wrong?
Not working for me
After quite a bit of testing, I think I've figured it out. I'll detail my steps and see if anyone can figure anything out from there.
Go to the link at the top of the post to download the latest executable.
Place the executable anywhere. I personally placed it in the TileCreator Proxy installation folder, which for me is found at "C:\Program Files (x86)\TileCreator".
Open an administrator PowerShell and change the directory to wherever you put Tilandis. For me, the command to do this was cd "C:\Program Files (x86)\TileCreator" .
At this point, run the command in the original post. I don't know what the command does entirely, it seems like it would change something, but it doesn't as far as I can tell. I had to run it using .\Tilandis -r TileCreator as the original command left out the location of Tilandris which seems to be needed in PowerShell.
After this, you can close PowerShell.
Open PowerShell (administrator never hurts) and navigate to where your placed Tilandris.
Create a new link using the command .\Tilandis -n MyLinkName -p "C:\Link\To\The\Desired\Executable.exe"
Tilandris will then create a file called links.json that seems to be unusable by TileCreator. Changing links.json to links.config seems to allow it to be accepted and used normally.
Import the new config.config into TileCreator and you will be able to make tiles. This still points to TileCreator Proxy, which I imagine would not be the case if step four of the original process worked, but I can't figure it out.
Setup a tile how you normally would.
I hope we get a reply from the creator, as I'm positive this isn't how this is supposed to work.
What the command "tilandis -r tilecreator" is supposed to do is modify the Windows registry (that's why it needs administrator, it's supposed to spit an error message if it fails to edit the registry but due to a bug it's silent either way) to register Tilandis with the same protocol TileCreator uses to talk to TileCreator Proxy. I didn't test whether or not it would work if you already had TileCreator Proxy installed because I kind of figured Windows would just overwrite it for me. I don't know why I could have expected that... :V
Please open regedit and delete the key HKEY_CLASSES_ROOT\tilecreator (neither TileCreator nor its proxy keeps any configuration in this key, your tiles are safe), then try "tilandis -r tilecreator" as administrator again. This time, it should go straight to Tilandis without bothering with TileCreator Proxy as a middleman. (I'm surprised TCP accepted my JSON in the first place, I wasn't trying for compatibility). And sorry I'm late, I couldn't remember what password I used for this account and XDA's forgot password page has a broken captcha.
I can confirm that I have this working successfully now. I didn't find the registry entry you mentioned, but that is probably because I decided to delete TileCreator until you had replied to me.
Once you get the TileCreator window closing behind you, I think you've got a very solid replacement for the proxy. Well done, your work is much appreciated. Just don't forget your password this time!
New release! Changelog provided at the link.
The tl;dr is the "run as admin" switch (-A) is now implemented, and Tilandis will now close TileCreator (and at the moment only TileCreator) as it goes.
I'm also considering drafting a separate protocol, "tilectl", allowing UWP apps to create links in Tilandis (and any other proxy app that chooses to implement it) for you. Imagine a program like TileCreator being able to not only pin tiles with whatever image you want, but being able to configure what that tile actually launches without having to launch the other app and set it up yourself!
#NotDead
I knew eventually you would all get frustrated with having to use the CLI all the damn time, so I'm writing a control application for everyone. I'll probably also try and fix protocol registration while I'm at it, because man, that really oughta just work
Any updated info any time soon ?
DroidShift79 said:
Any updated info any time soon ?
Click to expand...
Click to collapse
Good news: There are boxes! And buttons!
Bad news: They don't do anything yet (or I'dve released it already). I'm sorry I'm not faster, I've got a bunch of real life issues that I'm battling at the moment. But, I'm here! And I haven't forgotten!
That's very much a placeholder GUI at the moment, eventually I'm going to come up with something that actually manages tiles properly. Might even build that UWP app after all.
(that's weird, I was sure XDA had an automatic merge for double posts. oh well)
Nice to hear from you.
Don't stress yourself. RealLife always go first!
Take all the Time you need @lavacano201014
Anyway, don't tease us
lavacano201014 said:
I'm sorry I'm not faster, I've got a bunch of real life issues that I'm battling at the moment. But, I'm here! And I haven't forgotten!
Click to expand...
Click to collapse
Hey man, loving the progress. Eager to try out the GUI, but don't let this effect your life (which you seem to not let it be doing, I just wanted to give you a reminder that it's okay.)
Good work!
It's finished!