Welcome to MSDN Blogs Sign in | Join | Help

Just a quick note that I've moved my blog to WordPress: http://tomarcher.wordpress.com/

On 25 July 2007, I officially started my new job as a Senior MVP Lead!! While I enjoyed my time as a Program Manager on the Windows SDK team (where I was responsible for the .NET Framework and Platform SDK Tools, C++ compilers and reference assemblies), I've always had an affinity for community work - whether it be running Web sites, writing books, or speaking at user-groups. In fact, one of my favorite accomplishments was being awarded as a Visual C++ MVP where my MVP Lead (Eric Sassaman) is now a teammate!

I will have two main responsibilities on the team to start with:

  • MVP Lead for the Windows SDK and the Windows Server Customer Experience. Due to my knowledge of the Windows SDK and my contacts on the team, Eric (the previous MVP Lead) was gracious enough to give this technology over to me. (Thanks Eric!) The Windows Server Customer Experience is made up of a group of MVPs who are mainly focused on user-group activities surrounding IT Pro needs, which segues perfectly into my second main responsibility.
  • Project Manager driving the "Offline MVP Discovery" task. Offline MVPs are those that have a community impact outside of the Internet/Web - such as trainers, authors, public speakers, user-group coordinators, etc. Therefore, my job will be to work with the rest of our MVP Program team to determine the best way to find, reward and enable these MVPs.

In the coming weeks, I look to get back into my blogging and article writing where - among other things - I'll write about the MVP program, my particular responsibilities and whatever cool thing I bump into here at Microsoft that I think others might find interesting.

0 Comments
Filed under:

The Windows SDK team has now released their September CTP to match the Windows Vista September CTP. While Windows Vista September CTP is only available to beta and TAP members, you can use the Windows SDK on "downlevel" machines - Windows XP SP1 or Windows Server 2003 (SP1 or R2). You can find all the links you need for the Windows Vista and .NET 3.0 development tools in my Compatibility Matrix blog post.

Speaking of that matrix, I wrote that blog post a couple of months ago (when July CTP released) to try and mitigate the confusion caused by having three concurrent CTPs/Betas of Windows Vista and the various .NET 3.0 development tools. The scenario of having multiple supported CTPs/Betas was an anomoly so I didn't anticipate updating that blog entry. However, the matrix has proven so popular that I've decided to continue updating it through RTM with each of our Windows Vista and .NET 3.0 development tool releases.

Windows Vista, .NET 3.0 and Windows SDK Compatibility Matrix

From the standpoint of someone working at Microsoft and responsible for the Windows SDK, this is incredible news. We are basically acquiring some of the best tools for that space (low-level, hard-core devs) as well as the services of two very talented people in Mark Russinovich and Bryce Cogswell. (I actually had the pleasure of meeting Mark some years ago when I ran CodeGuru and on top of being extremely intelligent he's also a very cool person).

I don't know what this will mean to who the Winternal and Sysinternals tools will ship in the future - as part of the Windows SDK?? - but will post here as soon as I know something that I can share.

[28 September 2006 Update] The Windows Vista September CTP has been released to beta members. There is a matching September CTP from the .NET 3.0 Runtime Components, Windows SDK, "Orcas" Tools and Workflow Extensions to Visual Studio 2005.

I originally wrote this blog entry to help folks reconcile the differences between three concurrent releases of Windows Vista - each of which had different release points (public vs. MSDN vs. beta-only) - with the various moving parts that developers needed (.NET 3.0 Runtime Components, Windows SDK and Visual Studio 2005 Extensions). Due to popular demand, I've decided to continue updating it through RTM with each release of the various products.

Note: CTPs are generally removed once superceded by two releases. Therefore, this blog entry will be updated to remove the links to those releases which are no longer available from our servers.

Below, I’ve listed the builds in terms of what works with each operating system and development/runtime environment to help you decide which build you need. Once you know which build you wish to install, you can then use the Download Locations Matrix to locate the download pages/links. The last section then enumerates some key points regarding each build milestone.

Determining the Build that is Right for You

Are you setting up this environment for Windows Vista?
  • Is Windows Vista September CTP the most current build you have access to? (Beta Members and CPP) September CTP
  • Is Windows Vista RC1 the most current build you have access to? (MSDN Subscription, Beta Members and CPP) RC1
  • Is Windows Vista Beta 2 the most current build you have access to? (While the Windows Vista Beta 2 is publicly available to anyone, the June CTP requires a beta membership and July CTP requires either beta membership or an MSDN subscription) Beta 2
  • Do you have access to the Windows Vista June and July CTP builds and want the complete set of matching Windows Vista/.NET 3.0 development bits? June CTP (There is no July CTP build of the “Orcas” Development Tools for the .NET Framework 3.0)
  • Do you have access to Windows Vista July CTP and want the matching Windows Vista/.NET 3.0 development bits even though they do not contain the “Orcas” Development Tools for the .NET Framework 3.0? July CTP
Are you setting up this environment for Windows XP SP2 or Windows 2003 Server?
  • Do you want the latest complete set of matching .NET 3.0 development bits? September CTP

Download Locations Matrix

To use this matrix, simply locate the row that matches the operating system and build milestone that you're targeting (shown in the first column of each row). Then from left to right download and install each desired tool on that row with the following considerations:
  • If you want to run (not develop .NET 3.0 applications), you only need the .NET 3.0 Runtime Components for the desired build milestone. (The other downloads are for developing native and .NET 3.0 applications)
  • If you want to develop native-only (non.NET) applications, you only need the Windows SDK for the desired build milestone.
  • "Orcas" Tools for .NET 3.0 Development is only needed if you are writing Windows Presentation Foundation applications and are using a released (non beta) copy of Visual Studio 2005 (including the Express Editions)
  • Windows Workflow Foundation (WF) Extensions to Visual Studio is only needed if you are writing Windows Workflow Foundation applications and are using a released (non beta) copy of Visual Studio 2005 (including the Express Editions)
Note: Since these are all "prerelease bits", it is highly recommended that you install these products/technologies on a non-production, test machine and remove any previous versions before installing.

Operating System .NET 3.0 Runtime Components Windows SDK "Orcas" Tools for .NET 3.0 WF Extensions to Visual Studio
 Vista - September CTP (5728) Sept CTP (4506.03 - installed by O/S) Sept CTP (5728.0.4) Sept CTP Release Candidate 5
 Vista - RC1 (5600) RC1 (4324.17 - installed by O/S) RC1 (5536.0.2) RC1 Release Candidate 5
 Vista - Pre RC1 (5536) RC1 (4324.17 - installed by O/S) None None None
 Vista - July CTP (5472.5) July CTP (4306 - installed by O/S) July CTP (5472.2.1) None Release Candidate 4
 Vista - June CTP (5456) June CTP (4131.06 installed by O/S) June CTP (5456.3) June CTP Release Candidate 2
 Vista - Beta 2 (5384.4) Beta 2 (installed by O/S) Beta 2 (5383.1.1) Beta 2 Beta 2.2
 
 XP (SP2) or Win2K3 Sept CTP (4506.03) Sept CTP (5728.0.4) Sept CTP Release Candidate 5
 XP (SP2) or Win2K3 RC1 (4324.17) RC1 (5536.0.2) RC1 Release Candidate 5
 XP (SP2) or Win2K3 July CTP (4307) July CTP (5472.2.1) None Release Candidate 4
 XP (SP2) or Win2K3 June CTP (4131.06) June CTP (5456.3) June CTP Release Candidate 2
 XP (SP2) or Win2K3 Beta 2 Beta 2 (5383.1.1) Beta 2 Beta 2.2

Build Notes

Here are some key notes for each currently published build milestone for Windows Vista and the .NET 3.0 Framework development tools.

Windows Vista Pre RC1

  • Windows Vista Build 5536 was a prerelease for RC1 directed at end-users (non developers).
  • There were no released matching developer bits (Windows SDK, Visual Studio 2005 Extensions, etc.)
July 2006 CTP
  • Windows Vista July CTP (5472.5) is only available for MSDN subscribers and beta members
  • The July CTP includes builds of the .NET Framework 3.0 Runtime Components and Windows SDK for use with Windows Vista July CTP (5472.5), Windows XP or Windows 2003 Server
  • There is no July CTP build of the “Orcas” Development Tools for the .NET Framework 3.0
  • The July CTP builds of .NET Framework 3.0 Runtime Components and Windows SDK are not supported for .NET 3.0 development on Windows Vista Beta 2 or Windows Vista June CTP
June 2006 CTP
  • Windows Vista June CTP (5456) is only available to beta members
  • There are public downloads for June CTP builds of .NET Framework 3.0 Runtime Components, Windows SDK and “Orcas” Development Tools for the .NET Framework 3.0 for use with Windows Vista June CTP (5456), Windows XP or Windows 2003 Server
  • The June CTP builds of .NET Framework 3.0 Runtime Components, Windows SDK and “Orcas” Development Tools for the .NET Framework 3.0 are not supported for .NET Framework 3.0 development on Windows Vista Beta 2
Beta 2
  • Windows Vista Beta 2 (Build 5384) is the most current public build of the Vista operating system that is available to anyone.
  • There are matching bits for the .NET Framework 3.0 Runtime Components, Windows SDK, “Orcas” Development Tools for the .NET Framework 3.0 and the Visual Studio 2005 Extensions for Windows Workflow Foundation bits that are also publicly available.
  • If this is the most current version of Windows Vista that you can access (the June CTP requires beta membership and the July CTP requires beta membership or an MSDN subscription), then you should only use the matching Beta 2 bits for the aforementioned runtime components and development tools.

 

Hot on the heels of last month's public Beta 2 release, we've released a June 2006 CTP for the Windows SDK. Note that this build of the Windows SDK is to be used with the following:

Important Notes

While we all like to play with the latest and greatest, there are quite a few moving parts to the whole Windows Vista/Windows SDK/.NET Framework 3.0 combination. Therefore, please read the following to ensure that you take everything into account before downloading and installing the latest SDK - and as always with beta and CTP software, we highly recommended only installing on a non-production, clean machine.
  • As noted, this CTP is intended for users of Windows Vista build 5456 and the .NET Framework 3.0 Runtime June CTP. This CTP contains updates for native Win32 developers, including improvements to documentation and samples.
  • This build is not supported for users running the Windows Vista Beta 2 for .NET Framework 3.0 development, but it will work for native Win32 applications on Windows Vista Beta 2.
  • If you are using Windows Vista Beta 2 for .NET Framework 3.0 development, we recommend that you do not install this version of the SDK and instead use the Windows SDK Beta 2 release. The .NET Framework 3.0 June CTP runtime is a later version than the one that ships with Windows Vista Beta 2, and code that uses the .NET Framework 3.0 will not work with this CTP.
  • Finally, refer to the ReadMe file for more information on known issues.

Additional Information

For information on what to install for different scenarios (e.g., "I'm looking to develop native-only apps for Windows Vista", etc.), please refer to the Get the Beta page.
19 Comments
Filed under:
Not much to say here except ... "YAY!!!"

You can finally download the Vista Beta 2 bits by enrolling in the Customer Preview Program. Note that the WinFX Runtime Components (needed to run WinFX apps) are automatically installed in this Windows Vista build. Therefore, if you're looking to just run WinFX applications on Windows Vista, installing Vista is all you need to do.

I would strongly suggest using the Get the Beta page to determine what to download and in what order as it covers the different scenarios - such as "I want to develop WinFX apps" , "I want to develop only native (non .NET) apps", etc.

Also note that the links on the Get the Beta page are to the bits that are in alignment with Vista Beta 2.

Enjoy!
Tom

Back in April, I posted a blog entry on the ReadyBoost feature - the Windows Vista feature that allows you to use a USB key as virtual memory in order to enhance performance. While I originally intended the post to be an overview of ReadyBoost, it proved quite popular and garnered quite a few questions seeking more detail. I apologize that it's taken this long, but I've finally tracked down "the man" who could provide the answers - Matt Ayers, who is the Program Manager in the Microsoft Windows Client Performance group and basically owns the ReadyBoost feature.

Instead of updating the original post, I created this new post entry that will be the home of the Q&A I receive. That way, people won't have to wade through opinions and comments and can come to this post to see only Q&A. 

Note: Matt will be speaking at Tech*Ed where he will present a session on on Vista Perf Improvements (ReadyBoost, ReadyDrive and SuperFetch – CLI312)

From Matt Ayers:

"I'm the Program Manager in the Microsoft Windows Client Performance group and own the ReadyBoost feature. I wanted to give some offical answers based on the excellent questions and discussions that I've seen in this blog, to date. Also, I'll be using this as a starting point for the official ReadyBoost FAQ.

Overall, as many posters have pointed out, the feature is designed to improve small random I/O for people who lack the expansion slots, money, and or technical expertise to add additional RAM. As y’all know, adding RAM is still the best way to relieve memory pressure.

Thanks, again, for your interest, questions and ideas."


 

Q: What perf do you need on your device?
A: 2.5MB/sec throughput for 4K random reads and 1.75MB/sec throughput for 512K random writes

Q: My device says 12MB/sec (or 133x or something else) on the package but windows says that it isn't fast enough to use as a ReadyBoost device... why?
A: Two possible reasons:
  1. The numbers measure sequential performance and we measure random. We've seen devices that have great sequential perf, but horrible random
  2. The performance isn't consistantly fast across the entire device. Some devices have 128M of lightning fast flash and the rest of the device is really slow. This is fine for some applications but not ReadyBoost.


Q: What's the largest amount of flash that I can use for ReadyBoost?
A: You can use up to 4GB of flash for ReadyBoost (which turns out to be 8GB of cache w/ the compression)

Q: Why can't I use more than 4GB of flash?
A: The FAT32 filesystem limits our ReadyBoost.sfcache file to 4GB

Q: What's the smallest ReadyBoost cache that I can use
A: The smallest cache is 256MB (well, 250 after formatting). Post beta2, we may drop it another 10 MB or so.

Q: Ok... 256M-4GB is a pretty big range... any recommendations?
A: Yes. We recommend a 1:1 ratio of flash to system memory at the low end and as high as 2.5:1 flash to system memory. Higher than that and you won't see much benefit.

Q: Isn't this just putting the paging file onto a flash disk?
A: Not really - the file is still backed on disk. This is a cache - if the data is not found in the ReadyBoost cache, we fall back to the HDD.

Q: Aren't Hard Disks faster than flash? My HDD has 80MB/sec throughput.
A: Hard drives are great for large sequential I/O. For those situations, ReadyBoost gets out of the way. We concentrate on improving the performance of small, random I/Os, like paging to and from disk.

Q: What happens when you remove the drive?
A: When a surprise remove event occurs and we can't find the drive, we fall back to disk. Again, all pages on the device are backed by a page on disk. No exceptions. This isn't a separate page file store, but rather a cache to speed up access to frequently used data.

Q: Isn't user data on a removable device a security risk?
A: This was one of our first concerns and to mitigate this risk, we use AES-128 to encrypt everything that we write to the device.

Q: Won't this wear out the drive?
A: Nope. We're aware of the lifecycle issues with flash drives and are smart about how and when we do our writes to the device. Our research shows that we will get at least 10+ years out of flash devices that we support.

Q: Can use use multiple devices for EMDs?
A: Nope. We've limited Vista to one ReadyBoost per machine

Q: Why just one device?
A: Time and quality. Since this is the first revision of the feature, we decided to focus on making the single device exceptional, without the difficulties of managing multiple caches. We like the idea, though, and it's under consideration for future versions.

Q: Do you support SD/CF/memory stick/MMC/etc.?
A: Mostly. In beta2, we added support for a small number of SD/CF cards on internal USB2 & PCIe busses. RC1 has a much broader support range.

Q: Why don't you support SD on my USB2.0 external card reader?
A: We unfortunately don't support external card readers - there were some technical hurdles that we didn't have time to address. In general, if a card reader shows a drive without media in it (like a floppy drive or CD ROM does), we can't use it for ReadyBoost.

Q: Will it support all USB drives, regardless of how they are ID'd to the OS ("hard disk drive" or "Device with Removable Storage")?
A: We have no way to tell what is on the other end of a USB cable so we do some basic size checks (since no one has a 200GB flash device ;-) ) and then perform our speed tests. HDD will not, however, pass our speed tests, and there is no benefit to using a USB HDD for ReadyBoost.

Q: Can you use an mp3 player to speed up your system?
A: Not currently. MP3 players use the 'plays for sure' interfaces to expose themselves to Windows. We require that the device appear as a disk volume. These aren't currently compatible.

Q: How much of a speed increase are we talking about?
A: Well, that depends. On average, a RANDOM 4K read from flash is about 10x faster than from HDD. Now, how does that translate to end-user perf? Under memory pressure and heavy disk activity, the system is much more responsive; on a 4GB machine with few applications running, the ReadyBoost effect is much less noticable.

Q: I can't get my device to work with ReadyBoost... can I lower the perf requirements?
A: Unfortunately, no. We've set the perf requirements to the lowest possible throughput that still makes your system faster. If we lowered the perf requirements, then there wouldn't be a noticeable benefit to using ReadyBoost. Remember, we're not adding memory, we're improving disk access.

Q: Which manufacturers support ReadyBoost?
A: Well, I hope that all of them do, eventually. Right now, we're working with manufacturers to create a program that will allow them to identify ReadyBoost capable devices on their packaging.

A member of another team here at Microsoft dropped by and chatted with us a bit about a great new site that enables developers to prepare for Windows Vista. This site - http://www.devReadiness.org - contains lots of great technical articles and interviews aimed at helping you get your applications ready for Windows Vista today.

Some examples of the content they have are:

  • IE 7 Compatibility Overview video that covers the basics of II7 compatibility issues
     
  • Update Advisor application that runs on an XP system and tells you if your hardware will allow you to run Windows Vista
     
  • Application Verifier that you can run to determine if your existing Windows application(s) will run on Windows Vista
     
  • Article on how UAC (User Access Control) will impact your application(s)
     
  • Hands-On Labs that walk you through the sorts of changes some application developers will need to make to ensure that their applications run on Windows Vista
     
  • ...much more...

If you're looking to start supporting your applications on Windows Vista, you'll definitely want to check out this site to stay ahead of the building customer demand for the next generation of Windows systems.

10 Comments
Filed under:
In addition to the launch of the first public Windows Vista Beta since last year's PDC, we have also published a complete redesign of the MSDN Windows Vista and WinFX developer centers in order to create a seamless, unified experience for users moving from one site to another. The sites also reflect the look and feel of the Windows Vista UI, and the Windows Vista site on www.microsoft.com.

There were many goals associated with this project, including

  • Ensuring that key technical information is more discoverable with redesigned site navigation
  • Coordination with other site teams to launch a set of sites that are visually connected, similar in messaging, but audience-appropriate
  • Creating a seamless, unified experience for users moving from one site to another – whether that be from Vista to WinFX or among the various audience-specific Vista sites (MSDN, TechNet and Microsoft.com)
  • Supporting a newer, cleaner "look and feel"

While the look and feel you see today is a huge step in the right direction – especially in terms of helping developers find the information they need more quickly – we're definitely not finished. Over the next couple of weeks, stay tuned for the following additions/modifications to the Vista and WinFX Developer Centers.

  • Learning - The Learning section will be updated to better offer guidance and help to people new to Windows Vista development. This includes overview pages of various technologies with links to articles and hands-on labs for further discovery as well as links to training as that becomes available from the Microsoft Learning Product Group.
  • Community - As many have seen with our "CodeZone" initiative, we as a company are focusing more and more on the aggregation of various information sources to enable developers to find the help they need. In addition, product teams are more committed than ever to answering your questions on the various MSDN Forums. To that end, we're almost complete with a new Community page that will enable developers to locate all of these resources from a single page.
  • Support - Another page we've redesigned that is close to publication is the Support page that enable developers to quickly find the level of support they need from a single page

At the end of the day, our job performance is measured by whether or not we've been able to provide to you, the developer, the information you need in an easily accessible manner. Therefore, as always please feel free to email me regarding any improvements that you would like to see regarding your experience with the Windows Vista and WinFX Developer Centers.

While you will hear people state that hash codes generate a unique value for a given input, the fact is that, while difficult to accomplish, it is technically feasible to find two different data inputs that hash to the same value. However, the true determining factors regarding the effectiveness of a hash algorithm lie in the length of the generated hash code and the complexity of the data being hashed.

Let's first talk about the hash algorithms themselves. Hashing algorithms generate a fixed-length hash code regardless of the length of the input. For example, the MD5 hash function always generates hash codes that are 32 bytes in length, the SHA1 hash function generates 20-byte hash codes, SHA256 generates 256-bit (32 byte) hash codes, and so on. Therefore, since there are a limited range of possible values for a given hash code and an unlimited range of values to hash, it stands to reason that the length of the hash code generated with a given hash algorithm is directly related to the difficulty of finding two inputs that will generate the same hash code.

This is easy to prove. If n is the number of possible hash codes, we only need n + 1 distinct input values to prove that there is an overlap. Granted that for most hash functions, n is rather large so we can safely assume that for any meaningful input values, it would be very difficult to find another meaningful input that would give the same hash.

That brings me to the second point—the input value itself. It is assured that if the input is anything more involved than random data, then even if you were to find two inputs that generated the same hash value, the two inputs would have no semantic relationship to one another. This is especially evident if you are hashing text, because there are many more ways to produce gibberish than there are ways to produce meaningful words. In other words, it's extremely difficult to create random words, even harder to form sentences, and very unlikely that those sentences will form a paragraph or a document and still have it make sense.

As an example, let's say you're generating a hash code for a top-secret document that details the route of nuclear warheads for disposal. The chances of someone randomly generating words until they matched the hash code generated for the original document and producing a document that makes any sense are so small that you could accurately say it would be impossible.

Therefore, the fact that each possible hash code doesn't uniquely match an input value only comes into play when you are dealing with random (nonstructured) data. An example of this would be spyware-removal applications that determine if a file is spyware by hashing each file in a specified folder or drive and then comparing that hash value to a list of known spyware-file hash codes. In this case, relying solely on the hash code would be a mistake as the files being hashed are of varying lengths with many files having no semantic meaning (as the application is not determining the meaning of the data; only the hash code values). As a result, it would be highly recommended that these applications either match on file name before hashing the file's contents (which dramatically reduces the possibility of "false positive" results) or use a hash code with a very long output value - such as SHA256.

This brings us to the concept of password hashing. Instead of storing their users' passwords, some applications will store only the hash code for the password. When the user attempts to log into the system, the application hashes the user's input password and compares that hash value to what has been stored for the valid password. This is a very good technique because it means that the users' passwords are not stored and therefore - theoretically cannot be hacked as hash codes cannot be reverse-engineered to their pre-hashed values. However, assuming that a hacker got his hands on the password-hash file, a brute-force method could be employed by the hacker to continually generate hash codes until a code is generated that matches a hash code on the password list. The value the hacker used to generate the matching hash code could then be used to allow the hacker unauthorized access.

This is a very real risk as passwords generally have a fixed length (such as 6-10 characters). Therefore, the hacker doesn't need to generate as many hash codes as he would if attempting to regenerate the same hash code that was originally hashed for a much longer value. As a result, anyone using this technique to protect user passwords should go a step further by adding a salt, or static piece of data, to the input value before it is hashed. This would produce an almost fool-proof system as even if someone were to obtain a list of hashed passwords and were to produce a password that generated to a hash code in the list, this password would not work because when attempting to log in, the system would apply the salt and the resulting hash code would differ from that stored for the user. In other words, the hacker's input value would already be salted, but the system is expecting a non-salted value that it salts. As a result, the addition of the salt greatly increases the difficulty in cracking the passwords, because now the hacker would need to 1) steal the hash-code file, 2) know that a salt has been added, 3) know the value of the salt and 4) know exactly how the salt was added.

Therefore, while there isn't a one-to-one correlation between every possible hash code and every possible input value such that all combinations are guaranteed to be unique, hash codes are an extremely reliable means of protecting data integrity.

Related Reads: Keith Brown did a full article on securing the username token with WSE 2.0 that is a good read even if you're not doing Web Services as it talks about general security issues regarding the protection of user authentication information that is being sent over the wire.

One very cool feature of Windows Vista – especially for machines not natively equipped with the kind of horsepower to fully enjoy the rich visuals of Windows Presentation Foundation (Avalon) applications is ReadyBoost. ReadyBoost enables you to plug a USB key into your machine and have Windows Vista use it as memory. I hadn’t actually used this myself, but had heard of it long ago. When a reader emailed me asking if this was an urban legend, I decided to check it out for myself and was very impressed with how easy and seamless the process is.

Installing/Configuring the USB Key as Memory

First I took a standard USB 2.0 key (I’ll list the prerequisites shortly) and plugged it into my machine. I’m running Windows Vista Beta 2, Build 5346, but I’m told that this works with the latest CTP made available to beta and TAP members as well as MSDN Subscribers. Upon plugging the USB key into my computer, I was greeted with the standard "AutoPlay" dialog box asking how I wanted to the operating system to treat the USB key. However, with ReadyBoost I get the additional option (circled below in the screen capture) of using the key to "speed up my system".

AutoPlay dialog box displayed when a valid USB Key is inserted into a machine running Windows Vista

Once I click the "Speed up my system" option, the Properties dialog box for the device is displayed where I can specify to start/stop ReadyBoost usage of the device and how much space I want used as a memory cache. (Actually, according to one of the Product Specialists here, this space is used more as a flash-based page file than true RAM, but the impact is that the more space you choose here, the more benefit you’ll get in terms of overall system performance.)

The device Properties dialog box allows you to turn on/off ReadyBoost for that device and to set the exact size of the cache.

(In order to return to this dialog box, open the Computer window, right-click the drive (F: in this case) and select Properties. From there, click the Memory tab (as shown in the previous screen capture and adjust the settings as needed).

For the inquisitive, opening the drive in an Explorer window reveals that ReadyBoost has created a cache file of the specified size.

Example cache file created by ReadyBoost on a USB Key

Things to Know About ReadyBoost

If you have a USB key configured to use ReadyBoost and then insert a second key, Windows Vista will display the Properties dialog box where you’ll see the message on the Memory tab as shown in the following screen capture.

Example of a USB Key that cannot be used by ReadyBoost as it doesn’t have enough free space for a cache

While ReadyBoost will work with other devices – such as SD Card, CompactFlash, etc. – I’ve only used it with a USB key and here are the baseline requirements the team gave me regarding what ReadyBoost will work with:

  • The USB Key must be at least USB 2.0
  • The device must be able to do 3.5 MB/s for 4 KB random reads uniformly across the entire device and 2.5 MB/s for 512 KB random writes uniformly across the device.
  • The USB Key has to have at least 64mb of free space

 

Update: Due to so many questions about this feature, I've tracked down the Program Manager (owner) of this feature - Matt Ayers. Matt has put together a complete ReadyBoost FAQ for everyone that I've posted in a separate blog entry. Therefore, feel free to make comments here, but if you have any questions, first check out the FAQ and if it's not answered there, post me a question and I'll see if Matt can update the FAQ with your question/answer.

From time to time, I get queries like “Why is Microsoft forcing managed code on us?” or “Why is Microsoft abandoning native code?” and so on. As MSDN is a key Microsoft public interface to developers, I thought I’d answer that from my own perspective.

 

Being a Program Manager at MSDN offers me a unique position within Microsoft as my specific job (Content Strategist) is to publish content that balances the needs of marketing and the technical product teams with our own knowledge of the target audience and the technologies involved while aligning with Microsoft’s overall business goals. Needless to say, the job can be quite challenging and at times more political than I’d prefer as I’ve been a programmer since the early 80’s and sometimes long for the days of being lost in low-level code as opposed to endless meetings. However, at the same time, I do enjoy my job very much as it enables me to see the business from many different vantage points and to have a basic understanding of why we do some of the things we do. One of those issues is the whole “managed code vs. native code” issue regarding why we promote the former much more than the latter.

 

To start with, I submit to you that there is no black and white here. We’re talking about the amount of information on managed code and managed code tools relative to native code information. In terms of native code, there are over 7,000 new APIs in the Windows SDK and every two weeks, we publish a new chapter to the Windows Vista Developer Story – a 600+ page collection of information on native SDK development. In addition, as we get closer to releasing the Windows Vista and the new Windows SDK, you’ll begin to see even more native code articles. However, most of the native code information is centralized on the Windows Vista and Visual C++ Developer Centers with the majority of information being published by MSDN being focused on managed code. Hopefully, this post will explain why – at least from my point of view.

 

Marketing –At Microsoft we have hundreds of products, but it’s no surprise that the reason we remain the most profitable software company in the world is by virtue of selling two main products - Windows and Office. In addition, it’s critical for the long-term stability of Microsoft that we also have a major impact on the Web.

 

Everything else (especially development tools) is simply a means of accomplishing those goals. An example is the Windows SDK. It’s completely free to anyone that wants to download it as it serves the greater purpose of getting developers to write Windows applications, which in turn sells more copies of Windows. In addition, you frequently see us hold training seminars that, at best, break even and might even lose money. Once again, the goal isn’t making money from these products or functions. The goal is to get information into the hands of developers so that they write Windows applications – or Web applications using Microsoft technologies.

 

There are many more examples – such as the free Visual Studio Express products, free training, free technical articles on MSDN and so on, but you get the point. The focus is always things like, “What can we do to the O/S to enable developers to create the apps they want for their customers?”, “How can we make the development tools easier to use to lower the cost of delivering that software in a timely fashion?”, etc.

 

Having said that, the latest technologies that accomplish the goals of selling Windows, pushing the Web and making it easier for developers to write Windows applications, are things like Windows Presentation Foundation, Windows Communication Foundation, Windows Workflow, etc.  

 

Therefore, most conversations between marketing and MSDN deal with focusing on these newer technologies – in the form of publishing technical articles and whitepapers written by evangelists, promoting training and seminars, providing demos and hands-on labs and so on.

 

Product Teams – This is an easy one as most likely if you’re reading my blog, you’re also a developer and realize that most developers want to work on the latest, coolest thing. Our dev teams are no different. Therefore, internally when our product team developers write for MSDN they’re generally writing about the latest technologies. In addition, the various levels of management for these product teams also focus on requesting that we more heavily promote the latest innovations and features of their products.

 

Target Audience – If you ever want the definitive answer for why we at Microsoft do something, follow the metrics. The Visual Studio and .NET Developer Centers are – by far - the two most popular Dev Centers (in terms of traffic and users). They are followed up by Windows Vista (which is gaining rapidly despite still being in beta) and VB.NET. The meaning is clear. Developers come to MSDN looking for information about managed code and Windows Vista.

 

Therefore, one way of answering the question of why we post so much managed code content (relative to native code) is via the old adage, "We don't make the news; we only report it."  Like any other company we stay in business by meeting the needs of our customers. If customers weren't asking for and responding favorably to this, we’d be going in a different direction. Therefore, it’s simply inaccurate to say that we’re forcing anything on anyone. We’re the ones reacting to what the masses have requested and right now that’s managed code and tools for developing advanced UIs in the fasted time possible.

One of the most exciting things I’ve seen since I started to work at Microsoft is how open the development teams are to listening and helping our customers when a problem arises. One case in point took place over the past couple of weeks.

 

Without stating specifics, a customer wrote me (via this blog) and asked if Windows Vista would continue to support ANSI code. He explained that his company produces a well-known imaging product that makes calls to the STI functions. (STI, or Still Image, is part of the Graphics and Multimedia APIs and provides a means of programmatically acquiring digital still images from cameras.)  Evidently, his application calls the StiCreateInstanceA function directly and while it works on Windows XP, they found that deploying and attempting to run the application on Windows Vista resulting in an (“Entry Point not Found”) error.

 

Now obviously, Windows Vista would have the shelf-life of a tsetse fly if it were not to support the countless ANSI applications in existence today. After some debugging with the customer, we determined that the XP version of the STI.DLL (5.1) was different than the Windows Vista version (6.0.5) and that his application works when he replaces the Windows Vista DLL with the XP version.

 

Therefore, this was definitely not a Windows Vista issue and I needed to communicate with the STI team. Armed with this information, I contacted the PM (Program Manager) for the STI team and, after a few back-and-forth emails, I learned that the ANSI versions of the STI functions were never originally supposed to ship with STI and were only discovered during code analysis. Once they were discovered, they were not removed, but they were never documented. In fact, the STI.H header file redefines StiCreateInstance as StiCreateInstanceW (Unicode) so that no one accidentally calls the undocumented StiCreateInstanceA (ANSI) version.

 

So how then did the customer call it? Evidently the customer’s programmer (for reasons unknown) explicitly called the StiCreateInstanceA function instead of converting the parameters to wide char so that the Unicode version could be used. I politely explained the situation to the customer and they were very cool with the globally acknowledged situation that if you use undocumented functions, you do so at your own risk.

 

However, Windows SDK PM Brent Rector made a great point. While we didn’t technically “document” the function in terms of formal documentation on MSDN, we as a company implicitly documented it by releasing it to the public in such a way that developers could make use of it and become dependent on it. At that point, I spoke to the STI PM and Lead Developer who listened to my advocacy on the part of the customer and were very open to at least considering putting the ANSI functions back. They asked that I create a bug in our internal database to track the issue and get feedback from other STI team members.

 

Will the ultimate resolution be to return the APIs. Honestly, I doubt it. First, this is the only customer that has even brought this issue up. Second, the customer has stated that this only impacts a very small piece of code and he’s migrating to full Unicode anyway. However, the key point here was that we could have easily blown the customer off with the standard reply of, “You used undocumented functions. Sorry, but we can’t help you.”, and the customer would have been cool with that. However, several people stepped up to not only ensure that we gave an acceptable answer, but that we did everything we could to do right by our customer.

 

 

18 Comments
Filed under:
Sorry for the late notice, but I've just been informed that there's a free Visual C++ 2005 certification exam available (#71-526). While this is a "beta" exam and is only good until January 31, it does count towards certification in the same way as the final version of the exam. Note that the exam can be taken using Visual C++, Visual C# or Visual Basic - you specify your desired language when the exam begins.

The story here is that Microsoft has launched a "new generation of certifications" consisting of two distinct series of credentials for .NET Framework developers:

  • Microsoft Certified Technology Specialist (MCTS) - The MCTS credential highlights your ability to develop Windows, Web, or distributed applications using the .NET Framework 2.0 and Visual Studio 2005.
  • Microsoft Certified Professional Developer (MCPD) - The MCPD credential highlights your job role, featuring your specific area of expertise and allowing you to distinguish yourself as an expert in Windows Development, Web Application Development, or Enterprise Applications Development.

To explain how these exams fit together the bigger picture:

Exam 70-526 (the "final version" of this exam") is one of two exams required for the “Microsoft Certified Technology Specialist: .NET Framework 2.0 Windows Applications” (MCTS) credential. To achieve this credential you will also need to pass exam “70-536: TS: Microsoft .NET Framework 2.0 - Application Development Foundation”.

After achieving the MCTS credential for Windows applications, you will be able to achieve the “Microsoft Certified Professional Developer: Windows Developer” (MCPD) credential by passing one additional exam: “70-548 PRO: Designing and Developing Windows-Based Applications by Using the Microsoft .NET Framework.”

Special Notes

Please be aware of the following:

  • Promotional Code and Exam Number - The exam number is 71-526 and the promotional code is TSB526
  • Passing the exam - Candidates who take and achieve a passing score in the beta exam will receive a free exam voucher for any Microsoft Certification Exam. Vouchers will be sent after exam scores are tabulated.
  • Restrictions - The beta exams are not offered in China, India or Pakistan. Please don't waste your time sending me emails about this issue as I have no control over it.

Registering For and Taking the Exam

This is an in-person exam only (not an online exam). However, there is information online about the exam itself, including a self-test evaluation that you can take to measure your preparedness.

To register for the test in your area:

  • Thomson Prometric: (800) 755-EXAM (800-755-3926)
  • Pearson VUE: 800 TEST Registration (800-837-8734)

Outside the U.S./Canada, please visit the following Web sites for registration information:

287 Comments
Filed under:
More Posts Next page »
 
Page view tracker