<i>but the backwards compatibility guarantees make Windows an absolute joy compared to Linux if you want to write software with a long service lifetime</i><p>The linux user-space ABI is extremely stable. I think the one thing that would frustrate the development of long service lifetime software on linux would just be library availability on various distros, but the actual operating environment presented by the kernel and the image loader for user-space software on linux is very, very stable.<p><i>And all future Win32 implementations must be 100% binary compatible with previous ones</i><p>And no one is asking microsoft to break the windows user-space ABI. Adding a new, sufficiently-tested, MBCS codepage would have no impact at all on existing windows software. None whatsoever. Other than to make localization a whole lot easier. And compared to the cost of building in a whole new csrss-level subsystem like the one Microsoft just built in to windows last month (linux), it&#x27;s probably a lot safer and easier to test.<p>Working in this world myself, windows developers become philosophical when discussing localization. &quot;Someday, we&#x27;ll turn on UNICODE,&quot; &quot;We really should be using TCHAR&quot; (as if that silly thing would fix anything at all), &quot;Shouldn&#x27;t we really be using wstring?&quot;<p>OSX, Linux, and mobile developers just do it. It&#x27;s mostly a solved problem on those platforms.<p><i>The decision to stick with 16-bit Unicode is an engineering tradeoff.</i><p>It&#x27;s a cost tradeoff - Microsoft doesn&#x27;t want to spend the developer and testing time adding a UTF-8 codepage.