1. 16 Oct, 2011 1 commit
  2. 15 Oct, 2011 2 commits
    • Matthias Clasen's avatar
      Move environment-related functions into their own files · 7a9987d3
      Matthias Clasen authored
      gutils.[hc] is a bit of a grab bag, so lets start cleaning
      things up by moving all the environment-related functions
      into separate genviron.[hc] files.
      
      The private _g_getenv_nomalloc has been moved to its sole caller.
      7a9987d3
    • Dan Winship's avatar
      gutils: Add functions for working with environment arrays · 409d9314
      Dan Winship authored
      When spawning a child process, it is not safe to call setenv() before
      the fork() (because setenv() isn't thread-safe), but it's also not
      safe to call it after the fork() (because it's not async-signal-safe).
      So the only safe way to alter the environment for a child process from
      a threaded program is to pass a fully-formed envp array to
      exec*/g_spawn*/etc.
      
      So, add g_environ_getenv(), g_environ_setenv(), and
      g_environ_unsetenv(), which act like their namesakes, but work on
      arbitrary arrays rather than working directly on the environment.
      
      http://bugzilla.gnome.org/show_bug.cgi?id=659326
      409d9314
  3. 13 Oct, 2011 1 commit
  4. 04 Oct, 2011 3 commits
  5. 02 Oct, 2011 1 commit
  6. 27 Sep, 2011 1 commit
  7. 21 Sep, 2011 1 commit
    • Allison Karlitskaya's avatar
      Rework GMutex and GCond APIs · 80730bc7
      Allison Karlitskaya authored
      Do a substantial rework of the GMutex and GCond APIs.
      
       - remove all of the macro indirection hackery which is no longer needed
         since we dropped support for switchable thread implementations
      
       - expose the structure types and add G_MUTEX_INIT and G_COND_INIT
         static initialiser macros
      
       - add g_mutex_init() and g_mutex_clear() for use when embedding GMutex
         into another structure type and do the same for GCond as well
      
       - avoid infinite recursion hazards by ensuring that neither GCond or
         GMutex ever calls back into any other part of GLib
      
       - substantially rework the Windows implementation of GCond and GMutex
         to use the SRWLock and CONDITION_VARIABLE APIs present on Windows
         2008/Vista and later, emulating these APIs on XP
      80730bc7
  8. 09 Sep, 2011 1 commit
  9. 29 Aug, 2011 1 commit
    • Matthias Clasen's avatar
      Spelling fixes · 1b28408b
      Matthias Clasen authored
      Spelling fixes in comments and docs, provided by
      Kjartan Maraas in bug 657336.
      1b28408b
  10. 18 Jul, 2011 1 commit
  11. 09 Jun, 2011 2 commits
  12. 07 Jun, 2011 2 commits
  13. 31 May, 2011 1 commit
  14. 15 Mar, 2011 2 commits
  15. 13 Mar, 2011 1 commit
  16. 19 Feb, 2011 1 commit
  17. 28 Jan, 2011 1 commit
  18. 05 Jan, 2011 2 commits
  19. 29 Nov, 2010 1 commit
  20. 06 Nov, 2010 1 commit
  21. 04 Nov, 2010 1 commit
  22. 29 Oct, 2010 1 commit
  23. 18 Oct, 2010 1 commit
    • Tor Lillqvist's avatar
      Use CSIDL_LOCAL_APPDATA on Windows · 9d80c361
      Tor Lillqvist authored
      Make g_get_user_data_dir() return the CSIDL_LOCAL_APPDATA folder on
      Windows, and not CSIDL_PERSONAL. On Windows 7, that corresponds to the
      subfolders AppData\Local vs. Documents under the profile ("home")
      folder. This matches what Qt does, for instance, and has been widely
      requested.
      
      Also make g_get_user_config_dir() return this and not the (roaming)
      CSIDL_APPDATA folder. The reason for this change is that it would be
      surprising and hard to justify if g_get_user_data_dir() returned the
      local application data folder while g_get_user_config_dir() would
      return the roaming one. Nothing in the function names or the XDG specs
      suggests that any roaming vs. local dichotomy would be involved.
      
      Document the new semantics and the fact that these two functions now
      return the same directory on Windows.
      
      Note that in reality, code that really truly wants to support Windows
      as well as possible probably will not use these GLib functions anyway,
      but Win32 APIs directly to be sure what it is doing...
      
      Should hopefully satisfy complaints in bug #620710 and related bugs.
      9d80c361
  24. 06 Sep, 2010 1 commit
  25. 05 Sep, 2010 1 commit
  26. 02 Sep, 2010 1 commit
    • Tor Lillqvist's avatar
      Recuce DLL hijack risk on Windows · 6ddef375
      Tor Lillqvist authored
      Don't call LoadLibrary() on shell32.dll or kernel32.dll. kernel32.dll
      is always loaded. Shell32.dll is also already loaded as glib links to
      functions in it. So just call GetModuleHandle() on them.
      
      For mlang.dll in win_iconv.c and winhttp.dll in gwinhttpvfs.c, always
      try loading them from a complete path, from the Windows system
      directory.
      
      Use the "tool help" API to enumerate modules in gmodule-win32.c. It is
      present in all Windows versions since Windows 2000, which is all we
      support anyway. Thus no need to look that API up dynamically. Just
      link to it normally. We can bin the fallback code that attempts to use
      the psapi API.
      6ddef375
  27. 26 Aug, 2010 1 commit
  28. 07 Jul, 2010 1 commit
  29. 10 Jun, 2010 1 commit
  30. 06 Jun, 2010 4 commits