We need to use g_content_type_get_mime_type() to look up the mime type of
the file from the registry on the content type that was acquired on
Windows, as g_file_info_get_content_type() does not acquire the
file mime type (unlike on *NIX).
g_content_type_get_mime_type() on *NIX is more or less an no-op as it
simply returns the g_strdup()-ed version of the passed-in content type.
This will enable the resources test to pass on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
==1265== 84 (8 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 793 of 827
==1265== at 0x4029467: calloc (vg_replace_malloc.c:467)
==1265== by 0x408479B: standard_calloc (gmem.c:104)
==1265== by 0x4084846: g_malloc0 (gmem.c:189)
==1265== by 0x4084B2D: g_malloc0_n (gmem.c:385)
==1265== by 0x4228A98: g_resource_load (gresource.c:253)
==1265== by 0x804A56D: test_resource_registred (resources.c:198)
==509== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 828 of 837
==509== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==509== by 0x4084724: standard_malloc (gmem.c:85)
==509== by 0x40847C7: g_malloc (gmem.c:159)
==509== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==509== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==509== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==509== by 0x804A48C: test_resource_data (resources.c:174)
==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204== by 0x4228D38: g_resource_open_stream (gresource.c:363)
==28778== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 842 of 863
==28778== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28778== by 0x4084724: standard_malloc (gmem.c:85)
==28778== by 0x40847C7: g_malloc (gmem.c:159)
==28778== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==28778== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==28778== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==28778== by 0x804C2B1: test_uri_query_info (resources.c:435)
==28318== 38 (12 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 613 of 865
==28318== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28318== by 0x4084724: standard_malloc (gmem.c:85)
==28318== by 0x40847C7: g_malloc (gmem.c:159)
==28318== by 0x4084AB4: g_malloc_n (gmem.c:361)
==28318== by 0x4229599: g_resources_enumerate_children (gresource.c:806)
==28318== by 0x804B39E: test_resource_registred (resources.c:283)
==27820== 31 bytes in 1 blocks are definitely lost in loss record 587 of 866
==27820== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27820== by 0x4084724: standard_malloc (gmem.c:85)
==27820== by 0x40847C7: g_malloc (gmem.c:159)
==27820== by 0x4084AB4: g_malloc_n (gmem.c:361)
==27820== by 0x409D6A1: g_strdup (gstrfuncs.c:356)
==27820== by 0x4069FF7: g_get_current_dir (gfileutils.c:2544)
==27820== by 0x804BCA7: test_resource_module (resources.c:370)
With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
