Getting Processor architecture in x86 and x64 bit platform.

 

GetSystemInfo provides the basic system information and processor architecture of the underlying platform. This API can be used successfully in both x64 and x86 platform. But, under 64-bit WIndows, we can run 32 bit Applications( WOW64). If a WOW64 process call GetSystemInfo API, it will return the processor architecture as x86. Of course it should be the way, this API act otherwise there could compatibility problems may arise and application could act weird and show undefined behavior.

If the WOW64 process want to know the original platform it’s running, it must call GetNativeSystemInfo. When we’ve to use this? I’ve a realworld example. When we spawn process explorer (procexp.exe, it realize the underlying platform and create another exe procexp64.exe (64bit version) to iterate all process information in the system. Note that the GetNativeSystemInfo need to be called only if you 32bit application wants to run under 64 bit platform and need to care about the true underlying platform. In all other cases, call GetSystemInfo, which works across platforms uniquely. See the snippet below

#include "stdafx.h"
#include 

void displayPrcessorInfo( SYSTEM_INFO &stInfo )
{
        switch( stInfo.wProcessorArchitecture )
        {
        case PROCESSOR_ARCHITECTURE_INTEL:
                printf( "Processor Architecture: Intel x86\n");
                break;
        case PROCESSOR_ARCHITECTURE_IA64:
                printf( "Processor Type: Intel x64\n");
                break;
        case PROCESSOR_ARCHITECTURE_AMD64:
                printf( "Processor Type: AMD 64\n");
                break;
        default:
                printf( "Unknown processor architecture\n");
        }
}

int _tmain(int argc, _TCHAR* argv[])
{
        SYSTEM_INFO stInfo;
        GetSystemInfo( &stInfo );
        displayPrcessorInfo(stInfo);

        GetNativeSystemInfo( &stInfo );
        displayPrcessorInfo(stInfo);
        return 0;
}

To know more about the different processor architecture in abstract level, please do check one of my previous posts.

 

How to restrict Window Movement?

 

This is beginner level post. How we can make a Window immovable?

Roughly we’ve two methods to do this.

Method #1. Handle the NCHITTEST message and ignore while user click on the caption area (Titlebar). This method doesn’t work well in Windows 7/Vista if Aero is enabled. This method works with any type of Window having titlebar. The disadvantage of this method is , the user will still able to move using keyboard, if system menu is available.

 

LRESULT CMoveWindowSampleDlg::OnNcHitTest(CPoint point)
{
    UINT nHitTest = CDialogEx::OnNcHitTest(point);

    if( HTCAPTION == nHitTest )
        nHitTest = HTNOWHERE;

    return nHitTest;
}

Method #2 – Remove the Move command from System Menu (Works with windows having system menu stle (WS_SYSMENU) ). The the Move command in the system menu will be removed in this case. Windows will internally disable the movement of this kind of Windows.

BOOL CMoveWindowSampleDlg::OnInitDialog()
{
    CDialogEx::OnInitDialog();

    CMenu* pSysMenu = GetSystemMenu(FALSE);

    if (pSysMenu != NULL)
    {
        pSysMenu->RemoveMenu( SC_MOVE, MF_BYCOMMAND );
       }
...

       return TRUE;
}

PS: Using method 2, this is the same method we use to disable the close button of a Window. For disabling a menu/titlebar button. Call EnableMenu function with relevant parameters.

 

Windows 7 Task Dialog – Part 1 – Displaying a basic task dialog

 

Every programmer must be familiar with the MessageBox es in any platform. It’s the simplest way to notify the user to take an action or provide notifications. Windows provides standard message box functionality with MessageBox API for displaying MessageBox with most frequently used buttons (OK, Cancel, Yes, No etc) and icons (error, warning, info etc.) This is again limited in programmer’s point of view and most we used to create our own messagebox to meet our extended purpose.

Windows UI has revamped since windows Vista and the UI experience was totally new from its predecessors. Most of the Windows Vista/7 applications display and extended form of messagebox called task dialog. Task dialog gives us more flexibility over the typical messagebox we used to have in Windows. We can display progress bars, extended information on footer, custom icons, predefined icons like Shield Icons (to indicate UAC elevation is required for operation etc.)

Task dialog comes with a simple set of interfaces and also provides an advanced version of interface to take control over what all we’re displaying in the task dialog

Displaying a Simple Taskbar

A simple task dialog can be displayed by calling TaskDialog API. The default buttons like OK, Yes, No, Cancel, Retry and close button. It’s simple as displaying a normal messagebox. The major difference is that we can have a custom icon, also a main instruction to show the intention of task dialog and main content provides further description of it. Organization of message is better readable and can have more focus than standard messagebox.

TaskDialog

	TASKDIALOG_COMMON_BUTTON_FLAGS tButton =
		TDCBF_OK_BUTTON| TDCBF_YES_BUTTON|
		TDCBF_NO_BUTTON| TDCBF_CANCEL_BUTTON|
		TDCBF_RETRY_BUTTON| TDCBF_CLOSE_BUTTON;

	int nClickedBUtton;
	TaskDialog( m_hWnd, NULL,
		_T("Demonstrating TaskDialog API"),
		_T("This is the main instruction"), _T("This shows the main content"),
		tButton,
		MAKEINTRESOURCE( IDI_SHIELD ),
		&nClickedBUtton );

In the above code you can see the default buttons are displayed with binary OR “|” operator. The return value is passed as parameter and can refer after calling the API. The return value of the function gives the error status. S_OK means the dialog was successfully displayed. the details of the parameters and return values are described in the TaskDialog API documentation. In the next installment, let’s have a look at advanced usage of Task Dialog.

 

Proudly powered by WordPress
Theme: Esquire by Matthew Buchanan.