It's IPv6. Use IPv4@GoodDayToDie unable to use newest version. got a url that is http://2406:3003:2046:9f:da31:cfff:fefb:8957:577. unable to open this with chrome or ie
It's IPv6. Use IPv4@GoodDayToDie unable to use newest version. got a url that is http://2406:3003:2046:9f:da31:cfff:fefb:8957:577. unable to open this with chrome or ie
That's an IPv6 address, it means either that your network doesn't offer IPv4, or that the app grabbed the wrong address for some reason (incidentally, you can probably still connect to it on the usual address). If it's the latter, restarting the app (wait a few seconds before starting it again) should fix things. I guarantee you I didn't touch that part of the code at all.
In browsers it should be in [], for example localhost would be http://[::1]/ and your address http://[2406:3003:2046:9f:da31:cfff:fefb:8957]:577/ (if the port was 577)@GoodDayToDie unable to use newest version. got a url that is http://2406:3003:2046:9f:da31:cfff:fefb:8957:577. unable to open this with chrome or ie
Modifications (uploading or editing files, creating, deleting, or changing registry keys or values) are currently not supported. They will be "soon" although my personal testing suggests that basically the whole registry, and most of the file system, is off-limits for writing. Interestingly, I can *read* most of the registry, including stuff that I probably shouldn't be able to.
Once I (or somebody) gets full root access - currently, the only way to do that is through MTP (USB connection, not a user app so we can't control what it *does*) - then I will definitely implement modifications and uploading in the app, if I haven't already. I'd like to get them working soon, but it's relatively low priority next to working on the various unlock hacks (including trying to get "root"), exploring what I can do with the permissions that I have so far, and developing other apps that take advantage of those permissions. I'm working on it, though!
Currently, the only locations that the app can write to (using the standard capabilities) are its install folder and its data folder. That's not terribly exciting, so I didn't bother implementing file upload yet.
Not much, right now. There's a few things that are easier to do from the nativefilesystem library, but mostly it's to lay a groundwork for future stuff that isn't (officially) supported/possible. For example, NativeFileSystem has the option of creating symbolic links (requires ID_CAP_BUILTIN_SYMBOLICLINK or similar, I forget the exact cap) which isn't supposed to be possible.
New version, 0.4.9 posted. Should have fixed or at least greatly improved the performance and stability issues that were plaguing the app. Additionally, resume and port-changing now work as they should, and all registry types (including unknown/illegal ones) are now supported.
Trust me, that's on the roadmap. If the server was written in native code, I'd probably already have done it; native EXEs are easy to create and I could have it run in the background while the app controls it. It's probably possible to make an EXE out of managed code on WP8 too, but I'll need to work on that. Alternatively, I could make the server spoof itself as a navigation app or something similar that is permitted to run continuously in the background. That's probably easier, though it feels less "elegant" to me.