This is a reply that I posted to a public newsgroup on www.IrDA.org on 15th November 2000. The thread started by someone asking how to use certain infrared applications on Windows ME, a replying poster recommended that everyone complain to Microsoft that they had changed the infrared support from what was in Windows 98 and that it should be returned exactly to the way it was in Windows 98. I thought that, whilst complaining is to be recommended, this was short sighted and rather than re-instate the old IrDA functionality stictly it would be bettter to improve upon it.
Warning: Sorry this is very long!!!
Before we all go off and complain to Microsoft I think it would be useful if we could decide what IrDA functionality and interface we would want in a multi-tasking extensible OS.
BTW I have no allegiance to any manufacturer or other party affected in this discussion, I'm only a user who wants interoperable, easy to use systems.
What Microsoft has removed is:
1. an IrCOMM Virtual COM Port, and
2. (if I understand it correctly) DIRECT access to the infrared tranceiver to send and receive full bottom-to-top frames.
To deal with the latter first, allowing direct access to the infrared tranceiver seems quite a scary thing to me. This is if I understand it correctly, what LogoManager and its ilk require, see the website at www.logomanager.co.uk). It would seem to create all sorts of possibilities for interference with IrDA communications. Surely its better for an IrDA-compatible interface to be provided and used so that programs can communicate with peer devices safely and easily.
Do such programs really need raw access to the infrared stream? Was it just that there was no IrDA API in Windows 95 where IrDA support first appeared? Surely all devices we'd want to communicate with support (at the minimum) IrLMP e.g. even the Nokia 6110, which doesn't have AT commands nor IrOBEX, uses IrCOMM (/IrLPT)?
If the programs don't require raw access then they should be updated to use the WinSock IrDA support (see e.g. http://msdn.microsoft.com/library/backgrnd/html/IrDAwp.htm) that appeared in Windows 98 and CE and all subsequent releases e.g. 2000 and I presume ME and Whistler? This is not difficult. The API provides TinyTP, IrLMP (I think) and IrCOMM services.
Back to the first point. The "IrCOMM virtual COM Port" does/did provide "no work" IrDA wire replacement support for device manufacturers. For instance Palm had only to add IrCOMM support to their device's OS to allow HotSync to work, HotSync Manager was configured to communicate with the IrCOMM virtual COM port and thus no changes were required there (see below for details how Palm supports 2000 & ME etc). Mobile phone manufacturers just had to add IrCOMM support and all services that worked over a cable are available over IrDA. Super!...?
But this wide reliance on IrCOMM causes problems. It is a real hassle to have to enable and disable HotSync Manager, ActiveSync, IrTran-P receiver etc, as I want to use my Palm, PocketPC or Digital Camera respectively. (BTW why does IrTran-P run over IrCOMM?) This is not the brave new world of easy to use point-and-shoot applications and devices!
Microsoft discuss the problems at http://msdn.microsoft.com/library/backgrnd/html/ircomm.htm saying: · Many customers have difficulty with the concept of virtual ports. · Multiple applications cannot share a virtual serial port. · Windows 2000 IrDA connections must be supported by multiple device connections.
Applications that run on Windows (or any multi-tasking, extensible device e.g. Linux, MacOS etc) as IrCOMM servers are NOT a good thing. Applications that run as IrCOMM clients are not _so_ bad. As they are individually activated by the user they won't conflict (well mostly!).
Palm has updated HotSync Manager to include IrCOMM server support internally, see the support site at Palm.com for a "Desktop Updater". This still conflicts with the IrTran-P Image receiver application (Wireless Link) which has to be disabled.
Microsoft's intention would seem to be good, it was to make the system easier to use. No programmer/manufacturer was going to change their systems to stop using the IrCOMM virtual COM port or DIRECT infrared access if they still existed. I still wonder whether Microsoft should have left in a 'client-only' IrCOMM virtual COM Port for Mobile Phone usage? This might have caused more confusion though.
Software that re-adds IrCOMM virtual COM port seems to have leaked out from Extended Systems, see http://www.irda4w2k.com/. I have no experience with this software.
Note using the Virtual COM port for client application is a not a great solution either when there may be multiple infrared tranceivers and peer devices in range, which of the devices are you intending to connect to?
I would like to hear other peoples’ views on this and what they think the best solution is. My one firm view is that Windows (etc) applications should NOT run as IrCOMM servers due to the conflicts, beyond that...?