(Re-adding codekiddy and Fan to To:) On Tue, Feb 17, 2015 at 11:18 AM, Arnavion <arnavion@xxxxxxxxx> wrote: > 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
