Ditch the Aero window frame in Windows Live Messenger “Wave 4”

8 Jun
2010
11 Comments

Windows Live Messenger window without Aero frame

Digging around Windows Live Messenger “Wave 4” bits, looking for a way to turn off the permanently enabled SmartScreen-based link scanner, I stumbled on a flag that disables/enables the Aero window border.

If you’re interested in that sort of thing, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Live\Messenger and create the DWORD value AeroWindowFrameEnabled with its data set to 0 or 1.

For those on 64-bit platforms, don’t forget you need to tack on Wow6432Node after the Software\ node, or you’ll be fishing around in 64-bit waters. (Windows Live Messenger is a 32-bit process.)

Given how poorly this works (e.g. can’t move the window, no title bar), I’m guessing it’s unfinished or on its way out.

Comments (11) »

Browsers re-tested in the IE9 Testing Center, different results surface

2 Jun
2010
20 Comments

Update: Retested Mozilla Firefox w/ proper trunk build, thanks Kirkburn for the heads up (and schooling).

Shortly after the release of the Windows Internet Explorer Testing Center – a site housing a comprehensive browser feature implementation test suite – there have been some grumblings regarding the accuracy of the data within. More specifically, Microsoft performed a comparison of its Internet Explorer 9 browser technology – currently in developmental stages – to stale builds of Mozilla’s Firefox, Apple’s Safari, Google’s Chrome, and … that browser no one cares about (sadly) – Opera.

Sounds like a valid argument to me. I decided to re-test using builds of Mozilla Firefox “Namoroka” (1.9.2.5pre), Mozilla Firefox “Minefield” 3.7a5pre, Google Chromium (6.0.397.0/46552), and Apple Safari w/ a newer WebKit engine (r58804) that matched release dates with Internet Explorer 9 (May 5, 2010). After clicking around the site a hundred or so times in each browser, the results… changed. Each browser made noticeable improvements in areas like CSS3 and DOM; Apple barely beat out Chrome for the most improvement, while Firefox proved to be a bit slower (but error free). The numbers, Ed Bott’s favorite meal, are below. The takeaway here isn’t the numbers – forgive me if I made a slight error – but the fact that you can’t compare bleeding edge browser builds with stale release builds. That’s just not fair.

 Browser re-test results matrix (rev 1 - used proper Mozilla trunk build)

Comments (20) »

We’re not doing Google anymore.

1 Jun
2010
13 Comments

logo Back in March, Long Zheng and I pushed out a Windows 7 Sensor that discovered your location using surrounding wireless access point data as a reference. For this to work properly, we needed a database that mapped geographical coordinates to access points. Without the resources needed to create our own super database, we decided to piggy back Google’s Location Services (GLS), the same technology used in Mozilla Firefox and Google Latitude. With its core easily accessible (via JSON) to the public, adoption was clean, easy and pretty darn fast.

Days before our 1.0 release in March, we touched base with Google in hopes to stir up interest and to ensure the GLS API was there to stay (for a while), on the heels of Gears’ transitory news. After a few exchanges, with a middle man, we were passed a note, paraphrased as such: The Terms of Service for the Gears API doesn’t allow for this type of usage.

Confused? We were, because we’re not using nor touched Google Gears. Reading the Google Gears TOS, we discovered this nugget of evil:

5.3 You agree not to access (or attempt to access) any of the Services by any means other than through the interface that is provided by Google, unless you have been specifically allowed to do so in a separate agreement with Google.

To conform to the TOS – despite its confusing scope of applicability – Google wanted us to funnel our access through their deprecated Gears product (or ask for special permission). More focused on pushing out Geosense 1.0, we ceased communication with Google and simply put our blinders on. “They wouldn’t know any better, with their hundred million queries per day, pffft.”

We pushed out Geosense 1.0. 1.1. And finally 1.2, fixing some major issues.

Interested in taking the sensor through Windows Logo certification – admittedly with Windows Update access in mind – I met with some Logo folks at the (Microsoft) mothership to soak up some knowledge. One of the huge benefits after Logo’ing an item is placement on The Gold List. (I made the name up.) The Gold List is simply a list of all Windows Logo certified vendors categorized down by product genre. For example, we’ll be the first (and only) entry under Windows 7 Sensors. With the pending Google legal nitnoid, however, I had to halt my Logo plans; there is no chance in hell an OEM would be interested in a sensor that has legal issues.

Coming full circle, we revisited our outstanding legal issue. We took our blinders off and contacted our Google representative, in hopes to obtain special permission for Geosense. Eleven days later we haven’t received anything back. No out of office, no “I’m looking into this, have a seat in the lobby”. Nada. Not being ones to wait patiently (or play lame corporate politics), we’ve decided to end our relationship with Google Location Services. I hope we can still be friends.

We are currently evaluating alternative services, such as those from Skyhook and Navizon. After we pick one and implement it, we’ll resume Windows Logo certification and testing.

Comments (13) »