Microsoft has officially announced that "Longhorn" will be branded "Windows Vista". "Vista" sounds more like a codename to me, but hey, as a Texas Aggie I'm just glad to finally be rid of the "Longhorn" moniker.
Windows Vista AnnouncementHeres the official press release with video.
Friday, July 22, 2005
Friday, July 15, 2005
EventLogs Syndication and RSS
[Posted on my MSN Space on July 15, 2005]
I thought I had a totally original idea, but it turns out someone already beat me to it. However, I still consider my intent original so I'm going to post this anyway.
My RSS aggregator (RSSBandit) has become the central source of news and blogs during my day. Since I spend so much time monitoring this application, why not make it the central source of information about my computer. The most obvious way to do this is to have an application or service monitor the event logs then publish an RSS feed when an entry is written. Conceptually, however, this notion isn't limited to just the Event Logs. You could potentially tap into WMI, Performance Counters, and failure-predictive hardware and consolidate them all in to 'system health' RSS feeds. This works great for a single user on a single PC, but it's also scalable. Drop in a simple web server like Cassini (requires modification for serving up content to remote machines) or CassiniEx and now a system admin can monitor the feeds for multiple machines from a single location (OK, so you wouldn't really want to monitor thousands of machines this way, but maybe in an SMB situation).
This becomes a much more compelling scenario when you consider the proposed RSS support in Longhorn. If Longhorn is already going to maintain a list of RSS feeds, why not add a few more to the mix and let application developer plug into the data?
My first attempt was to create a library that parses the event logs then publishes the entries into a separate RSS feed for each event log. The library can publish all event logs in one go, or you can selectively publish individual logs by passing in the log name. I also added some filtering so that certain events would be ignored during syndication (for example, if you only want to publish warnings or errors, you can filter out informational and audit events).
The attached snapshots show RSSBandit with the feeds generated from my notebook. Everything has been coded using the July CTP of VS.NET 2005.
Screen Shot 1
Screen Shot 2
As far as the monitoring application, it can be done any way you like. I wrote a fairly simple application that can either publish the event logs on demand, or monitor the logs and publish them when a new entry is written. The monitoring code can be put into a form or service pretty easily. Here's what it looks like:
#using System.Diagnostics;
...
// in form load, service start, etc.
EventLog[] eventLogs = GetEventLogs();
foreach(EventLog eventLog in eventLogs)
{
eventLog.EntryWritten += new EntryWrittenEventHandler(eventLogMonitor_EntryWritten);
eventLog.EnableRaisingEvents = true;
}
...
private void eventLogMonitor_EntryWritten(object sender, EntryWrittenEventArgs e)
{
EventLogRssPublisher rssPub = new EventLogRssPublisher();
rssPub.PublishEventLogs();
}
Thats all for now,
Tony
I thought I had a totally original idea, but it turns out someone already beat me to it. However, I still consider my intent original so I'm going to post this anyway.
My RSS aggregator (RSSBandit) has become the central source of news and blogs during my day. Since I spend so much time monitoring this application, why not make it the central source of information about my computer. The most obvious way to do this is to have an application or service monitor the event logs then publish an RSS feed when an entry is written. Conceptually, however, this notion isn't limited to just the Event Logs. You could potentially tap into WMI, Performance Counters, and failure-predictive hardware and consolidate them all in to 'system health' RSS feeds. This works great for a single user on a single PC, but it's also scalable. Drop in a simple web server like Cassini (requires modification for serving up content to remote machines) or CassiniEx and now a system admin can monitor the feeds for multiple machines from a single location (OK, so you wouldn't really want to monitor thousands of machines this way, but maybe in an SMB situation).
This becomes a much more compelling scenario when you consider the proposed RSS support in Longhorn. If Longhorn is already going to maintain a list of RSS feeds, why not add a few more to the mix and let application developer plug into the data?
My first attempt was to create a library that parses the event logs then publishes the entries into a separate RSS feed for each event log. The library can publish all event logs in one go, or you can selectively publish individual logs by passing in the log name. I also added some filtering so that certain events would be ignored during syndication (for example, if you only want to publish warnings or errors, you can filter out informational and audit events).
The attached snapshots show RSSBandit with the feeds generated from my notebook. Everything has been coded using the July CTP of VS.NET 2005.
Screen Shot 1
Screen Shot 2
As far as the monitoring application, it can be done any way you like. I wrote a fairly simple application that can either publish the event logs on demand, or monitor the logs and publish them when a new entry is written. The monitoring code can be put into a form or service pretty easily. Here's what it looks like:
#using System.Diagnostics;
...
// in form load, service start, etc.
EventLog[] eventLogs = GetEventLogs();
foreach(EventLog eventLog in eventLogs)
{
eventLog.EntryWritten += new EntryWrittenEventHandler(eventLogMonitor_EntryWritten);
eventLog.EnableRaisingEvents = true;
}
...
private void eventLogMonitor_EntryWritten(object sender, EntryWrittenEventArgs e)
{
EventLogRssPublisher rssPub = new EventLogRssPublisher();
rssPub.PublishEventLogs();
}
Thats all for now,
Tony
Software Uninstaller
[Posted on my MSN Space on July 05, 2005]
A new Community Technical Preview of Visual Studio 2005 has been posted for MSDN subscribers. It has the same intensive requirements for ordered uninstallation of previous builds. In order to make this process easier, I wrote a little app while I was downloading the June CTP. The app enumerates all uninstallable software, allows a user to select SW to uninstall and configure the order of uninstallation, then performs a synchronous uninstallation of all the selected SW (see the pic for an example). The only problem is that the VS.NET uninstaller launches a separate process, which breaks the synchronous process flow, but other than that it worked like a champ when I went to uninstall Beta 2 before installing the June CTP. I have placed the code out here, so give it a try and leave any comments (USE AT YOUR OWN RISK).
Click here for a screen shot of the UI
A new Community Technical Preview of Visual Studio 2005 has been posted for MSDN subscribers. It has the same intensive requirements for ordered uninstallation of previous builds. In order to make this process easier, I wrote a little app while I was downloading the June CTP. The app enumerates all uninstallable software, allows a user to select SW to uninstall and configure the order of uninstallation, then performs a synchronous uninstallation of all the selected SW (see the pic for an example). The only problem is that the VS.NET uninstaller launches a separate process, which breaks the synchronous process flow, but other than that it worked like a champ when I went to uninstall Beta 2 before installing the June CTP. I have placed the code out here, so give it a try and leave any comments (USE AT YOUR OWN RISK).
Click here for a screen shot of the UI
Disabling WOW64 File System Redirection from C#
[Posted on my MSN Space on June 28, 2005]
A long time ago on a blog now gone (looks like erablog.net disappeared!) I wrote a post about interacting with WOW64 (Windows on Windows 64) from a 32-bit application. The example I posted was unmanaged C++. Yesterday, a coworker wanted to implement the same functionality in C#. I don't know of any managed interfaces to WOW64 (if you know of one let me know) so I used Interop and DllImport to call Wow64EnableWow64FsRedirection from Kernel32.dll. A nice feature of interop is that you can simply throw the function in a try-catch block so that if the application is run on an OS that doesn't support the API (32-bit Windows XP, for example), you can simply catch the exception and continue. In the unmanaged C++ world you have to use runtime dynamic linking.
Here's what it looks like from unmanaged C++:
typedef WINBASEAPI BOOLEAN WINAPI LPFN_ENABLEFSREDIRECTION(BOOLEAN);
...
LPFN_ENABLEFSREDIRECTION *fnEnableFSRedirection;
fnEnableFSRedirection = (LPFN_ENABLEFSREDIRECTION*) GetProcAddress(GetModuleHandle("kernel32"),"Wow64EnableWow64FsRedirection");
if(NULL != fnEnableFSRedirection)
{
if(fnEnableFSRedirection(bEnable))
{
cprintf(TEXT("Success disabling FS Redirection"));
}
}
else
{
cprintf(TEXT("Error disabling FS Redirection"));
}
Here's what it looks like in C#:
class Wow64Mgr
{
[STAThread]
static void Main(string[] args)
{
try
{
if(Wow64Interop.EnableWow64FSRedirection(false))
Console.WriteLine("WOW64 File System Redirection Disabled");
else
Console.WriteLine("Failure Disabling WOW64 File System Redirection");
}
catch (Exception exc)
{
Console.WriteLine("Failure Setting WOW64 File System Redirection.");
Console.WriteLine(exc.Message);
}
}
}
public class Wow64Interop
{
[DllImport("Kernel32.Dll", EntryPoint="Wow64EnableWow64FsRedirection")]
public static extern bool EnableWow64FSRedirection(bool enable);
}
A long time ago on a blog now gone (looks like erablog.net disappeared!) I wrote a post about interacting with WOW64 (Windows on Windows 64) from a 32-bit application. The example I posted was unmanaged C++. Yesterday, a coworker wanted to implement the same functionality in C#. I don't know of any managed interfaces to WOW64 (if you know of one let me know) so I used Interop and DllImport to call Wow64EnableWow64FsRedirection from Kernel32.dll. A nice feature of interop is that you can simply throw the function in a try-catch block so that if the application is run on an OS that doesn't support the API (32-bit Windows XP, for example), you can simply catch the exception and continue. In the unmanaged C++ world you have to use runtime dynamic linking.
Here's what it looks like from unmanaged C++:
typedef WINBASEAPI BOOLEAN WINAPI LPFN_ENABLEFSREDIRECTION(BOOLEAN);
...
LPFN_ENABLEFSREDIRECTION *fnEnableFSRedirection;
fnEnableFSRedirection = (LPFN_ENABLEFSREDIRECTION*) GetProcAddress(GetModuleHandle("kernel32"),"Wow64EnableWow64FsRedirection");
if(NULL != fnEnableFSRedirection)
{
if(fnEnableFSRedirection(bEnable))
{
cprintf(TEXT("Success disabling FS Redirection"));
}
}
else
{
cprintf(TEXT("Error disabling FS Redirection"));
}
Here's what it looks like in C#:
class Wow64Mgr
{
[STAThread]
static void Main(string[] args)
{
try
{
if(Wow64Interop.EnableWow64FSRedirection(false))
Console.WriteLine("WOW64 File System Redirection Disabled");
else
Console.WriteLine("Failure Disabling WOW64 File System Redirection");
}
catch (Exception exc)
{
Console.WriteLine("Failure Setting WOW64 File System Redirection.");
Console.WriteLine(exc.Message);
}
}
}
public class Wow64Interop
{
[DllImport("Kernel32.Dll", EntryPoint="Wow64EnableWow64FsRedirection")]
public static extern bool EnableWow64FSRedirection(bool enable);
}
Aero "Glass" in Longhorn build 5048 (WinHEC 05 build)
[Posted on my MSN Space on May 20, 2005]
I just found these instructions on enabling Aero in Longhorn build 5048. It's somewhat flakey, but appears to work.
For images, see the following...
Image 1
Image 2
I just found these instructions on enabling Aero in Longhorn build 5048. It's somewhat flakey, but appears to work.
For images, see the following...
Image 1
Image 2
WinHEC Post Conference
[Posted on my MSN Space on April 30, 2005]
...while I was at WinHEC I was interviewed by a reporter. I wasn't expecting to be quoted, but it looks like I made it! Heres the TechTarget Article
[Posted on my MSN Space on April 27, 2005]
As I'm sitting here watching the event hall be torn down, I can't help but have the "blahs". I wonder why that is? Every conference ends with mixed emotions - glad to be going home, but there's something depressing about watching the place you've spent the last few days be broken-down and boxed-up. Oh well. Guess I'll just have to head out and eat some real food for a change (the food at this years conference was REALLY bad).
WinHEC Interview
...while I was at WinHEC I was interviewed by a reporter. I wasn't expecting to be quoted, but it looks like I made it! Heres the TechTarget Article
[Posted on my MSN Space on April 27, 2005]
Post conference 'blahs'
As I'm sitting here watching the event hall be torn down, I can't help but have the "blahs". I wonder why that is? Every conference ends with mixed emotions - glad to be going home, but there's something depressing about watching the place you've spent the last few days be broken-down and boxed-up. Oh well. Guess I'll just have to head out and eat some real food for a change (the food at this years conference was REALLY bad).
WinHEC Day 3
[Posted on my MSN Space on May 05, 2005]
Microsoft's "ConnectNow" initiative introduces a new paradigm in which device Plug and Play and use is non longer restricted to physical busses but can be accomplished via the network. Today there are two distinct UXs when plugging-in a USB device versus attaching a device to the network.
The benefits of ConnectNow are:
The main areas of ConnectNow are Discovery, Association, Security, and Function Discovery. Discovery requires a network protocol rather than a bus electronic signal. This will allow metadata exchange of hardware information such as device ID, friendly name, compatible IDs, etc. Association allows the PC to use a Network Connected Device (NCD). In the area of security, Plug-and-Play Extensions for Network Connected Devices (PnP-X) exposes and IP Bus Enumerator that provides a platform for establishing trust and a secure channel between a PC and a device. Function Discovery will allow abstraction of underlying provider implementations and allow one common API. Currently planned in-box providers for Longhorn are PnP, SSDP (for UPnP), WS-Discovery (Web Services for Devices), Registry, and 3rd-party.
This session outlined the Longhorn-ready PC program. The goals of the program are to ensure that customers can make good Longhorn-capable PC decisions and to provide OEM's an early opportunity to plan and market Longhorn-ready PC's. For 2005, Microsoft plans to finalize the technical requirements of the program, begin industry engagement, and develop enterprise guidelines. In 2006, ReadyPC products should be available as well as marketing for the ReadyPC program.
The projected platform features of a PC in the Longhorn timeframe include correct ACPI implementation, hybrid disk (NVRAM + disk), drivers verified to not introduce latency, TPM 1.2, UAA, LDDM, > 64 MB graphics memory. Microsoft is also encouraging industrial design features such as form factor that matches function (Media Center, for example), front-mounted ports, labeled and colored connectors, quiet, easy-open case, tool-less I/O card add/remove, judicious and well designed use of lights, enough 1394 and USB ports, etc.
This session is the most immediately applicable to bPC. Device Management and Installation (DMI) is a platform for creating stable, Microsoft-approved driver installation packages. The platform abstracts OS version and supports Windows 2000 forward and with version 2.0 is localized in 24 different languages. DMI also creates a down-level driver store which handles driver updates and roll-backs, so driver developers don't have to worry about this. The Driver Install Frameworks are currently in their 3rd generation (1.0, 1.1, 2.0). In this version, support for test-signed and unsigned drivers has been added to support "legacy" mode. The three major components of DMI are the Driver Package Installer (DPInst), the Driver Install Frameworks for Applications (DIFxApp) and the Driver Install Frameworks API (DIFxAPI).
This session outlined the two new Logo programs that will be introduced in the Longhorn timeframe. The name of the Logo program is changing from the "Designed for…" wording to simply "Windows Logo Program". In addition, there will be two levels of Logo - Gold or Premium, and Silver or Standard (actual names are just a placeholder for now). Device vendors can still participate in signature programs without participating in Windows Logo programs.
Consumer
Commercial
Mobile
Printers
System Components:
All drivers must meet minimum quality rating.
Schedule: See slide deck for program requirements draft schedule.
Device and PC Integration with Discovery, Plug and Play, Publication, and Network Explorer
Microsoft's "ConnectNow" initiative introduces a new paradigm in which device Plug and Play and use is non longer restricted to physical busses but can be accomplished via the network. Today there are two distinct UXs when plugging-in a USB device versus attaching a device to the network.
The benefits of ConnectNow are:
- Simplified discovery and use of network connected devices.
- Enumeration and use through standard windows API's. Abstracts the actual protocols being used (UPnP, PnP-X, WSD, etc.)
- Can be managed by existing asset management infrastructure (Group Policy).
The main areas of ConnectNow are Discovery, Association, Security, and Function Discovery. Discovery requires a network protocol rather than a bus electronic signal. This will allow metadata exchange of hardware information such as device ID, friendly name, compatible IDs, etc. Association allows the PC to use a Network Connected Device (NCD). In the area of security, Plug-and-Play Extensions for Network Connected Devices (PnP-X) exposes and IP Bus Enumerator that provides a platform for establishing trust and a secure channel between a PC and a device. Function Discovery will allow abstraction of underlying provider implementations and allow one common API. Currently planned in-box providers for Longhorn are PnP, SSDP (for UPnP), WS-Discovery (Web Services for Devices), Registry, and 3rd-party.
Building Longhorn-Ready PC's
This session outlined the Longhorn-ready PC program. The goals of the program are to ensure that customers can make good Longhorn-capable PC decisions and to provide OEM's an early opportunity to plan and market Longhorn-ready PC's. For 2005, Microsoft plans to finalize the technical requirements of the program, begin industry engagement, and develop enterprise guidelines. In 2006, ReadyPC products should be available as well as marketing for the ReadyPC program.
Requirements for the program:
- PC Hardware Quality - Windows XP Logo for 32 or 64.
- System Requirements - Modern CPU, 512 or higher RAM.
- Graphics Stability - LDDM for PC graphics made available within 90 days of launch (if not supported in-box on Longhorn). Possible LDDM UX models:
- Classic - Windows 2000 look-and-feel.
- "To Go" - ALC-type products.
- Aero
The projected platform features of a PC in the Longhorn timeframe include correct ACPI implementation, hybrid disk (NVRAM + disk), drivers verified to not introduce latency, TPM 1.2, UAA, LDDM, > 64 MB graphics memory. Microsoft is also encouraging industrial design features such as form factor that matches function (Media Center, for example), front-mounted ports, labeled and colored connectors, quiet, easy-open case, tool-less I/O card add/remove, judicious and well designed use of lights, enough 1394 and USB ports, etc.
DMI: Driver Install Frameworks Tools and Strategies
This session is the most immediately applicable to bPC. Device Management and Installation (DMI) is a platform for creating stable, Microsoft-approved driver installation packages. The platform abstracts OS version and supports Windows 2000 forward and with version 2.0 is localized in 24 different languages. DMI also creates a down-level driver store which handles driver updates and roll-backs, so driver developers don't have to worry about this. The Driver Install Frameworks are currently in their 3rd generation (1.0, 1.1, 2.0). In this version, support for test-signed and unsigned drivers has been added to support "legacy" mode. The three major components of DMI are the Driver Package Installer (DPInst), the Driver Install Frameworks for Applications (DIFxApp) and the Driver Install Frameworks API (DIFxAPI).
Driver Package Installer (DPInst)
- For INF-installable drivers
- Supports software-first installs
- No code or custom installers to write
- Creating a driver installer package requires three steps
- Place DPInst.exe into temporary directory.
- Place driver files into the same temporary directory (supports subdirectories if necessary).
- Create self extracting .exe file that launches DPInst.exe
Driver Install Frameworks for Applications (DIFxApp)
- Creates a Windows Installer Custom Action
- Can be used by Windows Installer, WISE, InstallShield, or open sources MS WiX (Windows Installer XML).
- Used for more complicated installs such as additional software applications, etc.
Driver Install Frameworks API (DIFxAPI)
- Allows creation of custom installers with DIFx backend.
The Next Generation Logo Program
This session outlined the two new Logo programs that will be introduced in the Longhorn timeframe. The name of the Logo program is changing from the "Designed for…" wording to simply "Windows Logo Program". In addition, there will be two levels of Logo - Gold or Premium, and Silver or Standard (actual names are just a placeholder for now). Device vendors can still participate in signature programs without participating in Windows Logo programs.
Program Details
- Gold delivers the "premium" Longhorn experience (Aero glass, etc.)
- Created in response from partner feedback wanting product differentiation.
- Must have Silver/Standard Logo first. Sliver Logo is comparable to Windows XP Logo program. Gold builds upon the Sliver Logo.
- New and expanded device categories on WinQual (and Windows MarketPlace).
- Administration similar to Windows XP Logo (online submission to WinQual).
- Driver signatures will have Gold or Silver attribute.
- There will be different artwork for Gold versus Silver Logo
- Microsoft will begin a marketing push for Gold program only.
Possible Gold System Logo Requirements
Consumer
- Aero visual theme support.
- DVD burning.
Commercial
- TPM 1.2.
- RTC with array microphone capable audio system.
Mobile
- 802.11g.
- External video must be DVI.
- Hardware feature buttons or function key combinations (turn wireless on/off, for example).
- Battery life indicators.
Printers
- Enhanced color matching.
System Components:
- Audio - WaveRT miniport WDM.
- Input - KMDF (new keyboard driver model).
- Graphics - At least one DVI-out required on multi-head cards.
All drivers must meet minimum quality rating.
Schedule: See slide deck for program requirements draft schedule.
WinHEC Day 2
[Posted on my MSN Space on April 27, 2005]
Best session of the conference - Why? Because they handed out 1GB USB2.0 UFD's - woohoo!. Really though, this actually was a pretty good session. We've been working with WinPE pretty intensly since it's introduction during Windows XP development through the development of "Interim" WinPE announced at last year's WinHEC. Nothing in this session came as much of a suprise with the exception that MS is saying that the .NET framework can be added to WinPE. They don't provide support or a mechanism, but have stated that is can be and has been done. I'll have to take a look at that, maybe leveraging the Windows XP Embedded .NET framework component to disect exactly how it can be added to WinPE. Once again, we got some mud in our (HP) eye for not supporting high-speed USB 2.0 boot capability in our BIOS. Hopefully we'll get there sooner than later since UFD's are taking off so rapidly. MS also alluded that more WinPE details for Longhorn, including booting WinPE from MS's new WIM image format, would be revealed at the PDC - I guess I'll have to start begging to go to LA again :). The session finished with two demos from ISV's using WinPE for diagnostics and backup/recovery. It's interesting to see how ISV's/IHV's are adopting and implementing WinPE in solutions.
I wan't able to find any sessions during this timeslot that directly related to my job or workgroup, so I thought I'd attend this session since it sounded interesting. There was a very brief update on the updates to USB and IEEE 1394 for Longhorn. For USB 2.0 Microsoft is doing a complete rewrite of USBHUB.SYS. Later in the day I would learn that this was due, in large part, to power managment enhancements. MS also plans to enable kernel debugging via USB 2.0. I loved hearing this since debugging on legacy-free systems has always presented a challenge. Apparently there was a Driver DevCon session on this, so I'll have to try and track down the slide deck. The 1394 update was even more brief, simply stating that IP addressing would be removed from 1394 in Longhorn. As for Bluetooth, the main emphasis was to being looking at the enhancements that have already been added to XP SP2 and to stop using COM ports for Bluetooth applications (use RFCOM? and sockets instead). The Longhorn updates include stack improvements, improved channel interference avoidance with 802.11, new faster EDR radio, and extensibility features. The extensibility features will include SCO driver development (for Bluetooth headsets), a service discovery protocol, L2CAP, and a new Driver Development Interface which simplifies application development.
In short, this session discussed the power and thermal envelope considerations in respect to processor performance of daul-core versus single core processors. It was presented by AMD and was very AMD architecture centric. The key take away was that a dual-core processor can run with the same power consumption and thermal conditions at 400MHz less than a single core processor. However, even with the 400 MHz difference, there are significant performance gains.
Nope, this wasn't about disk partitioning and Virtual Disk Services. I guess I should have looked in the conference guide. I have to admit I was kind of suspiscious when I met several enterprise server guys in the audience. I ended up leaving early and moving next door into:
I arrived a little late, but here's the rundown on power managment enhancements in Longhorn. Power profile management will be updated to include management/configuration from group policy, powercfg.exe, etc. No word on whether the power management API will be updated (or the lib and header files fixed!). Longhorn will also include a better mechanism for handling a power profile when no users are interactively logged on to the system. MS is also updating processor power management which will include a rewrite of existing processor drivrers (p3.sys, amdk7.sys). Longhorn will also include an improved UX with simplified shutdown/sleep UI, battery meter, hung app resolution, etc. The new UX will also include OEM extensibility. OEMs will have enhanced opportunities for adding/configuring power schemes, control panel applet property sheets, etc. One interesting point was that the new default settings are STILL not EStar compliant.
Longhorn will introduce a new paradigm of scaling OS functionality in respect to hardware capabilities. Today, application developers need to do custom detection of hardware detection and usually dumb-down their apps to the lowest common denominator. MS is adding an infrastructure (cmd line util, API, WMI provider) to provide some basic system metrics for hardware assessment. The basic metrics are graphics performance (used to determine which Aero model the graphics card can support), memory, processor, and storage. The command utility, winstat.exe, will produce XML output that IHV's and ISV's can read to determine if the system is capable of advanced features included in applications without having to write their own assessment code. Winstat.exe is included on the WinHEC build of Longhorn and documentation was included on the conference proceedings CD, so I'm going have to play with this on a few of our systems see how Longhorn ready they are. Seeing that MS was using our systems for several of their Longhorn demos, I'm thinking we're pretty close :)
The presenter used to be our TAM, so I had some inside info before attending this session so I didn't take too many notes. The key information is that Microsoft is placing new emphasis on OEM and corporate deployment scenarios on Longhorn, rather than these scenarios being an afterthought once the retail install was developed. Longhorn will inclue the OPK (with new and improved tools for image management, deployment and maintainence), and will introduce the WAIK, an OPK like package for enterprise level customers who have a tendency to ask OEMs for copies of the OPK (which we can't legally give them). This session also covered the "world-wide binary" concept. Longhorn will separate code from resources, allow a language-generic base image that uses MUI for translation. This will finally fix the problem of creating and managing an image per language. The session also glanced over WinPE updated that were presented in detail in the morning and introduced WDS (Windows Deployment Services), the eventual replacement for RIS.
Gibson, Intel, and Cakewalk hosted this year's party at EMP. It wasn't quite as fun as last year's party, but still a good time. See pics below.
Well, I'm off to finish up the second half of day 3. I'll try and post the day 3 summary tonight.
Guitar Tower 1
Guitar Tower 2
Sky Church Jellyfish
Sky Church Stage Side
Sky Church Stage Center
Space Needle
Building Support Solutions in WinPE
Best session of the conference - Why? Because they handed out 1GB USB2.0 UFD's - woohoo!. Really though, this actually was a pretty good session. We've been working with WinPE pretty intensly since it's introduction during Windows XP development through the development of "Interim" WinPE announced at last year's WinHEC. Nothing in this session came as much of a suprise with the exception that MS is saying that the .NET framework can be added to WinPE. They don't provide support or a mechanism, but have stated that is can be and has been done. I'll have to take a look at that, maybe leveraging the Windows XP Embedded .NET framework component to disect exactly how it can be added to WinPE. Once again, we got some mud in our (HP) eye for not supporting high-speed USB 2.0 boot capability in our BIOS. Hopefully we'll get there sooner than later since UFD's are taking off so rapidly. MS also alluded that more WinPE details for Longhorn, including booting WinPE from MS's new WIM image format, would be revealed at the PDC - I guess I'll have to start begging to go to LA again :). The session finished with two demos from ISV's using WinPE for diagnostics and backup/recovery. It's interesting to see how ISV's/IHV's are adopting and implementing WinPE in solutions.
Bluetooth and USB
I wan't able to find any sessions during this timeslot that directly related to my job or workgroup, so I thought I'd attend this session since it sounded interesting. There was a very brief update on the updates to USB and IEEE 1394 for Longhorn. For USB 2.0 Microsoft is doing a complete rewrite of USBHUB.SYS. Later in the day I would learn that this was due, in large part, to power managment enhancements. MS also plans to enable kernel debugging via USB 2.0. I loved hearing this since debugging on legacy-free systems has always presented a challenge. Apparently there was a Driver DevCon session on this, so I'll have to try and track down the slide deck. The 1394 update was even more brief, simply stating that IP addressing would be removed from 1394 in Longhorn. As for Bluetooth, the main emphasis was to being looking at the enhancements that have already been added to XP SP2 and to stop using COM ports for Bluetooth applications (use RFCOM? and sockets instead). The Longhorn updates include stack improvements, improved channel interference avoidance with 802.11, new faster EDR radio, and extensibility features. The extensibility features will include SCO driver development (for Bluetooth headsets), a service discovery protocol, L2CAP, and a new Driver Development Interface which simplifies application development.
Multicore Processor Technology - Maximizing Performance in a CPU Constrained World
In short, this session discussed the power and thermal envelope considerations in respect to processor performance of daul-core versus single core processors. It was presented by AMD and was very AMD architecture centric. The key take away was that a dual-core processor can run with the same power consumption and thermal conditions at 400MHz less than a single core processor. However, even with the 400 MHz difference, there are significant performance gains.
Dynamic Partitioning and Windows Longhorn
Nope, this wasn't about disk partitioning and Virtual Disk Services. I guess I should have looked in the conference guide. I have to admit I was kind of suspiscious when I met several enterprise server guys in the audience. I ended up leaving early and moving next door into:
Longhorn Power Management
I arrived a little late, but here's the rundown on power managment enhancements in Longhorn. Power profile management will be updated to include management/configuration from group policy, powercfg.exe, etc. No word on whether the power management API will be updated (or the lib and header files fixed!). Longhorn will also include a better mechanism for handling a power profile when no users are interactively logged on to the system. MS is also updating processor power management which will include a rewrite of existing processor drivrers (p3.sys, amdk7.sys). Longhorn will also include an improved UX with simplified shutdown/sleep UI, battery meter, hung app resolution, etc. The new UX will also include OEM extensibility. OEMs will have enhanced opportunities for adding/configuring power schemes, control panel applet property sheets, etc. One interesting point was that the new default settings are STILL not EStar compliant.
System Performance Assessment Tools for Windows Longhorn
Longhorn will introduce a new paradigm of scaling OS functionality in respect to hardware capabilities. Today, application developers need to do custom detection of hardware detection and usually dumb-down their apps to the lowest common denominator. MS is adding an infrastructure (cmd line util, API, WMI provider) to provide some basic system metrics for hardware assessment. The basic metrics are graphics performance (used to determine which Aero model the graphics card can support), memory, processor, and storage. The command utility, winstat.exe, will produce XML output that IHV's and ISV's can read to determine if the system is capable of advanced features included in applications without having to write their own assessment code. Winstat.exe is included on the WinHEC build of Longhorn and documentation was included on the conference proceedings CD, so I'm going have to play with this on a few of our systems see how Longhorn ready they are. Seeing that MS was using our systems for several of their Longhorn demos, I'm thinking we're pretty close :)
Longhorn OS Deployment and Manufacturability
The presenter used to be our TAM, so I had some inside info before attending this session so I didn't take too many notes. The key information is that Microsoft is placing new emphasis on OEM and corporate deployment scenarios on Longhorn, rather than these scenarios being an afterthought once the retail install was developed. Longhorn will inclue the OPK (with new and improved tools for image management, deployment and maintainence), and will introduce the WAIK, an OPK like package for enterprise level customers who have a tendency to ask OEMs for copies of the OPK (which we can't legally give them). This session also covered the "world-wide binary" concept. Longhorn will separate code from resources, allow a language-generic base image that uses MUI for translation. This will finally fix the problem of creating and managing an image per language. The session also glanced over WinPE updated that were presented in detail in the morning and introduced WDS (Windows Deployment Services), the eventual replacement for RIS.
x64 Party
Gibson, Intel, and Cakewalk hosted this year's party at EMP. It wasn't quite as fun as last year's party, but still a good time. See pics below.
Well, I'm off to finish up the second half of day 3. I'll try and post the day 3 summary tonight.
Guitar Tower 1
Guitar Tower 2
Sky Church Jellyfish
Sky Church Stage Side
Sky Church Stage Center
Space Needle
WinHEC Day 1
[Posted on my MSN space on April 26, 2005]
Now for the real deal. You gotta love the time difference on the West Coast. I was actually able to roll out of bed at 6:30 and function without too much difficulty.
As usual, WinHEC kicked off with a keynote by Bill Gates (and others). It was the usual smoke and mirrors, but it was good to see that at least conceptually, a lot of the ideas tied to WinFS (personal information managment and search) have been added back into Longhorn sans WinFS. You can view the keynote
With all due respect to the presenter (who knows infinitely more about this subject than me), this session was pretty much a wash. This ended up being a 30 minute session on current challenges with post-boot graphics driver/firmware/acpi communication and interaction, followed by Longhorn challenges. No solutions, call to action, etc. Just challenges. Not much to take home here.
Pretty good session on upcomming preboot (boot loader and OS loader) changes in Longhorn. Discussed the differences between loader behavior on traditional PC/AT systems and new EFI systems. Also presented challenges and potential solutions of systems that support both 32- and 64-bit. I have yet to meet someone outside of Microsoft or Intel who is completely sold on EFI, but this session did give some good info.
More of an informational session about the efforts of UFDA (USB Flash Device Alliance), U3, and IEEE to develop standards around UFD's. I attended this session mainly out of curiosity. HP currently uses UFD's as a restore solution for our Thin Clients and have had a handful of customer issues with UFD's that are not compatible with our FreeDOS implementation (or our internal WinPE-based implementation). The main take-away in this session is that maybe we should be participating in this effort to ease our support issues when customers try to use a new/unsupported UFD when managing their HP Thin Clients.
Normal buffet food and drinks. I didn't stick around for too long. I gave installing Longhorn on VirtualPC another unsuccessful try then called it a night after checking in with the office.
Some more photos of the event facilities, etc. I definitly love this new phone. I typically don't bring a camera to these conferences, and when I do, I rarely take pictures. Having a camera in my phone really makes it easy!
Alienware PCs
Down to the water
Real F1
F1 Game
HP Exhibit
Lunch and Exhibit Hall
Slot racing
Gibson x64 Les Paul
WinHEC Day 1
Now for the real deal. You gotta love the time difference on the West Coast. I was actually able to roll out of bed at 6:30 and function without too much difficulty.
Keynote
As usual, WinHEC kicked off with a keynote by Bill Gates (and others). It was the usual smoke and mirrors, but it was good to see that at least conceptually, a lot of the ideas tied to WinFS (personal information managment and search) have been added back into Longhorn sans WinFS. You can view the keynote
Goodbye SMI - ACPI and Graphics Driver / System Firmware Interface
With all due respect to the presenter (who knows infinitely more about this subject than me), this session was pretty much a wash. This ended up being a 30 minute session on current challenges with post-boot graphics driver/firmware/acpi communication and interaction, followed by Longhorn challenges. No solutions, call to action, etc. Just challenges. Not much to take home here.
Pre-OS Firmware for the Longhorn Boot Environment
Pretty good session on upcomming preboot (boot loader and OS loader) changes in Longhorn. Discussed the differences between loader behavior on traditional PC/AT systems and new EFI systems. Also presented challenges and potential solutions of systems that support both 32- and 64-bit. I have yet to meet someone outside of Microsoft or Intel who is completely sold on EFI, but this session did give some good info.
USB Flash Drive Standardization Effort
More of an informational session about the efforts of UFDA (USB Flash Device Alliance), U3, and IEEE to develop standards around UFD's. I attended this session mainly out of curiosity. HP currently uses UFD's as a restore solution for our Thin Clients and have had a handful of customer issues with UFD's that are not compatible with our FreeDOS implementation (or our internal WinPE-based implementation). The main take-away in this session is that maybe we should be participating in this effort to ease our support issues when customers try to use a new/unsupported UFD when managing their HP Thin Clients.
Welcome Reception
Normal buffet food and drinks. I didn't stick around for too long. I gave installing Longhorn on VirtualPC another unsuccessful try then called it a night after checking in with the office.
Some more photos of the event facilities, etc. I definitly love this new phone. I typically don't bring a camera to these conferences, and when I do, I rarely take pictures. Having a camera in my phone really makes it easy!
Alienware PCs
Down to the water
Real F1
F1 Game
HP Exhibit
Lunch and Exhibit Hall
Slot racing
Gibson x64 Les Paul
WinHEC Day 0
[Published on my MSN space on April 26, 2005]
I planned on giving a blow-by-blow of WinHEC, but I've had trouble logging into my space and never configured it for email posting. I was finally able to get in from the Internet Cafe here are WinHEC.
Day 0 (Sunday) is typically a non-event. Travel, find the hotel, check-in at the conference, sort through the swag bag, etc.
Travel was particularly painful (still better than traveling through the So. Cal fires for PDC 03) since I was in Ft. Worth on Sunday morning and flew out of Houston Sunday afternoon. After four hours in the car, I sat in the airport for a couple hours then spent four more hours in the plane.
Checking in at the conference was pretty smooth; better than in the past. MS mailed out badges prior to the conference so the only thing I really had to do was grab by bag and go.
The swag bag is back to a traditional laptop case (one-arm bandit) rather than the backpacks that have been handed out at the last few WinHECs. I actually prefer it that way. The software includes some x64 stuff, driver development and test goodies (DDK and WDF) and new Longhorn bits. MS also included a hard copy of their PC design guides. I haven't seen one of these since WinME came out.
I tried to install Longhorn in VirtualPC to no avail. First off, it looks like Longhorn setup cannot create partitions on a VPC Virtual Hard Disk. I was able to use an existing Virtual Hard Disk with an NTFS partition, but setup simple runs for ever. I let it run overnight and finally I had enough and canceled out of it. I'll try to install it on actual hardware when I get back to Houston.
The remainder of the day was spent getting settled into the hotel, so there's not much to tell. Here are some pics at the Hotel.
Image 1
Image 2
Image 3
Image 4
I planned on giving a blow-by-blow of WinHEC, but I've had trouble logging into my space and never configured it for email posting. I was finally able to get in from the Internet Cafe here are WinHEC.
Day 0 (Sunday) is typically a non-event. Travel, find the hotel, check-in at the conference, sort through the swag bag, etc.
Travel was particularly painful (still better than traveling through the So. Cal fires for PDC 03) since I was in Ft. Worth on Sunday morning and flew out of Houston Sunday afternoon. After four hours in the car, I sat in the airport for a couple hours then spent four more hours in the plane.
Checking in at the conference was pretty smooth; better than in the past. MS mailed out badges prior to the conference so the only thing I really had to do was grab by bag and go.
The swag bag is back to a traditional laptop case (one-arm bandit) rather than the backpacks that have been handed out at the last few WinHECs. I actually prefer it that way. The software includes some x64 stuff, driver development and test goodies (DDK and WDF) and new Longhorn bits. MS also included a hard copy of their PC design guides. I haven't seen one of these since WinME came out.
I tried to install Longhorn in VirtualPC to no avail. First off, it looks like Longhorn setup cannot create partitions on a VPC Virtual Hard Disk. I was able to use an existing Virtual Hard Disk with an NTFS partition, but setup simple runs for ever. I let it run overnight and finally I had enough and canceled out of it. I'll try to install it on actual hardware when I get back to Houston.
The remainder of the day was spent getting settled into the hotel, so there's not much to tell. Here are some pics at the Hotel.
Image 1
Image 2
Image 3
Image 4
Playing with Visual Studio.NET 2005 Beta 2
[Published on my MSN space on April 20, 2005]I've been playing with the newly-released Beta 2 version of Visual Studio 2005. As a quick little project, I create a host application for the the Microsoft RDP (Terminal Services) ActiveX control. Instead of worrying about custom forms for all of the properties associated with the RDP client control, I've shoe-horned everything into a property grid control. Check out the pics for details.
Image 1
Image 2
Image 3
Image 1
Image 2
Image 3
Subscribe to:
Posts (Atom)