Compiling as either MultiByte or Unicode should not make a difference. That setting only affects the use of unannotated Windows API, but glib/gtk should already be using the W forms of those API (with an intermediate utf8<->utf16 step). MultiByte is probably there in the project files because it's the default for new projects. Changing it should make no difference. If you find something that breaks because it uses the unannotated form of a Windows API on a utf8 string expecting to get the A version, this would break when you changed it to Unicode since it would now try to run the W version on a utf8 string. If you find such a case, I think you should file a bug for it. (That said, I don't see the point of changing this. In the best case, you would find a bug where an A version of some API is being called with a utf8 string instead of W version with utf8<->utf16 conversion step. In the worst case, you'll achieve nothing.) -Arnav On Tue, Feb 17, 2015 at 11:09 AM, John Emmas <john@xxxxxxxxxxxxxxxxxx> wrote: > On 17/02/2015 18:36, codekiddy wrote: >> >> (even Fan's projects which I'm using) which were >> set to Multibyte character set are now set to *unicode character set* >> >> Can you tell what consequnces could that have? >> I'm starting to think it would be better to re-compile everything with >> Multibyte instead because I have bad problems with GTK+ on run-time, there >> should be reason why those projects found in official sources are all set to >> Multibyte?? >> > > Hi there, > > As someone else who builds a lot of GTK related stuff with MSVC, my > experience has been that the most commonly used Unicode format (for GTK+ > based projects) tends to be UTF-8. UTF-8 can only be represented easily > when you select the multibyte character set. Windows Unicode uses precisely > 2 bytes to represent each character. But UTF-8 can use anywhere between 1 > byte and 4 bytes (in fact, I think the early implementations could use up to > 6 bytes!) It probably makes things a lot easier too for Glib::ustring. > > Hope that explains it. > > John > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
