Three Stooges Syndrome

True Story: Coworker and I recently found a bug where three programmers who no longer work with us had touched the code in the rendering loop and introduced three separate quite serious bugs.

The result was a “Mr Burns” bug where the bugs were acting symbiotically together to produce almost acceptable behavior and not crash. Fixing one or two (but not all three) bugs would result in catastrophic failure since any remaining bug would cause fatal behavior. However, leaving all three bugs in the code together allowed it to survive and limp along without crashing but with suboptimal results under certain conditions.

The only way to fix any of the bugs without causing issues was to fix all three simultaneously - which is what I did but only after a couple serious WTF's.

Rarely have I ever seen such an outstanding collaboration of obviously wrong code somehow cobbled together to produce a result that seems to work under many conditions even though it’s obvious that serious coding errors were present and demonstratably exhibiting buggy behavior while the code was “working”… it was truly a bad code masterpiece.

Memory Manager

I've spent a large chunk of time rewriting the memory system for Mortal Kombat. It was a huge and ambitious endeavor using a lot of new techniques that are not really used in other systems. Development on it was expensive but justifiable because we plan on reaping benefits from the system and eventually sharing it with other studios under the WB Games umbrella.

So my "Director of Engineering" told me today that Rock Steady Studios (the developers of Batman: Arkham Asylum) have integrated the Memory Manager I developed for Mortal Kombat into their latest game under development. It only took them 2 days without any help and was a very smooth integration. Right off the bat it saved them 4.5MB on PS3 which is an enormous amount to get back just from a memory manager and also it resulted in a large increase in stability for that platform.

Woo hoo! I feel pretty good about that.

More Windows 7 Gripes

Windows 7 isn't all good -- it's mostly good but I continue to find little quirks where they "dumbified" things which were more useful in Windows Vista.

Taskbar Behavior

In Windows 7, the Taskbar is Always-On-Top. The only way to have full sized windows on your primary screen is to turn on the Auto-Hide Taskbar option. There is no longer an OS supported way to have a TaskBar that is not always on Top. Basically, this is a "dumbification" of the UI that ends up with a choice between wasting screen space or forcing you to auto-hide the Taskbar.

There is a hack in the Windows Seven Forum though to reintroduce this Vista/XP functionality... I'm not sure why MS removed useful functionality from Vista in making 7.

The hack isn't perfect though and has some flaws. It would have been much nicer to just have the feature in the OS and work correctly.

Windows 7 Explorer Quirks

Open Window Position

New Explorer Windows open to wherever you moved the most recent Explorer Window. They do not remember where they opened from before for that directory (or root). Windows XP and Vista both remember where Explorer windows were opened for a particular file root. For example, you could get "My Computer" or a directory shortcut to open in a consistent screen location before. Now they open wherever the last active Explorer window was.

Folder Views

Menu "Tools"->Menu Item "FolderOptions"->Tab "View"->Item "Folder Views"->Button "Apply To Folders"

This no longer actually applies the current folder view to all other folders -- only to folders of similar types. In particulare, it doesn't work at all for certain folder types.

It mainly bothersome because I'm stuck with the "XBOX360 Neighborhood" browser constantly defaulting to "tile" view even though I prefer "list" view and I have to change it anytime I recreate the folders (i.e. clean builds) on my development system.

Read-Only Handling in Explorer

In Windows 7, Directories can not be made Read-Only, only the files within them are made read only. The button for the properties probably doesn't work the way you expect it to (i.e. it defaults to read-only but files created there are not really read-only - they only change state when you update the checkbox and click OK).

Also, delete (or move) will delete (or move) Read-Only files without any additional confirmation (other than the initial confirmation you may get with non-Read-Only-protected files).

Basically, the "read-only" flag no longer protects files in the Windows 7 Explorer GUI. Just a word of warning to y'all.

NOTE ON CMD commands with Read-Only Flag: The "read-only" flag is also ignored for "rd /s" or "rmdir /s". However, the "read-only" flag still does work for some commands like "del".

Windows 7 Photo Viewer Gripe

Overall, Windows 7 is pretty good but there are a couple things that I actually like better about Vista. The main problem is that Microsoft removed some useful functionality and "dumbified" parts of the OS.

For example, the "Windows Photo Viewer" in Windows 7 has been totally castrated. In the Vista version, you could view photos and perform simple modifications: rename (from DSC_0216.jpg to MakingAGoofyFace.jpg for example while looking at that picture), fix red eye, crop picture.

All the editing features save rotation have been removed in the Windows 7 version. They didn't even included the simple ability to rename a picture.

To get these standard Vista features back you need to download the "Live Essentials Photo Gallery" which installs all sorts of fun stuff like an SQL Server CE 3.1, MS Application Error Reporting Service, Windows Live Sync, and Windows Live Communications Platform.

Basically, in order to get back a small number of useful features, you need to install the entire "Live" platform of cruftware. Not to mention that the install of the new "Live Essentials Photo Gallery" requires 56MB of diskspace !!!!

I wonder why they didn't leave the simple basic functionality in the original viewer rather than making you have to download an entire "Live Essential" Platform to get a poor Picassa clone.

Windows 7 GodMode

If you have Windows 7, you can create a folder called the following:

"GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}"

Then, if you type “GodMode” in the Explorer Bar, you basically get a one-stop configuration panel that handles 95% of your config panel needs from a single click without going through the fluffy layers of the “Control Panel” happy hierarchy.

http://www.tomshardware.com/news/GodMode-Windows-7-How-to,9345.html

Another Note on Empty Structs

I mentioned this C++ Standard Violation by MSVC++ in my last post on empty structs:

- There is no padding (other than for alignment) between the last base class and the first class member or vft-pointer(s). *** NOTE: this is an over-aggressive empty-base-optimization that can break the C++ standard.

Let me explain:

The standard on empty struct inheritance specifies that separate structs of the same type should yield unique addresses. In the following code, the two addresses printed should be different in a standards compliant compiler (Intel or GCC). MSVC++ ends up printing the same address twice.

class a { public: void awork() {} };

class b : public a { public: int bdata; };

class c : public a { public: b cdata; };

c test;

a *pca=&(test);

a *pcb=&(test.cdata);

printf("Offset of c::a %d\n",size_t(pca));

printf("Offset of c.b::a %d\n",size_t(pcb));

Empty Struct / Class & Empty Base Rules for MSVC++ and GCC

I now GROK empty class (and empty base optimizations) fully on MSVC and GCC.

----------------------------------------------------------

GCC C++ follows these rules:

- class EmptyBase {}; --> sizeof(EmptyBase) == 1

- Any number of empty-bases will map to 0 in the struct offset as long as all are unique types (including parenting).

- Non empty-base parents are simply in the order declared with only padding for alignment.

- If the first member of a derived class that immediately follows empty-bases does not derive from any of those bases, it is allowed to start at the first properly aligned offset for that member that is greater-than-or-equal-to the empty-base address -- this may be the same address as the empty-bases.

- If the first member of a derived class that immediately follows empty-bases does derive from any of those bases, it will start at the first properly aligned offset for that member that is greater-than the empty-base address -- this is never the same address as the empty-bases.

- Members that are empty-classes take at least one byte of storage in the containing class.

----------------------------------------------------------

MSVC++ follows these rules:

- class EmptyBase {}; --> sizeof(EmptyBase) == 1

- The only way an empty-base class (or class derived from an empty-base) will start at offset 0 (zero) is if it is the first base class.

- A Non-empty-base class will start at the next valid alignment offset for the base class.

- All empty-base classes will appear to have zero effective storage in the derived class and do not affect the current offset unless followed by another empty-base class (or class derived from an empty-base) in which case you should see the following rule.

- An empty-base class (or class derived from an empty-base) that follows an empty-base class (or class derived from an empty-base) will add 1 to the current offset position before padding to the proper alignment for the class.

- There is no padding (other than for alignment) between the last base class and the first class member or vft-pointer(s). *** NOTE: this is an over-aggressive empty-base-optimization that can break the C++ standard.

- Members that are empty-classes take at least one byte of storage in the containing class.