After writing Part 1 of this series, I've spent some real time working with Visual FoxPro on Linux. I've successfully deployed an application to my Linux workstation, and maintained several other applications by using the VFP IDE under Linux. These efforts did have their struggles, however, and there are certain things I either couldn't do at all or that required significant workarounds.
This article will offer an overview of the current major trouble areas with running Visual FoxPro on Linux. After reading all of this, you may find yourself saying, "Boy, why would I want to go through all that hassle?" Indeed, this article is definitely a second act: It's about the sobering realizations of what works and what doesn't, and about looking forward to the climax of this saga—when the Wine project reaches maturity and Visual FoxPro looks and feels the same on Linux as it does on Windows. The pieces are all starting to fall into place, but as of this writing (June 2003) there are still some issues.
The Wine project, which makes it possible to run native Windows applications directly on Linux, is continually advancing. It's still Alpha software, which means it's definitely not ready for an end-user install, but as you saw if you followed my steps in Part 1, Visual FoxPro works surprisingly well on Linux. Since my article in March, a few fixes have been made to Wine that benefit Visual FoxPro. The patch that you had to apply to keep Visual FoxPro from freezing is no longer needed. Visual FoxPro windows can now be resized normally by grabbing the window border. WAIT WINDOW and ToolTipText windows are now displayed correctly (a patch is required for this, which I'll tell you how to apply). The GetFile() dialog box now displays correctly. The list of fixes and enhancements to the Wine project in general is quite large, and there are certainly other things that have made Visual FoxPro run better that I haven't even noticed yet.
Before I get much further with this, let me assure you that I fully expect Visual FoxPro to run perfectly well on Linux and Macintosh OSX within 18 months. As it stands currently, Visual FoxPro doesn't run at all on Macintosh OSX, and I estimate that it runs at about 75 to 80 percent of capacity on Linux. By getting your feet wet now, you'll be ready to develop and deploy on Linux and OSX when that time comes.
So, I'll start off by offering instructions on how to get current with Wine, which assumes you've read my original instructions in Part 1 (FoxTalk, March 2003). I'll then list some problem areas with Visual FoxPro on Wine, and offer workarounds or solutions where possible—should you want to get started sooner rather than later. By the time you read this, I expect that a number of current issues will already have been taken care of.
cd ~/wine/wine su make uninstall exit
Now, get the latest version of the Wine source (as of this writing, 20030508) and expand it into ~/wine/wine. Follow these steps to apply a patch to make the WAIT WINDOW and ToolTipText windows display properly:
1. Get the patch and save it to ~/wine/vfpwinepatchwinsize. I've included the patch file in the accompanying Download file, or you can download it from www.paulmcnett.com/vfp/wine/vfpwinepatchwinsize.
2. At the command shell, type the following commands:
cd ~/wine cat vfpwinepatchwinsize | patch -p1
3. When asked for the file to patch, enter the following:
If all went well, you should have received a message that the patch was applied.
Okay, now you have the current source code and you've applied the latest patch to the source code, so you're ready to install. Follow my complete instructions in Part 1, but briefly what you need to do is:
cd ~/wine/wine ./tools/wineinstall
After the install finally finishes, do the simple tests to make sure it's all working, as outlined in Part 1.
Recap of critical Wine config file settings
The most critical thing that you need to change is in the [Version] section of the config file. By default, Wine emulates Windows 95, and the config file shows the Windows version line commented out. You need to uncomment it, and change it to force Wine to emulate Windows NT4. (Note: Even for Visual FoxPro 8, which doesn't officially run on Windows NT4, you still want to set Wine to emulate NT4, as there are areas of VFP that don't work if you set it to "winxp" or "win2k".) You can make this change globally, as I just directed you to do, or you can put it in the application override section of the Wine config file as I directed you to do in Part 1. Once you have this fixed in the config file, Visual FoxPro will start without crashing.
You also need to make sure that you have the following Windows DLLs in your Wine fake Windows system directory (~/c/windows/system, if you followed my instructions):
• msvcr70.dll (VFP7 and VFP8 only)
• gdiplus.dll (VFP8 only)
msvcr70.dll and gdiplus.dll can be found on the VFP8 CD, while oleaut32.dll and comdlg32.dll will have to be copied from your real Windows distribution. (You've got a spare license for those files since you had to install Linux on a machine that originally came with Windows, since it's impossible to buy a desktop computer without Windows already installed.) Next, you need to edit the Wine config file so that the "native" versions of oleaut32.dll and comdlg32.dll are loaded instead of Wine's "built-in" versions, which can't at the moment seem to get the _VFP object properly set up, and can't display the MODIFY CLASS dialog correctly.
Before I go on, let me talk a bit about making the Linux command line easier to use. Your fake Windows directory has long directory names for certain directories, namely "Program Files". But because I use the command line for almost everything, I really hate having to type that in all the time. Do the following to make a shortcut:
cd ~/c ln -s Program\ Files/ prg
You now have a symbolic link (a shortcut that Linux recognizes at the filesystem level) and can choose to type "prg" when you mean "Program Files". So, do this to start up VFP7, which you already did by following my instructions in Part 1:
cd ~/c/prg/vfp7 wine vfp7
The first thing you should do after VFP loads is to right-click on the command window and uncheck "dockable"—otherwise, strange things may occur (for what it's worth, strange things also occur on Windows with "dockable" checked).
Now, create a project, add programs, classes, and reports to it, build an executable, and just get a feel for the IDE in general. There are few areas that don't work, and the rest of this article is dedicated to discussion of the various issues I've encountered.
cd ~/c/windows/system regsvr32 comctl32.ocx
You'll now see the common controls in VFP's tools/options/controls/ActiveX section. However, if you try to use them by putting a TreeView, for example, on a form in the class designer, you'll get an error that the appropriate design-time license isn't found. To get this to work, you need to locate the appropriate Registry keys on your Windows install, export them to a .reg file, and copy them over to your Linux/Wine file system and import them. But even this may not work, as I tried registering comctl32.ocx on my machine and running a VFP app that had been compiled in Windows with a TreeView control, and I couldn't get the TreeView to work at all on Linux. So, for now at least, consider ActiveX controls as out of bounds for Linux/VFP apps. I've always pretty much avoided ActiveX controls in my apps anyway, usually electing to make my own controls based on Visual FoxPro's native controls, so this really isn't an issue for me. But do take heart: ActiveX will eventually work in VFP/Wine, it's just a matter of time.
That said, there's a newly discovered bug that will cause record locking to not work correctly in certain situations. The bug isn't with Wine, but with the Linux implementation of smbmount, which is essentially the client side of the Windows file sharing mechanism. The short answer is that connecting your Linux box to a file server by using the smb client will result in incorrect locking. This is unfortunate because it's a common situation to have your DBFs on a Windows server for all your clients (Windows and Linux) to connect to.
The answer is to not connect to your data from Linux using the smb client, at least for now. What I'd suggest instead is that you move your data over to a Linux Samba server and connect with Microsoft Networking from your Windows clients, and that your Linux clients use the native NFS (Network File System) to access the data. You'll likely find that Linux is a much better file server than Windows anyway (I put a Linux Samba server at a client almost two years ago and all data problems have gone away—and they've never had to reboot that server). By connecting with NFS from Linux, and with SMB from Windows, locking is respected by all. Configuring Samba and NFS is beyond the scope of this article, but it isn't hard to do.
So that's the good news. The not-so-good news is that the various font-properties windows in Visual FoxPro don't work correctly. You may choose Arial, size 12, bold, but you actually get Arial, size 10, italic. Note that I'm talking here about the font-picker window that you see in the report designer, for instance. Font properties as set in the Properties sheet of the form/class designer work just fine. I've been able to use trial and error to get the actual size I desire, but it's definitely annoying nonetheless.
Weird window backgrounding
Your Linux X Windowing environment has any number of virtual desktops that you can use. Look down in your Linux taskbar and there's likely a representation of four possible virtual desktops. You can choose to put VFP on its own virtual desktop, and then, since it's the only application on that desktop, it will never "disappear." To do this, select the control menu (upper-left of the VFP window) and choose "To Desktop..." and select an empty desktop. Then switch to that desktop by clicking its representation in the taskbar and you're all set.
That solution is what I did for a while, but I got really tired of switching to different desktops, especially with several instances of VFP running alongside several instances of the various VFP-built applications that I was testing. Instead, I've set a configuration option to not let X Windows manage my VFP windows. This means that your VFP windows won't appear in the Linux taskbar, nor will you be able to Alt+Tab between them. They'll be AlwaysOnTop, which means you're forced to minimize them when you want to switch to another app. I still like this better than the first option, but it sure is inconvenient to be forced to minimize the window and then search for the icon floating on the desktop to restore it. To try this option out, look for the line in ~/.wine/config under the [x11drv] section that looks like "Managed" = "Y". Take the semicolon away from the beginning of the line, change the "Y" to "N", and restart Wine/VFP (exit VFP and restart VFP). As long as no other instances of Wine are running, your new settings will take effect.
There's an additional option: Under that same [x11drv] section in your ~/.wine/config file, set the following:
; Allow the window manager to manage created windows "Managed" = "Y" ; Use a desktop window of 800x600 for Wine "Desktop" = "800x600"
With these settings, Wine will put your VFP window inside a container window of size 800x600. You can't size the container window at runtime, but you can resize your VFP window within it as you see fit (I don't see any point in doing anything but maximizing it). Each instance of VFP you run will result in a separate Wine container window. This looks kind of hokey, but it's the best of all the options in my opinion because you can still Alt+Tab between applications.
Now for the great news: The Wine developers rewrote some of the windowing modules, and my testing today indicates that this "weird window backgrounding" problem was fixed with the rewrite. Therefore, the next version of Wine (the version that will come out after wine-20030508) will be the version that you want to use, and if you do you won't have to worry about this issue at all.
The class designer
There has been some talk of people being able to get Internet Explorer running under Wine, but it looks pretty hairy and there are all kinds of warnings about possible file corruption issues. Perhaps if you could get Internet Explorer working, you could then get hh.exe working and be able to view CHM Help files. I didn't try that, opting instead to wait until there's a Wine HTML Help viewer available.
The report writer and the report designer
Because of the current printer setup difficulties, you probably won't be able to edit printer properties settings such as landscape/portrait. In fact, unless you can set up a printer at all, the GetPrinter() dialog is empty, and prone to causing C0000005 errors. So developing plain-vanilla portrait reports can be done with ease, but you won't be able to design a report with any of the printer driver-specific options such as landscape, duplex, or custom sizes and tray assignments. I'd recommend using VFP on Windows for working with reports, for the time being.
Connecting to remote data with ODBC
Wine does come with its own implementation of ODBC, which looks really slick as it wraps around the Linux-native UnixODBC package. For some reason, even though I can set up my UnixODBC connections and test them from the Linux command line successfully, Visual FoxPro fails with stack overflow errors when I try to use SQLCONNECT() or SQLSTRINGCONNECT() on them. So set your ODBC32.DLL to "native" in your Wine config file and you should be all set. Do install MyODBC 2.5x from MySQL, even if you don't use MySQL, as it will set up the Microsoft ODBC programs and Registry entries, and you can then do a "wine odbcad32.exe" to set up your DSNs.
CursorToXML() and XMLToCursor()
Making a _WINE public variable
PUBLIC _WINE _WINE = "wine" $ LOWER(getenv("_"))
Wine will pass all Linux environmental variables into the Wine environment, making them accessible from VFP with GETENV(), and the underscore is an automatic environmental variable in Linux—it contains the last-executed script or program run from within that shell. I took advantage of that fact in crafting the _WINE public variable.
The good news is that for the most part, all of the features that were part of VFP7 will work in VFP8 under Wine. The bad (but not unexpected) news is that most of the VFP8 enhancements have trouble in Wine. For instance, don't even try running the Task Pane, as it relies heavily on Internet Explorer. Similarly, the Toolbox and Find References have problems because of missing OCXs. Basically, the things that work in VFP tend to be the things that are built into the VFP executable or runtime libraries. The things that don't work tend to include system libraries, which are likely not set up on Wine because you didn't actually install VFP—you just copied it over. VFP8 includes more of the latter type of feature, and therefore very few of the IDE enhancements work on Wine at the time of this writing.
However, language enhancements such as TRY...FINALLY, CursorAdaptor, and the Empty Class seem to work just fine. The report designer improvements, such as tabbing between controls and Page X of Y, work. The "View Parent Code" button functions as advertised.
One thing that doesn't work properly in VFP8, even though it used to work in VFP7 and before, is the adding of resources to your EXE file during the build process. One of the last things that happens to your EXE when it's being built is the addition of version resources and icon resources. In VFP8, these resources don't get added.
Linux and Macintosh both represent growth markets for desktop applications. There currently are no IDEs for developing database-centric applications (what other types of applications are there, really?) with VFP's richness available for either platform. Opportunities are ripe for growing the popularity (and sales figures) of the Visual FoxPro product, by making and deploying Visual FoxPro applications on Linux and Macintosh, as well as on traditional Windows. Instead of being in a dying niche, Visual FoxPro developers can be in high demand again!