Holy cow, I wrote a book!
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.
A customer reported that when they called
on a ZIP file,
attribute was not returned.
But ZIP files are compressed.
Why isn't the
FILE_ATTRIBUTE_COMPRESSED attribute being set?
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
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),
FILE_ATTRIBUTE_COMPRESSED attribute is set.
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
(Note that many special-purpose file formats, such as
are internally compressed,
even though they are not advertised as such.)
The name of the product is the
Xbox Kinect™ Premium Starter Kit.
and box images
show an Xbox Kinect
But if you look closely, you'll see that the
Xbox Kinect™ Premium Starter Kit
does not come with an Xbox Kinect.
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:
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,
Think of it as performance
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
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
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
Maybe those were bad reasons, but that was the thinking.