Related
Hello everybody,
I got a WP7 Samsung Focus and I want to port my old application to this device and join native forces for WP7
My plan is simple: I'll convert my app into a dll, rewrite new gui in C# (or whatever the way to do it on WP7). I saw multiple posts about calling native code (original from Cris Walsh: http://goo.gl/2Tjks). Then I saw a few posts mentioning that it's impossible etc etc.
So, a few questions:
0) can I do it for my app (I don't need marketplace exams etc, I don't care for that)? I know that some WinAPI could be unavailable/broken, all I ask at this point if it's possible to load and run native dll without changing or re-flashing ROM.
1) ms wants 100$ out of my pocket to be able to deploy to my own device (WTF?!). What can I do to deploy to my phone without paying the crooks? (VS2010 tell me to register there and registration askes for 100$).
2) Is there a sample project I could D/L and run, I have zero experience in C# and I have no idea how to load and call native DLL from managed code in WP7? All these half broken samples are totally useless to me, I simply wanted to working HelloWorld app that loads and runs simple dll.
thanks
0) Yes, what you describe is possible. There are lots of limits, though - WP7 applications have very low permissions, and calling native code doesn't fix that. Unless you need to edit something outside the app's own iolated storage, though, you're probably OK.
1) Aside from the official marketplace account ($100), there are a few options:
a) if you've got an LG phone, they come with a built-in registry editor that can be used to dev-unlock your phone. I forget the exact key you need, though.
b) if you've got a student email address (ends in .edu) you can try registering through DreamSpark. This is free.
c) if you don't mind rolling back to pre-NoDo (7004 or 7008) you can use ChevronWP7 Unlock (instructions available on this forum). If you don't have a restore point that far back you can flash an official ROM for that version.
d) if you don't mind waiting, ChevronWP7 Labs will be available at some point (no ETA that I've seen, but it's been talked about for months) and will provide dev-unlock (but not marketplace account) for a nominal fee.
2) There are lots of apps distributed with source, and most of them will use some native code. You could do a search on this forum for subject lines including the tag "[SOURCE]" and find several (I release source for all my apps). However, I suspect what you'd find most useful is Heathcliff74's guide to WP7 apps that use native code, which is on this forum at http://forum.xda-developers.com/showthread.php?t=1299134. It includes step-by-step instructions.
Hope that helps! I look forward to seeing your app. Also, don't hesitate to ask for help with the actual development; I suck at GUIs and Silverlight but am fairly proficient at C# if you need somebody who knows that language, for example.
There is an ETA for the new ChevronWP7 unlocker:only a few weeks away from launch!
Hi GoodDayToDie
GoodDayToDie said:
0) Yes, what you describe is possible. There are lots of limits, though - WP7 applications have very low permissions, and calling native code doesn't fix that. Unless you need to edit something outside the app's own iolated storage, though, you're probably OK.
Click to expand...
Click to collapse
At this point I want to make a DLL from my simple app and call a few functions that interact with filesystem and network. FS is needed only for simple stuff (loading config file etc) from installation folder and creating some temporary files for local storage. Network is tcp/udp, I guess network should be available.
GoodDayToDie said:
1) Aside from the official marketplace account ($100), there are a few options:
...
Click to expand...
Click to collapse
I did some search, it seem that I've done that part. Chevron dev unlock was pulled out from their site, but the old version remains scattered all over the board. There is a good thread a good thread on how to do it. It happens that my phone is 7004. Where can I get old ROM in case if something goes bad and I need to re-flash? Is it easy, am I risking to brick and loose my phone?
I just tried to run sample phone app and it runs on the phone. Initially it said that it was revoked by MS, I run dev-unlock one more time and now it works.
GoodDayToDie said:
2) There are lots of apps distributed with source, and most of them will use some native code. You could do a search on this forum for subject lines including the tag "[SOURCE]" and find several (I release source for all my apps). However, I suspect what you'd find most useful is Heathcliff74's guide to WP7 apps that use native code, which is on this forum at http://forum.xda-developers.com/showthread.php?t=1299134. It includes step-by-step instructions.
Click to expand...
Click to collapse
I'll try to search, hope I'll be up and running soon. Too bad WP7 is DOA. They always had much better tools than all these ghetto Symbian/Android/Xcode crapware tools... WTF is wrong with these guys, at the point when they were surpassed at speed of light by newbies iPhone and Android they made some backward steps to cut off most of the devs (but they added all these 500K Silverlight newbie devs...). I'm so disappointed with Android, seems like they hired all these retards who were fired at symbian: same **** tools
I downloaded a few samples and it seems that all of them contain prebuild dll's and all of them are COM dlls or something like that.
What I'd like to find is simple sample that contains src code to native WinMo dll and C# project that it uses.
As far as I know native dll cannot be build with latest tools (am I right?), but I can use cegcc or VS2008 to build native DLL's.
stuff like:
Code:
if (ComBridge.RegisterComDll("ComFileRw.dll", new Guid("EEA7F43B-A32D-4767-9AE7-9E53DA197455")) != 0)
is totally unknown to me. I would really like to avoid to even elarning anything about COM related stuff. I prefer not to mess up with code that isn't portable.
HI mtlgui,
unless Heathcliff finishes his WP7 Root Tools SDK, you don't have any other way to access native c++ code besides using COM. DFT (The DarkForcesTeam) released a firmware loader, that allows you to flash customized unsigned firmware. They were also able to do some native c++ coding with the WM API. However the used firmware for that is not public and it is limited to HTC devices.
Did you already consider to write your application in c#? Mango has now TCP/UDP socket support for outgoing connections. Incoming connections or services running on the phone aren't possible without using native code, at least for the moment.
Hi rudelm,
if the only way to use native is to build COM dll, then I'm OK with that. My app code is old and I'd rather throw my WP7 device to trash can than trying to rewrite my app in C#.
Eventually, down the road while hacking maybe I'll learn c# well enough to do anything with it other than GUI and calling native/COM dlls.
So, just to confirm my understanding. I need to write COM dlls that access native API (socket, filesystem, wavein/waveout etc) and then load these COM dlls and call their functions from C# (or whatever is the closest lang to c/c++ in the WP7 world).
@mtlgui:
You've pretty much got it. A few thoughts, though:
There is a webserver project available on this site. It includes source for its C++ native component (the library is called NativeIO; I can probably send you the source if you can't find it). It exposes registry, filesystem, and TCP server and client sockets to COM. Note that because this library was built for pre-Mango phones, just compiling it and shipping it may not work on Mango phones as many deprecated libraries were removed in Mango and if the DLL contains any references to them, it won't load.
Generally speaking, what you're asking for with TCP/UDP is possible, though you may have to code against the winsock API directly. It sounds like you're doing as little as possible with C#, so even if the Socket API that is available with Mango were sufficient for your app's needs, you wouldn't be using it.
Filesystem access... even if you have read access to your app's install folder (I haven't checked, though you should), you almost certainly won't have write access. Each app does have a writable "isolated storage" though, under \Applications\Data\{GUID}\Data\IsolatedStore\. I've only ever tried writing to it using C# though, so I don't know for sure if it's writable using the native APIs directly (should be, though).
It's probably perfectly OK to write your app as one big native DLL (hell, it *might* work to just change the build type from Application to Library, then rename main() or something like that). You will need to expose the library to COM, but that's easy. You can then write a very simple C#/Silverlight app (see Heathcliff's instructions, or just post the COM interface and soembody could write it for you). All the C# app needs to do is use ComBridge to access the native DLL, and call a "run()" function or something similarly simple.
For what it's worth, C# is very close to a superset of C++, at least on the desktop. The phone version is crippled a little by not allowing the use of pointers - everything has to be done with strongly-typed references instead, which can make network code a little annoying but is otherwise rarely a problem - but with a little experimentation you may find your disdain for C# to be misguided. It's a useful language to know it today's job market, if nothing else.
Why is your phone still on 7004? That's the launch retail build, something like eight months out of date. On the plus side, this means that things like ChevronWP7 Unlocker still work for you, as you found. On the minu side, it means you're putting up with bugs and missing features that you needn't be. Have you tried updating at all? If/when you do update, make sure to back up the restore points that the Zune software generates (they got in %localappdata%\Microsoft\Windows Phone Update\). That way, if you ever need to roll back to 7004, you can do it. Normally, only the most recent restore point is kept.
Flashing ROMs is safe so long as you don't try something like flashing the wrong one for your device. Unless your bootloader is unlocked (only possible on HTC), you can only flash official ROMs anyhow, which saves you from most of the risks. On the other hand, you're already on as old a ROM as you will find, and so long as you keep your restore points, you can return to it any time you want to, easily.
I'm googling now the board to find NativeIO and that webserver app. So far only references to it, but no src code.
I'm ok with isolated read/write access. All I care is persistent fs storage.
My phone is still 7004 because I just bought it so I can do some WP7 development. I don't want to mess up with updates at the moment.
As I understand from another post ComBridge is C#->COM->native c++ dll or any other dll that can be used, right? I'm just learning some COM to learn enough to start actually programming for the phone. I see that I can pass whatever data I want, but I don't seem to be able to see a way to register callbacks so that native/COM could call back to C#
mtlgui said:
I'm googling now the board to find NativeIO and that webserver app. So far only references to it, but no src code.
I'm ok with isolated read/write access. All I care is persistent fs storage.
My phone is still 7004 because I just bought it so I can do some WP7 development. I don't want to mess up with updates at the moment.
As I understand from another post ComBridge is C#->COM->native c++ dll or any other dll that can be used, right? I'm just learning some COM to learn enough to start actually programming for the phone. I see that I can pass whatever data I want, but I don't seem to be able to see a way to register callbacks so that native/COM could call back to C#
Click to expand...
Click to collapse
Basic introduction to native code and COM, including references to more background info: http://forum.xda-developers.com/showthread.php?t=1299134.
Callback from C++ -> COM -> C# can be done. Decompile the WP7 Acrobat Reader app. You'll see how it works.
Ciao,
Heathcliff74
Webserver (for Mango)
Webserver is now supported for Mango devices!
During NoDo this tool was used much for exploring the "\Windows" directory, but when Mango came none could explore it.
There is probably many new things to find in the new OEM Mangos (that could not be extracted till now (Exception's: ROM dumps))
Source code is available in attachment and should build without any problems (except for the dll reference)
- Follow stem 6 for Microsoft.Phone.InteropServices.dll errors
Install XAP => Navigate to the phone's IP shown in application => Browse and enjoy.
- Change password on first launch (its randomized)
Many thanks to davux for creating the base for this tool.
- Orginal NoDo thread Here
Changelog:
v0.1 - Initial Mango version release
v0.2 (iconizer)
- Thanks MarysFetus aka Suicide Clown for the great icon set and start screen, love em
- Many thanks to GoodDayToDie for informing me that this app can / and will run from now without the <"ID_CAP_INTEROPSERVICES">
- Removed old OEM dll's that where not used (xap size: 812 KB => 250 KB)
//fiinix
Nice works my friends... I Like It
Thankx
@fiinix:
Thx for porting the webserver to Mango !
As I remember the initial version from Davux had an on device execute feature.
Do you plan to implement execute feature ?
Could be very useful for exploring all .exe files in the windows folder.
Greetz
contable
Freaking awesome, man!
One suggestion: I don't believe this app does anything that requires ID_CAP_INTEROPSERVICES (that is, it doesn't need to open any driver handles). I may be mistaken about that, of course. If it doesn't, however, there's a real benefit to removing that capability as people with interop-locked phones could then run it. Note that the library used may try to do things requiring interop even though the app doesn't need it to.
In addition to its uses as a hacker's tool, I also want to point out that this app can be used to store files on the phone for easy transfer between computers. It's less convenient than true USB Mass Storage, but it works (even if you don't have the USB cable with you) so long as there's a WiFi access point that the phone and PC can both connect to.
Oh, and by the way, this app will run happily in the background if you use JaxBot's no-dehydrate hack. You can do other things then, even browsing the webserver from the phone's own browser! Of course, it will also use some resources.
Now slimmer, and no ID_CAP_INTEROPSERVICES
OK, this is just a modification of the XAP file - I didn't even recompile the source (thank you so much for including it, though!)
Things I did:
Removed ID_CAP_INTEROPSERVICES from the AppManifest. This will allow the app to be installed on interop-locked phones. It wasn't using it anyhow.
Removed the OEM-specific DLLs that are only useful if you have ID_CAP_INTEROPSERVICES. They weren't being used, but they made the download and install bigger.
Result: A smaller app that works exactly the same and can be installed on any Dev-unlocked Mango phone.
Really neat. Mind if I design some sort of decent icon for this app?
Regards, Suicide Clown
//Update:
finished the Icon:
Hope you like it.
MarysFetus said:
Really neat. Mind if I design some sort of decent icon for this app?
Regards, Suicide Clown
Click to expand...
Click to collapse
Sure, go ahead.
Its the freedom of XDA, do what you want
I added the new NativeIO_Mango.dll to my battery status app instead of the old filesystem.dll. I hope that's okay. Thanks so much for your great libraries.
singularity0821 said:
I added the new NativeIO_Mango.dll to my battery status app instead of the old filesystem.dll. I hope that's okay. Thanks so much for your great libraries.
Click to expand...
Click to collapse
The "NativeIO_Mango.dll" is actually a communicator for "Homebrew.csproj" containing COM+ "IWinSock" and "IFileSystem"
- Homebrew.csproj exists in this projects code.
The battery interop will not talk to NativeIO_Mango.dll (the "Webserver" will tho)
Phone.Battery.GetBatteryAdvanced()
-- goto here
---- DllImportCaller.lib.GetSystemPowerStatusExAdv7(ref str, true);
Homebrew.IO.Directory.GetFiles ( [path] )
-- cctor (static constructor) => Register("NativeIO_Mango.dll", "B0E4E41C-BE1D-4BA2-B8CE-7D632EA1CA37");
---- FileSystem.FindFirstFile ( ... ) & while FileSystem.FindNextFile( ... )
:here
Code:
[COLOR="DeepSkyBlue"]Registrer[/COLOR].Register(BasePath +
[COLOR="RoyalBlue"]#if[/COLOR] RUNNS_UNDER_MANGO
[COLOR="DarkRed"]"DllImportMango.dll"[/COLOR], [COLOR="DarkRed"]"434B816A-3ADA-4386-8421-33B0E669F3F1"[/COLOR]
[COLOR="RoyalBlue"]#else[/COLOR]
[COLOR="Silver"]"FileSystem.dll", "F0D5AFD8-DA24-4e85-9335-BEBCADE5B92A"[/COLOR]
[COLOR="RoyalBlue"]#endif[/COLOR]
);
Filesystem.dll is not used anymore in Mango version (its a NoDo dll)
"Thanks so much for your great libraries."
- Thank you so much
I could swear it didn't work without the filesystem.dll one time I tried haha. I guess that was something else
Thanks~
perfect! Now we'll look for regedit editing & file transfering. Any ideas?
Fiinix this is just amazing work! Because of you, I've need to rewrite a chapter of my thesis
Let me ask some questions regarding the supplied source code:
There are four folders inside the rar archive:
The Lib folder contains all OEM DLLs from Samsung, HTC and LG.
The Homebrew folder contains all old code from davux that is necessary to open up the sockets, files and registry entries (if needed?)
NativeIO_Mango contains your altered native DLL that can be used under Mango
The Webserver folder contains the actual WP7 application, that glues everything together into one nice app.
From the underlying workings:
Davux tried to build an API that resembles C# Sockets from the desktop. This way the C# Webserver project of jgauffin can be reused in the WP7 application. You removed from Davux's NativeIO project the references to all parts that require the native OEM DLLs (which is why GoodDayToDie stripped the unneeded DLL files and removed ID_CAP_INTEROPSERVICE to allow users without interop-unlock to use the app).
If this is so far correct, I'm wondering how some things in this application could work:
Ok, so you've removed the code that allows access to the filesystem and registry which uses the native OEM DLLs. How is it possible, that this application can access folders outside its Isolated Storage??? The application should not be allowed to access the windows folder nor any other folders? I know only of one folder, that should be read/writeable. Its a folder that heathcliff found in the policies, I think it was some kind of log folder. Or is readable access with WM6 native API to all files possible?
In WMAppManifest.xml stands ID_CAP_NETWORKING. This is necessary for navigating between different XAML pages but also necessary if we want to do something with the native network access. Can this capability removed or will the application break?
To sum up, if these assumptions are all correct, the policy system is partly useless from the moment on, where someone is capable to call native code, that does not require ID_CAP_INTEROP. This would theoretically allow a submission to the Marketplace?
Right now, I'm heavily confused and irritated, please explain me my error in thinking
PS: I tried to build the NativeIO_Mango project. I changed to release target and build. However, it exits with error message regarding the missing _CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA setting. I've added it, but then I get 19 more errors. Each time it is unresolved external symbol.
Hi Rudelm,
I can't answer exactly what Fiinix did, but I can resolve a couple other points for you.
The OEM DLLs allow higher-than-normal app permissions (breaking out of the low-privilege "sandbox" that apps normally operate in). However, there are a few parts of the filesystem that can be accessed even without them, by design. One of those is the Isolated Storage for the app, which obviously needs to be readable and writable by the app. Another one is the install directory, which only needs to be readable so libraries and resources can be loaded (the webserver app doesn't allow you to browse this folder, but I'm confident that it could if it was coded to). The third is the Windows directory, which is also read-only (and many files and folders within it can't be read) but is similarly required because the app needs to be able to load system libraries (including the TaskHost.exe binary that hosts the app DLL). "Normal" apps can't access these folders simply because the Silverlight API doesn't have a function to open or list an arbitrary location on the filesystem (only within the isostore, which it abstracts the path to).
I don't know what happens if ID_CAP_NETWORKING is removed. It's quite likely the app would break, since that capability may be checked any time the app tries to open a socket (directly as this app does, or indirectly via the Silverlight APIs). You could experiment and do some research to find out, though. It would be interesting to see.
I wouldn't worry too much about apps in the marketplace running amok with native code (even in the low-privileged process, they could still do some harm). The ComBridge Silverlight API that is required to access native code at all is prohibited from use by independent software vendors - only Microsoft and their partners are allowed to use it for Marketplace apps. Somebody tried submitting a Homebrew app to the marketplace (another opportunity for some research, if you'd like to find out more) and discovered that the use of ComBridge is detected and blocked during the submission process.
There we go, a enchanted new version v0.2
- Optimization's from what everybody has told, the best from all worlds
thanks for the explaination!
It seems like a plausible idea that the native code and the WP7 app needs to access some of the folders to work. So the silverlight managed code won't grant access by design to the Windows folder. Can you tell me where this folder for the installation packages is?
Regarding the capabilities: I've checked it with the marketplace capability test tool:
Result Details
[INFORMATION] : Capabilities used by application :
ID_CAP_PUSH_NOTIFICATION
ID_CAP_NETWORKING
ID_CAP_IDENTITY_DEVICE
I've removed ID_CAP_NETWORKING and it immediately stopped working. No dialogue that shows the IP address, only username and password. That is at least good to hear
Regarding the marketplace certification: You could be right, I've also read somewhere that COM is only available to some third parties like Adobe and manufacturers. Maybe I try to submit a little test app that uses interop.
rudelm said:
thanks for the explaination!
It seems like a plausible idea that the native code and the WP7 app needs to access some of the folders to work. So the silverlight managed code won't grant access by design to the Windows folder. Can you tell me where this folder for the installation packages is?
Regarding the capabilities: I've checked it with the marketplace capability test tool:
Result Details
[INFORMATION] : Capabilities used by application :
ID_CAP_PUSH_NOTIFICATION
ID_CAP_NETWORKING
ID_CAP_IDENTITY_DEVICE
I've removed ID_CAP_NETWORKING and it immediately stopped working. No dialogue that shows the IP address, only username and password. That is at least good to hear
Regarding the marketplace certification: You could be right, I've also read somewhere that COM is only available to some third parties like Adobe and manufacturers. Maybe I try to submit a little test app that uses interop.
Click to expand...
Click to collapse
The Capabilities Test only checks through managed code and its caller references (Dll references, method usage within dll)
Why the ID_CAP_NETWORKING is needed is because of the WP7 policy system; ID_CAP_NETWORKING allows usage to those resource locations:
Allowance to "WINSOCK", windows socket API
Code:
<Rule Description="Authorization rule for capability ID_CAP_NETWORKING" ResourceIri="$(GLOBAL_RESOURCES)/WINSOCK/CONNECT" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
- <Match AccountId="$(CAPMACRO_ID_CAP_NETWORKING)" AuthorizationIds="GENERIC_ALL" />
<Rule Description="Authorization rule for capability ID_CAP_NETWORKING" ResourceIri="$(GLOBAL_RESOURCES)/WINSOCK/LISTEN" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
- <Match AccountId="$(CAPMACRO_ID_CAP_NETWORKING)" AuthorizationIds="GENERIC_ALL" />
<Rule Description="Authorization rule for capability ID_CAP_NETWORKING" ResourceIri="$(GLOBAL_RESOURCES)/WINSOCK/ACCEPT" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
- <Match AccountId="$(CAPMACRO_ID_CAP_NETWORKING)" AuthorizationIds="GENERIC_ALL" />
<Rule Description="Authorization rule for capability ID_CAP_NETWORKING" ResourceIri="$(GLOBAL_RESOURCES)/WINSOCK/SERVICE_PROVIDER_CHAIN" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
- <Match AccountId="$(CAPMACRO_ID_CAP_NETWORKING)" AuthorizationIds="GENERIC_READ" />
"Can you tell me where this folder for the installation packages is?"
\Applications\Install\9bfacecd-c655-4e5b-b024-1e6c2a7456ac\Install\
Nice, thanks for the policy entry. Where did you find it?
Regarding the installation path: I thought you ment a special path to the place where the compressed xap is deployed or something like that before installation. But now it is clearer to me why the application is able to access Windows, installation dir and isolated storage
I've tried to upload a small app with native code but as GoodDayToDie said, the marketplace will see that it contains access to native API and that my account isn't allowed to do that.
So the world is safe again, I'm calmed down now hehe
The policy is from a ROM dump: BasePolicy.xml (Currently got "WP7 Mango Build 7661" dump), i think its this one i downloaded: [DUMP]WP7.1 Build 7661 "Mango"
Some more clearance: \Applications\Install\{ The application Guid }\Install\
- Each application has its own isolation storage:
\Applications\Data\{Guid}\Data\IsolatedStore\
I don't know if it's possible but can you add access to /My Documents?
voluptuary said:
I don't know if it's possible but can you add access to /My Documents?
Click to expand...
Click to collapse
Sorry to say but the basics of this app allows only access to \Windows (dll reference location) as used for extracting of xap files, xml and dll (reverse engineer). You will probably need WP7 Root tools.
Long time follower of all of the work done here. Its a shame that the device is so locked down and no progress has been made. However, I thought I would share with anyone who is interested that its now possible to sync your kin on linux without the need for a virtualbox and windows loaded up.
You can find the fork of lib-mtp at: github [dot] com/kbhomes/libmtp-zune
I've tested it and am able to now sync via terminal or with gMTP. The project was started with the hopes of syncing zunes.. Zune has the same handshake process as the KIN (MTPz)
The background on how it came to be can be found on his project blog: kbhomes.github [dot] com/blog [dot] html.
Hope this helps anyone else who just would like to sync pictures, video, images, songs.
Back to lurking I will go.
Well, it was possible already. No one here uses virtual machines (i hope) in linux but mono runtime.
At least till Kino version comes, so more native (c++ over libusb) approach would be taken.
If you are able to use the standard MTPz way (not our shorcut mtp propietary command), a better approach would be to help here into decrypting the app syncing/uploading procedure, so we could understand what xna framework does in the background and do homebrew launch (which could then help the phone development).
On the other hand, being able to "transparent" sincing would be kind of a good stuff if you could use the kin in software like rythmbox
Sounds good. I hadnt thought abou going at the KIN through Linux before although it would make sense if the KIN was open source. I dont know how much this will help us though.
What he's providing is a fork of the mighty libmtp libraries & tools which is a open implementation of mtp (right one) used by almost any access on the linux environment to mtp devices.
in that fork, he redid the real stuff (aka MTPz) which could be just said as "bypassing" the kin handshake between zune and the device. At least if kin operates exactly like a Zune device (which we think).
It could help by using the kin as a normal (not protected) device on linux providing which kino does IF programs are redirected to it instead normal libmtp, so you can access files and also use in Zune-like software.
On my test field, i wasn't able to compile the software "out of the box" to try on my debian box, so no providing compilation instructions nor a .deb file (debian & ubuntu flavours) or a .rpm file (fedora & redhat 's) makes it just another utility which is non usable by common joe.
What i meant above is that the blog (which i followed back in the day) explains what he did for reversing mtpz protocol, but is not a walkthrough, so we can't just take it and learn, for example, how the kin receives "half succesfully" a XNA application, as i did back in the day in the thread "XNA madness".
better now?
What f we programm an application split it in half and add a part we dont care about for the other half that does nothing then send it to the device with a strip that tells it to complete itself by recommbining itslef on the device?
Hi all
I have purchased a windows Rt and love it. The only thing I can't figure out is I can't access my dvr cameras though internet explorer on my device through my ip address and port number. I can view it on my desktop pc.
Is there any app or way I can view my dvr host on windows rt??
steve.zdravko said:
Hi all
I have purchased a windows Rt and love it. The only thing I can't figure out is I can't access my dvr cameras though internet explorer on my device through my ip address and port number. I can view it on my desktop pc.
Is there any app or way I can view my dvr host on windows rt??
Click to expand...
Click to collapse
BUMP
How is the DVR content presented? If it's HTML(5), that should be no problem at all, so it's probably not. The next most likely is Flash, which RT supports but which may not work when specifying an IP address. You could try using the registry tweak that was previously required for Flash on unknown sites (see the EnableFlash script in my signature). If it's a Java applet, you're screwed (in more ways than one; if you've had the Java browser plugin enabled on your home PC for the last few months, there's an excellent chance that your machine has been infected through it; that thing has atrocious security bugs). If it's some other third-party plugin, for example an ActiveX control from the DVR manufacturer, it's probably not going to work on RT just because RT run on ARM chips and typical ActiveX controls are compiled for x86 (it's possible to make ARM ActiveX, but nobody does and you'd need to "jailbreak" the device before installing the plugin anyhow).
GoodDayToDie said:
How is the DVR content presented? If it's HTML(5), that should be no problem at all, so it's probably not. The next most likely is Flash, which RT supports but which may not work when specifying an IP address. You could try using the registry tweak that was previously required for Flash on unknown sites (see the EnableFlash script in my signature). If it's a Java applet, you're screwed (in more ways than one; if you've had the Java browser plugin enabled on your home PC for the last few months, there's an excellent chance that your machine has been infected through it; that thing has atrocious security bugs). If it's some other third-party plugin, for example an ActiveX control from the DVR manufacturer, it's probably not going to work on RT just because RT run on ARM chips and typical ActiveX controls are compiled for x86 (it's possible to make ARM ActiveX, but nobody does and you'd need to "jailbreak" the device before installing the plugin anyhow).
Click to expand...
Click to collapse
The DVR is set up with its own ip and port forwarding number, and that how I connect to it from other desktop PC's. Or it gives me an option to view it through a program called CMS lite which the Win RT doesn't allow me the download. I have jailbroken my RT as well.
What happens when you connect to that IP and port on your RT device? What do you see in the browser (if anything)? Does it connect, or does it say it couldn't find the site? You haven't actually explained the problem very well at all, even to the point of saying what device it is. We probably don't have your exact setup at home, so you'll need to be very precise describing it so that we know how to fix it.
You also didn't answer my question in the previous post. How is the content normally presented? Flash or HTML5 should be fine, but *might* take some tweaking. Java or a plugin are unlikely to work, although I suppose it's possible that the x86 emulator could be made to work with a plugin.
For that matter, have you tried the x86 emulator with your CMS Lite program? It's unlikely to work, but worth a shot.
GoodDayToDie said:
What happens when you connect to that IP and port on your RT device? What do you see in the browser (if anything)? Does it connect, or does it say it couldn't find the site? You haven't actually explained the problem very well at all, even to the point of saying what device it is. We probably don't have your exact setup at home, so you'll need to be very precise describing it so that we know how to fix it.
You also didn't answer my question in the previous post. How is the content normally presented? Flash or HTML5 should be fine, but *might* take some tweaking. Java or a plugin are unlikely to work, although I suppose it's possible that the x86 emulator could be made to work with a plugin.
For that matter, have you tried the x86 emulator with your CMS Lite program? It's unlikely to work, but worth a shot.
Click to expand...
Click to collapse
my device is a windows rt surface. when I open internet explorer and type in my ip and port number in the search engine it comes up with my login and password which I type in. after that the screen comes to a blank white screen which gives me the option. Webserver or CMS lite setup I always view them from webserver. Once I click webserver the screen just says on a blank white screen.
as for how the content present normally im not really sure.
A simple way to tell is to load the page in a desktop browser where it works, then right-click the video and see what menu comes up. If it's the Flashplayer menu, that's something that RT can handle. If it's something else (Silverlight or Java or a custom ActiveX), that may not be possible. Another way to tell would be to save that blank page to a file (I believe Ctrl+S works for this, at least on the desktop mode of IE, or you can do it from the Tools->File menu, or the File menu on the menu bar that is shown when you tap Alt). Send or post the HTML somewhere that we can read it, and we can tell you what it will take to view the page.
another question.. im still new to the windows rt group I have jail broken the RT surface. Is there any torrent client for downloads.
I wanna download movies from a website. thanks
Free Download Manager (it is in the ported apps thread) can be used as a torrent client. However discussion of piracy is prohibited so might want to zip it on the movies part.
Monotorrent was attempted on RT but I think ended up being buggy.
SixSixSevenSeven said:
Free Download Manager (it is in the ported apps thread) can be used as a torrent client. However discussion of piracy is prohibited so might want to zip it on the movies part.
Monotorrent was attempted on RT but I think ended up being buggy.
Click to expand...
Click to collapse
can u please send me the link
Read the forum rules, especially the first one. Then, read my signature. I don't mind helping people find obscure stuff, but this does not qualify. Please put forth at least a little effort on your own part...
I shouldn't have to share a link having told you where it is. Its easy to find, a) its in the list of ported applications in the RT development and hacking section. b) it has its own thread in that same section. c) it is listed on google. d) it is listed on forum search.
Full Article
http://justinangel.net/Win81APIs
Bluetooth 4.0 RfComm and GATT support
Point of sale: Barcode scanners and Magnetic card readers
Smart Cards
Lock screen Image Apps
VPN support for Metro apps
Scanner APIs and apps
Support for any External / USB device
Native PDF rendering in apps
Multiple screens projection support in apps
XAML/WinJS: New resolution scaling support / Super-high resolution tablets
Camera: Low-lag cameras / HDR
New Metro App Types: Appointments, LockScreen, Contacts and GeoLoc
New App Type: GeoFenced activation
New App Type: Lock screen call
New App Type: Appointments Provider
Text-to-speech
Read-write access to Camera roll, Saved pictures and playlists
XAML/WinJS: new SearchBox control
XAML/WinJS: Hubs for SemanticZoom
XAML: DatePicker and TimePicker
XAML: Flyout, MenuFlyout and SettingsMenuFlyout
XAML: AppBar simplification
XAML: DataBinding Improvements
Globalization: Currencies, Numeral systems and Numerical formatters
Other minor but important Win8.1 features
Be aware: these are new WinRT APIs, not Windows RT features. WinRT != Windows RT (I usually abbreviate the latter as "WRT" to avoid confusion and for similarity with things like WP8).
With that said, since WinRT is the only official API for developing WRT apps, and since Win8.0 and WRT_RTM support the same WinRT APIs, it's reasonable to assume that the same APIs are coming to WRT and therefore apps using these API features will be available on WRT devices.
Another interesting point is that WP8 uses WinRT as well (though only a subset of it). Hopefully at least some of these new APIs also become available on WP8.1; the obvious candidates are things like alarms and Bluetooth and such, though it'd be great to get *any* kind of VPN support in there...
"Support for any External / USB device"
Does that sound like unsigned (or testsigned, whatever) kernel mode code to anyone else?
Edit: Should probably read the thread closer, this is WinRT stuff.
It's not kernel mode. More accurate would be the ability to write (sandboxed, low-privilege) user-mode drivers using WinRT. That's still cool - it's the first official driver API of any kind, and from a security standpoint I'm way more comfortable about installing WWinRT apps than actual NT drivers - but it probably won't help with unlocks. It does mean you can talk directly* to USB devices, though, which is cool in many ways.
Given the ability to handle unrecognized devices, I'm guessing that apps will be able to register for specific USB IDs (in the same way that they can register for URI schemes and file extensions now) so that the app will auto-start when you connect a device, or so you can search the store for apps which can handle a specific device. This is big. The lack of third-party NT drivers for obscure hardware on RT has been an impediment (one of many) to progress on the platform. Asking people to write their own drivers is probably not going to fly for really complex hardware unless it's also quite popular, but I can see people doing things like writing an ADB app; there's no reason I know of why that needs to be a kernel driver.
* I'm assuming that the new WinRT APIs basically call into a generic NT driver that does the actual device IO. So, it's not literally directly talking to the device in the sense of sending bits down the USB port from your software, but it's still a lot closer to the metal than we could officially get before.
GoodDayToDie said:
* I'm assuming that the new WinRT APIs basically call into a generic NT driver that does the actual device IO. So, it's not literally directly talking to the device in the sense of sending bits down the USB port from your software, but it's still a lot closer to the metal than we could officially get before.
Click to expand...
Click to collapse
Yes, it is probably just a Metro wrapper around the old well-known WinUSB API: http://msdn.microsoft.com/en-us/library/windows/hardware/ff540174(v=vs.85).aspx
And there is a strange question in the article:
Despite the plethora of new VPN APIs, an open question remains as to whether WinRT Win8.1 apps will work by default on VPNs.
Click to expand...
Click to collapse
VPN works fine on RT. At least I can connect to our company VPN with the built-in client and access all our internal resources, for example Sharepoint from the Internet Explorer.
Confusion of "Windows RT" and "WinRT" again*. VPN works "fine" on Windows RT, or on Windows 8, for desktop apps. However, WinRT apps, on either Win8 or WRT, are known to have problems tunneling through VPNs. These new APIs will hopefully help with that, but the question remains whether WinRT (Metro) apps will work *by default* over a VPN, or not.
* I swear, the entire Microsoft branding department, or at least any of them who can't provide proof they didn't argue against this idiocy, need to be stood up against a wall, slapped in the face, by everybody who ever got those two mixed up, and then fired. Much like Windows Phone... at least the complete retard who came up with "Windows Phone 7 Series devices" got the boot, but the result was merely slightly less awful and it hasn't gotten better since.
Being able to write drivers in WinRT level sounds very interesting indeed. I wonder how much integration into the OS will those drivers have, especially, if they are to remain active even when the parent app is not running.
I just hope they bring the entire IO interface of .NET on WinRT. That way we would be able to write drivers from scratch if we really wanted to...
I just want to access to COM ports. Seriously that was a dumb decision on microsofts behalf to block it. Only security threat it poses Tcp also poses so that can't be the reason.
I guess with raw usb access you can try a custom driver to a usb adaptor.