January, 2012

  • The Old New Thing

    The new business model: Intentional billing errors


    Just in the last month, I had to call a bank to reverse four erroneous "Account Maintenance Fees" across two different accounts. It appears that intentional billing errors is the new business model for our struggling economy. (For the record, although I am responsible for maintaining these accounts, I did not open the accounts at the bank in question. My personal account is at a credit union.)

    One of my friends remarked, "I got only two. They must not really be trying yet."

    Many years ago, back when the dot-com bubble appeared unpoppable, a different friend of mine happened to meet somebody who sheepishly admitted that one of his previous jobs was at a what-we-can-euphemistically-call "adult online entertainment" site, where he was responsible for developing algorithms to determine which customers could safely be double- or even triple-billed.

  • The Old New Thing

    Why don't ZIP files have the FILE_ATTRIBUTE_COMPRESSED attribute?


    A customer reported that when they called Get­File­Attributes on a ZIP file, the FILE_ATTRIBUTE_COMPRESSED attribute was not returned. But ZIP files are compressed. Why isn't the FILE_ATTRIBUTE_COMPRESSED attribute being set?

    Because FILE_ATTRIBUTE_COMPRESSED tells you whether the file was compressed by the file system. It is not a flag which describes the semantics of the bytes stored in the file. After all, the file system doesn't know that this particular collection of bytes is a ZIP file and contains data that was compressed externally. Who knows, maybe it's just some uncompressed file that just happens to look superficially like a ZIP file (but isn't)?

    If a text file consists of the string "ADTUR ADKUH", is this a compressed file? Maybe it's somebody's product key, in which it isn't compressed. Or maybe it is short for "Await instructions before taking further action. Acknowledge receipt of this telegram by wire." That's an example of a commercial code, used to save telegram transmission costs by compressing frequently-used business phrases into five-letter pseudo-words.

    The file system doesn't try to figure out whether a particular sequence of bytes it has been asked to store was externally compressed. It just stores the bytes on disk, perhaps after performing its own internal compression, and if that internal compression was performed (even if it didn't actually result in any compression), the FILE_ATTRIBUTE_COMPRESSED attribute is set.

    Similarly, the FILE_ATTRIBUTE_ENCRYPTED attribute is set if the file contents were encrypted by the file system. If encryption took place externally, then the attribute is not set because the file system doesn't know that the byte sequence it was asked to store represented encrypted data.

    (Note that many special-purpose file formats, such as DOCX, JAR, JPG, and PNG, are internally compressed, even though they are not advertised as such.)

  • The Old New Thing

    Exploiting the inattentive: The Xbox Kinect Premium Starter Kit


    The name of the product is the Xbox Kinect™ Premium Starter Kit. The promotional images and box images show an Xbox Kinect device. But if you look closely, you'll see that the Xbox Kinect™ Premium Starter Kit does not come with an Xbox Kinect.

  • The Old New Thing

    Why wasn't the Windows 95 shell prototyped on Windows NT?


    Carlos wonders why the Windows 95 shell was prototyped as 16-bit code running on the still-under-development 32-bit kernel, USER, and GDI as opposed to being prototyped as fully 32-bit code on Windows NT.

    There were a number of reasons, some good, some bad.

    One reason was that the Windows 95 shell was being developed by the Windows 95 team, which was an outgrowth of the Windows 3.1 team. That meant that they had Windows 3.1-class hardware. And the hardware requirements of Windows NT were significantly higher than the hardware requirements of Windows 3.1. Here's a table for comparison:

    Platform RAM
    Minimum Recommended
    Windows 3.1 2MB 4MB
    Windows NT 3.1 12MB 16MB
    Windows 95 4MB 8MB

    The Windows 3.1 team adhered to the principle that the team members' machines, as a general rule, were as powerful as the recommended hardware requirements. If you asked really nicely, you were permitted to exceed that, but not by too much, with one notable exception. Think of it as performance dogfood. If Windows was unusable on the stated recommended hardware requirements, the entire team felt it because that's what they were running. (When Windows 95 shipped, my primary machine was a 486/DX50 with 8MB of RAM. My test machine was a 386 with 4MB of RAM. The combined computing power and storage capacity of all the machines in my office is now exceeded by your cell phone.)

    Okay, so you just finished Windows 3.1, and all of the team members currently have 4MB machines, with a few lucky people that have a whopping 8MB of RAM. If you decided to do your prototype work on Windows NT, that would mean tripling the amount of memory in most of the computers just to meet the minimum requirements for Windows NT. And you can't say that "Well, you would have had to pay for all that RAM anyway," because look at that chart: Windows 95's final hardware requirements were still lower than Windows NT's minimum!

    Spending all that money to upgrade the computers for something that was just a temporary situation anyway seemed like a bad way of spending your hardware budget.

    From the software development side, prototyping the new shell on Windows NT was not practical because Windows 95 introduced a whole bunch of new features to Win32, features which didn't exist in Windows NT. Part of the goal of the prototype was to exercise these new features, things we take for granted nowadays like Register­Class­Ex and WM_MOVING and the Close button in the upper right corner. Those features didn't exist in Windows NT; if you wanted to develop the prototype on Windows NT, somebody would have had to port them and build a special "throwaway" version of Windows NT for the Windows 95 team to use. That means devoting some people to learning a whole new code base and development environment (and buying lots more hardware) to add features that they had no intention of shipping.

    It was much more cost-effective to do the prototyping of the Windows 95 shell on Windows 95. You could see if a design led to poor performance and deal with it before things went too far in the wrong direction. You could use those fancy new functions in kernel, USER, and GDI, which is great because that meant that you would start finding bugs in those fancy new functions, you would start finding design flaws in those fancy new functions. If the shell team needed a new feature from the window manager or the kernel, they could just ask for it, and then they could start using it and file bugs when it didn't work the way they wanted. All the effort was for real. Nothing was being thrown away except for the stuff inside #ifdef WIN16 blocks, which was kept to a minimum.

    All through the shell prototyping effort, the code was compiled both with and without #define WIN16, and as the kernel team worked on supporting 32-bit processes, they had this program sitting there waiting to go that they could try out. And not some dorky Hello world program but a real program that does interesting things. (They couldn't use any of the Windows NT built-in programs because those were Unicode-based, and Windows 95 didn't support Unicode.)

    Maybe those were bad reasons, but that was the thinking.

Page 4 of 4 (34 items) 1234