Running Visual FoxPro on
Linux Using Wine
Session Number 37
Paul McNett
881 B Street
Hollister, CA 95023 USA
Voice: 831-636-9900
Fax: 831-636-3077
Email: p@ulmcnett.com
Overview
Visual FoxPro can run on Linux by using an open source project called Wine, which is basically
a substitute API. Wine is still in alpha stage, so Visual FoxPro support on Linux is not yet
complete. This session offers a practical overview of the current state of affairs of running Visual
FoxPro on Wine – what works, what does not, and how to set up a reliable install of Visual
FoxPro or a runtime version of an application built with VFP on your Linux workstation. This
whitepaper is VFP8-centric, but should apply to other versions as well.
Introduction
Companies all over the world, and of all different sizes and makeups, have internal applications
built with Visual FoxPro. Their investments in these applications are safe for the next 5 years at
least, provided they stick with Microsoft Windows on the desktop.
Since 1998, when Linux really hit the mainstream in the server arena, it has been steadily
gaining new users, mostly developers, until we come to early 2003 when normal users started
migrating to the Linux desktop as well. No one really knows how much of Microsoft's
commanding market share of the desktop will fall to Linux, but we already know of a few states,
countries, and municipalities that have mandated it, and of companies large and small that have
committed resources to switching their desktops from Windows to Linux. We also know that the
Linux desktop market is only at the start of its growth cycle. As new features get added to the
solid Linux platform, it will become an ever more compelling option for companies. As more
and more businesses adopt the Linux platform, more and more vendors will start writing native
applications for the Linux desktop.
We are not there yet. Software companies are still writing the vast majority of their titles
solely for Windows. Even while more people are switching to Linux every day, it is still
economically sensible for companies to produce software titles for just the dominant platform.
The time will come, however, when these same software manufacturers will be scrambling to
offer Linux ports of their popular titles, because it will become sensible from a business
standpoint to do so.
Until that time, developers of custom business applications need some sort of bridge, so
that they can start to gain experience on the Linux platform while still running – and developing
- legacy Windows applications. After all, we've invested a lot in the applications our businesses –
and our client's businesses – depend on. If our clients start moving to Linux, we will need a way
to continue offering our services.
For many Windows applications – Microsoft Office and Adobe Photoshop, for example –
the bridge is already there and getting stronger every day. Wine is the bridge that gives users the
ability to install Windows applications on Linux. The application is completely ignorant that it is
not in fact running on Windows, but interacting instead with the Wine API.
The “bridge” concept is an important one, when you consider the fact that there are
already Linux native applications that perform the same functions as Microsoft Office and
Adobe Photoshop. Switching from Microsoft Office on Windows to OpenOffice.org on Linux
overnight is a bit drastic, however, as the user will have to immediately learn how to do things
the OpenOffice.org way. It is a much better transition in a lot of cases to first switch the
underlying operating system while still running the familiar user applications, and perhaps
offering OpenOffice.org side-by-side with Microsoft Office. Once the user is comfortable with
OpenOffice.org - and once all the company's Word documents, templates, etc. are converted,
only at that point should the company uninstall Word completely. One of the biggest hurdles
organizations will have in switching from Windows to Linux is with the users – and the
applications those users are used to interacting with to get their jobs done. Wine provides the
bridge that allows the IT staff to switch the desktop to Linux while the users can transition their
use of Windows applications to Linux applications.
The case of legacy custom business applications is touchier than with shrinkwrap
applications. Where shrinkwrap applications tend to have open-source replacements available for
Linux, as with the case of OpenOffice.org, custom business applications may need to be
rewritten with other development tools to run on alternate platforms.
Fortunately, the rewrite of the business application doesn't necessarily need to happen
straight away. Just as Wine can provide a bridge for applications such as Word, Excel, and
Photoshop, it can work for Visual FoxPro applications as well. You as a VFP developer can run
on a Linux workstation while developing Visual FoxPro applications, and/or you can deploy
your Visual FoxPro applications to a Linux platform withWine.
This paper is divided into a few sections. First, I'll outline what isn't working in the
VFP/Wine setup. The list is longer that I'd like, and may well present a few show stoppers for
your own situation, so this section appears first. You'll need to have some idea of where you
stand with regard to your own application's potential for successfully running on Linux before
you can justify spending time and money on it. Keep in mind that this list used to be longer just a
few months ago, when VFP wouldn't even run without crashing, when file and record locking
didn't work, and when you couldn't even instantiate a simple ActiveX control.
I'll then provide a step-by-step guide to installing Wine and Visual FoxPro on your Linux
workstation, and discuss various strategies for working with this setup. Always keep in mind that
what we can do today with Wine is only a fraction of what we'll be able to do tomorrow. In other
words, the things that don't work today will eventually be fixed, and by knowing about the Wine
option now, you'll be ready to act tomorrow, when your client asks you to put your application
on his or her new Linux laptop.
Microsoft Windows will be the dominant desktop operating system for years to come, but
unlike just a few years ago, there are real and practical alternatives in Linux and Mac OSX.
Currently, these alternative operating systems are indeed on the sidelines, but at the same time
they are making inroads. Normal people recognize the 'Linux' name now, and power users are
starting to experiment with Linux. Developers of custom business applications need to have
strategies in place for deploying to these other operating systems should a customer demand it in
the future. Visual FoxPro/Wine can be an option, if even only a temporary one, buying time for
the developer to port the application into a more portable development environment, such as
Python or Java.
Potential Show stoppers
Wine is alpha software, not advertised to work and certainly not guaranteed to work. It seems
like every year, Wine will be at its 1.0 release in just another year or two. It is now over ten years
in the making. This is the reality - while I believe 1.0 is going to happen in the 12-18 month
timeframe based on the current rate of developer activity, only time will tell if Wine ever gets a
final release.
However, Visual FoxPro does work very well on Wine as it stands currently, barring a
few key features and a few less important ones. The following table should help you determine if
your Visual FoxPro environment is likely to work under Wine. Fortunately, VFP runtime
applications are less limited than the IDE as far as things that work are concerned. Therefore,
even if you can't (or don't want to) run your development environment on Linux, it is quite
possible that your runtime application will still work fine with few if any changes required.
Potential Show Stoppers: VFP IDE
Potential Show
Stopper
Discussion IDE Runtime
Fonts are not
equivalent between
Windows and Linux.
Microsoft's core fonts (Arial, Times
New Roman, Courier New, Andale
Mono, Verdana, Tahoma, and others)
do not exist on a plain vanilla Linux
distribution, so they are unavailable
inside VFP. Font substitution will
occur, which may result in controls
not being the correct size to display all
the text, and/or your controls, forms,
and reports not displaying as you
designed them.
http ://corefonts.sourceforge.net
contains instructions for legally
installing the Microsoft core fonts
onto Linux. Once that is done, Wine
will discover them and make them
available to Visual FoxPro as well.
Yes Yes
Potential Show
Stopper
Discussion IDE Runtime
Printing Reports may layout differently on
Wine than on Windows.
You'll have to assess this on a report
by report basis. Stick to core fonts and
generic printer features and it may
work with minimal hassles.
Developers may need to be prepared
to maintain two sets of reports based
on the platform being deployed to.
Yes Yes
No HTML Help A CHM Help Viewer application does
not yet exist for Wine, so you cannot
view your VFP Help file.
No current workaround known. When
Wine is released, it is expected that it
will have tools for displaying HTML
Help.
For runtime applications, you could
distribute a WinHelp version, or a
pure-HTML version.
Yes Yes
Version info and icon
resources do not get
included in EXE in
VFP8
VFP8 uses a different system call to
set the version info in a newly built
exe, and this system call is currently
not implemented in Wine, resulting in
no version or icon resources being
added to your EXE when built from
Wine.
When testing, this doesn't matter.
When time for final build for
deployment, build on Windows.
A runtime application on Linux built
with VFP8 on Windows will correctly
read the version and icon information
from the executable.
Yes No
C0000005 error with
JPEG images
When adding a JPEG image to a
control, a C0000005 error will occur.
Convert your image to a BMP
instead.
Yes Yes
