test_issue_8959_b fails when run from a service (in this case, from a buildslave running as a service).

It appears to count the number of open windows, expecting a non-zero value. But when run as a service, it looks like the return count is (correctly) zero.

FAIL: test_issue_8959_b (ctypes.test.test_callbacks.SampleCallbacksTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "C:\buildslave\trunk.moore-windows\build\lib\ctypes\test\test_callbacks.py",
line 208, in test_issue_8959_b
   self.assertFalse(windowCount == 0)
AssertionError: True is not False

To test windows callbacks, I suggest to use EnumResourceTypes() instead, which is more likely to work in any condition:

def test():
    from ctypes.wintypes import BOOL, HMODULE, LONG, LPARAM
    import ctypes
    EnumResourceTypes = ctypes.windll.kernel32.EnumResourceTypesA
    EnumResTypeProc = ctypes.WINFUNCTYPE(
        BOOL, HMODULE, LONG, LPARAM)

    resource_types = []
    def callback(hModule, typeid, lParam):
        resource_types.append(typeid)
        return True # keep enumerating

    hModule = None   # Main executable
    RT_MANIFEST = 24 # from winuser.h
    EnumResourceTypes(hModule, EnumResTypeProc(callback), None)

    assert RT_MANIFEST in resource_types

> To test windows callbacks, I suggest to use EnumResourceTypes()
> instead, which is more likely to work in any condition:

Unfortunately the proposed test doesn't detect the problem in Python2.7 rc1.
It runs without crashing, even if enumerating the resources in shell32.dll
which contains a lot more stuff than python.exe.

Maybe we should just remove the 'self.assertFalse()' call
in the current test?

I'm not sure what needs to be done to move this forward, but as it's a problem with the test rather than with any actual code, could something be done to avoid masking real issues? I agree with Thomas that in the absence of any other solution, the assertFalse call should be removed pending a better answer.

I can produce a patch, but it's pretty trivial and I'm away from my development PC for a few days, so it'll be a while before I get to it.

In the interests of moving this forward, I've committed the one-line removal of the assertion in r83948. Hopefully that will bring this buildbot back to life.

Fudge-fix committed as r83948, r83958. Not sure what status to set

Certainly the 2.7 branch on my buildbot is now OK (3.x is failing for
other reasons :-()

Hello. I've been finding the way to determine whether
the process is running as service or not. Does this way
work? On my environment, True is returned. I hope False
will be returned in service environment.

http://msdn.microsoft.com/en-us/library/d56de412%28v=VS.80%29.aspx
http://msdn.microsoft.com/en-us/library/ms683225%28VS.85%29.aspx

/////////////////////////////////////////

from __future__ import print_function
import ctypes
from ctypes.wintypes import *

UOI_FLAGS = 1
WSF_VISIBLE = 0x0001

class USEROBJECTFLAGS(ctypes.Structure):
    _fields_ = [("fInherit", BOOL),
                ("fReserved", BOOL),
                ("dwFlags", DWORD)]

def window_station_has_display_surfaces():
    dll = ctypes.windll.user32
    h = dll.GetProcessWindowStation()
    if not h:
        raise ctypes.WinError()
    uof = USEROBJECTFLAGS()
    needed = DWORD()
    res = dll.GetUserObjectInformationW(h,
        UOI_FLAGS, 
        ctypes.byref(uof),
        ctypes.sizeof(uof),
        ctypes.byref(needed))
    if not res:
        raise ctypes.WinError()
    return bool(uof.dwFlags & WSF_VISIBLE)

def main():
    print(window_station_has_display_surfaces())

if __name__ == '__main__':
    main()

Oh, I forgot to mention this. I think it can be possible
to disable "gui" resource on regrtest.py when this function
returns False. (I hope #9931 also can be fixed by this)

I'm planning to try it on buildbot XP-5.

I confirmed window_station_has_display_surfaces() returned False
on XP-5 which is running as service.

See
http://www.python.org/dev/buildbot/builders/x86%20XP-5%203.x/builds/1453/steps/test/logs/stdio
(It ran r85362)

I think this can be closed as fixed/resolved, am I correct?