On 6/3/16 8:03 AM, Yang Luo wrote:
> Hi list,
>
> I made a post on this list several months ago about compile errors of
> Wireshark on Windows:. http://seclists.org/wireshark/2015/Dec/125
>
> The errors are something like:
>
> 91>J:\github_repos\wireshark-win64-libs\gtk2\include\glib-2.0\gobject/gsignal.h: warning C4819: The file contains a character that cannot be represented in the current code page(936). Save the file in Unicode format to prevent data loss (J:\github_repos\wireshark\ui\gtk\about_dlg.c)
> [J:\github_repos\wsbuild64\ui\gtk\gtkui.vcxproj]
>
> 91>J:\github_repos\wireshark-win64-libs\gtk2\include\glib-2.0\gobject/gsignal.h: warning C4819: The file contains a character that cannot be represented in the current code page(936). Save the file in Unicode format to prevent data loss (J:\github_repos\wireshark\ui\gtk\addr_resolution_dlg.c)
> [J:\github_repos\wsbuild64\ui\gtk\gtkui.vcxproj]
>
>
> I didn't actually solve this issue at that time. These days I revisited
> this issue. And I tried Graham's method of using PowerShell
> (http://seclists.org/wireshark/2015/Dec/127) but with no luck.
>
> I also tried to switch my CMD session to Unicode by running "chcp 65001"
> based on this
> post: http://stackoverflow.com/questions/14109024/how-to-make-unicode-charset-in-cmd-exe-by-default,
> but also the same errors.
>
> Finally I found a workaround. I went to "Control Panel" -> "Region" window
> -> "Administrative" tab -> Change system locale.." button, then switched
> the locale from Chinese to English, then rebooted. And the compile went
> through smoothly this time.
> But in English locale, all my ANSI programs including .txt files with
> Chinese characters are broken. They all show messy code. So this is only a
> temporary hack.
>
> I wonder how other non-English Windows users compile Wireshark? Is there a
> better solution to solve this issue? I'm using Win10 x64 system.
gsignal.h has a UTF-8 ellipsis (hex e2, 80, a6) at line 516. For now you
should be able to remove it (it's in a comment) or re-save gsignal.h with a
UTF-8 BOM. We should probably do the same thing in the Win32 and Win64 GTK+
bundles.