{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibktam7h2t4zqk2urcrwr2bdvmmrteyo7y3kv2l6xyowqvhrsi4i4",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mikyh3zbyus2"
  },
  "path": "/viewtopic.php?t=33205&p=271760#p271760",
  "publishedAt": "2026-04-03T05:19:25.000Z",
  "site": "http://forum.palemoon.org",
  "tags": [
    "http://developer.palemoon.org/build/windows/"
  ],
  "textContent": "> To be fair on you, we don't really support Windows versions < 10 as build environment. We never supported VS2019 either (which seems to be the most recent Visual Studio that Windows 7 supports). http://developer.palemoon.org/build/windows/\n>\n> So don't be harsh on yourself!\n\nI appreciate the encouragement.\n\nThankfully, it turned out this was actually a 32-bit Windows build issue I overlooked, and a one-line fix that had nothing to do with Windows 7 at all. Which meant I didn't have to setup a Windows 7 build environment to reproduce.\n\nSo that means the only issue remaining to be solved is actually why he can't see Cyrillic characters in his compiler output anymore, and I already have a working theory on that, because I suspect that's also not limited to Windows 7.\n\nEssentially, the problem is this. MSYS1 itself appears to be a pure ASCII environment (at least that's what it is looking like so far). Just tested in all kinds of ways, couldn't get any non-ASCII characters to print normally inside MSYS1 no matter what I set LANG, LC_ALL, or any of that stuff to. A lot of the issues with that were papered over because I'm a native English speaker (and you can guess what that means for the triple ASCII/CP1252/UTF-8 safe zone/blindspot) and thus only noticed the UnicodeDecodeErrors themselves, and basically just fixed/bypassed them well enough to get Python 3 to \"shut up,\" but didn't realize what I had to do to make it actually display correctly for speakers of other languages.\n\nAnd my research so far has come up with this theory. That basically, Python 2 was able to (easily, as a quirky result of using ASCII bytestrings as its default string mode) bypass MSYS1 completely and somehow send raw bytes to the Windows ConHost that MSYS1 is running in. Because if MSYS1 \"sees them,\" it won't know what to do with anything that's not either ASCII or a Latin-1 like encoding that can be degraded gracefully to ASCII (much like the default behavior of... either XTerm or Konsole, don't remember which... on an old Linux distro from the early 2000s). On Python 3... this is still possible, but not very easy because you have to have actual decoded text to perform string operations at all, and so you have to make sure most internal consumers within the build system get strings as text, but that whatever you have is bytes by the time it hits ConHost so MSYS1 doesn't intercept it and decode to ASCII. I think I have located the main place where the text from something like compiler output is being captured and printed to the console as text (which we can't have on MSYS1), and possibly fixed it... though it's kinda hard to tell in an English CP1252 environment whether my fix did anything.\n\n* * *",
  "title": "Platform Development • Re: I created a Python 3 port of UXP out of boredom...",
  "updatedAt": "2026-04-03T05:19:25.000Z"
}