For over a year now I own a htc prophet.
Ever Since i've been on the lookout for a technique to use activesync over tcpip (wifi). It's been years since microsoft took that feature from us. all over the net i can hear the cries of people not understanding why it is missing.
There are virtual com port replicators, mappers, loggers and what not available for windows mobile.
there is just one thing missing!!!
A virtual com/serial port redirector for the ppc which redirects traffic to a server on the x86 machine over tcpip that creates a com port on the windows box for active sync to use. as both the ppc and the x68 active sync components support com connections.
ppc (wm5)->virtual com port client->tcpip(wifi)->virtual com port server(on x86 windows)->activesync 4.x
(of course bidirectional)
such software is readily available for windows to enable many computers to share a com device.
i have found libraries that would facilitate making such a product and i'm sure thousands would appreciate it (and happily hand over some amounts of money).
why is there no such thing? has ms been sending cease and desist letters to protect their exchange server business?
am i blind? was i just thinking too quick?
i might one day do it myself - unfortunately i can't stand visual studio and did never like learning ms-apis. I never needed it before and was happy with that.
Related
Hi all, I’d like some advice please.
I am still fairly new to all this so please treat me as a noob.
This weekend I removed all traces of Windows from my two computers at home. It is now entirely Linux powered
It is also upgrade time for me with my phone network (02 in the UK) and I’d like to get a phone that syncs up to one contacts list and does email. Wifi is a must, so I was thinking of the 02 xda Orbit, or maybe the Graphite (when it comes out)
I have also recently set up a gmail account. Busy time!
So now I am not sure what the next step is.
If I ran CrossOver office, would I be able to sync contacts/tasks/mails with (either) devices?
Should I just use gmail on the phone? (Trying to get my PST files into Gmail is proving a *massive* headache though!) and it looks like then the phone would have two contact lists? One for email and one for the phone.
Is there a better solution? I am quite happy to run thunderbird/evolution/something else on the computer, and or phone.
Nothing is set in stone here. I am completely flexible.
I am keen to hear whatever you recommend is the best solution.
Thanks in advance,
John
As ActiveSync would require direct access to the USB or Bluetooth, i doubt it unless the APIs are there (not to sure with CrossOver, but its not done for Wine).
Syncing in Linux with WM5 is a pain, at best you'll have to hand compile Synce and the OpenSync plugin, then setup OpenSync and Evolution. I currently export my info to vcal/vcf, do some script fu on them and bluetooth over to my mobile and use SkTools to remove any dupes.
Another option is to have QEMU running with Windows and ActiveSync on, then forward the USB device onto QEMU to use. I had this half working last night but the XP install i've got has issues with loading new drivers, i'll try again tonight
Thanks for that response - very very helpful.
I thought about the idea of using a host operating system, but I was concerned about processor speed and system load.
This would be for a laptop that is a few years old, and a mail client is the sort of thing I'd always have running. I am very keen to hear the results of your XP tests. If QEMU works, it may be the solution.
If not, I guess the alternatives are using a java gmail app on the phone and manually keeping the contacts inline.
Or wait to see what happens with this OpenMoko project.
I custom patched QEMU 0.8.2 with the USB Multi-interface mod (needed to pickup a HTC device) and tried to set it up, Devices is detected in WinXP but then errors like a hardware issue. It'd possibly work with VMWare as you can specifically assign a device to the VM but i dont think QEMU is up to the job quite yet.
Thanks for the update. I'll keep hacking, and if I have any success, I'll post about it here.
cheers
Does anyone knows if BlackBerry Connect can be use on Treo 750?
My Treo 750 going with Windows Mobile 6.0
Cheers,
I'd love to know this too.
I'm with you on that. I've got a Treo Pro and would really like to know if there's any type of Blackberry Connect software built specifically for Palm's Windows Mobile Devices.
Here's some things I've been looking into as an alternative:
1.) Lotus Notes Traveler: In Lotus / Domino 8.0.1 there's an application available for Windows Mobile Clients called, "Lotus Traveler"; the only catch is that your organization must be on the latest version (which in my case isn't the case), in addition to having the server software enabled.
http://www-01.ibm.com/software/lotus/products/notes/traveler.html
2.) Common Time - mSuite software: IBM Lotus Notes delivered to Smartphones and PDAs; works with push e-mail, calendar synch, everything you'd want from Blackberry Connect (I believe). However, the only catch (from what I understand) is that you must have a machine (desktop, server, etc.) within the organization LAN running a small service that you will connect with from the outside which acts as a go-between (over HTTP) and does all the synching. This also requires that you will first setup your device to work with the software on your machine (key/pair matching creating trust between the computer and your PDA). This didn't sound practical to me either.
3.) Blackberry Emulators for Windows Mobile: a developer at work was discussing this and I'm not too sure if there is even anything out there like this--I'm guessing that's sort of what Blackberry Connect is--a small subsystem that emulates RIM.
Any other feedback I get I'll post. You're the only person I've found who's looking to do the same thing as me. Would love to hear about anything you've found, or dead-ends you've encountered.
Any hunches and/or leads anyone has on this would be fantastic. I'm trying not to believe that this may be a dead end but for now I'll try doing some more research and see what I can come up with.
Thanks,
Matt
Here's that link for Common Time mSuite (et. al.)
http://www.commontime.com/
Also looked into:
- Pylon Anywhere: Sybase synch solution--I believe you may have to have the device craddled to the computer in order to make this happen. I don't believe this offers push e-mail, although I may be wrong about that. http://www.sybase.com/products/allproductsa-z/pylon
- Intellisync (intellisync.com)
- Lotus EasySync Pro (http://www-142.ibm.com/software/sw-lotus/products/product4.nsf/wdocs/easysyncprohome).
- Odyssey Client 4.0 (found nothing compelling, not too sure what this does).
- PDASync: http://www.laplink.com/products/PDAsync/overview.asp
- XNotes: http://www.tntsoft.com/index.php?xnintro
- XTNDConnectPC: (non push e-mail) http://www.extendedsystems.com/web/content.aspx?key=87479B0C67EF93379DB1AD4D6FA06319
- Heresay Blog Post / Yahoo News Article (news article doesn't seem to exist anymore): http://thinkabdul.com/2007/04/23/blackberry-emulator-for-windows-mobile-60-connect-synchronize-e-mailcalendarcontacts-to-blackberry-server/
Blackberry / RIM Virtual Emulator for Windows Mobile
Apparently there is some truth to the Blackberry Emulator for Windows Mobile.
*WindowsForDevices.com article: http://www.windowsfordevices.com/news/NS3720446400.html
*PCMag.com article: http://www.pcmag.com/article2/0,2817,2121074,00.asp
Official Blackberry Connect Message Board regarding Palm Devices
Palm Blackberry Connect (stuff about support on Treo 750, etc. right at the top)
http://www.blackberry.com/btsc/search.do?searchString=Palm&cmd=search
Windows Mobile Blackberry Connect page (very vague info on this--looks like they leave it up to manuf's to support on a per device basis):
http://na.blackberry.com/eng/devices/enabled/os.jsp#tab_tab_windows
***Looks like good news for Palm Treo 750
http://www.blackberry.com/btsc/search.do?cmd=displayKC&docType=kc&externalId=KB10593&sliceId=SAL_Public&dialogID=210080962&stateId=1%200%20210078421
That's all I got for now.
Hi Folks.
With both a Zune HD and WP7 devices not supported via USB conenction to a Surface RT, I was thinking there had to be a way to tweak/re-write the ZuneHD / Zune driver files to allow them to be installed on the Surface RT...The ZuneHD is an ARM based device running Windows Embedded - and RT is an evolution of Windows CE you might say.
If so, the earlier regedit hack to allow the WP7 (or ZuneHD) to connect as a USB mass storage device would hopefully be possible, without the full ARM recompile of the Zune software (a near impossible task).
It's ridiculous that pre WP8 devices cannot even be connected via USB to facilitate file transfers "non-cloud" way.....
I tried manually updating drivers on the Surface RT with my ZuneHD connected - pointing at the Zune 4.7 drivers, and it confirmed that they were not ARM compatible.
Cheers,
Sheeds.
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all? You act like you have some idea what an instruction set architecture is, but you say this. If I ran this entire message through a translator to Finnish and then ROT-13'd it, you'd probably have a better chance of understanding the post than of managing to get the existing x86 Zune driver working on RT without a full re-write plus an additional hack to bypass driver signing. The Zune driver isn't exactly open-source... binary emulation *might* work at some point, but it's not practical for a kernel-mode driver (signature checks or not).
There is not, and never was, a hack to allow Zune-like devices to connect using UMS. The hack you're referring to merely un-hid the MTPZ (Media Transfer Protocol, Zune) devices from Windows Explorer. MTP(Z or not) and UMS are not at all the same thing, although they can sometimes be used for some of the same purposes.
We'd have a much better chance of getting Zune to run on RT, actually. That's "just" a matter of emulating an x64 machine for it to run on and passing its system calls through to the real OS and back again. Won't do any good for this use case without the driver, of course.
What does it matter that RT and CE run on the same ISA? The driver that we need is x86/x64 only.
There is basically nothing in common between CE and NT, aside from the fact that they're both portable operating systems from Microsoft and both implement some large portion of the Win32 API. Claiming that "RT is an evolution of Windows CE" is laughably wrong. They probably have less in common than Windows 95 (9x kernel, partially based on Win16 code) and Windows 8 (NT kernel, completely different project that contains no portions of DOS/Win16 except the re-implementation of the shell in NTVDM) - at least Win8 can run (many) Win95 apps. CE is at least as different from each of those as they are from eachother.
At this point, I'd guess that the most practical way to connect Zune on Windows RT would be the following:
a) Use a full x86-machine emulator (Bochs or QEMU, for example).
b) Use one that does JIT and/or dynamic recompilation, so the performance isn't abysmal (not sure what qualifies here...)
c) Install XP on it (no point targeting something newer).
d) Install Zune on the emulated XP.
e) Forward the tablet's USB port to the emulated machine's USB port (not sure if anybody has the ability to do this... currently, we can't even get networking in the emulated machine).
Good luck with that! I actually mean that quite seriously, I have a WP7 device myself and it annoys me that my Surface and it can't communicate except over Bluetooth (and I had to hack the phone to get that much).
GoodDayToDie said:
...
"tweak/re-write" an x86 kernel-mode driver into an ARM kernel mode driver for installation on a platform that doesn't (currently) permit unsigned drivers at all?QUOTE]
LOL - Thanks for the informative reply Luckily I have no delusions of grandeur over the fact that I am A) not a Developer and B) can't code past "hello world"
I was coming from the angle of the old registry hack for WP7 which allowed your phone to work as a USB mass storage file by a simple change via regedit to one of the registry strings associated to the Zune Driver....Certainly ignorant of the finer (and even the coarser) detail of your reply...so thanks for the explanation.
I added a MS Answers post asking why Microsoft cannot provide USB device connection for legacy WP7 and ZuneHD units with Windows RT. Be interesting to see what they or their MVP's reply to this, if at all.
Cheers.
Click to expand...
Click to collapse
Yeah.. asking MS to support the devices is definitely the best approach. We might manage to make a user-mode connection to them using some third-party software talking directly to the USB port on sufficiently hacked RT devices, but that's about the best we'll get.
Also, I really with people would stop calling it a "USB Mass Storage" hack. I've posted to that effect in the relevant forums that I can find, too. This is not now, never was, and (short of custom ROMs or special bootloader modes) never will be a UMS interface to Zune-like devices. The device literally doesn't support it. Please don't confuse Media Transfer Protocol for USB Mass Storage. They are *not* the same. For example, those nicely named music files you see when using the "UMS" hack for WP7/Zune? *THEY DO NOT EXIST* anywhere on the device's filesystem. True, there are files containing the same binary data, but they have names like "2D.mp3" and are stored in a filesystem structure designed to make referencing them in a database faster. MTP exposes a hierarchical storage system (which may, coincidentally, mirror the filesystem although it does not do so on Zune-like devices), but it does *NOT* expose the filesystem/storage (which is what UMS does).
I have a device that uses Serial Port and work with MS Windows. I would like to replace it with android with mobility. So I dont need to bring the bulky notebook for the simple work. Since the software is windows based, I cannot install it in android. Remote Desktop is an alternative to access my home computer for the software functionarity. The missing link is the serial connection of the device. In desktop version of RDP, many app allow redirection of both parallel and serial port. Yet I did not see any RDP app implementaion. Are there any known solution or where to start my own compilation?
The serial port on android device is provided by prolific pl2303 and is proven to work with android already.
Thanks.
Is there any alternative to Hamachi for WinRT (with the WinRT device being the client)..
Because RT doesn't run x86 apps, I need to VPN into a machine that sits behind a firewall with no port forwarding for RDP (remote desktop).
Therefore I want to run some VPN server on the machine so that the Surface RT can connect to the local LAN over the internet for an RDP session.
RT has the standard Windows VPN capabilities built in, I think (haven't actually tried). Third-party VPNs aren't supported without jailbreak, and won't be until Microsoft officially makes it available; WinRT apps simply do not have the permissions to create a network interface or re-route traffic (remember the days when Android VPN apps needed to be run as root? That's basically where RT still is).
Out of curiosity, if you can't forward the RDP port, why do you expect you'd be able to hit a VPN server behind the firewall? If it's just a matter of them specifically blocking port 3389, you can change the port that Terminal Services (RDP server) listens on in the registry.
You could try teamviewer, they can route the traffic through their servers so you don't need to forward a port to your pc in a firewall
hberntsen said:
You could try teamviewer, they can route the traffic through their servers so you don't need to forward a port to your pc in a firewall
Click to expand...
Click to collapse
I am planning to try that but was hoping there was also a service like Hamachi available ...
GoodDayToDie said:
RT has the standard Windows VPN capabilities built in, I think (haven't actually tried). Third-party VPNs aren't supported without jailbreak, and won't be until Microsoft officially makes it available; WinRT apps simply do not have the permissions to create a network interface or re-route traffic (remember the days when Android VPN apps needed to be run as root? That's basically where RT still is).
Click to expand...
Click to collapse
GoodDayToDie said:
Out of curiosity, if you can't forward the RDP port, why do you expect you'd be able to hit a VPN server behind the firewall? If it's just a matter of them specifically blocking port 3389, you can change the port that Terminal Services (RDP server) listens on in the registry.
Click to expand...
Click to collapse
Look up Hamachi and reread my OP
Fair point. You're not actually VPNing *into* your machine, but into a Hamachi-operated central management server. That has... interesting... security implications, but I suppose it does provide convenience (it would also be an immediate termination offense anywhere I've worked that had a firewall configuration like you describe, but that's your problem, not mine). Why can't you set up port forwarding in the firewall? Also, you did expressly state "Therefore I want to run some VPN server on the machine" where "the machine" presumably means the one behind the firewall...
The only time I've tried using Hamachi before was for "LAN" gaming over the 'net, which I decided not to do after looking at how it worked. That was long enough ago I'd forgotten the details of how it worked.
My first post still stands. There are at least two things Hamachi (or similar) would need to do that are impossible for a WinRT app (or for any software on RT without a jailbreak, really): create a network interface (we haven't even managed that *with* jailbreak, because except in the case of the semi-official driver from Pluggable we don't have any NDIS6 driver we can compile for ARM) and control a network interface from an app (there are possibly some rather hacky ways this could be done, but nothing we have right now).
Good Thank you:fingers-crossed:
Maybe someone will port Zerotier? It's too complicated for me, please help me make my life little easier