The End of 16-bit

As you may have heard, 16-bit applications do not run on 64-bit versions of Windows.  The translation for Fox developers is that neither the DOS nor Windows versions of FoxPro 2.x (and earlier) will run on Windows Vista x64.  In fact, DOS does not exist at all under 64-bit.  Select Start->Run, enter command on Vista 32-bit, and you are greeted with a “Microsoft Windows DOS” command window.  Do the same on Vista 64-bit and you’ll get an error that it does not exist.  (NOTE: cmdis the Windows command-line and it still works, and though similar to DOS, it is not.)  Microsoft’s ability to claim “VisiCalc still runs” is coming to a close.So what?  There’s not any demand for 64-bit on the desktop, and certainly not like there was for 32-bit.  That’s true from a software point of view, but looking at hardware, any new computer with 4GB or more of RAM is going to ship with Vista x64, and that is becoming more commonplace.  By this time next year, the default installation for most new computers may be Windows 7 x64, and you’ll have to request 32-bit.

The obvious solution is to do just that and buy 32-bit Windows.  Of course, you aren’t going to receive a call from your client until after they buy the machine, and wiping the machine may not be a good option.  You could use Virtual PC or other virtualization software to install 32-bit Windows on top of the x64 version and run the app inside that environment indefinitely.  I think that will be a common choice.  If you’re lucky, maybe the client will realize it’s finally time to get off of DOS/Windows 3.x and upgrade the app.  Unless a complete rewrite is in order, the easiest and cheapest path will be to use VFP 9, which works just fine on 64-bit Windows.

Can we use the lifetime of 16-bit computing to predict the lifetime of 32-bit?  Not really, but let’s do it anyway :).  It’s hard to pinpoint the “beginning” of 16-bit, but let’s go with the dawn of the IBM PC in 1980.  32-bit computing clearly became mainstream with the release of Windows 95.  In 2010, whether or not 64-bit will be considered “mainstream” is debatable, but it certainly presents a problem for 16-bit apps.  With that in mind, it appears that desktop computing shifts to the next level roughly every 15 years.  Again, this is just conjecture, but if that pattern holds true, 32-bit Windows apps (like those written in VFP) would continue to function until 2025.  Virtualization may extend that further.  That doesn’t mean they will be acceptable in the marketplace, any more than 16-bit apps are now, but they may at least still run.

The FoxTabs Challenge


The latest FoxRockX issue includes an article on FoxTabs by Rick Schummer. After months of neglect, that inspired me to get another release out, so you can now grab FoxTabs 0.9 beta from VFPX. My feeling is that FoxTabs is now “feature complete” for a 1.0 release, although I would not be surprised if there are a few more releases to shake out any remaining bugs. Please download the latest version and help us get to 1.0!

As Rick points out in the article, stability can be an issue, especially while testing your code in the ide. To that end, I added a pause button that removes all event bindings temporarily. If things get a little flaky during testing, or if you just don’t want to risk any interference from FoxTabs, press the pause button. When you’re done, press resume and you’re back in business.

Wikipedia says the following about observation:

One problem encountered throughout scientific fields is that the observation may affect the process being observed, resulting in a different outcome than if the process was unobserved.

Unfortunately, that can sometimes be the case with FoxTabs, making stability the number one challenge of this project. We have come a long way since the initial release of FoxTabs, but there is more work to do. Capturing and responding to the myriads of events flying around can sometimes cause unpredictable results.

This is compounded by the fact that the various VFP IDE windows are not exactly consistent in their behavior. For example, most IDE windows broadcast a WM_SETFOCUS message when activated, which FoxTabs uses to highlight the associated tab. But the Project Manager doesn’t send out a WM_SETFOCUS. Why not? I don’t know. Neither does the Properties window, but it’s different than the Project Manager, because each of its tabs sends out its own messages. I had to find the right combination of events and messages, so that FoxTabs responds consistently to all IDE windows. This can be frustrating, but it’s also interesting, because you get a tiny peek at what’s going on under the hood.

Of a more serious nature is when some amalgamation of events combined with FoxTabs produces unexpected results, or worse, a C5 crash. That’s when you get the sinking feeling that your productivity tool has just become an un-productivity tool. These can be difficult to track down.

A few months ago a developer reported crashes when opening the debugger. I was able to open the debugger without issue using set step on or a breakpoint. It took me a whole day, but I eventually traced this to the Call Stack window, which only caused a crash if you opened it after suspending a program. It was a very specific set of circumstances that led to the crash. Fortunately, I was able to find a workaround.

Another interesting case was fixed in the latest version. Opening the expression builder
using GetExpr() worked fine. However, if you opened it from the functions and expressions button in the view designer, boom! Fox crashed. I traced the problem to this code from the FoxTabs window event handler:

function wmeventhandler(hwnd as integer, msg as integer, wparam as integer, lparam as integer)

local oexception as exception
local lnreturn as integer
lnreturn = 0
black hole: hwnd and msg do not exist ***
* must pass the message on
lnreturn = callwindowproc(this.prevwndfunc, hwnd, msg, wparam, lparam)
return lnreturn


Windows events pass four parameters to the event handler: hwnd, msg, wparam, and lparam. When opening the expression builder from the view designer, those variables don’t exist in the event handler. I don’t mean that they are not assigned a value, I mean that they do not exist! How is that possible given that the variables are clearly defined as parameters only a few lines earlier? It’s as if they were sucked into a black hole and out of existence. When you try to access the variables or pass the event on to its original destination (CallWindowProc), Fox crashes because nothing is there. It’s one of the strangest things I’ve seen in Fox. I was able to plug the hole by checking if the variables exist and simply returning if they do not. My hope is that this is the same hole causing other random C5 errors, and that those are now fixed.

So, yeah, there are some challenges, especially when you’re not a C/C++ programmer and you don’t deal with this kind of stuff every day. But I do have to say it is very satisfying to find solutions to these problems, and I learn a lot in the process. I guess this isn’t the best sales pitch
for using FoxTabs, but I think we’ll get there. I hope you give it a try and let us know how it works for you.