I can do that, yes, but before I do, you should know that using DLL was just a way for me to reproduce the issue on demand. gtsdll or mp3 ID3 tags are definitely NOT the cause of the problem, or it's a different issue. There is a log channel I'm in where a bot reports any changes made in a database of a website, often the changes include titles and names in Japanese characters. So what I did was change font script from Japanese to Western in that channel and scrolled up until mirc crashed. During that time the following non-ascii characters were on screen: "ギルバート・ケント", "魔星降臨" and "Le siècle de l`enfer". I later forced that same bot to report the same words again to see which of them makes mirc crash, "魔星降臨" and "Le siècle de l`enfer" didn't, but right after "ギルバート・ケント" appeared, mirc crashed. These are all katakana characters, save for the middle dot and the long vowel mark ー. I checked if there were any characters specifically that would make it crash, but none of them displayed alone did. Eventually I narrowed it down to バー, that made mirc crash (while ート didn't). However, when I entered that text myself or had someone else type it to channel, it didn't cause any crashes. What's the difference? Colour codes. DLL and the bot both output with colour codes. I can type in "(ctrl+k 3)バー (ctrl+k 7)bla" or "(ctrl+k 3)バ・ (ctrl+k 7)bla" and crash myself and so can anyone else. It only seems to work with certain character combinations, which I suppose happen often enough if you are in the right channels. This would explain the crashes with DLL and fullwidth characters, when encoding fails and it displays garbage, there are many non-standard characters there and combined with colour coding, they'll make mirc crash. But you still need to have Windows 7 (not sure if it matters if it's 32 or 64 bit), Japanese locale and mirc font script set to Western (or probably anything unable to properly handle certain characters).
Last edited by defianze; 23/03/10 06:28 PM.
