ecore_exe_win32: CreateProcess was called with random flags.
authorAdrien Nader <adrien@notk.org>
Sat, 25 Oct 2014 14:35:06 +0000 (16:35 +0200)
committerCedric BAIL <cedric@osg.samsung.com>
Sat, 25 Oct 2014 14:42:00 +0000 (16:42 +0200)
commite9e61718d1dc7d8f012ca4ee4958156ae47aea4f
treedd4e7d8ede36e210d48dcbdbc094e151dc877c45
parenta67feee6eccd343094f135d1427eadbbe0d8de38
ecore_exe_win32: CreateProcess was called with random flags.

CreateProcess() has a flags parameter which is being passed
"run_pri | CREATE_SUSPENDED".

The issue lies in the value of run_pri. It is best explained by the
following code somewhere else in the file:

   switch (run_pri)
     {
      case IDLE_PRIORITY_CLASS:
        return ECORE_EXE_WIN32_PRIORITY_IDLE;

The run_pri variable is supposed to store a value from the win32 API while
it was used to store one from the ecore API.

If I recall correctly, the windows one is equal to 32 and the ecore one to
9999. Meaning 9999 ended up used as flags so let's have a look at what that
actually enabled; the reference is "Process Creation Flags" from MSDN
http://msdn.microsoft.com/en-us/library/ms684863%28v=vs.85%29.aspx .

9999 gives 0x0000270F and this matches
  DEBUG_PROCESS | DETACHED_PROCESS | DEBUG_ONLY_THIS_PROCESS
  | CREATE_SUSPENDED | CREATE_NEW_PROCESS_GROUP | CREATE_SEPARATE_WOW_VDM
  | CREATE_UNICODE_ENVIRONMENT | <0x00002000 matches nothing>

Matches nothing? Weird. Well, maybe. Except that I stumbled upon this define
in the mingw-w64 headers:
  #define CREATE_FORCEDOS 0x2000

Mingw-w64 only has a #define, Wine has nothing (they don't do DOS anyway),
but ReactOS has some code about it:
  https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/kernel32/client/proc.c;hb=f60941f8dc775427af04eb0a3c3e4d38160c7641#l3007

Overall the actual set of flags probably made very little sense and wasn't
working very well. :)

I also noticed the following in the mingw-w64 headers:
  #define INHERIT_CALLER_PRIORITY 0x20000

This should be a better match for what seemed to be the original intent of
inheriting the priority. I haven't tested it and it's only documented on
MSDN for Windows CE and similar so I'm really not sure about what it does.

MSDN however mentions that the child processes will have at most the
"normal" priority by default (same as its parent if the parent has less
than the default one) but I'm under the impression a process can raise its
own priority level... Anyway, "NORMAL_PRIORITY_CLASS" will do for now.

With this change and a couple others, elementary's theme builds properly
on Windows (_on_ Windows). I'll assess the usefulness of the other changes
in my tree over the next few days.

Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
src/lib/ecore/ecore_exe_win32.c