(VFP) - Running Visual FoxPro on Linux
Running Visual FoxPro on Linux
By Paul McNett (FoxTalk, March 2003)
While Microsoft publicly refuses to release Visual FoxPro for alternate platforms, there's still hope for a multi-platform VFP. Using an open-source product called Wine, Paul McNett shows how we can take matters into our own hands and put the fox on Linux ourselves.
Remember last century, when one of FoxPro's greatest selling points was its ability to run and deploy to not one, not two, not three, but four separate platforms? This was a powerful selling point for me when I was choosing my development environment: Even though I only ever deployed to Windows, it was reassuring to know I wouldn't be painted into a corner should a client ask about a Mac, Unix, or DOS version of my software. Contrast that to today: As new versions of Visual FoxPro emerge with their great features and fixes, I keep finding myself thinking that our situation as VFP developers is pretty dire, being limited to developing and deploying on just one platform.
Have you seen a Mac OSX or a Linux desktop lately? Your clients are going to want to use these other advanced operating systems, and if you're like me, you'll want to be able to deliver. Unfortunately, if you want to deploy to multiple platforms this likely means picking a different development kit: Delphi/Kylix, Java, or maybe C++. You'll have to learn how to work in these other environments, and put up with the lack of Visual FoxPro's native cursor engine. I don't know about you, but I'm not ready to give up the power of Visual FoxPro just because Microsoft refuses to provide ports to other platforms. In this article, I'll show you how to get your Visual FoxPro IDE and runtime applications working on Linux. My hope is that by making VFP available on Linux, the fox may once again breathe with new life, and Visual FoxPro developers may once again be in high demand.
There are three pieces to the puzzle of getting VFP working on your Linux desktop. For starters, you need a Linux workstation installation, with all the developer tools installed (gcc, make, and so on). Second, you need a Windows install of VFP—from which you'll copy over the VFP program folder and subfolders into your Linux filesystem (avoid licensing issues—make sure you aren't running your Windows and Linux installations of VFP simultaneously). Third, you need to install a recent version of the free, open-source product called Wine. Think of Wine as a Windows compatibility layer. As your VFP app makes its standard Windows API calls, Wine intercepts those calls with its own code and effectively mimics the Windows API: Your FoxPro app has no idea it isn't actually running on Windows! To date, quite a few Windows applications are being successfully run on Linux using Wine. This article will concentrate on the installation and configuration of Wine, as it's the most important piece of the puzzle. Future articles will discuss what to do next.
Reality (a disclaimer)
Wine is alpha software. As such, not everything works correctly. Under Linux/Wine, Visual FoxPro will behave differently than you're used to, in mostly minor (but sometimes major) ways. Please don't follow the steps in this article thinking that everything is going to work perfectly right out of the box. You'll need to engage in your own testing, and make your own assessment as to the viability of deploying your specific VFP app to Linux. You should think of this as experimental, and if you end up using it for production work, it's even more important to maintain adequate backups of your source code. Eventually, as the Wine product matures, there will be no perceivable difference between running VFP on Windows vs. Linux. Until that time, though, it's up to us to find the various problems and document them, so that fixes can be found and integrated into the Wine project.
I plan on using Visual FoxPro on Linux as my primary development environment, because based on my testing so far I believe it is stable enough and functional enough for my purposes. However, I've made it a point over the years to keep things pretty simple—limited dependencies on external DLLs and OCXs, for example. If you depend on ActiveX controls (even the ones that ship with VFP), plan on having extra configuration problems and possibly even having to abandon the use of those controls. And this article was written while VFP 8 was in beta; it's difficult to say whether problems I've run into are because of issues to be resolved with VFP or with Wine.
Okay, now that you've read this disclaimer, it's time to begin the process of getting Visual FoxPro running on your Linux installation.
Choose a flavor of Linux and install it
If you're just getting started with Linux, the number of choices you have in every aspect of the installation and configuration process can be pretty daunting. You don't know whether you want RedHat or SuSE, Gnome or KDE, vi or emacs, how to allocate your swap partition, and so on and so forth. Don't worry so much about it. Just pick a distribution (hint—pick RedHat8, as that's what I'm using here), choose to do a workstation install, making sure to install the developer tools (you'll need them later to compile Wine from the sources), and you'll be ready to go in no time. Don't confuse the works: Install Linux to a secondary computer that has a hard drive you don't care about erasing. There are many ways to acquire RedHat8: Buy it off the shelf, purchase a book that has the install CDs included, download it from www.redhat.com, or borrow it from a friend. Installing Linux is beyond the scope of this article, but assuming you have a reasonably new computer with a free hard drive and bootable CD-ROM drive, you'll likely find the process surprisingly painless, even fun.
Download and install Wine
RedHat and other distributions come with Wine installations, but with a fast-moving project like Wine they quickly become outdated. Get used to checking frequently at www.winehq.com for the latest release. There are three different download options:
1. Binary Packages for specific Linux distributions (rpm, dpk)
2. Source tarballs (tar.gz)
3. CVS tree
Binary packages are usually the easy, safe way to go, especially if you're new to Linux. Think of them as equivalent to the Windows Installer. Everything necessary to run the program is put into the package, and when installed, an entry for that application will appear in the central package management database. The package manager knows where to put all the files, what links to add, everything. Depending on what you're installing, you may even need to explicitly accept a license agreement or make some simple configuration decisions.
Source tarballs are zipped archives of all the source code for a project. You download and unzip the tarball, and you're left with a directory structure that represents the source code and accompanying files for the project. You can optionally modify the source code, and then compile and install the software. Don't worry, this isn't as difficult as it may seem; compiling your first open-source project may very well give you that little spark of freedom and excitement that comes from the feeling that you're in control of your machine again.
The CVS (Concurrent Versioning System) tree has all the source code in up-to-the-minute fashion. As soon as Alexandre Julliard, the maintainer of the Wine project, accepts a patch submitted from one of hundreds of developers worldwide, he'll apply that patch against the current version of the code and then commit that change to the CVS tree. People who get their Wine from the CVS tree are on the bleeding edge, and risk running into trouble if a recent change has screwed something up. Wine developers rely on access to the live CVS tree; users should instead go the binary or tarball route.
I'll be using the option 2, source tarballs, for the examples in this article. [Editor's note: Don't let your newness to Linux nudge you into trying option 1—compiling from your own source tarballs really is very simple! Give it a shot!] Here's how to download and install Wine on your system:
1. Fire up Linux and XWindows, log in as a normal user (please don't log in as root), get an Internet connection, navigate your browser to www.winehq.com/download, and scroll down to the section "Wine Source from Tarball." You want the file named Wine-20021219.tar.gz. Choose to download this to a location under your home directory. I suggest ~/wine. The file is approximately 7.7MB in size—you can proceed to step 2 while waiting for the download to complete. My examples here are based on Wine-20021219.tar.gz, which was the latest release while writing this article. Note that by the time this article hits the street, later releases will be listed on the site as well—however, older releases are still available. Even if a later release is available, I'd suggest downloading this version at least at first, to ensure my examples work as expected. Note that the filename yields the release date of the version. For now, because it's still in the alpha stage, Wine releases don't have version numbers, but instead use the release date for version tracking. It's standard for open-source downloads to show the product version as part of the filename, which is rather convenient because frequent releases are the norm.
2. Open up a shell window. Almost everything I do to configure Wine and Linux is done using a shell window rather than graphical tools. You'll leave this shell window open and add others along the way, switching among them as you work on this example. Make yourself the superuser (root) for this command window (you'll need to know the root password):
su -
3. Now, it's important to make sure that any previous installation of Wine is removed from your system. On a system that uses RPMs (RedHat), first check with the package database to make sure there are no previous RPM installs of Wine. The following command will do this for you:
rpm -q --all | grep -i "wine"
If no output was returned, then RPM has no knowledge of Wine ever having been installed. Otherwise, you'll need to uninstall Wine for each entry returned in the preceding query, by using the following command:
rpm -e --allmatches --nodeps
where is entered exactly as it was reported in the rpm-q query results. Now, just because all traces of it have been removed from the Red Hat Package Manager, that doesn't mean that Wine doesn't still exist somewhere on your system. Search for installations by typing the following into your superuser command window:
cd /
find -name wine
This may take a minute or two. If any installations are found, manually delete them. For example, you might find files such as /usr/local/bin/wine and /usr/local/bin/winedbg. Remove these by typing something like:
rm /usr/local/bin/wine*
Also remove any library files such as libwine.* and the wine directory under /usr/local/lib. You can remove this directory, if found, by typing:
rm -r --force /usr/local/lib/wine
4. Now that you've downloaded the Wine sources (I'll assume you've downloaded them to ~/wine/Wine-20021219.tar.gz), it's time to unzip them and expand them. Your current command shell is logged in as root, but you must not install Wine as root. You could just type exit in the command shell to log out of superuser mode, but instead, why don't you just start another command shell? Now you have one shell that's ready and waiting to do superuser stuff, and one to use for normal, user-level tasks. Note that the command prompt gives you a visual clue as to who you're logged in as, and if you're ever confused about that issue you can type whoami at the prompt. Anyway, go to your new command shell (the normal-user shell) and enter the following commands:
cd ~/wine ;change directory
ls -al ;list directory
tar -xzvf Wine-20021219.tar.gz ;after W press TAB
ls -al
Now you should see, alongside the original compressed archive, a directory called ./wine-20021219. This directory structure contains lots of files, some tools, and the source code and makefiles for Wine. Have a look around at the structure of this directory if you wish. In particular, you may want to peruse the README file:
cd wine-20021219 ;after w press TAB
vi README
Use the pageup/pagedown and arrow keys to navigate the README file, and when you're done press:q.
5. Now that you have the source code expanded, it's almost time to build and install Wine. However, there's an important patch that we need to apply to the Wine source first that will allow Visual FoxPro to work. Download this patch file from http://cvs.winehq.com/patch.py?id=7029 (save target as ~/wine/vfpwinepatch7029). Apply the patch by executing these commands from your normal-user console window (by the way, that's "pee-one," not "pee-el," in the last argument):
cd ~/wine/wine-20021219
cat ../vfpwinepatch7029 | patch -p1
Basically, you're piping the output of the patch file into the patch command, which parses the patch file and applies the patch to the required source file, in this case ./windows/queue.c.
6. After applying the patch, the source code is ready to compile and install. Wine comes with a tool to help you with this, making it even easier. From your normal-user console window (not the root console), type the following:
cd ~/wine/wine-20021219
./tools/wineinstall
The wineinstall script starts by configuring your build. Lots of text will fly by without giving you a chance to read it—don't worry, the verbose output is normal. After about a minute of this you'll see the following message:
We need to install wine as root user, do you want
us to build wine, 'su root' and install Wine?
Enter 'no' to continue without installing
(yes/no)
This is an example of how un-user friendly Linux applications can be. Remember, it's still in the alpha stage. Basically, if you answer no, Wine will still be built but not installed—not very useful in our case. Type yes to continue, and go to lunch—the build process will take forever. (Okay, maybe unfriendly, but not without a personality, as the next message says "Building... Go to lunch, grab a video, whatever...")
After the build is complete, you'll be prompted for your root password. Enter it to continue, making especially sure you enter it correctly because if you fail, the script exits and you'll have to start this step all over again. Answer yes to create the local config file (~/.wine/config). Note that the install script has created a new directory, ~/.wine/, for you. This is where various files are stored that will affect the runtime behavior of Wine. I should backtrack for a moment and talk a little bit about the next message you'll see:
Searching for an existing Windows installation...
not found. (no matching /etc/fstab mount entry
found)
Windows was not found on your system, so I
assume you want a Wine-only installation.
Am I correct? (yes/no)
Wine can be set up to utilize an existing installation of Windows. Say you have a dual-boot system where you can boot into Linux or boot into Windows—a common practice. If you correctly set up your Linux installation to mount your Windows drive(s), then you can run your Windows software (the ones that work in Wine) without having to copy and/or reinstall them in Wine. There are lots of things that can go wrong with this method (not the least of which being that Linux doesn't officially support writing to NTFS volumes) so for simplicity please answer "yes" for a Wine-only installation. Accept the default on the next dialog by pressing:
Some fake Windows directories must be created,
to hold any .ini files, DLLs, start menu
entries, and other things your applications
may need to install. Where would you like your
fake C drive to be placed?
(default is /home/pmcnett/c)
You can actually choose whatever directory you like, but make sure to keep it under your own home directory or you won't have the proper access permissions.
Test your Wine installation
Now that you've installed Wine on your system, it's time to make sure it's working. Wine should have installed a few familiar utility programs in your ~/c/windows/ directory. Type the following in your normal-user console window:
cd ~/c/windows
ls -al
See the entry called notepad.exe? As you can see, it's actually a link to a library file called /usr/local/lib/wine/notepad.exe.so. This is Wine's implementation of Notepad, the familiar Windows text editing application—try running this to verify that your Wine installation is working fine:
wine notepad.exe
Since this is the first time you're running Wine, you'll see lots of text whiz by as the font metrics are set up. In a minute or so, you should see the Notepad program window, and if you interact with it you'll see that it behaves very much like its Windows counterpart. Choose File | Exit, and then rerun wine notepad.exe (hint—press the up arrow followed by the enter key) and notice that it starts up right away. No big deal yet: You've basically proven that you can load Wine's version of notepad.exe into Linux, but you haven't yet run any native Windows applications on Linux.
The next test is to grab a few native Windows executables from your c:\windows directory on your Windows system. I'd suggest trying out the following native Windows programs on Linux: sol.exe (Solitaire), calc.exe (Calculator), and regedit.exe (Registry Editor). Regedit.exe can be used to edit Wine's Registry, which mimics the Registry on Windows. If you try regedit.exe, rename it to winregedit.exe (there's a Wine text-only implementation of regedit and the name will conflict otherwise), and run it by typing wine winregedit.exe. Try out these native Windows programs by copying them to your ~/wine/c/windows/ directory, and then erase them immediately to avoid possible licensing issues.
This is more exciting than the Notepad example because you're actually running Windows executables (binaries) on Linux, albeit simple standalone ones. More complex applications have more dependencies than these smaller utility applications do, so they'll require more configurations. Microsoft Office, Internet Explorer, and Visual FoxPro can all run on Linux/Wine, but you won't be able to "install" them in the traditional Windows sense. You'll need to copy all of the necessary files and directories over and make the correct configuration changes in Wine to make them work. The steps that follow will show you how to configure Wine to run Visual FoxPro.
Copy VFP files and configure Wine for VFP
You're almost ready to load up the Visual FoxPro IDE on Linux. You'll need to copy the VFP files over to your Linux directory structure, and make a few configuration changes to your Wine installation:
1. Make the appropriate directories in your Wine directory structure. I tested VFP versions 5 through 8 for this article. From your normal-user command window, type the following (try pressing after the P to expand that directory for you, and try pressing the up arrow for lines 2-4 to save some typing):
mkdir ~/c/Program\ Files/vfp5
mkdir ~/c/Program\ Files/vfp6
mkdir ~/c/Program\ Files/vfp7
mkdir ~/c/Program\ Files/vfp8
Did you get confused about the backslash between "Program" and "Files"? Don't be. The simple answer is that spaces in filenames and directories aren't standard in Linux, and the backslash escapes it for the command interpreter. This makes it possible for Wine to mimic the silly Windows convention of the c:\Program Files directory.
2. Copy your VFP program files from your Windows installation. The method you'll use to do this will vary depending on how accessible your Windows volumes are from within your Linux installation. My Windows NT workstation is a different computer on the network, so I can, for example, copy my VFP7 install by executing the following:
cd ~/c/Program\ Files/vfp7
smbclient //nt_workstation/e$ -U Administrator
cd /prg/vfp7
recurse
prompt
mget *
This example uses smbclient to connect to a Windows system called //nt_workstation on the network to a share called e$, and log in as Administrator. It then changes to the directory where VFP7 is installed. Recurse is toggled On so that when we copy we get all subdirectories also. Prompt is toggled to Off so we don't have to confirm every copy. The mget * is what tells smbclient to get all the files. The point is that you need to copy your entire installed VFP installation over to your Wine fake C-drive. If you're at a loss, another way to do this would be to burn the VFP directory structure to a CD, and then mount that CD on Linux (mount /mnt/cdrom), and copy the files and subdirectories from there.
3. Copy a couple of files from your Windows System32 directory. Use the same method of copying as you did in step 2, but make the target directory ~/c/windows/system. The files you need are msvcr70.dll and oleaut32.dll. Also, get all the vfp runtimes (vfp*), which may be in your Windows\System32 directory or Program Files\Common Files\Microsoft Shared\VFP, depending on VFP version—but still make the target on Wine the ~/c/windows/system directory. Since these files are all installed or updated when you install VFP, you shouldn't run into license issues by copying them over to Linux now. Do remember to get a separate VFP license if you'll be running your Windows version alongside your Linux version.
4. You now need to edit your Wine config file (~/.wine/config) with at least one change. The first change has to do with how Wine acts from an operating system point of view. Wine can impersonate all the variants of Windows, the default being win98, but VFP won't load under Wine when impersonating win98—we need to change it to a NT-variant (nt351, nt40, win2k, or winxp). Do this by adding the following lines to the end of your ~/.wine/config file, above the closing line of # :
;; Visual FoxPro Entries:
;; VFP5:
[AppDefaults\\vfp5.exe\\Version]
"Windows" = "nt351"
;; VFP6:
[AppDefaults\\vfp6.exe\\Version]
"Windows" = "nt351"
;; VFP7:
[AppDefaults\\vfp7.exe\\Version]
"Windows" = "nt40"
[AppDefaults\\vfp7.exe\\DllOverrides]
"oleaut32" = "native"
;; VFP8:
[AppDefaults\\vfp8.exe\\Version]
"Windows" = "win2k"
[AppDefaults\\vfp8.exe\\DllOverrides]
"oleaut32" = "native"
If you have your own VFP-built app that you want to run, you'll need to add the appropriate entry similar to the preceding VFP entries. For example, say you have a vfp7-based app called dmp32.exe. You'd need to add the following entry:
;; DMP32:
[AppDefaults\\dmp32.exe\\Version]
"Windows" = "nt40"
No DLLs need to be overridden in the runtime, just in the VFP IDE.
Run Visual FoxPro on Linux
You should now be all set to run VFP. In your normal-user Linux terminal, type the following:
cd ~/c/Program\ Files/vfp7
wine vfp7
The VFP IDE will display, along with the command window. Before you do anything, press Alt+Tab to switch to a different app, and then press Alt+Tab again to switch back to VFP. You'll now notice that the command window is alive with a blinking cursor. Now, place VFP on an empty desktop. Click in the control box in the upper-left of the window, choose To Desktop..., and choose desktop 4. The VFP window will disappear from your active desktop (presumably desktop 1) and appear on desktop 4. In your taskbar, choose desktop 4. VFP needs to run on its own desktop to avoid weird window switching issues when the IntelliSense subwindows appear.
Now, play around with VFP on Linux. Try creating and compiling a test executable. Try running your existing applications. Next month I'll go into more detail about running VFP on Linux, and talk about some caveats and workarounds to the issues you'll certainly discover, and talk more about running your compiled VFP runtime applications on Linux. As you can see, VFP loads and runs, but there are things that don't work correctly. WAIT WINDOW, for example, doesn't show any text. There are plenty of minor issues, but for the most part the VFP core works just fine.
This is the beginning of a new adventure, and the future is unwritten. Perhaps Microsoft will eventually see the light and provide a Linux port of VFP. Or maybe not. Thanks to the Wine project, it won't really matter in the end.
Sidebar: Important Differences
There are some significant differences between Windows and Linux that might cause you problems even if you think you're following the instructions exactly.
1. First, Linux commands and filenames are case-sensitive, so be careful about typing. "Wine-2002.tar" is not the same as "wine-2002.TAR".
2. All the work in this article is done in your home directory, namely, /home/pmcnett. Instead of typing "/home/pmcnett" all the time, you can use the tilde symbol. Thus "~/xxx" means directory xxx relative to your home, so ~/xxx for me means /home/pmcnett/xxx.
3. The . symbol before a directory indicates the current directory, so that you're certain that you're at the right place.
By Paul McNett (FoxTalk, March 2003)
While Microsoft publicly refuses to release Visual FoxPro for alternate platforms, there's still hope for a multi-platform VFP. Using an open-source product called Wine, Paul McNett shows how we can take matters into our own hands and put the fox on Linux ourselves.
Remember last century, when one of FoxPro's greatest selling points was its ability to run and deploy to not one, not two, not three, but four separate platforms? This was a powerful selling point for me when I was choosing my development environment: Even though I only ever deployed to Windows, it was reassuring to know I wouldn't be painted into a corner should a client ask about a Mac, Unix, or DOS version of my software. Contrast that to today: As new versions of Visual FoxPro emerge with their great features and fixes, I keep finding myself thinking that our situation as VFP developers is pretty dire, being limited to developing and deploying on just one platform.
Have you seen a Mac OSX or a Linux desktop lately? Your clients are going to want to use these other advanced operating systems, and if you're like me, you'll want to be able to deliver. Unfortunately, if you want to deploy to multiple platforms this likely means picking a different development kit: Delphi/Kylix, Java, or maybe C++. You'll have to learn how to work in these other environments, and put up with the lack of Visual FoxPro's native cursor engine. I don't know about you, but I'm not ready to give up the power of Visual FoxPro just because Microsoft refuses to provide ports to other platforms. In this article, I'll show you how to get your Visual FoxPro IDE and runtime applications working on Linux. My hope is that by making VFP available on Linux, the fox may once again breathe with new life, and Visual FoxPro developers may once again be in high demand.
There are three pieces to the puzzle of getting VFP working on your Linux desktop. For starters, you need a Linux workstation installation, with all the developer tools installed (gcc, make, and so on). Second, you need a Windows install of VFP—from which you'll copy over the VFP program folder and subfolders into your Linux filesystem (avoid licensing issues—make sure you aren't running your Windows and Linux installations of VFP simultaneously). Third, you need to install a recent version of the free, open-source product called Wine. Think of Wine as a Windows compatibility layer. As your VFP app makes its standard Windows API calls, Wine intercepts those calls with its own code and effectively mimics the Windows API: Your FoxPro app has no idea it isn't actually running on Windows! To date, quite a few Windows applications are being successfully run on Linux using Wine. This article will concentrate on the installation and configuration of Wine, as it's the most important piece of the puzzle. Future articles will discuss what to do next.
Reality (a disclaimer)
Wine is alpha software. As such, not everything works correctly. Under Linux/Wine, Visual FoxPro will behave differently than you're used to, in mostly minor (but sometimes major) ways. Please don't follow the steps in this article thinking that everything is going to work perfectly right out of the box. You'll need to engage in your own testing, and make your own assessment as to the viability of deploying your specific VFP app to Linux. You should think of this as experimental, and if you end up using it for production work, it's even more important to maintain adequate backups of your source code. Eventually, as the Wine product matures, there will be no perceivable difference between running VFP on Windows vs. Linux. Until that time, though, it's up to us to find the various problems and document them, so that fixes can be found and integrated into the Wine project.
I plan on using Visual FoxPro on Linux as my primary development environment, because based on my testing so far I believe it is stable enough and functional enough for my purposes. However, I've made it a point over the years to keep things pretty simple—limited dependencies on external DLLs and OCXs, for example. If you depend on ActiveX controls (even the ones that ship with VFP), plan on having extra configuration problems and possibly even having to abandon the use of those controls. And this article was written while VFP 8 was in beta; it's difficult to say whether problems I've run into are because of issues to be resolved with VFP or with Wine.
Okay, now that you've read this disclaimer, it's time to begin the process of getting Visual FoxPro running on your Linux installation.
Choose a flavor of Linux and install it
If you're just getting started with Linux, the number of choices you have in every aspect of the installation and configuration process can be pretty daunting. You don't know whether you want RedHat or SuSE, Gnome or KDE, vi or emacs, how to allocate your swap partition, and so on and so forth. Don't worry so much about it. Just pick a distribution (hint—pick RedHat8, as that's what I'm using here), choose to do a workstation install, making sure to install the developer tools (you'll need them later to compile Wine from the sources), and you'll be ready to go in no time. Don't confuse the works: Install Linux to a secondary computer that has a hard drive you don't care about erasing. There are many ways to acquire RedHat8: Buy it off the shelf, purchase a book that has the install CDs included, download it from www.redhat.com, or borrow it from a friend. Installing Linux is beyond the scope of this article, but assuming you have a reasonably new computer with a free hard drive and bootable CD-ROM drive, you'll likely find the process surprisingly painless, even fun.
Download and install Wine
RedHat and other distributions come with Wine installations, but with a fast-moving project like Wine they quickly become outdated. Get used to checking frequently at www.winehq.com for the latest release. There are three different download options:
1. Binary Packages for specific Linux distributions (rpm, dpk)
2. Source tarballs (tar.gz)
3. CVS tree
Binary packages are usually the easy, safe way to go, especially if you're new to Linux. Think of them as equivalent to the Windows Installer. Everything necessary to run the program is put into the package, and when installed, an entry for that application will appear in the central package management database. The package manager knows where to put all the files, what links to add, everything. Depending on what you're installing, you may even need to explicitly accept a license agreement or make some simple configuration decisions.
Source tarballs are zipped archives of all the source code for a project. You download and unzip the tarball, and you're left with a directory structure that represents the source code and accompanying files for the project. You can optionally modify the source code, and then compile and install the software. Don't worry, this isn't as difficult as it may seem; compiling your first open-source project may very well give you that little spark of freedom and excitement that comes from the feeling that you're in control of your machine again.
The CVS (Concurrent Versioning System) tree has all the source code in up-to-the-minute fashion. As soon as Alexandre Julliard, the maintainer of the Wine project, accepts a patch submitted from one of hundreds of developers worldwide, he'll apply that patch against the current version of the code and then commit that change to the CVS tree. People who get their Wine from the CVS tree are on the bleeding edge, and risk running into trouble if a recent change has screwed something up. Wine developers rely on access to the live CVS tree; users should instead go the binary or tarball route.
I'll be using the option 2, source tarballs, for the examples in this article. [Editor's note: Don't let your newness to Linux nudge you into trying option 1—compiling from your own source tarballs really is very simple! Give it a shot!] Here's how to download and install Wine on your system:
1. Fire up Linux and XWindows, log in as a normal user (please don't log in as root), get an Internet connection, navigate your browser to www.winehq.com/download, and scroll down to the section "Wine Source from Tarball." You want the file named Wine-20021219.tar.gz. Choose to download this to a location under your home directory. I suggest ~/wine. The file is approximately 7.7MB in size—you can proceed to step 2 while waiting for the download to complete. My examples here are based on Wine-20021219.tar.gz, which was the latest release while writing this article. Note that by the time this article hits the street, later releases will be listed on the site as well—however, older releases are still available. Even if a later release is available, I'd suggest downloading this version at least at first, to ensure my examples work as expected. Note that the filename yields the release date of the version. For now, because it's still in the alpha stage, Wine releases don't have version numbers, but instead use the release date for version tracking. It's standard for open-source downloads to show the product version as part of the filename, which is rather convenient because frequent releases are the norm.
2. Open up a shell window. Almost everything I do to configure Wine and Linux is done using a shell window rather than graphical tools. You'll leave this shell window open and add others along the way, switching among them as you work on this example. Make yourself the superuser (root) for this command window (you'll need to know the root password):
su -
3. Now, it's important to make sure that any previous installation of Wine is removed from your system. On a system that uses RPMs (RedHat), first check with the package database to make sure there are no previous RPM installs of Wine. The following command will do this for you:
rpm -q --all | grep -i "wine"
If no output was returned, then RPM has no knowledge of Wine ever having been installed. Otherwise, you'll need to uninstall Wine for each entry returned in the preceding query, by using the following command:
rpm -e --allmatches --nodeps
where
cd /
find -name wine
This may take a minute or two. If any installations are found, manually delete them. For example, you might find files such as /usr/local/bin/wine and /usr/local/bin/winedbg. Remove these by typing something like:
rm /usr/local/bin/wine*
Also remove any library files such as libwine.* and the wine directory under /usr/local/lib. You can remove this directory, if found, by typing:
rm -r --force /usr/local/lib/wine
4. Now that you've downloaded the Wine sources (I'll assume you've downloaded them to ~/wine/Wine-20021219.tar.gz), it's time to unzip them and expand them. Your current command shell is logged in as root, but you must not install Wine as root. You could just type exit in the command shell to log out of superuser mode, but instead, why don't you just start another command shell? Now you have one shell that's ready and waiting to do superuser stuff, and one to use for normal, user-level tasks. Note that the command prompt gives you a visual clue as to who you're logged in as, and if you're ever confused about that issue you can type whoami at the prompt. Anyway, go to your new command shell (the normal-user shell) and enter the following commands:
cd ~/wine ;change directory
ls -al ;list directory
tar -xzvf Wine-20021219.tar.gz ;after W press TAB
ls -al
Now you should see, alongside the original compressed archive, a directory called ./wine-20021219. This directory structure contains lots of files, some tools, and the source code and makefiles for Wine. Have a look around at the structure of this directory if you wish. In particular, you may want to peruse the README file:
cd wine-20021219 ;after w press TAB
vi README
Use the pageup/pagedown and arrow keys to navigate the README file, and when you're done press
5. Now that you have the source code expanded, it's almost time to build and install Wine. However, there's an important patch that we need to apply to the Wine source first that will allow Visual FoxPro to work. Download this patch file from http://cvs.winehq.com/patch.py?id=7029 (save target as ~/wine/vfpwinepatch7029). Apply the patch by executing these commands from your normal-user console window (by the way, that's "pee-one," not "pee-el," in the last argument):
cd ~/wine/wine-20021219
cat ../vfpwinepatch7029 | patch -p1
Basically, you're piping the output of the patch file into the patch command, which parses the patch file and applies the patch to the required source file, in this case ./windows/queue.c.
6. After applying the patch, the source code is ready to compile and install. Wine comes with a tool to help you with this, making it even easier. From your normal-user console window (not the root console), type the following:
cd ~/wine/wine-20021219
./tools/wineinstall
The wineinstall script starts by configuring your build. Lots of text will fly by without giving you a chance to read it—don't worry, the verbose output is normal. After about a minute of this you'll see the following message:
We need to install wine as root user, do you want
us to build wine, 'su root' and install Wine?
Enter 'no' to continue without installing
(yes/no)
This is an example of how un-user friendly Linux applications can be. Remember, it's still in the alpha stage. Basically, if you answer no, Wine will still be built but not installed—not very useful in our case. Type yes
After the build is complete, you'll be prompted for your root password. Enter it to continue, making especially sure you enter it correctly because if you fail, the script exits and you'll have to start this step all over again. Answer yes to create the local config file (~/.wine/config). Note that the install script has created a new directory, ~/.wine/, for you. This is where various files are stored that will affect the runtime behavior of Wine. I should backtrack for a moment and talk a little bit about the next message you'll see:
Searching for an existing Windows installation...
not found. (no matching /etc/fstab mount entry
found)
Windows was not found on your system, so I
assume you want a Wine-only installation.
Am I correct? (yes/no)
Wine can be set up to utilize an existing installation of Windows. Say you have a dual-boot system where you can boot into Linux or boot into Windows—a common practice. If you correctly set up your Linux installation to mount your Windows drive(s), then you can run your Windows software (the ones that work in Wine) without having to copy and/or reinstall them in Wine. There are lots of things that can go wrong with this method (not the least of which being that Linux doesn't officially support writing to NTFS volumes) so for simplicity please answer "yes" for a Wine-only installation. Accept the default on the next dialog by pressing
Some fake Windows directories must be created,
to hold any .ini files, DLLs, start menu
entries, and other things your applications
may need to install. Where would you like your
fake C drive to be placed?
(default is /home/pmcnett/c)
You can actually choose whatever directory you like, but make sure to keep it under your own home directory or you won't have the proper access permissions.
Test your Wine installation
Now that you've installed Wine on your system, it's time to make sure it's working. Wine should have installed a few familiar utility programs in your ~/c/windows/ directory. Type the following in your normal-user console window:
cd ~/c/windows
ls -al
See the entry called notepad.exe? As you can see, it's actually a link to a library file called /usr/local/lib/wine/notepad.exe.so. This is Wine's implementation of Notepad, the familiar Windows text editing application—try running this to verify that your Wine installation is working fine:
wine notepad.exe
Since this is the first time you're running Wine, you'll see lots of text whiz by as the font metrics are set up. In a minute or so, you should see the Notepad program window, and if you interact with it you'll see that it behaves very much like its Windows counterpart. Choose File | Exit, and then rerun wine notepad.exe (hint—press the up arrow followed by the enter key) and notice that it starts up right away. No big deal yet: You've basically proven that you can load Wine's version of notepad.exe into Linux, but you haven't yet run any native Windows applications on Linux.
The next test is to grab a few native Windows executables from your c:\windows directory on your Windows system. I'd suggest trying out the following native Windows programs on Linux: sol.exe (Solitaire), calc.exe (Calculator), and regedit.exe (Registry Editor). Regedit.exe can be used to edit Wine's Registry, which mimics the Registry on Windows. If you try regedit.exe, rename it to winregedit.exe (there's a Wine text-only implementation of regedit and the name will conflict otherwise), and run it by typing wine winregedit.exe. Try out these native Windows programs by copying them to your ~/wine/c/windows/ directory, and then erase them immediately to avoid possible licensing issues.
This is more exciting than the Notepad example because you're actually running Windows executables (binaries) on Linux, albeit simple standalone ones. More complex applications have more dependencies than these smaller utility applications do, so they'll require more configurations. Microsoft Office, Internet Explorer, and Visual FoxPro can all run on Linux/Wine, but you won't be able to "install" them in the traditional Windows sense. You'll need to copy all of the necessary files and directories over and make the correct configuration changes in Wine to make them work. The steps that follow will show you how to configure Wine to run Visual FoxPro.
Copy VFP files and configure Wine for VFP
You're almost ready to load up the Visual FoxPro IDE on Linux. You'll need to copy the VFP files over to your Linux directory structure, and make a few configuration changes to your Wine installation:
1. Make the appropriate directories in your Wine directory structure. I tested VFP versions 5 through 8 for this article. From your normal-user command window, type the following (try pressing
mkdir ~/c/Program\ Files/vfp5
mkdir ~/c/Program\ Files/vfp6
mkdir ~/c/Program\ Files/vfp7
mkdir ~/c/Program\ Files/vfp8
Did you get confused about the backslash between "Program" and "Files"? Don't be. The simple answer is that spaces in filenames and directories aren't standard in Linux, and the backslash escapes it for the command interpreter. This makes it possible for Wine to mimic the silly Windows convention of the c:\Program Files directory.
2. Copy your VFP program files from your Windows installation. The method you'll use to do this will vary depending on how accessible your Windows volumes are from within your Linux installation. My Windows NT workstation is a different computer on the network, so I can, for example, copy my VFP7 install by executing the following:
cd ~/c/Program\ Files/vfp7
smbclient //nt_workstation/e$ -U Administrator
cd /prg/vfp7
recurse
prompt
mget *
This example uses smbclient to connect to a Windows system called //nt_workstation on the network to a share called e$, and log in as Administrator. It then changes to the directory where VFP7 is installed. Recurse is toggled On so that when we copy we get all subdirectories also. Prompt is toggled to Off so we don't have to confirm every copy. The mget * is what tells smbclient to get all the files. The point is that you need to copy your entire installed VFP installation over to your Wine fake C-drive. If you're at a loss, another way to do this would be to burn the VFP directory structure to a CD, and then mount that CD on Linux (mount /mnt/cdrom), and copy the files and subdirectories from there.
3. Copy a couple of files from your Windows System32 directory. Use the same method of copying as you did in step 2, but make the target directory ~/c/windows/system. The files you need are msvcr70.dll and oleaut32.dll. Also, get all the vfp runtimes (vfp*), which may be in your Windows\System32 directory or Program Files\Common Files\Microsoft Shared\VFP, depending on VFP version—but still make the target on Wine the ~/c/windows/system directory. Since these files are all installed or updated when you install VFP, you shouldn't run into license issues by copying them over to Linux now. Do remember to get a separate VFP license if you'll be running your Windows version alongside your Linux version.
4. You now need to edit your Wine config file (~/.wine/config) with at least one change. The first change has to do with how Wine acts from an operating system point of view. Wine can impersonate all the variants of Windows, the default being win98, but VFP won't load under Wine when impersonating win98—we need to change it to a NT-variant (nt351, nt40, win2k, or winxp). Do this by adding the following lines to the end of your ~/.wine/config file, above the closing line of # :
;; Visual FoxPro Entries:
;; VFP5:
[AppDefaults\\vfp5.exe\\Version]
"Windows" = "nt351"
;; VFP6:
[AppDefaults\\vfp6.exe\\Version]
"Windows" = "nt351"
;; VFP7:
[AppDefaults\\vfp7.exe\\Version]
"Windows" = "nt40"
[AppDefaults\\vfp7.exe\\DllOverrides]
"oleaut32" = "native"
;; VFP8:
[AppDefaults\\vfp8.exe\\Version]
"Windows" = "win2k"
[AppDefaults\\vfp8.exe\\DllOverrides]
"oleaut32" = "native"
If you have your own VFP-built app that you want to run, you'll need to add the appropriate entry similar to the preceding VFP entries. For example, say you have a vfp7-based app called dmp32.exe. You'd need to add the following entry:
;; DMP32:
[AppDefaults\\dmp32.exe\\Version]
"Windows" = "nt40"
No DLLs need to be overridden in the runtime, just in the VFP IDE.
Run Visual FoxPro on Linux
You should now be all set to run VFP. In your normal-user Linux terminal, type the following:
cd ~/c/Program\ Files/vfp7
wine vfp7
The VFP IDE will display, along with the command window. Before you do anything, press Alt+Tab to switch to a different app, and then press Alt+Tab again to switch back to VFP. You'll now notice that the command window is alive with a blinking cursor. Now, place VFP on an empty desktop. Click in the control box in the upper-left of the window, choose To Desktop..., and choose desktop 4. The VFP window will disappear from your active desktop (presumably desktop 1) and appear on desktop 4. In your taskbar, choose desktop 4. VFP needs to run on its own desktop to avoid weird window switching issues when the IntelliSense subwindows appear.
Now, play around with VFP on Linux. Try creating and compiling a test executable. Try running your existing applications. Next month I'll go into more detail about running VFP on Linux, and talk about some caveats and workarounds to the issues you'll certainly discover, and talk more about running your compiled VFP runtime applications on Linux. As you can see, VFP loads and runs, but there are things that don't work correctly. WAIT WINDOW, for example, doesn't show any text. There are plenty of minor issues, but for the most part the VFP core works just fine.
This is the beginning of a new adventure, and the future is unwritten. Perhaps Microsoft will eventually see the light and provide a Linux port of VFP. Or maybe not. Thanks to the Wine project, it won't really matter in the end.
Sidebar: Important Differences
There are some significant differences between Windows and Linux that might cause you problems even if you think you're following the instructions exactly.
1. First, Linux commands and filenames are case-sensitive, so be careful about typing. "Wine-2002.tar" is not the same as "wine-2002.TAR".
2. All the work in this article is done in your home directory, namely, /home/pmcnett. Instead of typing "/home/pmcnett" all the time, you can use the tilde symbol. Thus "~/xxx" means directory xxx relative to your home, so ~/xxx for me means /home/pmcnett/xxx.
3. The . symbol before a directory indicates the current directory, so that you're certain that you're at the right place.
Comments