Solitaire

I come by my love of Solitaire honestly.

It is fair to say that I am one of the leading experts in the type of card game known as Solitaire (in the US), or Patience (in the UK and elsewhere).  I have been working with Thomas Warfield at Goodsol Development for more than a dozen years, and in that capacity I have implemented literally hundreds of different Solitaire games on various platforms, including Windows, Mac OS X, and iPad.

However, one would be very mistaken to assume that I had to learn about Solitaire back then, or even that these were my first Solitaire software products.  In fact, I have been a Solitaire enthusiast for more than 40 years (easily predating my first access to a computer), and I have been writing programs for playing Solitaire for 30 years.  That is why it was such a good match when Thomas and I started working together; he is also a renown expert, with a very successful Solitaire game, Pretty Good Solitaire, and there is not another company on the planet with more Solitaire expertise from which to draw.

I first learned to play Solitaire from my father when I was about 5 years old.  He taught me a traditional form of Klondike (which many people just call, “Solitaire”), and I clearly remember the first time he watched me deal out the tableau on the stone hearth in front of our fireplace.  I played that a lot over the years, as well as a few other games I picked up.  My neighbor taught me Pyramid, which I really liked, and “Clock” (PGS: Travellers Clock), which had an appeal due to the elegance of play and the physicality of the the cards, but got boring quickly because of the lack of choice.  My mother taught me “Idiot’s Delight” (a name used to describe many different Solitaire games), which in this case was a purely mechanical version of Aces Up.  When I was sick, rather than comic books, I just wanted a couple decks of playing cards and, perhaps, some word search puzzles. 🙂

In the early years of elementary school, I had a couple of friends with whom I had discussions (and disagreements) about the rules of Klondike.  We spent time debating whether one should be able to build Aces to the tableau and, if so, whether Kings could be built on Aces, whether one was allowed to pull cards from the foundations (which I now know is called “winnowing back”), how many cards were dealt from stock to waste, and if there was a limit to redeals.  These are the same kind of game design discussions I still have now as we implement more games.

I also spent a great deal of time working on designing my own solitaire games, the rules of which, alas, were never written down and have been lost forever.  I recall that much of my focus was on small tableau games, those which could be played, ideally, with just one or two piles, making them easier to play in a car.  I also recall at least one with a unique mechanic, based on Go Fish, where the player would declare a selected card, and the play proceeded based on whether (or where?) the nominated rank appeared.  Of course, it is fair to assume that none of my inventions were as compelling as the traditional Solitaire games; otherwise, I probably would still be playing them.

During middle school, an acquaintance (friend of a parent) taught me an unnamed Solitaire game, which had two mechanics I had never seen before: movement of card groups regardless of order (as seen in Yukon) and a “hand” of up to 4 arbitrary cards (like the 4 cells in FreeCell).  This game had a greater degree of calculation and planning, and was less reliant on the luck of the deal, so it was very appealing to me.  Around the same time, I also learned how to do a “bridge” shuffle, so I tried to wear out my hands practicing the two together.  A variant of this game is implemented in PGS as Scorpion Head.

By this time, I was already programming computer games, and the idea of playing Solitaire on a computer was never far away.  My first proper (read: finished 🙂 ) implementation was a text version of Aces Up on my Commodore VIC-20.  The program would shuffle and deal the cards, and one would play with simple keypresses for activating a column (i.e., discarding the top card or moving it into an empty space).  As I recall, my friend and I were the only two who ever actually played this game, but we started wondering about the chances of victory with the implemented rules, so I wrote a computer player that would play a hand using a specific heuristic (n.b., not a comprehensive solution search).  Once debugged, I ran the program overnight and the consistent result was that victory was achieved in just about 5% of the games.  (Clearly, a search would have done better… and taken much longer.)

Many other computer implementations followed.  Our friends showed us a game they called “Canasta Solitaire” (similar to Thirteen Packs, which has nothing in common with Canasta), and at their request, I wrote a version of that for the IBM PC (which, incidentally, became the scene of my biggest computer crash disaster 🙁 ).  I wrote very nice DOS (EGA) versions of Pyramid and other games around 1990, and I was working on the Windows/DirectX versions of the these near the end of that decade, when I also worked (in a non-Solitaire capacity) with MVP Software on some other card game packages.

In 2001 (one suit of years ago), the Goodsol Development years began.  My first project was implementing a comprehensive display library, allowing the original Pretty Good Solitaire [for Windows] more options, including more than 2 decks per game.  The second project was Pretty Good MahJongg, which includes 55 original Solitaire games played with MahJongg tiles, followed by Action Solitaire, including (now) 75 Solitaire games played against the clock, and Most Popular Solitaire, my interpretation on the most popular games in PGS, as well as one (Crazy Quilt) that was the first Goodsol version of that game.  Add Mac and iPad versions of Pretty Good Solitaire and Most Popular Solitaire and a Mac version of Pretty Good MahJongg, as well as other products: Goodsol Solitaire 101 (Windows/Mac/iPad), FreeCell Plus (Windows/Mac/iPad), and A Little Solitaire (iPad).

Counting only Goodsol products (not different SKUs) on each platform (including bonus games), it appears that I have implemented 2639 Solitaire games!  More is definitely yet to come, as Thomas is already up to 840 and counting (with PGS), so I am still trailing by 290 games (on Mac and iPad, as well as an internal Windows project).

Of course, with the implementation of so many games, there is a focus on rules.  Due to my love of Solitaire (and games in general), I began collecting books of Solitaire rules.  The first game I learned from a book and really loved was La Belle Lucie, which I played with the merci (draw) rule, implemented in PGS as Three Shuffles and a Draw.  Since high school, I have amassed around two hundred books of traditional game rules, dozens of which have Solitaire games.  An informal survey of my current bookshelves shows 20 books dedicated solely to Solitaire, dating back as far as 1883 (because my copy of Lady Cadogan’s Illustrated Games of Patience is a reprint of the original 1875 book).

So, while Solitaire may be a simple pastime to most, keep in mind that a few of us really know (and appreciate) these games inside and out.  When you want to buy a computer Solitaire program lovingly crafted by the leading experts in the field…

Windows 8.1 Repaired

Microsoft fixes its touch interface bug reported previously.

Microsoft Windows 8.1About a month ago, I posted about a bug deep in the Windows 8.1 touch interface code, a problem which triggered an exception in our products.  I detailed the debugging process and verification that it was an error in Microsoft’s latest operating system.

Last week, Microsoft indirectly confirmed the bug by issuing an update, KB2919355, which fixes the reported problem.  With that update installed via Windows Update, our test system now works correctly with all of our unrevised games that had previously responded to a hardware (floating point) exception.  Of course, KB2919355 is a “cumulative update” comprised of more than 100 different fixes so, without unwarranted experimentation, I cannot be certain which one addresses our issue, though KB2927066: Ichitaro crashes when you use a touch screen to enter text in Windows 8.1 seems to be the most likely candidate.  (The description is very similar.)

Unfortunately, we still need to update all of our Windows products, since we cannot rely on customers applying the update (and, ironically, it actually fails to install on one of our development systems).  The fix comes too late, after Windows 8.1 was distributed to the public at large and, also, after I spent many hours debugging the problem.  Still, it is better that it was acknowledged and fixed (than denied and ignored).

A series of updates for Goodsol products will commence shortly.

Debugging Windows 8.1

There is bug deep in the Windows 8.1 touch interface code.

Over the past couple of weeks, I spent quite a lot of time trying to debug an issue that was causing crashes in our programs under Windows 8.1 and which, ultimately, turned out to be a bug in the touch interface code of the operating system.  The problem was not with our code; in fact, our tight programming practices actually outed Microsoft’s failure.

To see how we got to that point, read on…

Symptoms

Late last year, we got a single report of a crash in Pretty Good MahJongg under Windows, occurring only when the touch screen was being used; playing the game with mouse and keyboard worked fine.  Crashes in Pretty Good MahJongg are extremely rare, and this had all the earmarks of a device driver problem, so it was given fairly low priority.  Additionally, we did not have the necessary hardware (at that time) to reproduce the error.  Then we got a second report, and we knew something was amiss.

The first two bug reports were nearly identical, and the obvious commonality (and difference from our systems) was that both machines were running Windows 8.1 and, obviously, had touchscreens.  We had tested our products under Windows 8 when it was released, but did not check Windows 8.1 nor using a touch interface (which, in an ideal world, should not crash programs in any event).  Something appeared to be happening with either Windows 8.1 or the touchscreen interface, or both.

Specifically, the error being reported, in all cases, was “Floating point underflow“, though that actual text for the error comes directly from our exception handler, not the system.

Diagnosis

Our products have a very good crash logging system, so when I got the crash dumps, I discovered that the crashes did not appear to happen in program code at all and, in fact, some of them showed only system routines in the stack dump, while others were essentially the same, but with our message loop (but no other program code) in the stack.

My immediate thought was that the problem could be a message collision, knowing that the touch interface added some new Windows messages.  This could mean that either a touch message was triggering program (e.g., animation) code at an unexpected time, perhaps prior to initialization, or vice versa, with a program message causing driver code to be executed improperly.  This could potentially explain both stack conditions, although I would expect to see our program code elsewhere, but that was never the case.

The bigger problem, at first, was that all of the PGMJ message processing code was identical to that in the Goodsol Solitaire Engine, which drives Goodsol Solitaire 101, Most Popular Solitaire, and FreeCell Plus, as well as the code in Action Solitaire, and that most of the message loop is actually contained in a common library shared by all of these products.  After initial confirmation that all reports were for PGMJ, this concern was finally resolved when crash reports began to escalate, and they expanded to include the whole range of products.  At least the new reports fulfilled my expectation.

Of course, to get to the bottom of the problem, I needed to be able to reproduce the error myself, so I ordered a Windows 8.1 tablet (Dell Venue 8 Pro) for testing.  Fortunately, this tablet displayed the error, and I was able to determine a little bit more about the issue.  The crash happened immediately upon the very first touch within the program, whether clicking a button or simply selecting an edit box, though navigating the program with the virtual keyboard worked…  that is, right up until the first (virtual mouse) touch. 🙁

I built a version of PGMJ that moved custom messages elsewhere in the numbering space, but that made no difference at all.  I tried a couple of other brute force experiments, but nothing altered the crash behavior one bit, so I set up remote debugging on the device and began to debug the program properly.  Unfortunately, the debugger saw the stack in exactly the same way as our exception handler, so every crash was deep in system code and if any program routine was in the stack, it was only the message loop.  Still, our program was definitely and consistently crashing, which meant something was different.  The one major advantage of proper debugging, though, is that I got full symbols, so I was able to determine that the actual crash was happening in ‘ninput.dll‘.  But why?

Here you may imagine days of various attempts at debugging the root cause of the crashes, including “handling” certain messages rather than calling DefWindowProc(), doing the opposite and not processing any messages, and setting breakpoints all over the place and, mostly, being disappointed at how few triggered.  I finally narrowed down the issue to happening from a DialogProc() function within the common library when the (new) WM_GESTURENOTIFY message was posted.  That message is the result of the default processing of a WM_GESTURE message, so presumably handling that in some way would prevent the crash.  No dice.  There is a strange documentation conflict when WM_GESTURENOTIFY is sent to a dialog box, since, “This message should always be bubbled up using the DefWindowProc function.”  However, regarding DialogProc, “Although the dialog box procedure is similar to a window procedure, it must not call the DefWindowProc function to process unwanted messages.”  This gave me a bit of a combinatorial problem, too, but nothing seemed to have any effect on the crash.

Finally, frustrated, I regressed to pure shotgunning of the problem.  I knew that not all programs crashed when touched under Windows 8.1, but (all of) ours consistently did, albeit not in our code.  I added an early message box to demonstrate crashing before any of the dialog boxes or other interface features were shown, and then I began removing pieces of the initialization code.  Voila!  The issue revealed itself!

After removing some of the very first initialization code, executed prior to almost anything else being done, and seemingly entirely unrelated to interface code, the crashes disappeared (though, of course, the program no longer worked).  Methodically reducing the amount of code removed, I was able to determine that the crashes were triggered (but not caused) by three simple lines of code in the exception handler initialization.

Problem

Ultimately, the crash problem was a result of the following C++ code:

    unsigned flags = _controlfp ( 0, 0 );
    flags &= ~( _EM_INVALID | _EM_DENORMAL | _EM_ZERODIVIDE | _EM_OVERFLOW | _EM_UNDERFLOW );
    (void)_controlfp ( flags, MCW_EM );

This, very simply, enables floating point exceptions within the program, including the (now problematic) _EM_UNDERFLOW exception.  The purpose was to provide maximum checking for errors in our code, which is usually so clean that it squeaks.  We never imagined that it would catch errors in a released operating system.  For reference, the above code has been shipping for more than 9 years, to many thousands of customers (and potential customers), and never had any problem before Windows 8.1 arrived.

To be perfectly clear, the actual bug is in Windows 8.1, specifically within ‘ninput.dll’.  There is an error in that module, creating a floating point underflow exception, compounded by reliance on a particular floating point state, namely that the hardware underflow exception is (and remains) disabled.  This is a flaw in the operating system, even though the default floating point state and, therefore, most programs do not display symptoms.

Solution

The actual solution, of course, is to remove the above code, which is a workaround to avoid triggering the crashes.  The tradeoff is that our programs will no longer be quite as robust in detecting floating point errors, but as stated above, this checking has been in place for almost a decade without finding any problems in our code, so it should be fairly safe to remove at this point.

Note that removing these three lines of code is actually more than needs to be done to resolve the immediate problem (i.e., the underflow error exception), but enabling the other exceptions still provides additional places for the operating system to fail, perhaps even further along in the same processing path.  The fundamental problem is that Microsoft counted on the default floating point state (and never tested otherwise) for its latest touch interface code, so it is safest for us to simply revert to using the default state as well.

Verification

It is not enough to simply come up with a solution; that solution must be verified.  We approached this issue in two different ways.

First, I built a new beta version of Pretty Good MahJongg with the above solution applied, and that version was provided to as many of the PGMJ customers who reported a problem as feasible.  Every single one (who reported back) confirmed that the crashes were gone.

Second, we bought a brand new Ultrabook laptop with a touchscreen for testing on a different device.  The laptop shipped with Windows 8 (not 8.1), so it was perfect for conducting our verification tests.

I installed the shipping version of PGMJ (Pretty Good MahJongg 2.41) using nothing but the touch interface, and everything worked fine.  We tested several games and had no problems at all (n.b., under Windows 8).  Then, I upgraded the laptop to Windows 8.1 and confirmed that the crash detailed above happened in exactly the same manner and place when using the touchscreen, but the game was perfectly playable with the mouse and keyboard (until one forgot and touched the screen 🙂 ).  Finally, I installed the beta version of PGMJ with the workaround, and everything worked again; in fact, this is a great way to play the game, especially for a title designed without touchscreens in mind.

Given that we verified the solution using two different and separate processes, we are confident that the issue is resolved.  Indeed, Pretty Good MahJongg 2.5 will be released on March 25, so look for it, still the very best tile matching games available for Windows.

For those who know some of my background, the score now stands as follows:
Gregg Seelhoff 3 – Microsoft 0

PGMJ on Amazon

Get the best MahJongg Solitaire program shipped to your door.

Now, you can order Pretty Good MahJongg from Amazon.com.  For those of you who (like me) prefer a physical product, especially for gift-giving, this is a great opportunity.  Not only do you get the full game, with 55 solitaire and puzzle games plus 300 tile matching layouts and a layout editor, but you also get a professionally packaged disc, all for a discounted price.  This is a perfect birthday gift for all ages, or you can get a copy for yourself and display the box right next to your other retail games.  (Mine will keep company with all of the products I have worked on over the last 30 years. 🙂 )

Get your copies by searching for “Pretty Good MahJongg” at Amazon.com, or you can use this direct link:  http://www.amazon.com/exec/obidos/ASIN/B00BHIPOEG

For a limited time only: Be the first to review this item.

In Stock.

FreeCell Plus 4.10

This is a collection with FreeCell and several related games.

FCPlus 4.10 for Windows/MacGoodsol Development has published FreeCell Plus 4.10, a maintenance update to this inexpensive collection of FreeCell and related games, available for both Windows and Mac OS X systems.

FreeCell Plus includes 8 FreeCell-type games, including FreeCell itself, as well as several variations such as Sea Towers, a very popular game, Baker’s Game, the original game of this type, and Penguin, a challenging twist on the genre.

In FreeCell Plus, you can play these most popular “open” games, where every card is visible from the initial deal, putting an emphasis more on strategy, rather than luck, in solving these card puzzles.  The first one million deals of FreeCell are identical to the version shipped with Windows, but our game extends this to 2 billion deals, and the other games with the same general layout, Baker’s Game, Spidercells, and Two Cells (as well as three of the bonus games) use compatible deals.  Playing in climb mode, you can challenge yourself sequentially to each deal of this game that is winnable in more than 99.99% of deals (and play 11981 before reaching the first unwinnable one).

You can download a free 30-day trial version here for either Windows 8/7/Vista/XP or Mac OS X 10.4 or later (Mountain Lion, Lion, Snow Leopard, Leopard, or Tiger).  Buy a copy here for only $9.95, and receive 4 bonus games not available in the trial version.  Note that there is also a “special code” purchase available to allow FreeCell Plus to be played on all (Windows or Mac) computers in your household.

FreeCell Plus is actually a reboot/replacement of an older version for Windows 3.1 that sold well (unchanged) for more than a decade.  I recreated this version using our proprietary Goodsol Solitaire Engine (and none of the original code or resources), also adding the Quick Launch window.  This is currently the smallest GSE game, with only 12 games in the full version (although there is another game in the pipeline with even fewer, but a more diverse selection), and the iOS version is in active development.