Common Sense 4 Common People

Elements of Inner Change

Inner change is an issue that has in one way or the other occupied the mind of each of us, at one point or another in our lives. Becoming better persons, better partners, finding what we really want and following our heart, becoming ourselves, becoming happy.

"Am I ever gonna change?"
"Will I always stay the same?"

Do these ring any bells?

There is a lot of talk about change so I can freely add to that my own point of view.

Inner Change can happen. Inner change happens.

From my personal experience I have an idea of how it happens, but...
Although you may know how change happens, you can't force it to happen.
If it is going to happen, change will happen by itself.

This does not mean that you can do nothing at all about change. Of course you can. You can do a lot. You can do a lot, but only to prepare the grounds for change to happen. You can only prepare for change. If and when it is going to happen, change will happen by itself, almost spontaneously.

If you try to force change, you only make it harder for it to happen.
This is because what we do about change is mostly at the logical level. True inner change happens at the subconsious.

We all think we are purely logical, rational beings. We are not and we can never be. We can never articulate all the reasons why we are who we are, why we do what we do, why we like what we like, mostly because there are NO reasons to articulate. No reasons to analyze, examine and then logically substitute with new reasons that will make us somebody new. It doesn't work that way.

You have most probably heard that finding oneself in a real life-threatening situation and having a narrow escape is a life changing experience. Instantly your life flashes before your eyes, instantly you reevaluate everything and all of a sudden you are a new person.

OK, you know that, now try thinking really hard of yourself being in a life-threatening situation and having a narrow escape. Does it make you a new person? Does it change you? It should, damn it! But it won't... No matter how hard you try.
Why? Because you are NOT a purely rational being. Just accept it and play on. A logical thought like the one above cannot by itself cause inner change to happen, because... it is LOGICAL and inner change happens at the subconsious.

I said that I think I know how change happens but you can't force it to happen. I briefly covered the second part, which is the most crucial to realize. So how does change happen then?

Basically it is a truly stunning and staggering... two step process:
(1) Get new input
(2) Go to step 1.

Who would guess that inner change would be as simple as that???

Here is how it works. As you see, all that the process requires from you is to get new input, mainly into your logical brain. New input, new information, broadens your understanding, your perspectives, your options, your logical reasons TO and NOT TO do things.
New input will hopefully make you a bit wiser and it will prepare the path for inner change, but will not change you by itself.

As you keep on getting new input at some point a "critical mass" will be accomplished.
Now, it IS possible for change to happen. Now, it MAY happen.

Yes, but how does change happen after all?

Well, let's discuss first HOW do you get input. The input you need can only come from other humans. Not from a video game. Discuss life with your friends, open up to a total stranger you met in a bar, discuss with the barman if you will, see a psychologist, two psychologists, read books (they are mostly written by humans), any kind of book, not just psychology or self-help. Any kind of input is worthy. Any kind of input somehow contributes to the critical mass.

It is not a matter of how much input you gather. Once you are above critical mass, you are good. How much input you've got will only determine what kind of change will happen to you. Not when it will happen.

So, once again, how and when will change happen?

The missing element, the element that cannot be included in the two-step process above, is the TRIGGER.
It is an event that will trigger the inner change in the subconsious. By event I mean either an actual event (like a life-threatening car crash), something personal a friend told you, a thought that "randomly" poped up in your head, an unusual dream, or even some lyrics in a song. Anything can be your trigger.

There is no way to force the trigger to "happen". You can only be "open" to it and give it some fair chances, tempt chance. I mean sitting at home watching TV or staying awake in bed late at night thinking things over and over don't sound very triggering. Tempt chance, don't try too hard and remember to stay just a bit reasonable :-)
I mean, attempting suicide just to see how it feels like and if anyone will come to rescue you and care for you, or quickly divorcing your wife only to find out that it is her that you really love are probably "trying extra-hard" and plain silly. Take it easy, take it slow, and fate will take you anywhere you deeply intend to go.

Haven't you heard of the saying "When a disciple is ready, the teacher will appear"?
Do you see any similarities here? Will the teacher come to teach? Or will the teacher only come to trigger the disciple and make him LEARN in his heart apart from his mind and thus make him wise? The teacher's true mastery is not the knowledge of facts, it is knowing how to create the proper triggers for the disciple.

I do believe that when we are ready to learn then the true teacher always appears, because we can finally let him appear. Because finally anyone can serve as the teacher.

Similarly I do believe that when we are ready for inner change then the trigger always appears, because we can finally let it appear. Because finally anything can act as a trigger.

Have fun!
Dimitris Staikos

Embracing Confusion

I've been feeling a bit recursive the past days, so I thought I should try to explain the word "explain".
Let's start by seeing what the infamous online dictionaries propose:

Cambridge: To make something clear or easy to understand by describing or giving information about it.
Webster's:
1. Give an explanation for.
2. State by way of explanation.
3. Serve as an excuse for
Comments section: Explanations can only be given by those with understanding of the object which is explained.

Since Webster is recursive, i.e. uses the word "explanation" while trying to describe "explain" I also looked up "explanation" to see whether it included anything more thought provoking:
1. A statement that explains; "he launched into a detailed explanation"; "he demanded that I give an account for my failure".
2. Thought that makes something comprehensible.

Option (2) is good enough for my purposes, since "thought" may as well be replaced with "statement" or "description".

The operation and workings involved in communicating information from one human to another is a topic that has been extensively analyzed, although only a few care enough to study a little about it. It's mainly those to whom communication plays an important part in their profession (salesmen, politicians, managers, etc).

The rest of us know everything by definition, so we also know how to communicate :-)

So, since I by definition know everything too, I say that both the Cambridge and Webster definitions convey very little essence. Enter my vastly superior definition :-D

Explain: To make the target audience think they understand what you think you understand.

Understanding is nothing but an illusion. It can always expand and it will always expand. Confusion expands our understanding: You thought you understood, but now you are confused and don't understand. Hey, your understanding has just expanded and what previously looked solid and clear now appears complex and mysterious. Eventually you will reach a new and higher level of "solid" understanding, which may again be expanded by confusion, etc.

They routinely say "Embrace Change", I dare say "Embrace Confusion"!
And don't forget... Confusion is an illusion as well...

Have fun!
Dimitris Staikos

Vista boasting about throughput

This is yet another of those "Explorer Copy Estimated Time" bugs, but not THE "Explorer Copy Estimated Time" bug that gets fixed by the KB938979 hotfix MS released (described here).

I've always found the concept of estimating the remaining time for a massive file copy/move operation rather intriguing, given the combinations of where the source and destination hard disks are physically located. Data transfer may temporarily slow down, or it may gradually slow down, or it may oscillate between slow and fast every minute or so (depending on who knows what). I think that deciding which is the most meaningful time window for doing the throughput calculation displayed to the user and deciding the remaining time can be very tricky.

Since it is a tricky issue I would have thought that the Vista team paid some more attention to the issue. Noone forgets the embarassing "17482634 minutes remaining", then "24 minutes remaining", then "10943 minutes remaining", etc, of Windows XP.

Anyway, earlier this evening I started a file copy over an Ethernet 100Mbps network between an old PIII 733 running Windows 2000 and my brand new Vista PC. At some point in the process I noticed the contents of the copy progress dialog:

Wow64, I thought! 5.76GB in "about 5 seconds"??? That's awesome! That's throughput greater than 1GByte/sec. Now that's what I call a confident OS :-)
At the very same time the current speed was being reported as 628KB/sec.

I decided there and then that this was "Funny Software" material, so I started to follow how will Vista recalculate the remaining time as the copy operation progresses.

A couple of minutes later, this was our status:

0.7GB of data later and Vista hadn't changed it's mind yet. The throughput seemed to improve, but I really could not take any of the throughput numbers seriously. 0.7GB at any speed that is indicated in KB/sec would have taken at least 10-15 minutes, but I definitely not waited that much before I got the second screenshot.

Then after a little while a file copy completed and there were less items remaining. It seems that the Vista team thought that was a proper place to update their statistics:

Now they are getting a bit more realistic I have to admit: 4.83GB in 30 seconds going at 1,04MB/sec. I don't know, maybe they used the buggy Excel engine to do their math.

Following futher on, it seems that they are not updating the statistics only on file conclusion:

Midway through the 9th file, after a mere 0.13GB, Vista decided that it should pump up its estimate to 1 min and 15 sec, given the fact that the throughput improved as well. That's some strange math...

When the 9th file concluded, there was yet another slightly more modest estimate:

I don't know about you, but I am really curious about the logic behind this. I mean, more than 1.5GB had been copied between the first and the last screenshots, but still Vista thinks it has super natural powers.
It kind of reminds me of some code a coworker once wrote, that was only compiled but never tested; it first run on the customer site. It didn't crash, but our consultants got really strange results, almost random, results that they could not "figure out" no matter how hard they tried. Of course they had no idea what an "ininitialized variable" was or what a mess it is capable of causing.
Here it seems that the (4127-10) items that were copied at the beginning of this copy operation have affected calculations so badly that the situation cannot be salvaged.

Have Fun!
Dimitris Staikos

Like Father Like Son?

Given that we all need to relax a bit these special days, I won't blog about Writing Debuggable Code yet. Rather I thought I should share a photo I shot almost two years ago, when my son was just 19 months old.

Have fun!

Dimitris Staikos

Reinventing User Interfaces

Hey man, isn't software boring nowadays? I mean you press OK and you know what will happen, you press Cancel and you once more know what will happen. Boring boring booooring.

Thanks to the Allmighties of this world, some guys still get enough inspiration to make our user experience worth our while.

This comes from a web mailer I use. For one thing, these guys thought about reinventing date sort order. As far as I can remember, ordering my email by date-descending means "newest mail first".
Well these guys have a different opinion. They define date-ascending as "newest mail first".

Here is an excerpt from my settings page:

And here is how the date column looks in my inbox (note the UP arrow indicating ascending order):

 

In constrast, here is what Microsoft Outlook thinks about date sorting:

Anyway, I don't know, may be some other famous mailer has the same kind of date sorting and these guys decided to adopt that one. I don't know. It's too much to attribute to stupidity...

Another cool side effect of the behaviour that they have implemented is the following: When I am reading an email, there are two buttons available Previous and Next. Say I am reading an email I got on Thursday and I press Next. Can you guess what happens? In front of me I see a mail I got on Wednesday. Next moves me to an older email, and Previous moves me to newer mail. Isn't that cool? Previous and Next are extremely bad names for this purpose. That's why MS Outlook has an UP and DOWN arrow, so you know what to expect.

But date sorting is not the part where these guys excel. They also redefined timezone-sorting. When I tried to configure my timezone I got a huge drop down list that looks like this (click to enlarge):

Super Cool! Completely random sorting. Neither geographical, neither timezone, nor alphabetic sorting. And it is a HUGE list containing an entry for all major cities on the globe (not just the capitals).

After trying a bit to locate my city I paused and thought about it. Then I selected the first entry, closed the drop down and moved the keyboard focus in the list. Then I repeatedly typed E (for Europe) until I saw my city appear in the selection. Now that's what I call "Software that Makes You Think".

Have fun and Merry Christmas (where applicable)!
Dimitris Staikos

How adding more RAM to your PC can hurt Windows performance

This is a story that should really tell us something broader about how computers work and how software that controls computers works:

• Often in weird ways.
• Often in totally unexpected ways.
• Often in sadistic ways.
• Often in seemingly nonsensical ways.

When trying to explain a complex technical concept I always try to start by making a real world analogy; I think it greatly helps understanding the nature of the concept I am trying to explain, which is the prerequisite to understanding the details.

So imagine you go to a restaurant and you order a bowl of soup. The waiter, along with the soup, brings an impressive selection of spoons, so that you can pick the one that better suits your eating habits and preferences. You are really hungry and in a hurry, so you grab a really huge spoon and finish off the soup in a snap.

The next day you enter another restaurant, and you order their specialty soup. After a while the waiter arrives with your soup and brings along a small luxury spoon, children’s size. You stare at the spoon with bewilderment and ask for a bigger one.

"I am sorry sir, I am afraid these are the only spoons we have. They are selected by our chef so that customers can properly enjoy their soup".

At first you are shocked; then puzzled; then... you name it. Anyway you decide to give it a go. The soup is excellent and the little spoon can be made to work.

Now imagine you go to a third soup restaurant and the chef mandates that clients eat their soup using a spoon so small it can only hold a single drop of liquid.
What excuse can the chef offer you that could possibly justify what you have to go through in order to eat your soup using such a spoon? I don’t think I would fall for anything.

End of analogy.

In the example the restaurants represent the various versions of Windows running on different hardware. The soup represents "data", while you get to be on the device driver seat. The chef is the Windows kernel and the spoon is the size of the "bucket" that you can use to move data from your device.

Let’s get a bit more technical.

The Windows kernel has a concept called "Map Registers". Map registers translate to the size of the maximum DMA transfer that you are allowed to program on your device.
Instead of confusing you with "Map Registers" I will be talking about Maximum DMA Transfer or use the simpler term of "DMA Limit" that we use in Unibrain’s Firewire software documentation.

The DMA Limit is of course decided upon by the Windows kernel.

• On x86 Windows running on plain-vanilla x86 hardware, the DMA limit is 2GB which means that... there is NO LIMIT. No DMA Limit. Any driver can program a DMA transfer as big as its heart desires, like 100MB for example.
• On x64 Windows running on x64 hardware the DMA limit is 1MB. This is not a typo. It actually says "One Mega Byte".

Before getting too upset about "Why didn’t Microsoft set a bigger DMA Limit on x64?" I think it is better that you consider a different question: "Why didn’t Microsoft set ANY DMA Limit on x86?"

In my opinion this is the point where Microsoft initially got it wrong. By not putting a DMA limit on x86  Windows Microsoft made the lives of driver developers much, much easier, and thus they achieved having x86 Windows drivers for everything under the sun.
The downside was that many of these drivers were of dubious quality, allowing applications to setup even 100MB DMA transfers (which is a huge waste of system resources).

If Microsoft had put a reasonable DMA limit into x86 Windows, like say 10MB, then driver developers would be really used to the idea of working with a DMA limit and then the transition to x64 would be much smoother.

Instead Microsoft adopted a different approach for x64. By setting the DMA limit to 1MB they are essentially telling driver makers:

If you can’t operate your device using max 1MB DMA transfers then we don’t want your driver running on x64 systems.

Fair enough I say; 1MB is more than enough and keep in mind that it is not a 1MB overall total. It is 1MB per DMA Adapter Object. If your device has multiple execution contexts, then it uses 1 DMA adapter object for each context, and you get a 1MB maximum per execution context.
Trust me when I say that 1MB IS ENOUGH to serve even the demanding 800Mbps of Firewire.

However, the fact remains that this change in the DMA limit from the x86 world to the x64 world was a bit dramatic. And it is the core reason why YOU are having so much trouble finding x64 drivers for the hardware stuff you have on your Windows PC.

I hope I haven’t bored you to death with all the above but this was the simplest introduction I could come up for the REAL ISSUE of this article.

You might have noticed that something is missing in my earlier description about how Windows sets the DMA limit: Unlimited on x86 OS on plain-vanilla x86 hardware, 1MB on x64 OS on x64 hardware.

So what about x86 OS running on non plain-vanilla x86 hardware?
What about x86 OS running on x64 hardware, which is the norm these days?

The common denominator here is that we are talking about hardware that can address more that 32 bits of PCI space. This feature was referred to as PAE (Physical Address Extensions) on those exotic x86 machines that first supported it, and it still appears that way on your x86 Windows running on your x64 PC on the Computer Properties dialog.

On these systems, there is no DMA limit as long as the total amount of PCI-addressable memory space is less than or equal to 4GB.

What’s the difference between "memory" (RAM) and "memory space"?
Well, memory space is a space where memory lives. Master of the obvious, am I not?

The PCI-addressable memory space is where you RAM lives.

Is there anything else inhabiting that space?
The answer is YES: Device memory.

Device registers and the device’s PCI configuration space are "memory mapped" (mostly), which means that they have PCI-level physical addresses that the operating system can use to access them. Your graphics adapter memory goes in there too.

A crucial thing that happens a little after you start up your PC is that the infamous chipset, working together with the BIOS and other mystical powers, reserves 0.5GB up to 1GB of PCI-addressable memory space for device memory. In most systems I have tested it was either 0.75GB or 1GB. I’ll refer to this as DeviceMemory.

Now let me reiterate one of the previous paragraphs and see if it starts ringing any bells:

On these systems, there is no DMA limit as long as the total amount of PCI addressable memory space is less than or equal to 4GB.

Ladies and gents, we have arrived at our destination.

If you bought 4 or more GB of RAM for your PC, running an x86 version of Windows on the aforementioned hardware then RAM+DeviceMemory>4GB, so one of two things will happen:

• The x86 OS will only "see" 3GB, or 3.25GB or 3.5GB of RAM.
  Actually it will see VisibleRAM=(4GB minus DeviceMemory).
• More usually however, especially when modern x64 hardware is involved, the x86 OS will take advantage of PAE support on the hardware and then VisibleRAM=(Full RAM).

If the first option is what happened to you, then you are a lucky bustard (typo intended – I don’t use slang in my posts ;-)). The reason that you are lucky is that in your case the x86 Windows kernel continues to operate in the generous NO DMA LIMIT mode. Every driver on the planet is happy in that land.

If the second option is what happens to you, then you are in for a nasty surprise which is the article’s punchline:

On x86 Windows with VisibleRAM+DeviceMemory>4GB the DMA Limit is 64KB.

Once again there is no typo: SIXTY FOUR KILOBYTES
Or 16 map registers if you prefer.

So you installed 4GB of RAM on your x86 Windows PC running on x64 hardware and suddenly:

• Logοn takes several minutes
• File copies are slower than usual
• Network is sooooo slow
• Everything feels sluggish and defunct

There is a way out and it is pretty simple: edit your BOOT.INI and add /MAXMEM=3072 (or the equivalent with my beloved BCDEDIT on zVista). See if it makes any difference and then try readjusting it up or down until you find the maximum value that does not invoke the 64KB death penalty.

This 64KB DMA limit is the tiny spoon I was talking about in my analogy at the beginning.

Just try serving up a bandwidth hungry 800Mbps Firewire device using a 64KB spoon. A huge and coordinated effort is required in the code and then it will only work up to a point. After that point the Firewire device (usually a high res high fps digital camera) will be shooting data at the PC so fast that with a 64KB spoon you are just out of luck (data flies on the cable and your spoon is not there to receive it).

I don’t know how or why this 64KB value was decided upon. This is an interesting topic for speculation. Some said it was historical issues dating from the EISA bus or something. I personally can’t figure it out. It just can’t be stupidity. There must be some reason behind that. Or may be indeed it comes from the EISA days and they just forgot about it.
I would be very interested if you sent me some comments with your speculations on this.

So, it’s high time we brought this to a closing:

How can you tell if you are infected (other than by witnessing sluggish behavior)?

Well, to the best of my knowledge, you can only get this information from a kernel driver. There is a considerable chance that Windows does not use one single value as the DMA limit for all devices. May be they are using different values depending on the type of bus the device is found on, or even the type of device, so there might be no global value to report.
Based on my discussions on NTDEV and private emails, it seems like it is a per-bus setting, which means that all PCI devices probably get the same value.

Doing a SysInternals-like project to display this value on your system, with a self registering driver hiding in its resources, etc, is interesting, it requires several hours of careful work, but is otherwise trivial for a DDD. Did I forgot to mention the endless support afterwards?

So I am not going to do it. Or should I put it better, I am not going to redo it, since I have already done it somewhere else.

Seeing the DMA Limit from userland is a feature that I have added to Unibrain’s Firewire drivers (ubCorePro 5.21) after the technical investigation of this issue came to a close. If your motherboard has a 1394 port or you happen to have a Firewire adapter you can use our software to see the DMA Limit.

This is a f.r-e^e download from www.unibrain.com, mostly harmless to install :-)
Just make sure you download the Pro version.

Install ubCorePro, reboot, login and wait until Windows starts up all the drivers, then run FireCommander and type the DMALIMIT command to see the DMA limit that your system granted to our drivers.

Some words of caution for those who will not bother reading the manuals:

• You don’t have to uninstall ubCore in order to get back to using the Microsoft 1394 drivers. We have a tool called UBSWITCH that does exactly that, in both directions.
• There is no significant performance difference between the Microsoft SBP2 driver and our own. Don’t bother trying to see if you will gain anything on that aspect. Remember we are focused on industrial applications not end users. Industrial applications don’t use SBP2 so there is no incentive for us to try to make the driver faster than the MS driver (supposing SBP2 devices can go any faster).

Finally, if you care for the technical discussions of this issue as they took place on OSR Online, you can go to the NTDEV forum, select advanced search and search for "Maximum 16 map registers" without the quotes. You should see my name on the post that started the thread.

I have also posted a technical explanation for FireAPI developers on our informal newsgroup.

Have Fun!
Dimitris Staikos

Demystifying Device Driver Development (DDDD)

It just occurred to me recently that most people don't really have a clue about what it is that Device Driver Developers (DDDs) do for a living. Since I am a DDD myself, among other things, I thought I should make an attempt of describing what I do in a way that Common People can hopefully digest.

Since I enjoy making wannabe hilarious Tom & Jerry dialogs, I will try to put it in a dialog between Jerry the Technical Interviewer and myself. I will intentionally wear the hat of the anti-social, psycho-path, under-the-hood programmer and let Jerry extract all the information from me in a criminal-interrogation like style.

Here we go...

Jerry: So you are a DDD.
Me: Yeap.
Jerry: Can you tell me what it is that you do?
Me: Yeap.
Jerry: I mean you build device drivers right?
Me: Yeap.
Jerry: What exactly is a device driver?
Me: It's just a piece of software that controls a device. Don't you know that? Are you wasting my time?
Jerry: Yes, I guess I do, ehhh I mean I do know, but what exactly is a device?
Me: That's an interesting question so I will dignify it with an answer. A device is a clever piece of hardware. To make things simple, imagine that a device has a little CPU of its own, a CPU that can execute various tasks depending on the hardware at hand.
Jerry: Wow64, there is a CPU on these things? A CPU on a PCI card that I buy off the shelf?
Me: Duh, but of course, how else do you think they would do any useful work?
Jerry: I thought the computer's CPU was the only CPU in the block.
Me: No, devices have CPUs and depending on the hardware they can be pretty sophisticated.
Jerry: That's awesome! What can you tell me about these little CPUs?
Me: For starters, they are not little. Most of them can do several tasks at the same time and they can be pretty darn fast.
Jerry: Hmmm, wherever there is a CPU, there is a program right?
Me: Yeap.
Jerry: Well, where are the programs that these CPUs execute? Firmware stored in flash memory may be?
Me: You'd wish.
Jerry: Please elaborate, I'm getting really curious here.
Me: OK, if you insist... These programs are generated by the device driver.
Jerry: Pardon me?
Me: The programs that the device CPUs execute are generated by the device drivers. Clearer now?
Jerry: Wow64!
Me: Indeed.
Jerry: Generated by the device driver... In what language?
Me: That was a good one! Machine language of course.
Jerry: You mean mov ecx,edx and the like?
Me: Well, in a sense yes. Each device CPU has its own machine language.
Jerry: You are kidding me right?
Me: No way. Don't be an idiot.
Jerry: So the device driver builds machine language programs for the device CPU?
Me: Actually, it's even worse than that. These CPUs usually have many sub-CPUs, execution contexts we call them. The device driver generates programs for several (if not all) execution contexts. Each program is called a context program.
Jerry: Wow64 once again! And where are these context programs located at runtime?
Me: Well, in most cases in main memory, the little thingy you call RAM. Sometimes devices may have onboard memory for storing these programs, but in most cases it's just RAM.
Jerry: In RAM? Wait wait... And how can the device CPU read from RAM? Can it handle virtual addresses and the like?
Me: Man, you are really something! Virtual addresses? What are you talking about? When was the last time you heard the term "Physical Address"? These are the kind of things these CPUs can swallow.
Jerry: Physical Address? What are YOU talking about? Are we talking about DOS here?
Me: LOL. Please realize NOW that devices are what's called "Close To The Metal". They don't and they won't understand virtual crap of any sort. They operate at the PCI level, so they will only understand PCI-level physical addresses.
Jerry: Then how does it all work?
Me: Well the device driver allocates some piece(s) of memory where it intends to store the context programs and then kindly asks the operating system to give it the physical addresses of these pieces of memory. The OS happily obliges and then the device driver prepares the context programs, using physical addresses wherever a jump is required. When the context programs are ready, the device driver sets the Program Counter register on the various sub-CPUs of the device and then starts these CPUs. Ain't it cute?
Jerry: Wowowowowow64!!! That's super cool.
Me: Yeap.
Jerry: If I understand well, the device driver is like a mini operating system for a device, right?
Me: You couldn't phrase it better.
Jerry: Now I realize why being a DDD is so tough! You have to write a mini OS of your own and make the device do your bidding!
Me: Yeah, but the truth is making the context programs and handling their operation is the easy part.
Jerry: Huh? And what is the difficult part?
Me: ERROR HANDLING.
Jerry: Please please, please elaborate!
Me: Well, it's no big deal for an experienced DDD to write a device driver for a well behaved device. The tough thing is to write a driver that does not malfunction or crash the OS in the presence of device errors. These do not happen often so it is really hard to test the error handling code. Actually if you write ANY decent program, user mode or kernel, error handling largely amounts to 50% of the code. If it does not amount to 50% in your code, then you haven't done enough error handling. No developer likes error handling (with the exception of myself of course). It's boring, it's nasty, it's creepy. But unless you do it and you TEST it throughly you can't write decent software. For device drivers this is even more crucial, since in the presence of device errors the best thing that you can hope for is that the device stops functioning (we call it the device is dead). However in the majority of cases (at least in Windows) you get an OS crash.
Jerry: And how do YOU test your error handling code?
Me: That's a trade secret.
Jerry: Com'on now...
Me: I keep an arsenal of malfunctioning devices at my office. Everyone in my team has strict instructions to immediately hand me any device that appears to be malfunctioning. They are my secret treasure.
Jerry: But how can you be sure that your driver handles correctly all possible errors?
Me: I am not.
Jerry: You're NOT???
Me: Well, why do you think it is that people still get BSODs when something unusual happens? Even if you get a driver developed by a team that takes error handling very seriously, they can't test everything, simply because they haven't seen everything yet. So you get BSODs.
Jerry: I am shocked. This is brutal.
Me: Well, as I've said elsewhere BSODs are a blessing. As far as your complaints are concerned, please pass them on to the device manufacturers. If they would put some "test mode" into their devices and make them fail randomly then MY job would be MUCH more easier. But these things would have to go to the chip level and then they would have a significant added cost as you realize. So practically everyone in the industry operates in a "hoping for the best" mode.
Jerry: ...
Me: You can't imagine what I have to go through to make buggy devices operate correctly. In your mind the term "bug" is most probably related to software, but let me break some news to you: There are COUNTLESS bugs in hardware chips and devices, and poor DDDs like me have to struggle hard to ship a decent driver only to have lusers scream their lungs out at ME when they get a BSOD. They scream because probably I didn't handle 100% correctly all the bugs in the hardware chips. But who am I supposed to scream at? Texas Instruments? Intel? You get the picture.
Jerry: Well, I can only say that under this new light I have a whole new appreciation for the work you DDDs are doing.
Me: Darn right you should.
Jerry: My special thanks for this enlightening interview.
Me: May the force be with you.
Jerry: Any last minute advice for Common People who use PCs?
Me: Don't add more RAM to your PC unless you know what you are doing.
Jerry: Excuse me? Don't add more RAM? What harm could additional RAM possibly cause???
Me: I will describe that in a separate post, when I feel like having mercy on the masses. For the time being I know, and you don't. Huh!

Have fun!
Dimitris Staikos

The new generation

I am in a fancy mood tonight, so I thought I could share some personal stuff.

Based on the photo below I have some first indication that my son will get involved in the same profession that both his dad and mom are in. He's not yet even 4 and a half years old and he can use our tablet laptop with remarkable ease.

Have fun!
Dimitris Staikos

What are you talking about?

Well, sometimes software engineers can get really inventive. And when that happens usability goes down the drain.

Here is a one-of-a-kind dialog box, a monument of inventiveness:

A question on the dialog caption? On the dialog caption for heaven's shake???
People expect to see the program name on the caption, or something equivalent, and thus almost never look at what the caption says. So the average user is confronted with an answer but he can't see the question.

Needless to say this dialog box also demonstrates additional usability bugs:

• First of all it traps the user. There is no Cancel button for the poor user that is not certain about what to do.
• Second, YES/NO dialogs are the lazy programmer's way out when he needs feedback from the user. The dialog should really have a Disable and a Cancel button. However this means that the programmer must create a new dialog resource, a dialog class, etc, so most opt out and select a YES/NO question which is readily available through the Win32 MessageBox function.
  
  Still, if you insist on using MessageBox, you can put your brains to work and structure the question in a way that it has a YES/NO answer.
  
  "If you select YES such and such will happen ..." is plain silly.
  
  Almost any question can be formed as follows:
  
  The application can do blah blah...
  Do you want to do that?
  YES/NO/CANCEL

Have fun!
Dimitris Staikos

Hardware stack

I am a device driver developer and Unibrain, the company I work for, produces what's called a software stack. In plain text this means several pieces of software that are layered, one on top of the other. Each piece uses the services of the layer below it and provides services to the layer above it.

In Windows kernel programming the concept of "device stack" is prevalent. One device object attached to another device object, attached to another device object, etc.

This is a pretty common concept in software engineering.
Mind you, software stacks in the above sense have nothing to do with the "stack" data structure.

Although I am not a hardware engineer, as far as I can tell a concept similar to a software stack does not exist for hardware. Hardware components are definitely combined together, but the combination usually is on a side-by-side basis, not one layer on top of another on top of another etc.

If you search the Internet with "Hardware Stack" you will mostly find items describing hardware support for the stack as a data structure.

Anyway, one day, being in a funny mood, I decided to implement my own a hardware stack or device stack if you prefer. Here's what it looks like!

Btw this is a really expensive stack (five digits in USD).

Have fun!
Dimitris Staikos