TD Visa Disgust

I've been banking with TD Canada Trust for most of my life. I banked with them back before the Canada Trust merger, I held my first credit card with them, my first retirement savings, even my first investments. But today, they have paid me a gross insult, hidden within pages of legalese, that has me seriously considering leaving this bank forever.

Today, TD Visa sent me a chip and pin card.

For those of us who have been away from Canada now, chip-and-pin cards, as a result of intense pressure from card issuers, have become a de-facto standard for merchant transactions in Canada. Rather than the familiar process of swiping a magnetic stripe and signing a piece of paper, you instead stick your credit card into a terminal, and enter a short numeric code (your PIN). The system has become so pervasive that in many establishments in Vancouver, new members of the service industry don't even know how to swipe a card - much to my amusement when I visit with my ancient magstripe cards.

Why chip-and-pin? It's more secure! Anyone with cheap (or even free) hardware can duplicate the information on a magstripe card, write a random squiggle on a receipt, and walk out of any merchant with as much as they can carry. It's much harder to steal from a chip-and-pin. The card never has to leave the user's hand, and even if it does, is exceedingly difficult to duplicate (millions of dollars of high-end forensics hardware). Even if the card is duplicated or just outright stolen, without the PIN it is difficult to extract any money from it.

Credit cards that are harder for people to steal from? Sounds pretty good, right? Well they are! Except many banks, including TD Canada Trust, have used it as an opportunity to offload risks onto their cardholders.

From their cardholder agreement:

Before you notify us, the Primary Cardholder will not be responsible for any unauthorized Transactions that occurred, as long as you have complied with the Agreement. If at any time your Card or the Account is used, including at an ATM, with a personal identification code (such as a Personal Identification Number (PIN), Connect ID and/or Password), that will be considered an authorized Transaction for which the Primary Cardholder will responsible.

What this translates to is: if you use a credit card, you're not liable for any theft or fraud, unless it's a chip and pin, in which case you're liable for 100%. You're liable for a mugging. You're liable for a terminal with a tampered screen. You're liable if someone uses well-known man-in-the-middle attacks to use your card without your PIN. It may be a bit harder to steal from you, but if they do, it's your problem, no matter what the circumstances.

I don't know if all banks do this. It seems to be a recent change or clarification with TD Canada Trust. I've heard CIBC made this change years ago. Smaller credit unions may be behaving more responsibly than TD Canada Trust. I desperately hope I can find an institution in Canada that actually respects its cardholders, rather than lining them up for theft.

... or maybe I'll just drop my Canadian credit cards entirely. In an ironic role reversal, US law protects cardholders from liability.

Leaving IEEE

I was a member of the Institute for Electrical and Electronics Engineers for ten years, joining as a student member in my early days at the University of Waterloo. I enjoyed my days as a student member, taking advantage of student paper nights, and getting involved with the local student society. During my Masters degree, I was lucky enough to attend a few IEEE conferences, and even published in a few of them. Overall, I felt that

However, after several years in industry, it's not quite as useful. I'm not publishing, nor attending (IEEE) conferences. The very concept of magazines and journals seems dated in an era of RSS, Reddit, and open access. Combine that with a very underwater mortgage, a family to support, and much higher membership fees, and the membership value proposition becomes hard to justify.

But what killed me more than anything - the spam. Neverending spam. I think the most offensive was the IEEE-affiliate life insurance - clearly not even tangentially related to the IEEE, yet I'm getting shredder food every month. Next on my list, the IEEE Communications Society. I don't do communications. I'll probably never do communications. I haven't the slightest interest in the topic, nor have I ever expressed such an interest. Still, they sending me every last call for papers, nag me regularly to subscribe to their content, and steadfastly refuse to honor my unsubscribes.

Finally, I had enough, and let my membership lapse at the end of 2011. This was just the beginning of the spam, with nearly a dozen different offers, warnings, requests and complaints trying to encourage me to renew. Not entirely unexpected, but what really got me was when they opened a support incident at "my request" in their support system, simply to further spam me through their ticket system. Every new email further reinforces how right I was to disassociate with this organization.

IEEE, you are supposed to be the premier professional organization for modern engineers, not an affiliate marketing business. Shame on you.

Good old Games?

Recently I've been availing myself of GOG.com - a site that sells old PC video games at bargain prices, most often $6, though with regular $3 weekend sales that can be hard to resist. Most of the games are packaged to run under the DOSbox emulator, and so far every one has run perfectly.

In an era of multi-million pixel displays, 3D audio, and multi-gigabyte drives, are these ancient games really worthwhile? Some definitely have withstood the test of time. So far, my favorite has been Lands of Lore. There's something about that MIDI soundtrack and the gameplay that seamlessly mixes combat and puzzles that is just as addictive now as it was in my teenage years.

Still, playing many of these classic games have reminded me just how much things have evolved in game design; simple concepts that took the industry surprisingly long to catch on to, that you can't help but miss when going back to those old games.

Control Mapping
Back before the mouse was a basic requirement of every game, it was popular to use the arrow keys for navigation, rather than the now-popular WASD. This allowed the dominant (right) hand of most players to be used for  precise movement. Games eventually adopted the mouse for look, and thus stole the right hand from the arrow keys. Try using the arrow keys with your left hand, while using the mouse with your right. It cramps. Quickly.

But even more fundamental than the arrows-WASD debate, is that most modern games will let you set whatever controls you want. As long as you're willing to spend a few minutes in an option screen, you can set up whatever control scheme you can imagine. In the old games, the controls are the controls, and you live with them or play something else.

New games even let you adjust whether to use inverted or regular mouse look. Yes Magic Carpet, I'm tired of inverted mouse.

Checkpoints
I think I first saw this in Halo - the idea that without significant player intervention, the game would save your progress, so that if you died, you could recover at the start of the most recent section of the map. Now, we take it for granted that in most games your progress will be saved, and a death can only cost you a finite amount of progress. Having to repeat more than five minutes of play is considered poor style in a modern game.

Not so in old games. When you die, it's GAME OVER. Exit to DOS, or start a new game. You can reload from the last point you saved. If you saved three days ago... well sucks to be you. This is particularly relevant with old games, because they're hard! You'll be dying. A lot. It took me the better part of a day replaying Gladstone in Lands of Lore to get back into the step-step-save habit.

Tutorials and Tooltips
Game manuals are a thing of the past. I think the Starcraft 2 manual was more lore than instructions. Many Xbox games don't even come with manuals anymore. With digital download games, it's practically a requirement that the games teach their own gameplay. Even in complex games like high-end MMORPGs, you can learn almost everything you need to know from nothing but tooltips.

With old games, manuals are often essential. First, to learn the controls themselves, which as previously mentioned, can't be discovered or remapped. In some games like Magic Carpet, even the objective of the game can be unclear without some tips. Syndicate's manual is over fifty pages, and even reading that, I only barely understand the game.

C++ interface multiple inheritance

Warning: if you're not a programmer, stop reading now.


Earlier this week I was thinking about multiple inheritance in C++. This practice is often discouraged due to challenges like the diamond problem, demanding solutions so complex that it starts to outweigh the benefits of the multiple inheritance in the first place. However, everyone says that multiple inheritance of interfaces (base classes with only virtual methods) is not only okay, but encouraged. This concept has been rolled into languages like Java and C# which otherwise don't have multiple inheritance!

But this bothered me - in C++, virtual methods are generally implemented by a virtual function table, with a pointer in each implementing class. But how does that work with multiple inheritance? How does the holder of an interface pointer know how to find the virtual functions that matter to their interface as opposed to the other interfaces? Does it even work, or will my code start breaking if I try this? I spent way too much time Bing-ing about looking for the answer with no success. Finally I decided to find out myself.

My test setup is a native C++ Win32 console application, compiled with Microsoft Visual Studio 2010. My output is 32-bit (sizeof(void*)==4).

1. How do we find the right vtable?

class IFoo {
    virtual void Foo() = 0;
};
class IBar {
    virtual void Bar() = 0;
};
class CImpl : public IFoo, public IBar
{
    void Foo() { printf("Foo"); }
    void Bar() { printf{"Bar"); }
};



int _tmain(int argc, _TCHAR* argv[])
{
    CImpl *pImpl = new CImpl;
    IFoo *pFoo = pImpl;
    IBar *pBar = pImpl;
    printf("Ptrs: pImpl = %p, pFoo = %p, pBar = %p", pImpl, pFoo, pBar);
}

Ptrs: pImpl = 000C6F98, pFoo = 000C6F98, pBar = 000C6F9C 

Well that answers that. When we try to take a pointer to the second interface, C++ will adjust your pointer, such that it points to the expected vtable inside the class.

2. But what about the "this" pointer?

So, IBar isn't actually pointing to the object. How does "this" work... is it corrupt when we call it from the offsetted pointer?

class CImpl : public IFoo, public IBar
{
    void Foo() { printf("Foo this: %p\n", this); }
    void Bar() { printf{"Bar this: %p\n", this); }
};



int _tmain(int argc, _TCHAR* argv[])
{
    CImpl *pImpl = new CImpl;
    IFoo *pFoo = pImpl;
    IBar *pBar = pImpl;
    printf("Ptrs: pImpl = %p, pFoo = %p, pBar = %p", pImpl, pFoo, pBar);
    pFoo->Foo(); pBar->Bar();
    pImpl->Foo(); pImpl->Bar();
}

Ptrs: pImpl = 000C6F98, pFoo = 000C6F98, pBar = 000C6F9C 

Foo This: 000C6F98     Bar This: 000C6F98

Foo This: 000C6F98     Bar This: 000C6F98 

Huh. They're both the same, and match pImpl. How did that happen? We just showed that the pointers are different! To answer this, I looked to the assembly. On x86, classes use the "thiscall" convention, which puts the "this" pointer in ECX. Lets see what happens.

When calling via the patched pBar pointer, we set this = pBar. This implies that CImpl::Bar implementation must internally patch the pointer back from IBar to CImpl. But, that wouldn't work when calling from CImpl directly. The compiler, knowing that CImpl::Bar() is meant to look like IBar::Bar(), actually sets this = pImpl + 4.

Oh, you're clever, VC++.

3. What about the same method defined in multiple interfaces?

A fun thing you can do with interfaces, is that different interfaces can define the same method. Since it's just a name (well, a signature), an implementer providing a suitable method can simultaneously satisfy both interfaces.

class IFoo {
    virtual void Foo() = 0;

    virtual void Omg() = 0;

};
class IBar {
    virtual void Bar() = 0;

    virtual void Omg() = 0;

};
class CImpl : public IFoo, public IBar
{
    void Foo() { printf("Foo"); }
    void Bar() { printf{"Bar"); }
    void Omg() { printf{"Omg"); }
};

But how would this work? After all, we just discovered that CImpl::Bar() expects "this" to look like IBar. What does CImpl::Omg() make "this" look like - IFoo or IBar? It can't be both - they point to different locations. But, looking at the vtable in the debugger quickly shows the trick.

Aha, VC++ is more clever than I give them credit for. pFoo directs Omg() straight to CImpl::Omg(), while pBar directs Omg() to Omg`adjustor{4}'. I'd bet the intent of this function is to adjust the "this" pointer to match IFoo - then CImpl::Omg() can assume all callers are referencing it as IFoo::Omg(), and "this" is interpreted appropriately.

Conclusion

You can use "interface-like" classes in C++ just like you would in C# or Java, including multiple inheritance, and the compiler will magically take care of making it work. It accomplishes this through manipulation of your interface pointers and your "this" pointers when using the objects, and through thunk methods where there is ambiguity.

Trust your compiler. Program with interfaces. Win!

Hawaii Vacation–by Microsoft Flight

Amber and I will be taking a vacation soon to Hawaii, specifically “Hilton Hawaiian Village Waikiki Beach Resort”. A last chance to relax before Elora’s arrival.

But I couldn’t wait… I decided to go right now, with the new Microsoft Flight, specifically the Hawaiian Adventure Pack to get access to the high-res terrain for Oahu.

According to the Internet:

(credit: http://www.smarthawaiitour.com/)

 

According to Microsoft Flight:

Flying Icon A5, chase view, from the West

 

Apparently the lagoon is NOT long enough for a water landing in the Icon A5.

 

The underside did not enjoy the beach landing.

Lendio.com = Fail

They purport to "make small business loans simple." But their actual functionality consists solely providing an embarrassingly small list of vendors, with almost no relevant information, and largely ignoring most of the requirements they had collected in a drawn-out interview process.

... and then selling the detailed information to five times as many random small financial institutions, who then proceeded to cold-call me all week.

I think my favorite was the one who insisted that if I didn't want information from his institution that I must have been a victim of identity fraud, then hung up. Then emailed me, which SPF failed. Quality partner right there.

So, don't give Lendio any of your information, because it won't be yours for long.

Dear Facebook Application Authors…

If your app says it needs my email address to function, I’m going to block it.

Seriously. What could your *Ville-of-the-week¹ possibly need my email address for? I’ll click through just about anything, but when broken down to a two-line prompt with a picture that essentially says “The author of this app is going to spam the crap out of you”, what do you really expect me to say?

[1. Zynga is just one of many offenders. Did I call them out specifically due to recent shadiness? Maybe…]

Assassin’s Creed: Revelations

Dear Ubisoft,

Please note the following list of completely redundant, unnecessary, and annoying features in your recent Assassin’s Creed titles.

• City renovations.
• Buying artwork / books / outfits.
• Den defense.
• 2D puzzles.
• 3D puzzles.
• Uplay.
• Crafting.
• Unskippable cutscenes.
• Continent-conquering menu system.
• Insta-win buttons.
• Reusing world models.
• Precursor civilizations.

I encourage you to consider redistributing the resources from the above areas into the following gameplay elements.

• Moar assassinating.
• A difficulty curve.

Sincerely,
  - Lownewulf

PS. Fix your clipping. Or at least reset me to checkpoint when I fall through the world.