none
Application Manifest may be ignored in Windows 7 x64 (Ja)

    Question

  • Hi,

    I found a potential compatibility issue in Windows 7 Ultimate x64 (Ja).
    Is this a known-issue?

    You can download the test application and its source code from here.
    http://www.dwahan.net/nyaruru/hatena/manifesttest.zip

    Thanks,


    Summary:
    An application declaring support for Windows 7 in the Compatibility section runs under Windows Vista context when it is launched from 32-bit process.

    Environment:

    • Windows 7 Ultimate x64 RTM (Ja).

    Repro Steps:

    1. Open 32-bit command prompt.
    2. Run the test application (see below) from the 32-bit command prompt.

    Actual Result:

    • DWM is disabled (as expected in the Windows Vista context)
    • The process is running in the Windows Vista context in resource monitor.

    Expected Result:

    • DWM is not disabled (as expected in the Windows 7 context)
    • The process is running in the Windows 7 context in resource monitor.

     

    #define STRICT
    #define WIN32_LEAN_AND_MEAN
    #define NOMINMAX
    #include <windows.h>
    #include <tchar.h>
    #include <comdef.h>
    #include <ddraw.h>
    
    #pragma comment (lib, "ddraw.lib")
    #pragma comment (lib, "dxguid.lib")
    
    _COM_SMARTPTR_TYPEDEF(IDirectDraw7, IID_IDirectDraw7);
    _COM_SMARTPTR_TYPEDEF(IDirectDrawSurface7, IID_IDirectDrawSurface7);
    
    HWND InitWindow(HINSTANCE instance_handle);
    
    int PASCAL _tWinMain(HINSTANCE hinst, HINSTANCE, LPTSTR, int nShowCmd)
    {
      if (SUCCEEDED(::CoInitialize(NULL))) {
        const HWND window_handle = InitWindow(hinst);
    
        if (window_handle) {
          ::ShowWindow(window_handle, nShowCmd);
    
          HRESULT hr = S_OK;
    
          IDirectDraw7Ptr dd;
          hr = ::DirectDrawCreateEx(NULL, reinterpret_cast<VOID**>(&dd), IID_IDirectDraw7, NULL);
          hr = dd->SetCooperativeLevel(window_handle, DDSCL_NORMAL);
    
          IDirectDrawSurface7Ptr front_buffer;
          DDSURFACEDESC2 surface_desc;
          ZeroMemory(&surface_desc, sizeof(surface_desc));
          surface_desc.dwSize = sizeof(surface_desc);
          surface_desc.dwFlags = DDSD_CAPS;
          surface_desc.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE;
          hr = dd->CreateSurface(&surface_desc, &front_buffer, NULL);
    
          {
            DDSURFACEDESC2 lock_desc;
            ZeroMemory(&lock_desc, sizeof(lock_desc));
            lock_desc.dwSize = sizeof(lock_desc);
    
            // DirectDraw Lock
            // Windows 7: Applications manifested for Windows 7 cannot call Lock API in DDRAW to lock 
            //   the primary Desktop video buffer. Doing so will result in error, and NULL pointer for
            //   the primary will be returned. This behavior is enforced even if Desktop Window Manager
            //   Composition is not turned on. Windows 7 compatible applications must not lock the
            //   primary video buffer to render.
            // Windows Vista (default): Applications will be able to acquire a lock on the primary video
            //   buffer as legacy applications depend on this behavior. Running the application turns off
            //   Desktop Window Manager.
            hr = front_buffer->Lock(NULL, &lock_desc, DDLOCK_WAIT, NULL);
            if (SUCCEEDED(hr)) {
              front_buffer->Unlock(NULL);
              ::OutputDebugString(_T("Lock Succeeded\n"));
              if (lock_desc.lpSurface == NULL) {
                ::OutputDebugString(_T("Retrieved pointer is NULL\n"));
              }
            } else {
              ::OutputDebugString(_T("Lock failed\n"));
            }
          }
    
          MSG msg;
          while (::GetMessage(&msg, NULL, 0, 0)) {
            ::TranslateMessage(&msg);
            ::DispatchMessage(&msg);
          }
        }
        ::CoUninitialize();
      }
      return 0;
    }
    
    LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {
      switch (uMsg) {
        case WM_DESTROY:
          ::PostQuitMessage(0);
          break;
      }
      return ::DefWindowProc(hWnd, uMsg, wParam, lParam);
    }
    
    HWND InitWindow(HINSTANCE instance_handle) {
      const TCHAR *class_name = _T("Windows 7 Compatiblity Test");
    
      WNDCLASS wc      = {0};
      wc.style         = 0;
      wc.lpfnWndProc   = WndProc;
      wc.cbClsExtra    = 0;
      wc.cbWndExtra    = 0;
      wc.hInstance     = instance_handle;
      wc.hIcon         = NULL;
      wc.hCursor       = ::LoadCursor(NULL, IDC_ARROW);
      wc.hbrBackground = reinterpret_cast<HBRUSH>(COLOR_WINDOW + 1);
      wc.lpszMenuName  = NULL;
      wc.lpszClassName = class_name;
    
      ::RegisterClass(&wc);
    
      return ::CreateWindowEx(
        0, class_name, TEXT("Test Window"), WS_OVERLAPPEDWINDOW,
        CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
        NULL, NULL, instance_handle, NULL);
    }
    
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <application>
          <!--Windows 7-->
          <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
        </application>
      </compatibility>
    </assembly>
    

    Sunday, October 11, 2009 2:48 PM

Answers

  • Hello NyaRuRu

    The product team confirms that this is a known issue of Windows 7, and the problem is scheduled to be fixed in future. A possible workaround is to always make sure that it is a 64 bit process that starts up your app, but I understand that this workaround may not be elegant enough. If you are blocked by the problem, I suggest that you create a support incident in Microsoft CSS department using the free incidents in your MSDN subscription. (http://msdn.microsoft.com/en-us/subscriptions/bb266240.aspx) Because it's about a known product issue, the incident will be free of charge, i.e. no free incidents will be deducted from your MSDN subscription.

    Regards,
    Jialiang Ge


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by NyaRuRu Tuesday, October 13, 2009 9:44 AM
    Tuesday, October 13, 2009 6:51 AM
    Moderator

All replies

  • Hello NyaRuRu

    Thanks for the report. I can reproduce the problem. I am digging into this issue and will update you as soon as posible.

    Regards,
    Jialiang Ge
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, October 12, 2009 10:17 AM
    Moderator
  • Hello NyaRuRu

    The product team confirms that this is a known issue of Windows 7, and the problem is scheduled to be fixed in future. A possible workaround is to always make sure that it is a 64 bit process that starts up your app, but I understand that this workaround may not be elegant enough. If you are blocked by the problem, I suggest that you create a support incident in Microsoft CSS department using the free incidents in your MSDN subscription. (http://msdn.microsoft.com/en-us/subscriptions/bb266240.aspx) Because it's about a known product issue, the incident will be free of charge, i.e. no free incidents will be deducted from your MSDN subscription.

    Regards,
    Jialiang Ge


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by NyaRuRu Tuesday, October 13, 2009 9:44 AM
    Tuesday, October 13, 2009 6:51 AM
    Moderator
  • Hi, Jialiang,

    Thank you for your prompt response.
    Fortunately, I'm not blocked by this issue but I'll suggest to use MSDN incidents if I see someone is blocked by the same problem.

    Thanks,

    Tuesday, October 13, 2009 10:29 AM
  • What chance is there of this happening in reverse.

    I have verified that Applications written for versions of windows prior to Vista/XP are not disabling DWM like the manifestion of change write ups describe.   The DirectDraw applications in question are supposed to lock the primary buffer, however either this is not occuring due to dwm not disabling or dwm is not disabling because this is not happening (can't verify as to which it is) anyway, the applications effected range from Blizzard's Diablo, Starcraft, Warcraft, to Team 17's Worms Armageddon.. and even in some cases microsofts Age of empires series. I can verify the intended behavior is not occuring as Vsync is meant to be applied when this occurs and instead tearing is visible, not to mention application freezes due to what i assume is a race issue caused by the inability to lock the buffer?
    Saturday, December 05, 2009 8:21 AM
  • FYI, KB978637 is what I saw.  I've verified the patch fixes this issue.

    Thanks,
    Wednesday, February 24, 2010 4:17 PM