I'm sure it was VMWare (the network driver of it)on your system, this would confirm my theory. But this isn't the solution for this problem for all. I don't have such thing installed on my quite clean and newly installed system (AMD XP 2.5GHz, Win XP with SP2 integrated, Antivirus turned off for test, nothing installed but what I need right now (Office, Delphi, PODS, Firefox, Firebird)). I also tried it in XP safe mode but the problem is still the same.
I believe it is as described earlier the timing thing where two processes share the same port, thus it doesn't occur on all systems but mostly on XP systems with SP2. I think it is intended as a feature by the developers of PODS to look if the random generated port is available and then assign this port to the Simulator. It may be Windows which causes the problem and maybe makes PODS believe the port is unavailable later during the debugger session startup. But PODS seems to make a second check before it starts the PalmOSDebuggerM process, that is the real problem. (I'm think this is the problem because the Emulator, other than the Simulator, will always listen to port 2000 - but PalmOSDebuggerM will still connect to port 0). The proper solution is PODS to remember the port given to the Simulator. It would also be better if PODS assigns the port as a command line argument instead of changing the ini file of the Simulator, otherwise users won't be able to use the external debugger with the Simulator that comes with PODS without changing the ini every time (the Emulator will work). Ben -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
