The rule of thumb for TCP throughput over Wi-Fi is that you can get 50-60% of your signaling rate. So in your case, you should see 75-90 megabits per second of TCP throughput.
Wait, why is your TCP window size just 8 KibiBytes? That strikes me as an absurdly low default.
Let's see what yours should be by calculating a "Bandwidth x Delay product" for your connection.
If Windows 7 is reporting that you're getting a 150 mbps signaling rate, that's 150,000,000 bits per second, so let's use that as the bandwidth number.
As for delay, well, my average ping round trip time over Wi-Fi to my AP is a little under 3 milliseconds. But you're going from one wireless client to another, which gets relayed by the AP (to avoid the hidden node problem), so I'm guessing if you pinged one of your wireless clients from the other one, you'd get a round trip time of up to 6ms.
So 150,000,000 bits/sec of bandwidth * 0.006 seconds of delay = 900,000 bits you need to be able to put "in flight" before getting an Ack back, in order to keep the pipe full.
900,000 bits / 8192 bits per KibiByte = about 110 KibiBytes of TCP window needed. Let's be generous and make it a nice round 128.
-w 128K to your
iperf argument lists on both the client and the server to force the TCP window to something reasonable, and see if that helps.
Since wireless is a fickle medium and there can sometimes be latency spikes due to transient noise forcing link-layer packet retransmissions, you could even try going larger than that, maybe up to 512KiB, but at some point there will be diminishing returns.
If increasing your TCP window size gets you up to around 75 megabits/sec of TCP throughput in IPerf, but if Windows 7 is defaulting your window size to 8KiB, then you probably need to figure out how to get Windows 7 to pick a better default TCP window size for all TCP connections.