It's certainly possible to develop on a Windows machine, in fact, my first application was exclusively developed on the old Dell Precision I had at the time :)
There are three routes;
- Install OSx86 (aka iATKOS / Kalyway) on a second partition/disk and dual boot.
- Run Mac OS X Server under VMWare (Mac OS X 10.7 (Lion) onwards, read the update below).
- Use Delphi XE4 and the macincloud service. This is a commercial toolset, but the component and lib support is growing.
The first route requires modifying (or using a pre-modified) image of Leopard that can be installed on a regular PC. This is not as hard as you would think, although your success/effort ratio will depend upon how closely the hardware in your PC matches that in Mac hardware - e.g. if you're running a Core 2 Duo on an Intel Motherboard, with an NVidia graphics card you are laughing. If you're running an AMD machine or something without SSE3 it gets a little more involved.
If you purchase (or already own) a version of Leopard then this is a gray area since the Leopard EULA states you may only run it on an "Apple Labeled" machine. As many point out if you stick an Apple sticker on your PC you're probably covered.
The second option is more costly. The EULA for the workstation version of Leopard prevents it from being run under emulation and as a result, there's no support in VMWare for this. Leopard server, however, CAN be run under emulation and can be used for desktop purposes. Leopard server and VMWare are expensive, however.
If you're interested in option 1) I would suggest starting at Insanelymac and reading the OSx86 sections.
I do think you should consider whether the time you will invest is going to be worth the money you will save though. It was for me because I enjoy tinkering with this type of stuff and I started during the early iPhone betas, months before their App Store became available.
Alternatively, you could pick up a low-spec Mac Mini from eBay. You don't need much horsepower to run the SDK and you can always sell it on later if you decide to stop development or buy a better Mac.
Update: You cannot create a Mac OS X Client virtual machine for OS X 10.6 and earlier. Apple does not allow these Client OSes to be virtualized. With Mac OS X 10.7 (Lion) onwards, Apple has changed its licensing agreement in regards to virtualization. Source: VMWare KnowledgeBase
New answer, powershell
TCP
Get-Process -Id (Get-NetTCPConnection -LocalPort YourPortNumberHere).OwningProcess
UDP
Get-Process -Id (Get-NetUDPEndpoint -LocalPort YourPortNumberHere).OwningProcess
Old answer, cmd
C:\> netstat -a -b
(Add -n to stop it trying to resolve hostnames, which will make it a lot faster.)
Note Dane's recommendation for TCPView. It looks very useful!
-a Displays all connections and listening ports.
-b Displays the executable involved in creating each connection or listening port. In some cases well-known executables host multiple independent components, and in these cases the sequence of components involved in creating the connection or listening port is displayed. In this case the executable name is in [] at the bottom, on top is the component it called, and so forth until TCP/IP was reached. Note that this option can be time-consuming and will fail unless you have sufficient permissions.
-n Displays addresses and port numbers in numerical form.
-o Displays the owning process ID associated with each connection.
Best Answer
There are a couple of features Mono has that .NET doesn't.
Mono is highly modular. You can break it apart in tiny little pieces and only deploy exactly those parts that you need. Don't want System.Xml? Fine, it's gone.
Mono is embeddable. You can host it inside your C/C++ application, to allow users to script it from a safe managed sandboxed environment. The most famous example of this is mod_mono, which hosts Mono inside the Apache webserver, and is how ASP.NET is implemented in Mono, for example. This feature goes great together with the modularization mentioned above.
This has already been mentioned: static linking. Also goes great together with modularization.
Compiler as a Service is another one. Anders Hejlsberg has been talking about it for a long time, and maybe, just maybe it is going to be ready for C# 5.0. Well, Mono already has it, and actually had it for years.
Miguel de Icaza, Mono's Lead Developer also has an initiative that he calls "Embrace and Extend.NET", which extends the CLI in ways not (currently) possible with other CLI implementations (including .NET). So far, Embrace and Extend.NET has three features.
Mono.Simd, which gives safe and controlled access to the SIMD instructions of the underlying CPU (e.g. SSE on Intel or AltiVec on PowerPC). Used for Games and Graphics.
64 Bit array indices, which are allowed by the ECMA specification, but Mono is the only VM that actually provides them. Used in supercomputing.
And most recently, continuations. This is actually the first time that Mono strays outside the realm of the specification: long array indices are perfectly valid as per the spec, and Mono.Simd also works on every CLI compliant implementation (albeit very S-L-O-W), but Mono.Tasklet needs special support from the VM that is not part of either CLI or .NET. This is used for game logic and e.g. in Second Life.