Why will WCF client be disconnected after the connection idles for a long time?

The default receive timeout is 10 minutes, so WCF client will be disconnected after the idle time exceeded that limitation. What can I do if the connection needs to be kept alive?

Solution #1 - Server provides a dummy operation for client calls it regularly to let it not idle.

Solution #2 - Enable reliableSession and set receiveTimeout and inactivityTimeout to "infinite" in both the client and server.

The configuration snippet may like the following:

<system.serviceModel>
  <bindings>
    <wsHttpBinding>
      <binding name="WSHttpBinding" receiveTimeout="infinite">
        <reliableSession inactivityTimeout="infinite" enabled="true" />
      </binding>
    </wsHttpBinding>
  </bindings>
  <services>
  ...
  </services>
  ...
</system.serviceModel>

You can get more detail explanation in the following reference link.

Reference in MSDN:
Binding.ReceiveTimeout Property

Reference in Paulo Reichert's Blog
WCF Reliable Sessions Puzzle

How To: Detect Windows Media Center Version

If your program is depending on a specified version of Windows Media Center, just try the following code to identify Windows Media Center versions.

Sample Code:

//
// Get Windows Media Center version from registry
// Function return false if no media center is installed on your windows
//
// Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center
// Registry value name: Ident
// Registry value data type: REG_SZ
//
bool GetMediaCenterIdent(wstring& wstrIdent)
{
  bool bRtn = false;

  HKEY hkResult = NULL;
  LONG lRetOpen = ::RegOpenKeyExW(
    HKEY_LOCAL_MACHINE,
    L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Media Center",
    NULL, KEY_READ, &hkResult);

  if(lRetOpen == ERROR_SUCCESS)
  {
    WCHAR wszRet[2048] = {0};
    DWORD type_1 = REG_SZ;
    DWORD cbData = sizeof(wszRet);

    LONG lRetQuery = ::RegQueryValueExW(hkResult, L"Ident", NULL,
      &type_1, (unsigned char *)wszRet, &cbData);
    if(lRetQuery == ERROR_SUCCESS)
    {
      wstrIdent = wszRet;
      bRtn = true;
    }
  }

  if(hkResult)
  {
    ::RegCloseKey(hkResult);
    hkResult = NULL;
  }

  return bRtn;
}

Ident value v.s Windows Media Center version

< 2.7 = Windows XP Media Center Edition 2002
2.7 or 2.8 = Windows XP Media Center Edition 2004
3.0 = Windows XP Media Center Edition 2005
3.1 = Windows XP Media Center Edition 2005 with Update Rollup 1
4.0 = Windows XP Media Center Edition 2005 with Update Rollup 2
5.0 = Windows Vista
5.1 = Windows Vista with Media Center TV Pack 2008
6.0 = Windows 7

Reference on MSDN:
Identifying Windows Media Center Versions

How To: Determine whether a 32-bits application is running on Windows 64-bits platform

WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows.

Sample Code:

bool IsRunningOnWow64()
{
  BOOL bIsWow64 = FALSE;

  BOOL (WINAPI *fnIsWow64Process)(HANDLE, PBOOL);
  fnIsWow64Process = (BOOL(WINAPI*)(HANDLE, PBOOL))::GetProcAddress(
    ::GetModuleHandleW(L"kernel32"), "IsWow64Process");

  if(NULL != fnIsWow64Process)
    fnIsWow64Process(GetCurrentProcess(), &bIsWow64);

  return bIsWow64 ? true : false;
}

Reference on MSDN:
IsWow64Process Function

Read/Write Windows Registry on Windows 64-Bits Platforms

On Windows Vista 64-bits, there's a 32-bits emulator called WOW64 for 32-bits applications. A 32-bits application running on WOW64 uses the registry redirector, because the 64-bit version of an application may use different registry keys and values than the 32-bit version.

For 32-bits application:
On 64-bit platforms, it runs on WOW64 and accesses 32-bit registry (inside Wow6432Node).

For 64-bits application:
On 64-bit platforms, it runs natively and accesses 64-bit registry (not inside Wow6432Node).

Whatever, you can explicitly indicate which version of registry you want to access, just use RegOpenKeyEx function with KEY_WOW64_32KEY or KEY_WOW64_64KEY in the desired access rights parameter.

Example: A 32-bit application running on WOW64 accesses the 64-bit registry

HKEY hkResult = NULL;
REGSAM samDesired = KEY_READ | KEY_WOW64_64KEY;
LONG lRetOpen = ::RegOpenKeyExW(
  HKEY_LOCAL_MACHINE,
  L"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Media Center",
  NULL, samDesired, &hkResult);

Reference on MSDN:
32-bit and 64-bit Application Data in the Registry

Where can I find the list of installed ACM codecs on Vista?

It has moved to a strange place on Vista. Do the following steps to see the list:

1. Click on Windows Media Player 11 -> Help -> About -> Technical Support Information

2. It will generate "Support Information for Windows Media Player" and look under "Audio Codecs".

You can also see the information about windows media player binaries and the list of video codecs.

Reference:

Moving to Vista-- Part D'oh

error C3861: 'CoInitializeEx': identifier not found, even with argument-dependent lookup

You may get the following errors when trying to call CoInitializeEx(NULL, COINIT_MULTITHREADED).

 

error C2065: 'COINIT_MULTITHREADED' : undeclared identifier

error C3861: 'CoInitializeEx': identifier not found, even with argument-dependent lookup

The article in MSDN says "You must include the #define _WIN32_DCOM preprocessor directive at the beginning of your code to be able to use CoInitializeEx."

Look at the code snap in ObjBase.h:

#if (_WIN32_WINNT >= 0x0400 ) || defined(_WIN32_DCOM) // DCOM

WINOLEAPI  CoInitializeEx(IN LPVOID pvReserved, IN DWORD dwCoInit);

WINOLEAPI  CoGetCallerTID( LPDWORD lpdwTID );

#endif // DCOM

So, you need to follow the above rule if you want to call CoInitializeEx, of course you also need to include <objbase.h>.

Reference in MSDN:

CoInitializeEx

Why is the media sample upside down after convert its buffer data from YUV to RGB?

Question

I converted the buffer of a media sample from YUY2 to RGB24 pixel by pixel, and then I got a upside-down image. What's wrong with it?

Answer

The definition of the biHeight field of BITMAPINFOHEADER depends the the biCompression field of BITMAPINFOHEADER.

If the bitmap is uncompressed RGB format, the positive biHeight value means the image is bottom-up image; if the bitmap is one of YUV formats such as YUY2, UYVY, and YV12, the image is top-down oriented and the sign of biHeight value must be ignored.

So, I need to do a vertical flip to get a correct image after convert buffer data from YUY2 to RGB24.

You can get more detail information in FOURCC.org: Bitmap Orientation and biHeight