https://bugzilla.gnome.org/show_bug.cgi?id=750573

https://bugzilla.gnome.org/show_bug.cgi?id=734888

* Only check __OBJECT_ATTRIBUTES_DEFINED and __UNICODE_STRING_DEFINED
  on MinGW (MSVC doesn't have these)
* MSVC: disable:4005 when including windows.h and ntstatus.h
* Move NTAPI cconv into the parens with the NtQueryKeyFunc
* Fix return values in some functions

https://bugzilla.gnome.org/show_bug.cgi?id=734888

https://bugzilla.gnome.org/show_bug.cgi?id=734888

https://bugzilla.gnome.org/show_bug.cgi?id=666831

- On first call scan the registry, collect information about URI protocols,
  file extensions, applications and handlers, store that as a set of
  interconnected structures in several hash tables
- Watch the registry keys, re-scan the registry when any one of them changes.

https://bugzilla.gnome.org/show_bug.cgi?id=666831

https://bugzilla.gnome.org/show_bug.cgi?id=738504

This is now possible with g_settings_schema_list_keys().

https://bugzilla.gnome.org/show_bug.cgi?id=740308

Stop using g_settings_list_keys() because soon it will be deprecated.

https://bugzilla.gnome.org/show_bug.cgi?id=740308

Use the newly added g_settings_schema_list_keys() API instead of
g_settings_list_keys() in order to list keys.

Doing this allows the 'list-keys' command to work without creating a
GSettings object, which is more efficient.  It also means that we don't
have to provide a (meaningless and ignored) path when listing keys on
relocatable schemas.

While we're at it, update the 'range' command not to require creation of
a GSettings object, in a similar way.

https://bugzilla.gnome.org/show_bug.cgi?id=740308

The list of keys in a GSettings object depends entirely on the schema,
so it makes sense to expose this API there.

Move the implementation out of gsettings.c and into gsettingsschema.c,
replacing the earlier with a simple call to the new location.

We don't do the same for children because the children can change.

https://bugzilla.gnome.org/show_bug.cgi?id=740308

https://bugzilla.gnome.org/show_bug.cgi?id=747146

https://bugzilla.gnome.org/show_bug.cgi?id=747146

Cancellation of GPollFileMonitor is now handled correctly (in the sense
that no further signals will follow) but let's be extra paranoid and
disconnect our handler anyway, for good measure.

https://bugzilla.gnome.org/show_bug.cgi?id=739424

The new rules of GFileMonitor says that users should expect to see a
CHANGES_DONE_HINT following a CREATED as well as CHANGED.

https://bugzilla.gnome.org/show_bug.cgi?id=739424

GPollFileMonitor emits CHANGES_DONE_HINT after CHANGED signals, but it
doesn't check to ensure that the file monitor wasn't cancelled before it
does that.

If the original signal caused the monitor to be unreffed, cancelled and
destroyed, we would still end up emitting an extra signal on it.

Avoid that by checking first for cancellation.

https://bugzilla.gnome.org/show_bug.cgi?id=739424

Removed all mentions of GLib file name encoding referring to
the environment strings. The env var content has no defined relation
to GLib's notion of filename encoding, or any encoding whatsoever.
It would be wrong to pass all UTF-8 strings through
g_filename_from_utf8() in order to put them into the environment,
for one thing.

https://bugzilla.gnome.org/show_bug.cgi?id=738185

DBus has recently introduced new message flag
DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION, which tells that
caller is willing to wait for unspecified amount of time for the call
to return, as the service may perform interactive authorization (e.g.
using polkit).

https://bugzilla.gnome.org/show_bug.cgi?id=739616

In order to maintain a logical stream of events, we need to make sure we
flush and queued change notifications before responding to any requests
for information from clients.

If we don't do this, it's possible that we emit an 'add' event that was
queued at the time of a 'DescribeAll' call _after_ the reply to that
call (which already contained the description of the new action).

In practice, this is not only logically incorrect, but it can also cause
problems.  If a change to action 'state' or 'enabled' occurs after the
DescribeAll but before the signal has been dispatched, it will be
ignored because an 'add' signal is already pending.  When that add
signal is sent, it will contain the correct data, but the receiver will
ignore it because it already saw the action in the DescribeAll reply.

https://bugzilla.gnome.org/show_bug.cgi?id=749693

.get_action_state_type() does not return a copy.

We remove the annotation entirely because it is evident from the 'const'
on the return type.

https://bugzilla.gnome.org/show_bug.cgi?id=730168

Now that we are using inode/directory for directories, handle
this case in g_content_type_get_mime_type() as well.

This is a hack for GLocalFileInfo to correctly get icons for directories.
Without this change content type for any W32 directory is NULL
(because there's no registry entry for "inode/directory" by default,
and in any way there's no file extension that means "directory" to put there),
and GLocalFileInfo uses content type to grab icons.

https://bugzilla.gnome.org/show_bug.cgi?id=748727

The code here was returning gtk-directory and similar names as
fallback, with a comment claiming that these are 'builtin gtk'.
But they aren't, anymore, so just return the standard names.

"0." at the beginning of a line is interpreted as a numeric list
by the gtk-doc markdown parser, so be careful to avoid that.

https://bugzilla.gnome.org/show_bug.cgi?id=750399

Pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=750399

https://bugzilla.gnome.org/show_bug.cgi?id=741788

Prevents race condition in function g_io_condition_get_type by ensuring
that the initialization section for 'etype' is executed only once
during a program's life time, and that concurrent threads are blocked
until initialization completes. This changes solves the problem that
concurrent threads could execute the check 'etype == 0' before any of
them had initialized it, which in turn meant that multiple threads
would then attempt to register the "GIOCondition" type.

https://bugzilla.gnome.org/show_bug.cgi?id=750386

https://bugzilla.gnome.org/show_bug.cgi?id=750369

Avoiding checking for INVERT_BOOLEAN each and
instead choose the correct function in constructed().

https://bugzilla.gnome.org/show_bug.cgi?id=750369

It isn't actually doing anything, instead it is
being managed without actually being used.
This has the result that GBinding is now more
thread-safe.

https://bugzilla.gnome.org/show_bug.cgi?id=745013

https://bugzilla.gnome.org/show_bug.cgi?id=750344

This code used to look at the SCM_CREDENTIALS and ignore every message
not from uid 0. However, when user namespaces are in use this does not
work, as if uid 0 is not mapped you get overflowuid instead. Right now
this means we ignore all messages in such user namespaces and glib
apps hang on startup.

We can't look at pids either, as pid 0 is returned for processes
outside your pid namespace.

Instead the correct approach is to look at the sending sockaddr and
if the port id (nl_pid) is zero, then its from the kernel.

Source:
http://lists.linuxfoundation.org/pipermail/containers/2015-May/036032.html

https://bugzilla.gnome.org/show_bug.cgi?id=750203

Instead of just dropping address types that we're not specifically
handling we return a GNativeSocketAddress which is just a dummy
container for the stuct sockaddr.

https://bugzilla.gnome.org/show_bug.cgi?id=750203

sysconf() is documented as returning -1 if it can't determine
a minimum thread stack size. Check for this case before using
the return value.

https://bugzilla.gnome.org/show_bug.cgi?id=739122