Globally, yes. I think parent was talking about the US market where OS X is slightly more prominent and according to StatatsCounter surpasses the market share of Windows XP and Windows 10 combined. Microsoft still controls 3/4 of the desktop market according to these stats, but that would probably not qualify as monopoly anymore.
Is TLS_DHE_RSA_WITH_AES_256_CBC_SHA with a 768-bit group less secure than TLS_RSA_WITH_AES_256_CBC_SHA? Doesn't DHE just add an extra perfect forward secrecy layer to the non-DHE cipher suite without changing anything else?
If you can break the DH exchange in the DHE ciphersuite, you can recover the session key and decrypt the traffic. That can be a complete break of that particular session without any need to break the server's long-term RSA key. It's quite possible to have a situation where the TLS_RSA... used a 2048-bit RSA key while the TLS_DHE... used a 1024-bit (or worse) DH parameter. In that case an attacker could have an easier time breaking the 1024-bit discrete logarithm problem compared to breaking the 2048-bit RSA problem.
To answer your question more directly, the DHE does use a different form of key establishment which uses different algorithms, different parameters, and potentially different parameter sizes. The forward secrecy is a desirable property in itself, but under some circumstances implementations might use weaker cryptographic parameters in conjunction with it.
(Daniel Kahn Gillmor first told me about this problem; in TLS_DHE_RSA the RSA key is used for authentication of the DH key establishment -- to stop someone from doing an active MITM attack -- but not for the key establishment itself. In TLS_RSA the RSA key is used directly for key establishment. Thus when you use TLS_DHE_RSA, your security levels may be limited by the weakest link mechanism that you rely on for security, which could conceivably be the DH exchange, depending on other features of your configuration and environment. A number of folks have been aware of that particular problem to some extent for a while and even discussed it at, for instance, the IETF TLS working group, but this paper takes things considerably further and makes the problems really concrete.)
Edit: upthread you can find a link to pbsd and AlyssaRowan discussing forms of the problem half a year ago, including the fact that you can get less security from weak DH parameters than you would have gotten from strong RSA parameters, despite the presence of forward secrecy. In some settings there cost trade-offs are possible for attackers between breaking particular sessions vs. breaking all traffic to a particular service.
It depends on the size of the RSA key. With LogJam TLS_DHE_RSA_WITH_AES_256_CBC_SHA is likely weaker; with TLS_RSA_WITH_AES_256_CBC_SHA the client essentially makes up the shared secret, encrypts it using RSA and sends it to the server [1]. That exchange simultaneously establishes the session key and authenticates the server.
With DHE, the Diffie-Helman exponent math is what establishes the shared secret, and if the DH prime is broken, then the shared secret can be derived by a MITM. The public DH parameters are sent in the plain, so a MITM can just observe them. A hash of those parameters is signed using RSA, so they can't be changed, but that's not important to defeating forward secrecy.
So if if the RSA key is bigger than ~1024 bits, then TLS_DHE_RSA_WITH_AES_256_CBC_SHA is likely weaker.
[1] There is some further derivation done to get the actually session key, but that's not relevant here.
Yes, Bitlocker. There is something called "Device Encryption" in every edition, but it has some rather unusual hardware requirements (TPM and connected standby).
