Right, I've been digging around with the Windows Phone Developer Tools, and have been working on a few things.
The first tool I'm releasing is RemoteExecute, it lets you run any program that's already on the device, supplying a path and any parameters. (e.g. \Windows\RegionCPL.exe)
It's currently only connecting to the first WP7 device it finds (not emulators) but it could connect to any device/emulator if I bothered to code an interface for it.
There's very little error handling, because this has sort of been whipped up in a hurry...
Anyway, it may or may not need a developer unlocked device (I don't know, I've only got unlocked ones) and it doesn't let you deploy anything at all. And you might need the real WP7 Developer Tools, but I can't test that.
Source code may be available if anyone wants it, but I'll need to clean it up a little...
Enjoy, and Merry Christmas!
Update
Requires a developer unlocked device (Chevron should work for this purpose)
Programs to launch...
This is a list of some of the EXEs and what they do (bear in mind there are over 100 in \Windows, I'm not going through all of them!)
\Windows\Settings3.exe - Settings app
\Windows\ShortMsg.exe - SMS
\Windows\WebSearch.exe - Bing
\Windows\WiFiUXSplash.exe - WiFi setings
\Windows\ZipView.exe - Open ZipViewer, with no browsing function, needs ZIP passed via command line
\Windows\OMHub.exe - Office hub
Like on WM6.X, Office apps are PPT.exe, PXL.exe and PWORD.exe, but they need to be launched with command line parameters to open files, as they no longer have a browser built in.
Things that don't work:
\Windows\AutoDataConfig.exe - "Additional information: This program is blocked by group policy. For more information, contact your system administrator."
I like the idea of running apps from the desktop. Unfortunately when I run l3v5y.WP7DT.RemoteExecute.exe and provide a path like \windows\settings3.exe the app crashes:
Description
Faulting Application Path: C:\Native access\l3v5y.WP7DT.RemoteExecute\l3v5y.WP7DT.RemoteExecute.exe
Problem signature
Problem Event Name: CLR20r3
Problem Signature 01: l3v5y.wp7dt.remoteexecute.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 4d164edf
Problem Signature 04: l3v5y.WP7DT.SmartDevice.Connectivity
Problem Signature 05: 1.0.0.0
Problem Signature 06: 4d164e96
Problem Signature 07: 113
Problem Signature 08: 36
Problem Signature 09: TEEK34PJDMM4HDZEPFRMOBGOA4O3JUV0
OS Version: 6.1.7600.2.0.0.256.4
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Have you seen crashes like this? I just have a Samsung connected, and the Zune software running.
obelix said:
I like the idea of running apps from the desktop. Unfortunately when I run l3v5y.WP7DT.RemoteExecute.exe and provide a path like \windows\settings3.exe the app crashes:
Click to expand...
Click to collapse
for me it also crashes no mater what path I use it always crash .
I have a hd7.
ceesheim said:
for me it also crashes no mater what path I use it always crash .
I have a hd7.
Click to expand...
Click to collapse
obelix said:
I like the idea of running apps from the desktop. Unfortunately when I run l3v5y.WP7DT.RemoteExecute.exe and provide a path like \windows\settings3.exe the app crashes:
Code:
Description
Faulting Application Path: C:\Native access\l3v5y.WP7DT.RemoteExecute\l3v5y.WP7DT.RemoteExecute.exe
Problem signature
Problem Event Name: CLR20r3
Problem Signature 01: l3v5y.wp7dt.remoteexecute.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 4d164edf
Problem Signature 04: l3v5y.WP7DT.SmartDevice.Connectivity
Problem Signature 05: 1.0.0.0
Problem Signature 06: 4d164e96
Problem Signature 07: 113
Problem Signature 08: 36
Problem Signature 09: TEEK34PJDMM4HDZEPFRMOBGOA4O3JUV0
OS Version: 6.1.7600.2.0.0.256.4
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Have you seen crashes like this? I just have a Samsung connected, and the Zune software running.
Click to expand...
Click to collapse
Can I check if either of you have the WP7 Developer Toolkit installed?
l3v5y said:
This is a list of some of the EXEs and what they do (bear in mind there are over 100 in \Windows, I'm not going through all of them!)
\Windows\Settings3.exe - Settings app
\Windows\ShortMsg.exe - SMS
\Windows\WebSearch.exe - Bing
\Windows\WiFiUXSplash.exe - WiFi setings
\Windows\ZipView.exe - Open ZipViewer, with no browsing function, needs ZIP passed via command line
\Windows\OMHub.exe - Office hub
Like on WM6.X, Office apps are PPT.exe, PXL.exe and PWORD.exe, but they need to be launched with command line parameters to open files, as they no longer have a browser built in.
Things that don't work:
\Windows\AutoDataConfig.exe - "Additional information: This program is blocked by group policy. For more information, contact your system administrator."
Click to expand...
Click to collapse
Does anybody know which .exe launches the Bluetooth settings ?
Since I left WM 6.5 I´m really missing a Bluetooth and WiFi Toggle on my startscreen...
Thanks in advance
contable
By developer toolkit, do you mean the official Windows Phone Developer Tools? If so yes I have that installed but not any other kits.
I am curious how do you execute a process on the devic, are you connecting to a device side winsock server over USB and calling CreateProcess?
Toddsa said:
I am curious how do you execute a process on the devic, are you connecting to a device side winsock server over USB and calling CreateProcess?
Click to expand...
Click to collapse
I'm using the same libraries as Microsoft use for XAP installation and general communication with the phone (other than Zune media).
I'll post some code/explanations and things when I've got my desktop with me again.
Essentially, it's similar to this, but there are some significant changes between the VS2008+WM6.X model and the VS2010+WP7 one.
If the ability to create a process exists in the public API you may be able to copy a native application to the device and start it using that public API. You could then create an RPC mechanism in your application like RAPI as 6.x devices had. RAPI was just a Winsock client \ server application. I wonder if it is possible to create and deploy a Telnet and FTP server to the device using those public connectivity API.
RAPI is documented on MSDN but since I am under 8 posts I can not include a URL here.
Toddsa said:
If the ability to create a process exists in the public API you may be able to copy a native application to the device and start it using that public API. You could then create an RPC mechanism in your application like RAPI as 6.x devices had. RAPI was just a Winsock client \ server application. I wonder if it is possible to create and deploy a Telnet and FTP server to the device using those public connectivity API.
RAPI is documented on MSDN but since I am under 8 posts I can not include a URL here.
Click to expand...
Click to collapse
Creating processes is, but the file access functions of the libraries seem to give "Access Denied" errors on virtually everything. I'm working on this, and seeing whether there's a different library I can use.
It might be possible to piggy back on the VS2010 debugger utilities, and from there get more control over the device.
The advantage of deploying code to the device directly is it gets around the native code limitations of XAPs, and would allow a lot more freedom. Problem is, it doesn't work yet! I'll post my code when I can, as it's probably a useful basis for achieving more.
obelix said:
I like the idea of running apps from the desktop. Unfortunately when I run l3v5y.WP7DT.RemoteExecute.exe and provide a path like \windows\settings3.exe the app crashes:
Description
Faulting Application Path: C:\Native access\l3v5y.WP7DT.RemoteExecute\l3v5y.WP7DT.RemoteExecute.exe
Problem signature
Problem Event Name: CLR20r3
Problem Signature 01: l3v5y.wp7dt.remoteexecute.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 4d164edf
Problem Signature 04: l3v5y.WP7DT.SmartDevice.Connectivity
Problem Signature 05: 1.0.0.0
Problem Signature 06: 4d164e96
Problem Signature 07: 113
Problem Signature 08: 36
Problem Signature 09: TEEK34PJDMM4HDZEPFRMOBGOA4O3JUV0
OS Version: 6.1.7600.2.0.0.256.4
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Have you seen crashes like this? I just have a Samsung connected, and the Zune software running.
Click to expand...
Click to collapse
I have the same error on my trophy with zune open and vs2010 with WP7 tools.
I've just tested it, the device must be unlocked for the app to work!
martani said:
I've just tested it, the device must be unlocked for the app to work!
Click to expand...
Click to collapse
Ok thanks for the information.
martani said:
I've just tested it, the device must be unlocked for the app to work!
Click to expand...
Click to collapse
Thanks for that information, I'll update the first post.
Hi l3v5y
thanks for this very usefull tool.
it's possible to have the source file to see what we can do with it!
xboxmod said:
Hi l3v5y
thanks for this very usefull tool.
it's possible to have the source file to see what we can do with it!
Click to expand...
Click to collapse
I already played with the source code for this app, which is almost the same as the Tom Xap Installer, Reflector if your friend
martani said:
I already played with the source code for this app, which is almost the same as the Tom Xap Installer, Reflector if your friend
Click to expand...
Click to collapse
They're both effectively rehashes of the WP7 toolkit (though the XAP installer is just a copy/paste into one function of the Installer, this actually does something different).
Reflector is indeed your friend, though I'll post code when I can anyway, as it's a little less annoying to use!
Have you done any more work on this project
As of yet, nothing that works...
Hi all,
has someone tried to get privileged access to wp7 via calls to conmanclient3? The RemoteAgent settings are all there (C:\ProgramData\Microsoft\Phone Tools\CoreCon\10.0).
Visual Studio 2010 does use the new CoreCon 10 files if it deploys to a real wp7 device. If it deploys to the emulator it does use the 5.1 files instead.
It looks like the settings for the 10.0 files differ from prevoius versions as the SmartDevice Tools of VS2008 (Plattformbuilder 6 based) won't work with the new files.
But in theory it should be possible to get access via a RemoteAgent (h__p://msdn.microsoft.com/en-us/library/microsoft.smartdevice.connectivity.remoteagent(v=VS.90).aspx), shouldn't it?
As cormanclient3, CMAccess and friends are all signed by microsoft and consist of native code it would be interesting to talk to someone who has already created a RemoteAgent based connection to a smartdevice. Is there someone out there?
Best regards,
-tobias
From the WP7 Developer Tools Application Deployment Tool, I'm pretty sure it's only using the CoreCon 10.0 files.
My RemoteExecute program here is using the Device classes (though I might have rewritten it a bit to get the Device.ConManServer), I'll now try the sample you linked too, and see if I can get it to work. File manipulation using the ConManServerseems to give lots of "Access Denied" errors, which I'm trying to work out why, and there's some stuff to be done with registry access as well, but this is the only way I've yet found of controlling the device from a desktop, without extra on device apps.
I check it with procmon, if you deploy to the emulator is loads the 5.01 files.
The MSDN Sample from above won't work as the service ids are from an older ce version. You need to use the ids from the file in corecon 10 addon folder.
do you get "access denied" or "not implemented" errors? Would be interesting if there is another set of files in the platform builder 7 which do implement additional functionality. I'd seen your remote execute program but I think the trick is to get a remoteagent running (looks like that's what visual studio does to get the debugger working).
regards,
- tobias
kuerbis2 said:
I check it with procmon, if you deploy to the emulator is loads the 5.01 files.
The MSDN Sample from above won't work as the service ids are from an older ce version. You need to use the ids from the file in corecon 10 addon folder.
do you get "access denied" or "not implemented" errors? Would be interesting if there is another set of files in the platform builder 7 which do implement additional functionality. I'd seen your remote execute program but I think the trick is to get a remoteagent running (looks like that's what visual studio does to get the debugger working).
regards,
- tobias
Click to expand...
Click to collapse
Ah, I'm just checking the Application Deployment tools, rather than the debugger, which would be a lot more useful... I think the emulator isn't really emulating, it's running using x86 code, and just acting like a WP7 environment (unlike the older emulators that emulated the entire hardware).
Will find the IDs for corecon 10 then, as that might make things work! (I've got device connections working, device name is "Windows Phone 7 Device".
I get Access Denied with most of them, though there is at least one function that's not implemented somewhere (I can't remember which one it is though!). The file manipulation APIs are quite different in the latest version of Microsoft.SmartDevice.Connectivity, with things like ProvisionDevice() not exisiting at all.
Will look at getting a RemoteAgent running, the functions are all there, and implemented, I just need the right IDs.
I can upload my code somewhere if you want (it's a little messy though!)
When we were back on NoDo there were quite a few homebrew apps that used native code to apply tweaks to WP7 devices. Most of those apps seized to work after the device is upgraded to Mango. There a several reasons for this behavior. I've done research on this, because I wanted to make WP7 Root Tools compatible with Mango. In this topic I'd like to explain how developers can fix their apps to work on Mango again. It has taken me quite some time to compile this guide, but I hope to give the Homebrew development on WP7.5 Mango a boost.
This guide is NOT about creating homebrew executables (exe-files) for WP7. This guide aims to utilize native code DLL's (C++ / ARM) from within your Silverlight app.
Note that with native code you get access to a lot of extra API's. But that does not mean you automatically get access to resources you normally won't have access to. For example, you can use the CopyFile() API. But if you try to copy a file to the \Windows folder, you will get errorcode 0x4ec (1260), which means "Blocked by policy". So you are still bound to the rules of the sandbox of your app. If you want Full Root Access for your app, you have to wait for a new version of WP7 Root Tools, which will allow you to give your app root-access. I'm also working on an SDK for that, which wraps all common task into a neat managed library. But don't hold your breath for that, because it's all taking a bit longer than I expected.
To understand everything in this guide you need basic knowledge of C++, COM-interop and Silverlight for Windows Phone. If you are new to all this, you might want to do some reading on these topics first. Currently there is no way to debug the native code. The only thing you can do is create test-functions which return formatted debug-info. This makes things pretty difficult. Read the guide carefully, because a little mistake can make your app crash easily!
Important note: If you have any long-running tasks, they may work fine while you are debugging. But you need to make sure that you start a new thread to run this code. Because, when you run without debugger the WatchDog will monitor your application and if the User Interface thread is blocked for more than 10 seconds the WatchDog will exit your app ungracefully!
It has been suggested that native homebrew DLL's need to be signed with approved code-signing keys. This is in fact not true! You can use native DLL's on Mango devices, which are not signed at all!
Basically there are two reasons why homebrew apps are not working anymore:
- Interop Lock
- DLL's were built against libraries, which are not supported anymore on Mango
Interop Lock is discussed in this thread. Interop Lock is a new protection mechanism in WP7.5 Mango. Basically it means you can't use apps with ID_CAP_INTEROPSERVICES, unless a device is Interop Unlocked. Without ID_CAP_INTEROPSERVICES an app can't call any drivers. And most homebrew apps call these drivers directly or indirectly. So if an app uses the Interop Capability, it can only run on devices that are Interop Unlocked. If you're going to build an app that uses this capability on Mango, you'll have to give your users instructions on how to apply Interop Unlock on their device.
Most of the native code libraries that were used on NoDo, were based on a hand full of projects. These projects were created and then extended for their own needs by other developers. The result was that most of these projects had the same project-types and library-references. In Mango, a lot of DLL's that were not used anymore by Microsoft, have been removed from the OS. Mostly in the ShellCore. The DLL's were meant for MFC-type functionality, which was never even supported on WP7. Actually, these DLL's are not even used by the homebrew apps either, but there are references to these DLL's in the homebrew libraries, which will cause the library to fail loading into memory. You can see this behavior when you try to run an app with non-Mango-compatible native code on an Interop Unlocked device from within the Visual Studio 2010 development environment. When the COM-class is instantiated it will throw an COMException: "COM object with CLSID '{...}' cannot be created due to the following error: The request is not supported." This is errorcode 0x80070032. This exception is actually caused due to the fact that the previous call to RegisterComDll() failed. If you get the returnvalue of that function you should have 0. In this case the return-value is probably 0x8007007E, which is "Module Not Found". This actually means that you directly or indirectly refer to a DLL, which cannot be found on the device. To fix this we need to create a clean project and add our new or existing native code to that project.
Here are the steps to setup your development environment and create a new, clean project for your native code. Please keep in mind that this guide is still work-in-progress. I may add more detailed instructions and examples later on, when people ask for it.
Update 2011/10/15: Some improvements in the guide, based on comments of rudelm and GoodDayToDie.
Install Visual Studio 2008 with latest service pack and hotfixes. Make sure you install C++. You need Visual Studio 2008, because the necessary SDK does not support Visual Studio 2010.
Install Windows Mobile 6 Professional SDK Refresh.
Install Visual Studio 2010 with latest service pack and hotfixes. You need this to create your Windows Phone Silverlight app.
Install Windows Phone SDK 7.1.
Download the attached Microsoft.Phone.InteropServices.zip. After you downloaded the zip-file, open the file-properties and make sure the file is "unblocked" (Windows will block downloaded files). Some unzippers, including the built-in unzipper from Windows will mark the unzipped files as "blocked", which would give problems later on if you don't unblock first.
If your developmachine is 32-bit you go to "C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71" or if you have a 64-bit machine you go to "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71". Extract the DLL from the zip-file in this folder.
Open the Visual Studio Commandprompt and change directory to the folder where you just extracted the DLL. Then enter this command:
Code:
SN -Vr Microsoft.Phone.InteropServices.dll
In the same folder there is a subfolder called "RedistList". Open that folder and open the file "FrameworkList.xml". Add this line to that file:
Code:
<File AssemblyName="Microsoft.Phone.InteropServices" Version="7.0.0.0" Culture="neutral" ProcessorArchitecture="MSIL" InGac="false" />
Thanks to Tom Hounsell for this tip!
Install the latest version of Zune.
Open Visual Studio 2008 and create a new project.
Choose Visual C++ / Smart Device / ATL Smart Device Project and fill in a name and location for your native library. Do NOT choose MFC, or your library won't work on WP7! The name will be the name for the DLL. Later on you will create a COM-class. Choose a different name for your library and for your COM-class!
In the new wizard click "Next".
Remove the "Pocket PC 2003" from the Selected SDK list and add "Windows Mobile 6 Pro SDK" to the selected SDK's. Click "Next".
In "Application Settings" keep everything default and click "Finish".
Set your configuration to "Release", because you won't be able to debug anyway.
Go to Project Properties / Configuration Properties / C/C++ / Preprocessor / Preprocessor Definitions and add this: _CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA
Right-click the project and click "Add" / "Class" and choose "Simple ATL object".
In the new dialog enter the "Short name" for your COM-class. All other names are filled in automatically. Keep those names default to avoid naming-conflicts. Also make sure the name of your COM-class is different from the name of the library. All other options can are default, so you can click "Finish" now.
The basic layout for your native project is now ready. Note that you have these files: for your library you have a header-file (.h), a code-file (.cpp) and a COM-definition-file (.idl) and for your COM-class you have a header-file (.h) and a code-file (.cpp). I will refer to these files in the following steps, so make sure you can identify these files.
The COM-class you have now is based on IDispatch. IDispatch is the COM-interface that supports reflection-like functionality. The COMBridge in WP7 does not support this interface. Instead we should use IUnknown, which is the base-interface for all COM-objects and supports reference-counting.
In the header file of your COM-class you can see the public inheritance of IDispatchImpl. This is no problem and you can leave it as it is. But you can also see this COM-mapping:
Code:
COM_INTERFACE_ENTRY(IDispatch)
You need to remove that line.
In the IDL file of your library you need to change the inheritance of the COM-class from IDispatch to IUnknown.
Your native code layout is now ready to add your methods. A method in COM-class should always have HRESULT as return-type. This value should be 0 or positive in case of success (normally use constant S_OK for success). If you have an errorcode which should throw a COMException do a logical OR with 0x80070000 and return that value. If you want to return a variable, you'll to declare that as parameter of your method and decorate it as returnvalue in the IDL-file. The parameter-types are bound by the definition of COM. You can read about the supported COM-datatypes here and here. Study those parameter-types closely, because any mismatch in your managed and unmanaged declarations will make your app crash definitely. You need to add all your methods in 3 different places: in the COM-class code, in the COM-class interface and in the IDL-file. Later on you need to add an exactly matching interface to your managed code. All the declarations have their own specific format and decoration. I will give an example of two different functions for these 3 files. Note that in these examples, the COM-class was named "Native", so the class implementation is called "CNative" and the interface is called "INative". You have to change that if your class has a different name.
In the COM-class implementation (.cpp-file) add this code:
Code:
STDMETHODIMP CNative::TestMethod1()
{
BOOL result = ::CopyFile(L"\\Windows\\0000_System.Windows.xaml", L"\\Windows\\Test.xaml", TRUE); // This will fail due to insufficient privileges. This is expected behavior to show how errors can be handled.
if (result)
return S_OK;
else
return 0x80070000 | ::GetLastError();
}
STDMETHODIMP CNative::TestMethod2(BSTR InputString, BSTR* OutputString)
{
size_t size = 1000; // in chars
TCHAR* msg = new TCHAR[size];
wcscpy_s(msg, size, L"\0");
LPWSTR value = new WCHAR[20];
_itow((int)wcslen(InputString), value, 10);
wcscat_s(msg, size, L"Length of string is: ");
wcscat_s(msg, size, value);
*OutputString = SysAllocString(msg);
delete[] msg;
delete[] value;
return S_OK;
}
In the interface of the COM-class (.h-file) add this code immediately after END_COM_MAP():
Code:
STDMETHOD(TestMethod1)();
STDMETHOD(TestMethod2)(BSTR InputString, BSTR* OutputString);
Locate your interface in the IDL-file of the library. This may look a bit weird, because there are a lot of attributes that decorate the empty interface. Add these declarations to your interface (note the decoration of the parameters, read more here):
Code:
HRESULT TestMethod1();
HRESULT TestMethod2(BSTR InputString, BSTR* OutputString);
Now we need to locate two GUID's and copy them in a text-file, because we need these GUID's later on. These GUID's are in the IDL-file. We will call the first GUID "interface-GUID". It is the "uuid" in the tag RIGHT ABOVE the interface-declaration. We will call the second GUID "coclass-GUID". It is the "uuid" in the tag RIGHT ABOVE the coclass-declaration. There also a "uuid" in the tag above the library-declaration, but we don't need that one.
Open Visual Studio 2010 and create a new project: Visual C# / Silverlight for Windows Phone and choose a project-type, name and location.
Now go back to your native project in Visual Studio 2008. The compiled result DLL of this project will be used in your Windows Phone app. To make sure you always use the latest version of the native DLL in your Windows Phone app, you can add a Post Build Event to this project. This example assumes you will have a folder with a subfolder for the native solution and a subfolder for the Windows Phone solution. Go to Project Properties / Configuration Properties / Build Events / Post-build Events and add this (change the paths according to the soluton-foilder you will create for your Windows Phone app):
Code:
copy "$(TargetPath)" "$(SolutionDir)..\MyApp
If you checked the option "Create folder for solution" when you created the Windows Phone project, you may want to add another subfolder "\MyApp" to the path.
Now build your native project! The compiled DLL should now also be copied to the folder of your Windows Phone app.
Create a new file called "WPInteropManifest.xml" in the folder of your managed Windows Phone app. Copy this content in the file:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<Interop>
</Interop>
Switch back to Visual Studio 2010. In the solution explorer click on "Show all files". Your native DLL and the "WPInteropManifest.xml" should be shown now.
Select the "WPInteropManifest.xml" file and in the file-properties set "Build action" to "Content" and set "Copy" to "Always". You will always need this file in your project, regardless you will be calling drivers or not. If you don't have this file in your project, you won't be able to use your native DLL.
Select your native DLL and in the file-properties set "Build action" to "Content" and set "Copy" to "Always".
In the solution explorer, right-click on the project and choose "Add Reference". Then select "Microsoft.Phone.InteropServices".
Open the "WMAppManifest.xml" file and add this line below the other capabilities:
Code:
<Capability Name="ID_CAP_INTEROPSERVICES" />
Later on, you can try if your app will work without this capability. If you only use native code without calling drivers (directly or indirectly), you don't need the capability and your app will also work on devices that are not Interop Unlocked then. This specific example does not call any drivers, so in this example the ID_CAP_INTEROPSERVICES can be omitted and then it would run on non-Interop-Unlocked devices.
Now add a code-file to your project and copy this code into the file. You need the the coclass-GUID and interface-GUID you copied into a text-file earlier and you also need to replace the name of the class and interface to the names you used. Also note that the declaration must be an exact match (order and parameters) with the declaration in the IDL-file, although the IDL-file is differently formatted.
Code:
using System.Runtime.InteropServices;
[ComImport, ClassInterface(ClassInterfaceType.None), Guid("YOUR-COCLASS-GUID-GOES-HERE")]
public class CNative
{
}
[ComImport, Guid("YOUR-INTERFACE-GUID-GOES-HERE"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface INative
{
void TestMethod1();
[return : MarshalAs(UnmanagedType.BStr)]
string TestMethod2([MarshalAs(UnmanagedType.BStr)] string InputString);
}
Note that the interface is declared as IUnknown.
Now you need to call the native code. You can add this code to the constructor of your Page or to the eventhandler of a button, or anywhere you like. Be sure to replace the DLL-name, interface-name and class-name and use your coclass-GUID. The exception is a well-known error-code and the exception will be casted to a UnauthorizedAccessException, instead of a COMException.
Code:
uint retval = Microsoft.Phone.InteropServices.ComBridge.RegisterComDll("WP7Native.dll", new Guid("YOUR-COCLASS-GUID-GOES-HERE"));
INative MyNativeCodeInstance = (INative)new CNative();
string result1 = "OK";
try
{
MyNativeCodeInstance.TestMethod1(); // UnauthorizedAccessException is thrown due to insufficient privileges. This is expected behavior to show how errors can be handled.
}
catch (Exception ex)
{
result1 = ex.Message;
}
string result2 = MyNativeCodeInstance.TestMethod2("Hello, Mango!");
MessageBox.Show(result1 + Environment.NewLine + result2);
You can now run your project! Be sure that you deploy it to your device. The emulator won't work, because you project uses native ARM code. The emulator runs on x86, so your native DLL won't load in the emulator.
When you go more advanced, you may need the Marshal-class. For example to copy a native memory-block to a managed byte-array. Be aware that there are actually two "Marshal" classes. There is "Microsoft.Phone.InteropServices.Marshal" and "System.Runtime.InteropServices.Marshal". They both look the same. But be sure you are using "Microsoft.Phone.InteropServices.Marshal", because it will allow you to do a lot more! Most methods in "System.Runtime.InteropServices.Marshal" will throw a MethodAccessException, because they are tagged [SecurityCritical], while the same methods in the other Marshal class will work.
I hope this will help you port your homebrew apps to Mango or create some fresh new homebrew! If you created an app with native code, drop me a line here. Show me your Screen Recorders, Accent Changers and more!
Ciao,
Heathcliff74
looking fwd to the native apps , a universal screenshot apps would be awesome..
Update :
scratch that, just ready that the app will be bound to the rules of the sandbox of your app.I guess that means no universal screenshot app yet
Its time to get native! Thanks Heathcliff.. I think I have a very good idea on something I could use native code for.. Ill pm you =)
Sent from my SGH-i917 using XDA Windows Phone 7 App
Suddenly, awesomesauce! Wow, big thanks Heathcliff74! Eve since you said you'd figured out homebrew native DLLs on Mango, I was really excited to see what people could do. I never guessed the real reason homebrew DLLs didn't work on Mango, although in retrospect this makes sense. You're awesome for investigating this for us.
Thoughts that immediately come to mind:
Update the existing screen capture apps.
Update the existing WebServer app.
(As part of the above) update the sockets DLL so we have server sockets again.
Explore how much filesystem access we have. Can files be copied from one app's isostore to another app's isostore?
Explore accessing drivers. The HTC update breaks filesystem access for HTC homebrew, but maybe there's another driver entry point we can use.
Investigate direct access to the SMS store (message backup?)
... and so much more. Oh, this is going to be fun!
the0ne said:
looking fwd to the native apps , a universal screenshot apps would be awesome..
Update :
scratch that, just ready that the app will be bound to the rules of the sandbox of your app.I guess that means no universal screenshot app yet
Click to expand...
Click to collapse
Hi!
Screenshots apps are definitely possible! The API for this can be called from within the sandbox and using OEM drivers it is possible to switch off dehydration. I already discussed this with fiinix and gave him this info. And I believe he almost has a Mango version ready.
Thanks for writing the article
Ciao,
Heathcliff74
great to hear about the progress
thanks Heathcliff74 for sharing!
Wooohooo nice HowTo! I will definitively try it and will report later. However, that will require that I go back to NoDo and back to Mango first. I'm not looking forward to that procedure... anyways awesome work Heathcliff, thank you!
@GoodDayToDie: you mentioned that the HTC libraries are fixed regarding file access. Julien Schapman from TouchXplorer mentioned something like that a while ago on twitter. Do you have any additional information on that topic? Is it just the DLL files from the HTC apps or is it something with the Mango HTC Update? I'll hope this is reversible, if I go back to NoDo and want to try Heathcliffs instructions :/
@rudelm, I only have experimental knowledge; I haven't dug into the actual update. However, the way that things like ComFileRW.dll work is by calling into some high-permission module in the HTC firmware (probably a driver using an IOCTL, though it could possibly be an RPC call to a privileged process) which then executes the requested action with high permissions. That's why the HTC DLLs don't do anything on other phones; they can't talk to the component that actually does the work.
My guess is that the HTC update simply turned off whatever it was that the COM DLLs are calling into. It could be more complex than that - for example, they could be trying to validate the caller, and prevent it from being used by homebrew - but whatever they did, neither DLL works anymore once you have the HTC update *even though the DLLs themselves did not change.*
Is it reversible? Well, "fixing" whatever component they were calling into is one option. Using Heathcliff74's Root Tools to gain full permissions on a "normal" homebrew app is another. There might be more, but it would need more study.
Thanks. Will try it. Hopefully i can get "GetPhoneNumber" from Windows Mobile 6 SDK to run or maybe trying http://blogs.msdn.com/windowsmobile/archive/2004/11/28/271110.aspx
GoodDayToDie said:
@rudelm, I only have experimental knowledge; I haven't dug into the actual update. However, the way that things like ComFileRW.dll work is by calling into some high-permission module in the HTC firmware (probably a driver using an IOCTL, though it could possibly be an RPC call to a privileged process) which then executes the requested action with high permissions. That's why the HTC DLLs don't do anything on other phones; they can't talk to the component that actually does the work.
My guess is that the HTC update simply turned off whatever it was that the COM DLLs are calling into. It could be more complex than that - for example, they could be trying to validate the caller, and prevent it from being used by homebrew - but whatever they did, neither DLL works anymore once you have the HTC update *even though the DLLs themselves did not change.*
Is it reversible? Well, "fixing" whatever component they were calling into is one option. Using Heathcliff74's Root Tools to gain full permissions on a "normal" homebrew app is another. There might be more, but it would need more study.
Click to expand...
Click to collapse
uhoh... sounds pretty bad for HTC users. If it was a firmware update, we will have a bigger problem. I will try to revert back to Nodo and will try Heathcliffs instructions for Native Code first. InteropUnlock is still something I need to try for Mango
rudelm said:
uhoh... sounds pretty bad for HTC users. If it was a firmware update, we will have a bigger problem. I will try to revert back to Nodo and will try Heathcliffs instructions for Native Code first. InteropUnlock is still something I need to try for Mango
Click to expand...
Click to collapse
No worries. I did some testing with contable and we just got confirmation that my exploits for HTC will still work on HTC Interop Unlocked Mango devices (needs a little adjustment, but No Problem!) Still working on a version of WP7 Root Tools for Samsung/HTC/LG RTM/NoDo/Mango!!
Ciao,
Heathcliff74
A screenshot app is allready there:
TouchXperience for Mango from Schaps.
Atm there is only missing the WPDM Mango update for being able to save the screenshot...
Heathcliff, could you please try to fix that HTC bug first? I am running into this problem with the HTC update and now my old code does not work anymore But at least my phone is finally interop unlocked because I could deploy the app on Mango but I get this error:
COM object with CLSID '{C6BD09B4-96AA-4524-89C4-665A15DD7C9B}' cannot be created due to the following error: The request is not supported. .
Which is one of the errors you mentioned on the first page. So far, so good
rudelm said:
Heathcliff, could you please try to fix that HTC bug first? I am running into this problem with the HTC update and now my old code does not work anymore But at least my phone is finally interop unlocked because I could deploy the app on Mango but I get this error:
COM object with CLSID '{C6BD09B4-96AA-4524-89C4-665A15DD7C9B}' cannot be created due to the following error: The request is not supported. .
Which is one of the errors you mentioned on the first page. So far, so good
Click to expand...
Click to collapse
I don't get what you mean. What HTC bug? What HTC update?
Ok, I will explain it:
There was a HTC Update when I upgraded from Mango B2 Refresh to the Mango RTM from Microsoft. It was followed by a smaller HTC Update. It was called HTC Update for Windows Phone. You can read it here in my blog.
Yesterday, I decided to revert back to NoDo, so that I could Interop Unlock my HD7 before I upgrade to Mango RTM. I did this with these tools and instructions from petbede.
However, ansar found out, that MS changed the update procedure and included the HTC update directly in the 7720.68 update.
Now you mentioned yesterday, that you and contable found a solution to use the HTC DLLs although there was this HTC update on our phones. That was when I already feared that the HTC update will break everything I tried so far.
So I called it the HTC bug, because it breaks my stuff
rudelm said:
Ok, I will explain it:
There was a HTC Update when I upgraded from Mango B2 Refresh to the Mango RTM from Microsoft. It was followed by a smaller HTC Update. It was called HTC Update for Windows Phone. You can read it here in my blog.
Yesterday, I decided to revert back to NoDo, so that I could Interop Unlock my HD7 before I upgrade to Mango RTM. I did this with these tools and instructions from petbede.
However, ansar found out, that MS changed the update procedure and included the HTC update directly in the 7720.68 update.
Now you mentioned yesterday, that you and contable found a solution to use the HTC DLLs although there was this HTC update on our phones. That was when I already feared that the HTC update will break everything I tried so far.
So I called it the HTC bug, because it breaks my stuff
Click to expand...
Click to collapse
I see. Well, I didn't find a solution. I just checked if MY exploit still works. And it does! I don't even know what you use exactly (I assume you use some HTC DLL's, but I don't know which and I don't know which functions). I don't use the HTC DLL's myself. Mainly because I don't want to get copyright issues when releasing WP7 Root Tools. Just look at the current release of WP7 Root Tools. No OEM code in there. So I don't think I can fix that for you.
Ciao,
Heathcliff74
Hm ok, I understand. I was using a HTC dll for changing a registry value (overriding DHCP DNS Server). However, it is interesting to know why the HTC DLLs all of sudden stopped working after this update. The DLLs inside the HTC tools seem to be the same size and should not be changed by the update.
But this shouldn't then influence the DLL made with your instructions in this thread i guess?
@rudelm:
The HTC devices have HSPL support, so why you don´t flash the latest xboxmod rom ? This saves a lot of time and all available types of unlocking can be sent via cab sender.
For writing registry keys or doing file operations you can use DiagProvXML til Heathcliff has finished the next version of WP7 Root Tools.
Is there any other reason why you are updating your phone the official way ?
@rudelm: The HTC DLLs don't actually have elevated permissions by themselves. To do things that an app n ormally lacks permissions for (like accessing the whole filesystem or writing to the registry), it needs to call into a high-permission component (probably a driver or a high-permission process). All HTC had to do to make the registry and filesystem COM DLLs stop working is to change that component so it didn't do what the COM DLLs told it to do.
@contable: I've heard enough reports of things that *should* work on HTC phones not working on the custom ROMs that I'm hesitant to install one. Then there's the risk of bootloader issues. Then there's the lose-all-your-data-because-your-phone-gets-reformatted issue - until I have my backup app working fully, I prefer to avoid the last one in particular.
Edit: If you are looking for working attachments, please look at this posting.
@contable:
I need an unmodified version of WP7 for my master thesis. The other thing is that I don't want to play around with HSPL without having the original SPL or firmware. It's like GoodDayToDie said: I'm still hesitating of the said reasons.
@GoodDayToDie:
The HTC applications still work and they were not updated afaik. So they are using the same DLL files. If there would be some driver running in TCB or ECB and they changed something, then their applications should stop working too. However, they can still be executed without problems. I am not sure what DLLs are used by advancedexplorer, but I think it were also the HTC dlls. My own application which used the HTC dlls stopped also.
@Heathcliff:
I've tried your instructions and found some errors in it:
step 23: *OutpuString = SysAllocString(msg); instead of *OutputString = SysAllocString(msg);
step 25: ; missing after OutputString)
step 28: add \MyApp to path, because VS2010 Solutions always have a subfolder with the same name of the solution
step 36: [return : MarshalAs(UnmanagedType.BSTR)] should be [return : MarshalAs(UnmanagedType.BStr)]
step 37: result 2 needs a type => string result 2 = ...
on first run:
Error 1 Could not load the assembly file:///C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71\Microsoft.Phone.InteropServices.dll. This assembly may have been downloaded from the Web. If an assembly has been downloaded from the Web, it is flagged by Windows as being a Web file, even if it resides on the local computer. This may prevent it from being used in your project. You can change this designation by changing the file properties. Only unblock assemblies that you trust. See http://go.microsoft.com/fwlink/?LinkId=179545 for more information. NativeTestApp
Click to expand...
Click to collapse
This is because you forgot to register the DLL first. Look here: http://thounsell.co.uk/2010/11/avoi...g-the-interopservices-library-to-the-wp7-sdk/ and then down in the comments:
You must open the visual studio 2010 command prompt as administrator and call:
SN -Vr Microsoft.Phone.InteropServices.dll
then close and reopen Visual Studio, now it should work
Click to expand...
Click to collapse
In addition that, you will have to unblock the file in Windows Explorer, Properties of the file. Otherwise you will get this error in Xaml view:
Could not load file or assembly 'Microsoft.Phone.InteropServices, Version=7.0.0.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
Click to expand...
Click to collapse
This unblock will only work, if you use the Windows Explorer in administrator mode. The DLL file should be copied to a path were every user can access the file. Unblock it there and move it than back to the WindowsPhone71 folder. I've extracted it directly to the WindowsPhone71 folder and I couldn't change its properties there.
I've created a VS2008 and VS2010 sample project on your instructions and tried to add some comments to the sources. I've attached them to this post. Here are a few extra information to my project:
Interface-GUID: D28D8CB9-F8BC-4379-9D0A-FA77C87EF814
coclass-GUID: 7300CD4A-03F4-4569-B2D8-F1515385D46D
COM Class: NativeTestClass
INativeTestClass and CNativeTestClass
Always results in retval 0 and this exception:
System.MethodAccessException was unhandled
Message=Attempt to access the method failed: System.IO.FileInfo..ctor(System.String)
StackTrace:
at Microsoft.Phone.InteropServices.ComBridge.RegisterComDll(String dllFileName, Guid clsid)
at NativeTestApp.MainPage.actionButton_Click(Object sender, RoutedEventArgs e)
at System.Windows.Controls.Primitives.ButtonBase.OnClick()
at System.Windows.Controls.Button.OnClick()
at System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs e)
at System.Windows.Controls.Control.OnMouseLeftButtonUp(Control ctrl, EventArgs e)
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, Int32 actualArgsTypeIndex, String eventName)
Click to expand...
Click to collapse
I've rechecked every step but I am still stuck. The phone itself should be interop unlocked, otherwise I couldn't have deployed the app with the capability activated. Could you please look into it? I know this error from my earlier attempts to access the HTC dll directly, but then I used the NativeLibrary here from XDA which took care of all the GUID things etc.
My plan is to build an app which could transfer a printable file to a remote unix based system, send some bash commands and read the results.
I haven't found any confirmation about working ssh libs. Are there any?
My phone is unlocked so accessing the file system and unnative libs aren't a problem but it would nice if that isn't compulsory.
Thanks in advance!
opaounari said:
I haven't found any confirmation about working ssh libs. Are there any?
Click to expand...
Click to collapse
Have you ever tried to google "Silverlight SSH"? The very first link should bring you a reference to http://sshnet.codeplex.com/ (already ported to WP7/SL)
Also you may try to look/port these free libs:
http://granados.sourceforge.net/
http://sourceforge.net/projects/sharpssh/
Whopsie! I only tried to google "c# ssh" or with windows phone. Only found out about sharpssh, granados and else but their functionality wasn't guaranteed... Thanks alot I try'll that out and sorry!
opaounari said:
Thanks alot I try'll that out and sorry!
Click to expand...
Click to collapse
Here (on XDA) we do have a "Thanks" button, located under helpful post. Don't hesitate to use it
Of course! Thanks for pointing that out.
I tried to use the lib u mentioned
By these steps:
1: Download & unzip
2: In visual studio I have my windows phone project open
3: Solution Manager -> Right click on my project -> Add reference -> Projects tab -> Renci.SshNet -> OK
Then it just displays error:
Microsoft Visual Studio 2010 Express for Windows Phone
Unable to add the selected project reference. The project reference must be another silverlight for Windows Phone project that is the same or lower version.
-> No clues :S even after googling this alot.
You should use Renci.SshNet.WindowsPhone.dll (http://sshnet.codeplex.com/releases/view/83611#DownloadId=352294)
Or download source code tree and add WP7 project as reference (http://sshnet.codeplex.com/SourceControl/list/changesets# )
Looks like there is a nuget package too:
http://nuget.org/packages/SSH.NET