Get The Most From 64-Bit Computing

Get The Most From 64-Bit Computing

By   11:57   No comments:

Since it was introduced for Windows operating systems, 64-bit computing has changed substantially. Not only do computers running 64-bit versions of Windows perform better and run faster than their 32-bit counterparts, they are also more scalable because they can process more data per clock cycle, address more memory, and perform numeric calculations faster.

And do you know that Windows 7 supports two different 64-bit architectures:

• x64: This architecture is based on 64-bit extensions to the x86 instruction set, which is implemented in AMD Opteron (AMD64) processors, Intel Xeon processors with 64-bit extension technology, and other processors. This architecture offers native 32-bit processing and 64-bit extension processing, allowing simultaneous 32-bit and 64-bit computing.
• ia64: This architecture is based on the Explicitly Parallel Instruction Computing (EPIC) processor architecture, which is implemented in Intel Itanium (IA64) processors and other processors. This architecture offers native 64-bit processing, allowing 64-bit applications to achieve optimal performance.

You can also read my earlier post on which i have discussed the Advantages And Dis Advantages Of 64 Bit Windows

Sixty-four-bit computing is designed for performing operations that are memory intensive and that require extensive numeric calculations. With 64-bit processing, applications can load large data sets entirely into physical memory (that is, RAM), which reduces the need to page to disk and increases performance substantially.

The EPIC instruction set enables Itanium-based processors to perform up to 20 operations simultaneously.

Currently, the prevalent firmware interfaces are:

• ■ Basic input/output system (BIOS)
• ■ Extensible Firmware Interface (EFI)
• ■ Unified Extensible Firmware Interface (UEFI)

Itanium-based computers differ in many fundamental ways from computers based on the x86 and x64 specifications. While Itanium-based computers use EFI and the GUID partition table (GPT) disk type, computers based on x86 use BIOS and the master boot record (MBR) disk type.

Computers based on x64 use UEFI wrapped around BIOS or EFI. This means that there are differences in the way you manage computers with these architectures, particularly when it comes to setup and disk configuration.

However, with the increasing acceptance and use of UEFI and the ability of Windows 7 to use both MBR and GPT disks regardless of firmware type, the underlying chip architecture won’t necessarily determine what firmware type and disk type a computer uses. This decision is in the hands of the hardware manufacturer.

Generally, BIOS-based computers use MBr for booting or for data disks and Gpt only for data disks. eFI-based computers can have both Gpt and MBr disks, but you must have at least one Gpt disk that contains the eFI system partition (eSp) and a primary partition or simple volume that contains the operating system for booting.

In most cases, 64-bit hardware is compatible with 32-bit applications; however, 32-bit applications perform better on 32-bit hardware. Windows 64-bit editions support both 64-bit and 32-bit applications using the Windows on Windows 64 (WOW64) x86 emulation layer. The WOW64 subsystem isolates 32-bit applications from 64-bit applications. This prevents fi le system and registry problems.

The operating system provides interoperability across the 32-bit/64-bit boundary for the Component Object Model (COM) and for basic operations such as cutting, copying, and pasting using the Clipboard. However, 32-bit processes cannot load 64-bit dynamic-link libraries (DLLs), and 64-bit processes cannot load 32-bit DLLs.

In the shift to 64-bit computing, you may want to track which computers in the enterprise support 64-bit operating systems, which computers are already running 64-bit operating systems, or both. With Windows PowerShell you can:

• Determine whether a computer has a 64-bit operating system installed by using the OSArchitecture property of the Win32_OperatingSystem object.

An example and sample output follow:

get-wmiobject -class win32_operatingsystem | format-list

• 
• Determine whether a computer supports a 64-bit operating system by using the Name and Description properties of the Win32_Processor object.

get-wmiobject -class win32_processor | format-list name,description

Here, the first sample output tells you the computer is running a 32-bit version of Windows. The second sample output tells you the computer has an x64 processor.

As a result, you know the computer can be upgraded to a 64-bit version of Windows 7. Rather than check each computer individually, you can create a script to do the work for you.

Read More

Different Between UEFI and BIOS

Different Between UEFI and BIOS

By   11:45   No comments:

The standard BIOS has all sorts of problems, not least of which is its susceptibility to malware. For example, there are rootkits that hook themselves into the BIOS OS-loader code, permitting them to run underneath Windows. They're difficult to remove and will reinfect Windows over and over.

And because the BIOS sits on a chip on the motherboard, it's more difficult to update than an operating system or an application. So most PC users never update their BIOS, leaving the PC possibly incompatible with newer operating systems. (The early PC BIOS was hard-coded on a chip, so upgrading required replacing the entire chip or PROM.)

The UEFI is a more sophisticated system that runs before your primary OS kicks in. Unlike the BIOS, UEFI can access all PC hardware, including the mouse and network connections. It can take advantage of modern video cards and monitors. It can even access the Internet.

And as you can see in Figure below, UEFI offers a modern, easy-to-decipher user interface. It could make dual-booting simpler, more visual, and controllable by mouse or touch. If you've ever played your BIOS, you discover that UEFI is in a whole new dimension.

Figure: The view of a UEFI-interface screen.

Unlike the BIOS, the UEFI can exist on a disk, just like any other program — or in nonvolatile memory on the motherboard or even on a network share.

At this point, it's important to note that systems can run either the BIOS or the UEFI — or both. When they're both used, the BIOS goes first to run POST, then the UEFI takes over and hooks into any calls that may be made to the BIOS. (Windows typically doesn't make calls directly to the BIOS, but other operating systems might — and the UEFI will handle them, not the BIOS.)

The UEFI can also run without the BIOS — it can take care of all OS loading/interface functions previously handled by the BIOS. The only thing the UEFI can't do is perform the POST or run the initial setup (configuring the CPU, memory, and other hardware). PCs that have the UEFI but no BIOS have separate programs for POST and setup that run automatically when the PC is powered on.

As we all know, the BIOS initialization process — including POST — seems to take a long time. The UEFI, on the other hand, can run quickly.

Moreover, a BIOS is easily reverse-engineered and typically has no internal security protection, making it a sitting duck for malware. A UEFI can run malware-dodging techniques such as policing operating systems prior to loading them — which might make rootkit writers' lives considerably more difficult. For example, the UEFI could refuse to run OSes that lack proper digital security signatures. And that's where the UEFI controversy begins.

Read More