Microsoft says enhancements planned for IE 8 include improved support for Ajax programming and better security.
Microsoft (NSDQ: MSFT) plans to launch a test version of the next major edition of its Internet Explorer Web browser by the end of June at the very latest, a company official said on a blog post Tuesday.
"A beta version of Internet Explorer 8 will be released in the first half of 2008," said a developer writing on Microsoft's Explorer blog.
Currently in development, Explorer 8 hit a major milestone in December when it passed the "Acid2 Face" test, which measures the extent to which a browser conforms to a series of widely used Web standards. Among the enhancements planned for IE 8 are improved support for Ajax programming and better security, Microsoft has said.
Microsoft also needs to ensure that Explorer 8 will be compatible with Web sites designed for earlier versions of the software. A number of corporate IT departments, as well as the federal Department of Transportation, have shied away from IE 7 -- released in October 2006 -- due to such concerns.
Explorer 8 is just one of numerous products that Microsoft plans to release in the months ahead. On Wednesday, the company plans to formally launch Windows Server 2008, SQL Server 2008 and Visual Studio 2008 at an event in Los Angeles.
Later this year, Microsoft will release Small Business Server 2008. It's also planning to ship a public beta of its Silverlight 2 Web presentation technology in the coming weeks.
All of this comes at a time when Microsoft is engaged in a high stakes bid for its Internet rival Yahoo. Microsoft has offered more then $40 billion for Yahoo, but so far the board of directors at the Web portal have rejected the pitch.
Some analysts have questioned whether Microsoft would be able to keep all of its product development schedules on track while at the same time attempting to close and integrate a multi-billion dollar acquisition.
By Paul McDougall
InformationWeek 
Feb 27, 2008
Microsoft Readies Internet Explorer 8 Beta
WorldWide Telescope peers into Big Dipper
Microsoft on Wednesday gave TED conference-goers--an audience typically filled with stars like Goldie Hawn or Forest Whitaker--a close-up of real celestial bodies with its new virtual telescope.
Microsoft demonstrated long-awaited software called WorldWide Telescope to an audience at the exclusive Technology Entertainment and Design conference in Monterey, Calif., a four-day confab that started Wednesday. It's unclear whether the demo of the astronomy technology made anyone in the audience cry like former Microsoft evangelist Robert Scoble, but the images (shown above) were certainly stellar.
WorldWide Telescope, similar to the sky feature in Google Earth but much more expansive, is a virtual map of space that features tens of millions of digital images from sources like the Hubble telescope and the Sloan Digital Sky Survey, a project championed by missing Microsoft researcher Jim Gray (to whom Microsoft dedicated the WorldWide Telescope on Wednesday). From the desktop, the technology lets people pan and zoom across the night sky, zeroing in on the Big Dipper, Mars, or the first galaxies to emerge after the Big Bang. It also lets people call up related data, stories, or context about what they're seeing from sources online.
Harvard University astrophysicist Roy Gould, who demonstrated the telescope with Microsoft principal researcher Curtis Wong, said that that the technology holds promise for research and for humanity.
"The WorldWide Telescope takes the best images from the greatest telescopes on Earth...and in space...and assembles them into a seamless, holistic view of the universe," Gould, of the Harvard Center for Astrophysics, said at the conference.
"This new resource will change the way we do astronomy...the way we teach astronomy....and, most importantly, I think it's going to change the way we see ourselves in the universe."
Microsoft also unveiled a promotional site for the telescope project Wednesday, but the free technology won't be live until sometime this spring. Without the tears, several academics talk up the telescope in video on the site. Here is a sampling of the awe-struck sentiment: "It's the universe that you yourself can voyage through." "It's a magic carpet." "It's an example of where science and science education is going." "My hope is to have it on every kid's desktop."
Stefanie Olsen
What's Inside Google Android?
Linux, Java, and a few more surprises. See what's under the hood of Google's upcoming mobile platform.
Android is Google's foray into the handheld OS realm. It follows a path trodden by -- among others -- Symbian's Quartz, the SavaJe operating system, and J2ME. In fact, one of Android's stated goals is to overcome some of J2ME's shortcomings. Whether or not Android succeeds, either at that specific goal, or in general, remains to be seen.
This article addresses a specific question: What is it like to work with the Android SDK? And to a lesser extent: What is under the Android hood? As these questions are answered, bear in mind that the version of the Android SDK I used was not in final form. Some of the problems described may have -- in fact, I hope will have -- been corrected by the time you read this. In addition, while Android development is supported on Linux, Mac OS X, and Windows, I did all my testing on Windows systems.
Inside an Android
Peel away Android's carapace, dig down to its marrow, and you'll find a Linux kernel. Libraries are a layer above, a variety of frameworks above that, and a final layer of applications sits on the top. The library layer is home to code for entities such as media processors for playback and recording of audio and video, the core of the Web browser, font rendering, and the SQLite relational database engine. The Android runtime also lives in the library layer.
Above the libraries reside frameworks, which are sets of reusable services and common components available to applications. For example, one sort of framework is a content provider, which is any service that handles the storage and retrieval of data. The application interface into the SQLite engine is a specific instance of a content provider.
Applications run at the top of the OS stack. Android will ship (assuming that it eventually does ship) with a set of core applications, including an e-mail client, a calendar, a Web browser, and more. And, of course, it is toward this topmost layer that all of the faculties of the Android SDK are directed.
When a developer writes an Android application, that developer codes in Java. The Java source is compiled to Java bytecodes, but -- to execute the application on Android -- the developer must execute a tool called dx. This tool converts Java bytecode to what is referred to as dex bytecodes. "Dex" is short for "Dalvik executable," Dalvik being the virtual machine that actually executes Android applications.
From a developer's perspective, Dalvik looks like a Java Virtual Machine, but strictly speaking, Dalvik is not a JVM. As stated above, Dalvik executes dex bytecode, not Java bytecode. And there are differences in the structure of Dalvik class files as compared to Java class files. Nevertheless, for all intents and purposes, building an Android application is really an exercise in building a peculiar sort of Java application.
The Android SDK
The Europa version of Eclipse is the preferred development platform for Android applications. In addition, you need at least a JDK 5 or JDK 6 installation to use the Android tools (the JRE that Eclipse typically installs is insufficient). Instructions on the Android site walk you through installing the Android Development Tools plug-in for Eclipse, and verifying the installation's correct operation by guiding you through the creation and execution of a quintessential "hello world" application.
However, you are not tied to Eclipse as your Android development system. The Android SDK does provide tools that let you use other IDEs in place of Eclipse. For example, the IntelliJ IDE is mentioned specifically in the Android documentation.
Hard-core developers will be satisfied to work solely with the collection of command-line tools that come with the SDK. For example, the activityCreator tool -- which is provided as a batch file for Windows, and as a Python script for Mac and Linux users -- will construct the framework for an Android Activity. (Activity is the Android equivalent of an application; more on this later.) Executing activityCreator will build skeletal Java files, create the Android project's required subdirectories, and build the necessary manifest XML files. The tool also creates an Ant script file for compiling the source and building the application. Once built, the application can be launched via the SDK's adb tool, the Android debug bridge.
Other command-line tools in the SDK include logcat, which outputs a log of system messages. Thanks to the stack trace provided by logcat, it is useful whenever an error occurs on the Android emulator. If you need deep analysis of what is going on in errant code, you can import a special Debug class into your application. This class provides methods for starting and stopping execution traces. When activated, Debug will log method calls to a trace file, which can be examined later with the toolkit's TraceView application. From within TraceView, you can view thread interactions, as well as examine execution paths. TraceView also shows the amount of time spent in each method, so you can use the tool as an execution profiler.
Finally, there is the Android emulator itself. When started, the emulator displays the skin of a hypothetical android device, complete with specialized faceplate buttons and QWERTY keyboard. It does its best to mimic an actual device, though there are understandable limitations (it cannot, for example, take incoming phone calls). The Android emulator runs a modified version of Fabrice Bellard's excellent open source simulation/virtualization environment, QEMU. Android's version of QEMU simulates an ARM processor, and on that processor executes the Linux OS.
Working with Eclipse
Once the Android Eclipse plug-in is installed, building an Android application is much like building any other application. The plug-in adds an Android Activity project to Eclipse's project templates tree. Start a new project, and the plug-in builds the foundational Java files, creates the necessary folders, and constructs skeletal resource files.
The Eclipse plug-in handles compilation, conversion to dex, launching the emulator, and downloading the application. Because writing Android code is writing Java code, the editor behaves as it would were you constructing an ordinary Java application. Resource files, which are written in XML, are easily managed by XML editors already available in Eclipse. Debugging is likewise supported from within Eclipse, and Android opens a debug perspective that anyone already familiar with Eclipse will be comfortable with.
Unfortunately, Android introduces a whole new lingo for developers to memorize. Roughly speaking, an application is an Activity. (The current documentation is only marginally helpful on this point, describing an Activity as "a single focused thing that a user can do.") Within an activity, you define one or more views. A view -- realized via the View class -- corresponds to an area on the screen, and manages the drawing and event trapping of its associated area. (So, for Java developers, a View is roughly equivalent to a Canvas.) Event handling is governed by the Intent class, which models an activity's intention to handle events of a given kind.
In short, be prepared to spend some time in the documentation matching what you already understand about GUI application development with the corresponding elements as Android calls them. The documentation is reasonably good on this matter. Nevertheless, as is typical, I found the provided example code to be far more useful.
Just before I began testing the Android SDK in mid-February, a new SDK was released (m5-rc14, to be exact). I installed that SDK (and Eclipse plug-in) on a 1GHz, 1GB Windows XP system. Though installation went smoothly, the emulator took on the order of 30 minutes to complete its boot process when an Activity was launched from within Eclipse. Other users on the Android message boards reported similar behavior, though the problem was by no means universal. The solution appeared to be faster hardware. Luckily, I had a more powerful machine on hand: a 3GHz processor with 2GB of RAM (running Windows 2000). I reinstalled Eclipse and the Android SDK on this faster system, and -- sure enough -- the emulator was up and running my trial application in about 30 seconds after the launch from Eclipse.
Now, 30 seconds -- though worlds better than 30 minutes -- is by no means a comfortable launch latency, particularly if you're stuck in a heavy execute-crash-debug-fix-execute cycle. And I'm not certain that delay can be reduced appreciably. Remember, when you start the emulator, you're starting the QEMU environment, followed by a booting of the Linux kernel, which has to fire up all the framework services. In other words, a lot has to happen just to get to the first bytecode of your target application.
Android on the March
Android is definitely a work in progress. If you want to try your hand at creating a significant Android application with the existing toolkit, I salute you. But be prepared for a challenge.
My biggest concern with Android is that I find nothing compelling in it that sets it apart from other handheld OSes. Though one might be tempted to point to the inclusion of the SQLite database engine as significant, I am unconvinced that an SQL-speaking relational database is the "killer feature" that will help Android succeed where other, similar handheld OSes have simply fizzled.
Nevertheless, Android has the weight of Google behind it. Whether that weight is sufficient to propel Android where other handheld OSes have not gone before is uncertain. For now, I'll simply say that Google has a lot of propelling to do.
Rick Grehan, InfoWorld
Intel Core 2 Duo E8500 Processor Review - 45nm Wolfdale
Intel Dual-Core Processors Go 45nm - Wolfdale
When AMD released the quad-core Phenom processor series last November the industry was in shock by the low performance numbers and clock frequencies that Phenom was launched with. If that was not enough, AMD then had to deal with the TLB erratum number 298 that presented a BIOS workaround that fixes the issue for a large performance loss. Even during this bad news other headlines from November to February revolved around video cards, as both NVIDIA and ATI launched new series that both marked significant improvements over previous generations. With all the media focus going to the new video cards and how bad Phenom is doing, almost no one noticed the refresh of their Core 2 Duo processor lineup. The old 65nm Conroe dual-core processor that we have all come to know and love has been replaced by a new 45nm Wolfdale dual-core processor! The Intel Wolfdale based processors have the same technology benefits that LR has already talked about in previous articles, so if you don't know about High-k + metal gate transistors or Intel's lead-free technology you have some catching up to do.
With a die size of just 107mm2 and 410 million transistors, it is smaller than its predecessor the Conroe, as it had a die size of 143mm2 with 291 million transistors. The above pictures are not to scale, but they show what the layout of the dies look like. Most of the 119 million new transistors are for the larger 6MB L2 cache on the Wolfdale as the Conroe had just 4MB. Other transistors are dedicated to the new SSE4 instruction set and the super shuffle engine. The TDP rating (Thermal Design Power) for the chip impressively stays the same though at just 65W. For comparison, the fastest single desktop processor that Intel has to offer right now is the quad-core Intel QX9770, which has a TDP rating of 136W. All of the Intel dual-core Wolfdale series processors are rated at 65W TDP and have 6MB of L2 Cache.
Intel currently offers four Wolfdale processors and, as you can see from the table above, half multipliers are back in action as the Intel E8500 has a multiplier of 9.5. Of the four dual-core Wolfdale processors you might be wondering what the difference between the E8200 and the E8190 is as they have the same basic features. Basically, the E8190 lacks Virtualization and Trusted Execution Technology. Many people don't even know what virtualization is, so one can expect prices on the E8190 to eventually be less than that of the E8200. It should also be pointed out that some rumors are going around that Intel will have a Core 2 Duo E8300 with an 8.5x multiplier and an E8600 with a 10x mutliplier coming our later this year. 
Today, we will be testing out the Intel Core 2 Duo E8500 processor against six other processors, but keep an eye on the the $269.99 Intel Core 2 Quad Q6600 Processor and $259.99 AMD Phenom 9600 Black Edition Processor as these processors are in the same price range.
