Ubuntu Linux, VMware, 64-bit WinXP Guest: Getting Online

I was using Ubuntu 9.04 (Jaunty Jackalope). On Ubuntu, I was running VMware Workstation 6.5.2. In VMware, I had just installed 64-bit Windows XP. I was now trying to get online.

At first, I thought the problem was with my Linksys WRT54GL Wireless-G 2.4GHz 54Mbps broadband router. I inserted the Linksys setup CD and ran through its setup steps. It said, "Checking your computer settings, Please wait." After a minute or so, it gave me an error message: "Setup Wizard MFC Application has encountered a problem and needs to close." It did this repeatedly. But when I connected the computer directly to my DSL modem, bypassing the router, I still couldn't go online. Anyway, a post I saw somewhere said that the Linksys setup CD was to set up the router, not the computer. The router had already been set up from a previous installation, so that didn't seem to be the issue. I was able to access the Internet in Firefox in the underlying Ubuntu layer, so the problem was just with getting Windows connected from within the virtual machine (VM).

In VMware, I went to VM > Settings > Network. I saw that it was set to Bridged. I believed it was supposed to be NAT, not Bridged, so I changed it. I did the same thing with Network Adapter 2. I saved that and tried again to go to a webpage in Internet Explorer, but once again got "The page cannot be displayed." I connected the computer directly to the DSL modem again. This didn't seem to make any difference, but I left it that way for the moment, just in case I had more than one problem.

It occurred to me that maybe I was supposed to restart VMware in order for the changes to take effect, so I suspended the WinXP VM, closed VMware, and restarted it. Just to test it, I started a different VM and tried to go online. Internet Explorer worked with no problems in that machine, but still wouldn't work in the new 64-bit WinXP VM. I dug out my AT&T Yahoo SBC installation CD -- I had forgotten that I had such a thing, but I got reminded of it when I ran Start > Settings > Network Connections > New Connection Wizard > Next > Connect to the Internet. All the hardware was already plugged in, so I moved pretty quickly to AT&T's Software Installation dialog. When I clicked there, I got a message, "You need to install an Ethernet adapter in your computer." So the problem seemed to be that Windows was not recognizing the VMware virtual network connector.

Looking again at the VM settings, I noticed that the working VM only had one Network Adapter. There was no Network Adapter 2 there. The VMware FAQs said there could be problems if you had two network interface cards (NICs), so I deleted Network Adapter 2. This didn't help with the AT&T installation; I was still getting the message that I needed to install an Ethernet adapter. A Google search for that message didn't turn up anything.

I went to Start > Settings > Control Panel > System > Hardware > Device Manager, as I should have done at the beginning. There, I saw a yellow question mark and a yellow circle with a black exclamation mark next to "Ethernet Controller." I right-clicked on it and said, Update driver. The Hardware Update Wizard couldn't find a driver. Someone said they had resolved this problem by installing a new WinXP x64 VM using the 64-bit rather than the default 32-bit WinXP setup. I powered down the VM and checked in VMware's "Edit virtual machine settings" option for that VM. It showed that, under Options > Guest Operating System, I had already indicated that the guest was Microsoft Windows, Windows XP Professional x64 Edition. This didn't seem like it was the problem in my case, so I posted a question on it.

Another Try with VMware Workstation and Player

In a previous post, I described how I was sometimes getting no audio from my VMware virtual machines (VMs), at times when my 64-bit Ubuntu 9.04 (Jaunty Jackalope) installation on that same computer was able to play the same files without a problem. I experimented with VirtualBox as an alternative, but that was coming along slowly at this point, so I decided to give VMware another try. I had been using 64-bit VMware Workstation 6.5.2 to run 32-bit Windows XP VMs on this computer. I now recalled that, lately, I had begun to use VMware Player instead of Workstation to run some of my VMs. I wondered whether Player was somehow messing up my audio settings or my VMs, such that only a reboot or restart of the VM, of VMware, or of the whole computer would fix it (and sometimes that didn't even do the trick). I think what got me wondering about this was one occasion when I was not able to play an audio file in a VM in Player; but then, without rebooting or restarting anything, I opened another VM in Workstation and was able to play audio just fine - and then the audio in Player was OK too. I hadn't really been paying attention, and therefore wasn't sure that this was exactly how the sequence had unfolded; but I thought it was worth a second look. About a day later, I got my first renewal of flakiness from VMware. I was running a VM in Player. I minimized it and went to work on a different VM in Player. When I went back to the first one, I couldn't find it. That is, there was no entry for it in the taskbar at the bottom of the screen. I had learned, by now, that this didn't mean it had closed down; it just meant it was hiding. On Ubuntu's top panel (i.e., the taskbar running across the top of the screen, which in my case I had moved to the left side of the screen because left-right real estate was less crucial than top-bottom real estate, on my widescreen monitor) I saw the icon showing that VMware was up and running. I clicked on that and, sure enough, there was the name of that hidden VM. I clicked on it. It opened up - but not in Player. It opened up in VMware Workstation. This had happened several times previously, but this was the first time when I was absolutely sure, when I was watching for it. I made it full-screen and resized a few windows in Workstation - it had resumed in less than full-screen mode, which meant (in VMware's way of doing things) that all of the windows I had running in that VMware session were automatically resized - and then I clicked on the top panel. Workstation vanished. I went back to that icon in the left-side panel and brought that VM back onscreen yet again. Fortunately, the audio was still working, so this was as far as my bug-hunt was able to progress at this point. But it did make me wonder, again, whether VMware Player was part of the problem. At present, my sense was that running each VM in its own session of VMware Workstation was the most stable way to go. Postscript: two weeks later, running only Workstation since writing this note, I conclude that Player was indeed the problem. This problem has not recurred for me in Workstation.

VirtualBox 3.0 Instead of VMware Workstation 6.5?

As described in other posts in this blog, I was using VMware Workstation 3.5 and VMware Player to run Windows XP in virtual machines (VMs) on a 64-bit Ubuntu Linux 9.04 (also known as "Jaunty Jackalope") host system. I had run into intractable audio problems and decided to try other approaches. It appeared that VirtualBox, in particular, had come a long way since my previous look at it, in summer 2008. A survey in 2007 had found that it was gaining ground on VMware. More recently, 1 2 3 4 brief reviews posted in the first half of 2009 suggested that VirtualBox 2 was maturing and that VirtualBox 3 promised significant improvements over what I had encountered. VirtualBox 3.0.4 was now available as freeware, so I downloaded the appropriate version for my Ubuntu operating system. (Synaptic did not yet have version 3.0.) Since Ubuntu is Debian-based, I typed the following into Ubuntu's Applications > Accessories > Terminal, as suggested in the instructions on the download page cited above: sudo gedit /etc/apt/sources.list At the end of that file, I saw a bunch of commands that began with "deb http" and so forth. So, following the instructions, I added the appropriate line to the end of the file. In my case, that line was: deb http://download.virtualbox.org/virtualbox/debian jaunty non-free And then I continued with the instructions. Specifically, I went to the page where I could get the Sun public key for apt-secure. When that webpage opened up, I saved it with its default name (sun_vbox.asc). Then, back at the instructions page, I copied and pasted one long line into Terminal. That line was: wget -q http://download.virtualbox.org/virtualbox/debian/sun_vbox.asc -O- | sudo apt-key add - Terminal was not too talkative at this point; it just said OK. The next step was to enter the command to install VirtualBox: sudo apt-get install virtualbox-3.0 This didn't work; I got "Couldn't find package virtualbox-3.0." That was because my default download location was not where the installer expected it. Departing from the instructions, I used Ubuntu's File Browser (Nautilus) to navigate to my download folder. There, I double-clicked on the downloaded virtualbox*.deb file. This opened Debian's Package Installer. I told it to install the package, and I went with the default options. I did not need to do the instruction that called for the installation of the dkms package, because I checked in Synaptic and found that dkms was already installed on my system. I also didn't check the checksum on the download. After the Debian installer was done, I looked for the icon that I could click on to start VirtualBox. There didn't seem to be one. I went to the command line in Terminal and typed "virtualbox." This gave me the message, "The program 'virtualbox' is currently not installed. You can install it by typing: sudo apt-get install virtualbox-ose." My understanding, from the VirtualBox Editions webpage, was that, among other things, the "ose" (Open Source) version did not have USB support. This would be problematic at best. So if I typed the command just quoted, it seemed I would be installing the Open Source edition and would not get USB support. The full package, with USB support, was free too, so I felt I should continue on the present path and try to get the full package to run. I went back to the instructions webpage and saw that I had skipped the instruction about the "key fingerprint." I had not known what that was and, following the standard protocol for Interpreting Signs in Foreign Countries, I had therefore assumed that if I didn't understand it, it must not apply to me. So now I found another set of instructions, and started from the beginning with those. They were as follows: sudo sh -c "echo 'deb http://download.virtualbox.org/virtualbox/debian jaunty non-free' >> /etc/apt/sources.list" (which was easier than the approach recommended above) and then wget -q http://download.virtualbox.org/virtualbox/debian/sun_vbox.asc -O- | sudo apt-key add - which gave me that OK again, and then the instructions said, "The key fingerprint should be the following," which once again left me clueless. I searched for, but did not find, an explanation of this. The best I could find was that this appeared to be an optional way of verifying that I had the genuine article. I punted and, once again, moved on to the next step. According to this second set of instructions, the next step was to type this: sudo apt-get update That did a bunch of things, ending with the message, "You may want to run apt-get update to correct these problems." This was baffling; I had just run "apt-get update" as superuser. I tried it just as myself (i.e., without the "sudo" in front), but this gave me a Permission Denied error. In a thread pitting a total newbie against a seasoned veteran, I saw the advice to use "sudo apt-get install -f" to "install any missing packages." When I ran that command, it found some packages that were "no longer required"; it suggested that I run "sudo apt-get autoremove" to remove them. And when I did that, it brought up the Update Manager with lots of updates to install. I don't know why these updates had not appeared under the familiar panel icon that used to tell me I had updates to download and install. Anyway, after the updates were done, I went back and tried "sudo apt-get update" again. This time, no error messages. The next instruction, then, was this: sudo apt-get install virtualbox-3.0 dkms That informed me that I had already done this. So, OK. Next, the instructions told me how to respond to several questions that did not come up in my installation process. One of them involved the "vboxusers group." I didn't know what that was, but it sounded like maybe I could find out by running the next command, which was sudo usermod -G vboxusers ray where "ray" was my username. Terminal swallowed that command without comment. But what came next was most crucial: these alternate instructions gave me the all-important command to reboot the system. Oops. I hadn't thought of that, and the other instructions hadn't said it. So, OK, I rebooted. After restarting the computer, sure enough, Ubuntu's menu gave me Applications > System Tools > Sun VirtualBox. OK, now, how to use it? I started it up and tried to register it, as part of the startup process, but I got "Failed to register the VirtualBox product" followed by a huge list of problems. I had to use xkill to kill it. I tried again. Same thing. Third time around, I clicked "Cancel" instead of registering. And so, there I was, looking at VirtualBox. Based on some instructions, I went into File > Virtual Media Manager > Add. I navigated to the VMware .vmdk file for the VMware VM that I wanted to try opening in VirtualBox. (They advised backing it up first.) Weirdly, when I clicked OK, the dialog vanished. I tried again, and I saw that the thing had indeed been added. So this time, with that .vmdk file highlighted, I clicked New and went into their Create New Virtual Disk Wizard. They didn't warn that a dynamically expanding VM would be slower, so I went with that option. I called this new VM "Test." But when I was done, all I had was a second line, "Test," following the .vmdk file. I killed the Virtual Media Manager and tried the Machine > New menu pick. This gave me the option of choosing to use an existing hard disk. I chose that, and specified its default, which was the .vmdk file I had already added. This gave me a screen that showed my "Test" machine as being powered off. Its size and everything looked right. I clicked Start. This gave me a dialog box whose frame indicated that Test was running. But the box itself was black. I chose its Reset option and saw that it must have been running Windows XP, or trying to, because now I got that option that Windows gives you when you crash your system: did I want to reboot normally, or go into Safe Mode? I chose the latter. This gave me the usual list of drivers, or whatever they are, that WinXP is installing, down to the Mup.sys and agp440.sys items. And there it froze. So my new Test machine was indeed trying to load and run WinXP, when it gave me that black screen; but it just wasn't able to run. I started looking through the menu picks that VirtualBox offered me for that Test machine. There were three main menu options: Machine, Devices, and Help. Under Devices, I saw that there was the option to Install Guest Additions. This, I vaguely recalled, was like VMware Tools. Maybe that was the problem. So while the WinXP startup into Safe Mode was still frozen at the agp440.sys line, I selected that. Instead of getting information about the Guest Additions, I got a screen called VirtualBox - Guru Meditation. It said, "A critical error has occurred while running the virtual machine and the machine execution has been stopped." It went on to suggest that I consult the VirtualBox Community webpage. There, the only meaningful option was the Forums webpage, and there I selected the forum on Windows guests. But searches for posts on "critical error has occurred" or on "safe mode" did not turn up any helpful advice. I tried a Google search for those terms across all forums and got lots of hits. In one post, the solution was to repair the WinXP installation by booting from the WinXP installation CD. I killed the VM, inserted that CD, and clicked on Start again. I had to hit F12 to get the boot menu, when it was first starting up, and then I hit C on the keyboard to choose booting from the CD. But this gave me "FATAL: Could not read from the boot medium! System halted." A Google search for that phrase led to another thread involving a rude reply to a newbie by the same "seasoned veteran" ("Sasquatch") as above. As I went on, I saw more of those, and started to wonder whether VirtualBox was still in the private-club phase of development. Someone's post pointed me toward the VirtualBox FAQs, but those didn't seem to address this issue. After another reset and the same result, I went into VirtualBox's Machine > Show Log option. I noticed that, if there was no VM dialog open, the log ended with "Changing the VM state from 'DESTROYING' to 'TERMINATED,'" but if there was a VM running and hung, the log ended with "Guest Log: BIOS: int13_harddisk: function 02, parameters out of range 0000/0000/0001!" if it hung while attempting a Normal or Safe Mode boot of WinXP; but if the system hung while attempting to boot from CD, the log ended with "Guest Log: Could not read from the boot medium! System halted" and, slightly before that, "CDROM boot failure code : 0004. (I had to Refresh or Close the Log Viewer to get it to show this. The most recent log, in the Log Viewer, was named VBox.log, as distinct from VBox.log.1, VBox.log.2, etc.) Not getting solutions from the VirtualBox forums, I tried a Google search across multiple sources. One of the webpages turned up in that search was my own post from the previous year, where I had been stymied by the same problem. Another post said that you can't leave VM Tools installed in a VM that you're bringing over from VMware. So what I had to do was to fire up VMware, open a VM, remove Tools, save the VM, and then repeat the foregoing steps to make a new version of the Test VM for VirtualBox. Ah, but there's many a slip 'twixt cup and lip. I started VMware Player and tried to start the VM from which I had copied Test. Player said I had "insufficient permissions to access the file." I went into Terminal and typed "sudo nautilus," so as to check the permissions, but for the first time ever, I got "ray is not in the sudoers file. This incident will be reported." I tried using Player to open another VM, but it froze. In Workstation, I tried the same things with those same VMs and got the same results. I found some advice on how to fix the sudoers issue. The advice was basically as follows: (1) Restart the computer and choose the Recovery Mode option from the GRUB menu. (2) Choose the root ("Drop to root shell prompt") option. (3) Type "adduser ray admin" (without the quotation marks), where "ray" was the username I wanted to have working again, and hit Enter. (4) Type "exit" and resume a normal boot. (Those instructions also addressed some other options that didn't apply to me.) When Ubuntu had booted, I opened up a Terminal session and typed "sudo nautilus" and it worked. So now that the sudoers issue was fixed, I cloned a VM that I had just been working with, a few hours earlier, with the idea of opening that in Workstation and removing its VMware Tools. Meanwhile, I had seen a couple of references to the User's Manual, which was available in PDF or online form at the Downloads page. In PDF form it was 261 pages. The online version presumably didn't have any references to the error messages noted above, else it would have come up in the searches cited above; or perhaps it did come up, but was far enough down in the results list that I didn't notice it. Ditto for the How-Tos and tutorials. But now that I had a specific culprit - namely, VMware Tools - I searched the manual for particular references to that. But there weren't any references to it. There also didn't seem to be any solutions for the particular problems I was having in the Troubleshooting section. So it seemed I had saved quite a bit of time by not reading those 261 pages. By this time, the clone was done. I powered it on in Workstation and, when it was fully up and running, went to Control Panel > Add or Remove Programs and removed VMware Tools. I shut down the clone VM and restarted VirtualBox. I went through the steps, above, to open that VM in VirtualBox. Unfortunately, I got the same outcomes as above. So having VMware Tools installed was not the issue, or at least not the only issue. I had come across a post in which someone said they had enabled PAE mode. I wasn't sure what this was all about, so I went through the various possibilities in VirtualBox's Machine > Settings menu pick. Among other things, while I was there I noticed that I could set the boot order here, and that the options (e.g., booting the CD-ROM before the hard drive) were clearer than those provided by using the F12 option at bootup. I found the PAE option pretty quickly: it was under System > Processor in the Settings dialog. The tooltip that came up when I moused over that option said, "When checked, the Physical Address Extension (PAE) feature of the host CPU will be exposed to the virtual machine." I had not a clue as to what that meant. Another poster said they had also enabled Nested Paging, which I found there in the Settings dialog under System > Acceleration. While I was there, I went on through the Settings and changed several other things, notably giving 64MB of RAM to the video. I started the new VM and, when Windows gave me the option, I selected Safe Mode. Unfortunately, it froze once again, so it seemed I hadn't found the solution. That froze again, so - now that I had changed the boot order to prioritize the CD-ROM drive - I restarted the VM. But the bootloader still ignored the CD-ROM, so once again I reset the system and, this time, hit F12 during the splash screen to give me the boot device selection menu. I chose the CD-ROM and, once again, I got the FATAL message quoted above. Well, there was always the option of installing Windows XP from scratch in a new VM. I had a 64-bit WinXP CD, so I went through the setup sequence for a New virtual machine. This time, I told it to create a new 25GB hard disk instead of using an existing one, and call it P4VB. It created the P4VB virtual machine in the /home/ray/.VirtualBox/HardDisks folder. When I looked, that .VirtualBox folder was also the home of a Machines folder. I didn't want these things there; I didn't have enough space on that drive for several VMs. According to one post, this was easy enough to solve: just move the folder and then go into VirtualBox (which apparently some people also call VBox or VB) and select File > Preferences > General. But it looked like people had had some problems with that, so instead of moving I copied (rather than moving) the .VirtualBox folder to the new location. Then I double-clicked on the P4VB VM, there in VB, and changed those folder location settings. I finished that and then double-clicked on P4VB again. Now, to back up for a moment. When I had finished creating the new VB VM, where I was going to install 64-bit Win XP, VB got me started automatically in a wizard that was going to help me set up my hard drive. I wasn't ready for that right then, however - I wanted to finish the move process (above) while it would hopefully still be simple to do so. But now that I had finished the move, I wondered if I could get that wizard restarted. But after double-clicking on P4VB, what I got instead was a dialog box that said this:

VirtualBox - Error VT-x/AMD-V hardware acceleration has been enabled, but is not operational. Your 64-bit guest will fail to detect a 64-bit CPU and will not be able to boot. Please ensure that you have enabled VT-x/AMD-V properly in the BIOS of your host computer.

That didn't seem like something that the wizard would have fixed. I clicked "Continue" to see what would happen next. The answer is: Nothing. I was back at the VB basic screen, but now the note under P4VB said "Aborted" instead of "Powered Off." With P4VB highlighted, I chose Settings. Going down through the various Settings possibilities, I re-enabled PAE/NX and Nested Paging (above). I changed it to have 2 CPUs, since I had a dual-core processor. I gave it 64MB of video RAM and enabled 3D acceleration. I told it to mount the CD/DVD drive and use the VBoxGuestAdditions.iso image file. I tried starting the VM again, but I got this:

VirtualBox - Error VT-x is not available. (VERR_VMX_NO_VMX). Unknown error creating VM (VERR_VMX_NO_VMX).

So this was apparently the time when I needed to change the host BIOS as described in the previous error message (above). I shut down everything and restarted the computer. I didn't see the needed option in the CMOS Setup Utility for my BIOS, but another post suggested that maybe support for VT-x would be available after I updated the BIOS. I checked the manufacturer's webpage for my Gigabyte motherboard. There was indeed a BIOS update. I flashed the BIOS and took another look at it. About this time, I realized that I was looking (as shown above) for AMD-V, not VT-x (the Intel counterpart to AMD-V). So, as the saying goes, I wondered why the Frisbee was getting bigger, and then it hit me. AMD-V was short for AMD Virtualization, and "Virtualization" was the first option in the Advanced BIOS Features page in my BIOS setup. I dunno - I guess it had seemed too obvious. But now I was really ready. All I had to do (maybe) was switch it from Disabled to Enabled - the latter being described, in the sidebar, as "Hardware assisted Virtualization Technology which help improve performance of system running Virtual Machine Softwares." Exactly what I had been looking for all along. Jeez. But, OK, on with the show. I saved the BIOS change and booted the system. Back into VirtualBox > Settings. With everything set as I desired, I saved out and started the P4VB virtual machine again. New error: "FATAL: No bootable medium found! System halted." No surprise there: I hadn't installed WinXP x64 yet. Time to do that. Now, here was where I had made a mistake. I had set the settings to run the VBox Guest Additions ISO file on the CD drive. What I really wanted, first, was to install the WinXP CD in the host CD drive. So I fixed that, inserted the WinXP CD, and tried again. It ran Windows Setup. I installed the Guest Additions. Now the VB Machine > Auto-Resize Guest Display option worked; WinXP filled the whole screen. I was able to activate Windows. I ran Windows Updates. The first update that I needed, it said, was Service Pack 2 for Windows XP Professional, x64 Edition. But it didn't actually do anything. It said it was downloading, but hours passed and nothing happened. I was able to download other files in the meantime, but nothing doing in Windows Update. Trying again, I selected everything else that I could except Service Pack 2. When that was done, I tried again on Service Pack 2. Now it was willing to be friendly, and I was able to continue installing other updates. While that was going on, I was looking into how I could get access to my data partitions in VB3. David Hodgins pointed out that there were sharing and raw mode options. Raw mode seemed to mean having complete and direct access to the hard drive. It was covered in section 9.10 of the help manual included in VB (Help > Contents > Sun VirtualBox > Advanced topics > Using a raw host hard disk from a guest). Sharing was more familiar; it seemed to be what I had been doing in VMware. It was covered in section 4.6 of the manual (Help > Contents > Sun VirtualBox > Guest Additions > Folder sharing). To set up these shares, I proceeded as follows:

1. In Windows XP inside my P4VB virtual machine, I went to Start > Run > compmgmt.msc > Enter. This opened up Computer Management. There, in Storage > Disk Management, I right-clicked on the CD-ROM drive and changed it to drive Z. Since I had installed the VB Guest Additions, and since the Guest Additions pretended to be running from the CD-ROM drive, this changed them to drive Z as well. I closed Computer Management.
2. In the outer frame where VirtualBox was running (i.e., not inside the Windows virtual machine), I selected Devices > Shared Folders > Machine Folders, and then clicked on the +folder icon at the right side. This opened up the Add Share dialog. In the Folder Path box, I navigated to the hard drive partition I wanted to add as drive D inside my WinXP VM. (Drive C, of course, contained the virtual machine's Windows program files.) I clicked on "Make permanent" and then OK.
3. I closed the Shared Folders dialog and opened Windows Explorer and went to My Network Places > Entire Network > VirtualBox Shared Folders. I saw that the partition I had just selected as a share was now listed there. (If it's not listed, hit F5 to refresh the view.)
4. I wanted that shared partition to appear under My Computer, just like drive C and any other normal drive would be. So I right-clicked on it and chose Map Network Drive. This opened the Map Network Drive dialog. I clicked on the drop-down arrow for the Drive box and selected D (which was free, now that I had reassigned the CD-ROM). Leaving "Reconnect at logon" checked, I clicked Finish. To test it, there in Windows Explorer, I opened up drive D under My Computer and, sure enough, I could create and delete files, just like normal. I hit F2 to rename it as needed.

I repeated steps 2-4 for each hard drive partition I wanted to have visible in this VM. This was much like the procedure I had used to share partitions in VMware. At this point, VB was extremely slow in the process of downloading Windows updates; it was also extremely slow when I tried to move files. I rebooted the virtual machine, thinking that maybe it needed to clear its head after that drive-mapping exercise. It did help, but it was still very slow. It seemed that this problem had been around for a long time and was not going away soon. So it looked like I had better investigate the alternatives. Samba sharing seemed to be a faster way of sharing network drives (i.e., these other partitions on my computer). I figured I had better undo my present sharing before proceeding with the Samba approach. I wasn't sure how to do that, so I just did it in reverse order from what I described above: first, right-click on the partition shown under My Computer in Windows Explorer and choose Disconnect for each partition, and then go into VB's Devices > Shared Folders and click on the -folder option for each shared folder. Then, in Nautilus (with the left panel set to Tree view), I went to File System > media. In the right panel, I right-clicked on the first partition I wanted to share and chose Sharing Options. I clicked on "Share this folder" and then on the "Install service" button. I got a dialog saying something about restarting my session, but when I clicked to go ahead with that, instead I found myself back at the Folder Sharing dialog. There, I clicked on Create Share. It said it was going to set up sharing automatically, but then I got an error telling me, "You do not have permission to create a usershare." I fiddled around with this for a while and then tried a very clear tutorial on setting up Samba shares on Ubuntu. Like so many things in life, it went smoothly but did not seem to accomplish anything. While I was waiting for the last of the Windows updates to be downloaded and installed, I fired up VMware Player again. Alas, its audio was still not functioning properly. So when the Windows updates were all installed in VirtualBox, I decided to try again on the sharing approach that used VB's Shared Folders dialog (steps 2-4, above). I thought maybe that would be faster now; maybe I had inadvertently slowed things down by attempting to set up shares while Internet Explorer was downloading (it hadn't even gotten to the point of installing) various Windows updates. I had been moving some files around in Windows Explorer, so I went back to that task. I found it was a little faster now. There was a problem where I could not select multiple files in Windows Explorer using Ctrl-click; it didn't work normally. Then I realized that the right Ctrl key was the default key for moving the cursor outside the Windows VM, so that it could be used in the VB frame. I went into File > Preferences and changed it so that the right Winkey would do that job instead. But VB with sharing remained so horribly slow that I just could not imagine using it. Actually, it was not just a sharing thing: the process of using Windows Update via Windows Explorer was also extremely slow and seemed to freeze several times, whereas I hadn't been having that problem in VMware on the same computer. I posted a question on using Samba shares. I got a response, but by that point I had gone back to using VMware instead of VirtualBox, at least for the time being.

Ubuntu 9.04, VMware Workstation 6.5.2: Failed to Open Sound Device (continued)

In a previous post, I described my efforts to get the sound working in a Windows XP virtual machine (VM) running in VMware Workstation 6.5.2 on Ubuntu 9.04. (Note that there are ways to use VMware virtualization for free.) I did not seem to have solved the problem, though it did appear that restarting the system (or perhaps shutting it down for a while and then restarting) would clear up the problem. In normal usage, for some months now, I had been able to play audio in more than one VM with little difficulty. It seemed that an update of VMware Tools may have screwed things up for me.

Hoping to reach a more efficient solution, I went to a discussion thread cited in a comment on that previous post. In that thread, someone advised typing "fuser /dev/dsp." Neither that nor "fuser /dev/audio" produced any results for me, however; I just got a blinking cursor in response.

I pursued another possibility mentioned in my previous post. Someone had suggested installing a second sound card in the computer. I had onboard audio on my motherboard, so in my case this would be the only sound card. Since it looked lonely, I decided to install another one as well. So now I had three physical sound output devices - the motherboard's onboard audio plus these two sound cards.

The next question was how to use them. When I went to Devices > Sound Card > Connect in VMware Player, inside my WinXP virtual machine, I just got the same old error message: "Failed to open sound device /dev/audio: Device or resource busy. Failed to connect virtual device sound." According to the post I was following, I should have been seeing separate devices: /dev/dsp and /dev/dsp1 (or something like that), etc. I wasn't sure where I was supposed to be seeing them. I went to Ubuntu's System > Administration > System Administration and skipped through that to the part that said, "Click the Test button to play a sound on the automatically detected playback device .... Do you hear a sound?" I didn't, so I clicked No and then Next. But it just took me on through other questions, so it wasn't actually going to help me solve the problem.

I went to System > Preferences > PulseAudio Preferences. (I had that option, I think, because I had gone through some PulseAudio stuff earlier, as described in my previous post.) But I did not see anything there that provided an obvious solution. I went to System > Preferences > Devices > Sound and experimented with the Sound Events - Sound Playback option. This one gave me an audible test sound only for the Autodetect, ALSA, and PulseAudio options. I left it on Autodetect. Autodetect also worked on the other options, so I left it as it was for them too.

A search for "sound cards listed" led me to a post where they seemed to confirm that System > Preferences > Sound was where I needed to be: clicking on Autodetect, they said, would show my sound cards. So, OK, looking at it that way, the longish list of sound options seemed to boil down to four software solutions (Autodetect, ALSA, OSS, and PulseAudio) and a mix of hardware solutions (HDA NVidia ALC883 digital and analog, ALSA and OSS; and ICEnsemble ICE1724, ALSA and OSS). I couldn't remember which motherboard I had installed in this particular computer, and I didn't know of a system information utility that would tell me that. (Sysinfo wouldn't.) I popped open the case and saw that the motherboard was a Gigabyte GA-M61P-S3. The manual for that motherboard indicated that its audio circuits used a Realtek ALC883 chip. So the ALC883 numbers in the list of sound options evidently referred to the motherboard. Since those weren't working, I tried plugging my headphones into one of the two newly added sound cards instead. I had been using the motherboard's green audio outlet, which in my understanding was the output, so that's the color of the outlet I used on the sound card as well. Back in Ubuntu's Sound Preferences dialog, I found that now I was getting no sound from any option. So apparently Ubuntu was not recognizing that sound card. I tried the green outlet on the second newly installed sound card. This, too, did not work on any option. I also tried the step that the post had advised, of connecting the motherboard's green out to the sound cards' blue in, but this too yielded no sound from the soundcards' green outlets. I looked up the ICEnsemble ICE1724 item mentioned above. This apparently indicated the VIA Envy24 chipset. I seemed to have installed a generic sound card that used that chipset. So that was evidently the one that Ubuntu recognized; but it wasn't helping me.

I started up VMware Workstation as root ("sudo vmware") with the intention of seeing what sound card options I had there. But the sound card settings option was greyed out for all of my VMs. I restored a VM, but its sound options were grayed out too. Same thing if I started up Workstation under my ordinary username. I had forgotten that, while it wasn't necessary to run Workstation as superuser (sudo) in order to adjust sound settings, it was necessary to power the VM down (not merely suspend it) in order to do so. I powered down a VM and, in Workstation, went to VM > Settings > Sound Card. There, I restored the "Use physical sound card" to its "Auto detect" option (since the /dev/audio thing wasn't working - see previous post) and deselected its "Connect at power on" option. I was thinking this would prevent the sound card error message at startup and would also keep VMs from grabbing the sound card if they didn't need it. I saved those settings and powered that VM back up in VMware Player. When it was powered up, I selected VM > Removable Devices > Sound Card > Connect. Now the audio in that VM was working. It wasn't working before, but now it was.

At this point, the solution seemed to be that "Auto detect" was just fine (i.e., I didn't need /dsp/audio or /dsp/dev1), but "Connect at power on" needed to be deselected, and I could only do that if the VM was either powered on or powered off (not suspended).

I tried with another VM whose sound wasn't working in VMware Player. Its settings weren't available in Player. Weird thing: it seemed like I was looking at it in Player one minute, and then - after I minimized it, I think - I was suddenly looking at it in Workstation. What happened to Player? To back up and check that out, I suspended that VM in Workstation, exited Workstation altogether, and opened that VM in Player. Trying again, I observed that its sound card was shown as connected (Devices > Sound Card) but it was not playing any audio. I suspended this VM in Player and, without closing Player, switched to another Ubuntu workspace (or, as they call it in Windows, another desktop). Then I went back to the previous workspace and, what do you know, Player was gone. I started a new session of VMware Player and, without opening any VMs, tried switching desktops again. But no, this time Player was persistent; it was still there when I returned to the original workspace. So I wasn't sure what that seemingly funky Player disappearance was about.

With Player open but with no VMs open, I started Workstation. I resumed the VM that I had just been using in Player, that had had no audio. Workstation said, "Cannot connect virtual device sound. No corresponding device is available on the host. Would you like an attempt to be made to connect this virtual device every time you power on the virtual machine?" I said yes, figuring that this would preserve the "Connect at power on" setting. This machine's sound card settings now said "Auto detect" and "Connect at power on," but not "Connected." I deselected the "Connect at power on" option and saved those settings. Then I suspended the VM in Workstation and resumed it in Player. I had to wait a few minutes for Workstation to finish suspending. When I tried too quickly, I got an error message:

This virtual machine appears to be in use.

If this virtual machine is already in use, press the "Cancel" button to avoid damaging it. If this virtual machine is not in use, press the "Take Ownership" button to obtain ownership of it."

But no, apparently that wasn't the problem, after all. The problem was that Workstation was still open and was showing that VM as suspended. I killed Workstation and tried again, and now Player opened the VM. Now I selected Devices > Sound Card > Connect and tried playing sound. No joy. That is, the sound still wasn't working. Instead of suspending it, this time I powered it down (Windows Start > Turn Off Computer > Turn Off). When the VM was off, Player vanished too. I started Player again, opened the VM again, and chose Devices > Sound Card > Connect, and then double-clicked on an audio (.wav) file. Still no audio. I switched to the Ubuntu desktop and double-clicked on the same audio file. It played in Ubuntu.

I suspended the VM. Player closed itself. In Workstation, I resumed both of these two VMs that I had been experimenting with. Oddly, this second one again said, "Cannot connect virtual device sound." But I had told it not to try at startup. Now I clicked on either Yes or No - I didn't write down which - and, as before, I got the message, "Virtual device sound will start disconnected." Its sound card settings were now set to "Auto detect" and neither "Connected" nor "Connect at power on" were checked. I suspended this VM. With Workstation still on and showing the first (audio working) VM but not this second one, I opened the second one in Player. I went to Devices > Sound Card > Connect. Still no sound.

I suspended the VM in Player and resumed it in Workstation. When I got that "Cannot connect virtual device sound" error message, I chose No. The sound card settings were the way I wanted (Auto detect, nothing selected). This time, instead of suspending, I powered it down in Workstation; and instead of using Player, I powered it up again in Workstation. (Workstation was what I had been using until recently; I wondered if maybe Player was part of the problem.) When it was up and running, it wouldn't play the .wav file. I changed its settings to "Connected." I got "Cannot connect virtual device sound."

The situation at present seemed to be that, unlike before, I would not be able to play sound in two different VMs without manually disconnecting the sound in one and connecting it in another. This was how I had understood it would be all along, but it had not actually been this way until now. To confirm this, I disconnected the sound card in the first VM and connected it in the second one. But no, when I went to save the change in the latter, I still got, "Cannot connect virtual device sound." I noticed that the first one was still set to "/dev/audio" rather than being back at "Auto detect." I powered down the first VM and changed that and then powered it back up. When the first one was completely powered down, by the way, the second one still would not play audio. Finally, with the first VM powered up and its sound card not connected, the second one powered up and connected, and both set to "Auto detect," I got that "Cannot connect virtual device sound" error when I tried to save the settings on the latter. With the first VM suspended, same thing.

I decided to start over. In Workstation, I powered off all VMs. I changed their sound card settings so that they were all the same. All were set to "Auto detect" and their "Connect at power on" option was unchecked. I shut down Workstation. In Player, I then powered on the one that had not been able to play audio. It still could not play audio. I powered on the other one. Now it could not play audio either.

In Workstation, I set the one that had been consistently nonworking back to the previous "/dev/audio" setting. I powered it on, set its sound card to "Connected," and tried to play audio. It worked. While it was still running, I repeated these steps with the VM that had previously been able to play audio. It could play audio too. In fact, they were both able to play the same .wav file at the same time, giving me a kind of funky reverb effect. I tried with a third VM. It went to "Auto detect" without a problem, but when I clicked "Connected" and then "Save," it gave me the "Cannot connect virtual device sound" message. I restarted that Windows VM and tried again. Same outcome. Likewise with a fourth VM. But the audio in the first two was still working. I powered down the third VM, changed it to "Connect at power on," and restarted it. I got the "Cannot connect" error message when it was booting, and again when I tried setting it as "Connected" once it had booted up. The first two VMs were still able to play sound. Movie Player in Ubuntu was also still able to play sound. I went back to the first VM and set it so that it was "Connected" and also was to "Connect at power on." I saved that configuration and rebooted it. It could still play audio after rebooting. I repeated those steps with several other VMs. Now they could all play audio.

I really have no idea what the fix was. It doesn't seem like any one step did the trick, and several steps seemed to work at one time or another. Restarting and/or rebooting was probably as good a fix as any, but it seemed to me that it, too, had failed to work sometimes. So I was back in business, confident that the same damn problem would crop up again in a day or two, just like before. Eventually, it occurred to me that maybe it was not a problem with VMs at all; maybe it was a problem with Workstation and/or Player, and it could only be fixed by restarting them or otherwise changing them on some basic level.  When it went wrong again, I decided it was time to update my previous posts on virtualization alternatives, including particularly the previous summer's look at VirtualBox. I have described the process of trying VirtualBox in another post.  Later, I came across this issue again with a later version of Ubuntu, and there I think I found the problem.

Other Virtualization Solutions to Play Audio in Ubuntu 9.04

I was running 64-bit Ubuntu 9.04 (Jaunty Jackalope). I wanted to use IrfanView to listen to .wav files. I had been using it in a VMware Workstation 6.5.2 virtual machine (VM) running Windows XP, but I had lately been having a problem with stuttering audio playback, and my efforts to fix it had failed so far. It was possible that I had not correctly applied all of the suggestions I had encountered, so one option was to go back and review the recommended steps, perhaps by spending a few weeks working through the Comprehensive Video & Multimedia Howto. Since there seemed to be users whose problems persisted after trying those suggestions, however, I thought perhaps I should try out some alternatives. I posted a question about the VMware problem and left it at that for the time being, reserving the option of trying the supposedly surefire solution of installing a second sound card.

One alternative was to try running IrfanView directly on Ubuntu, with the assistance of Wine. I had made some progress on that, but that, too, was still pending resolution of a posted question. Another possibility I had overlooked was to use VMware Player instead of VMware Workstation. Player (a free download) had been installed when I had installed Workstation, and was now available to me in Ubuntu at System Tools > VMware Player. I opened a VM that I had powered down (i.e., that was not merely suspended) in Workstation. I hadn't really used Player before. I was pleased to see that it seemed to run VMs a little faster and simpler than Workstation.

I tried playing audio in VMware Player. To my surprise, both IrfanView and Windows Media Player played .wav audio files just fine, with no stuttering! I had shut down the machine the previous evening and powered it back up again that morning, so I wondered whether the cold restart had made a difference. I started up Workstation, resumed a previously paused VM, and tried playing .wav files in there. Those, too, played fine. Apparently the restart had indeed temporarily fixed the problem - might, indeed, have been the reason why the other solutions I had tried had seemed to work. I had rebooted the system previously, but it now seemed that I simply hadn't left it turned off long enough.

Since the problem seemed to be fixed, I abandoned (at least for the time being) the other possibilities that I had begun to explore. In case I (or someone else) needed them, however, that list of possibilities included the following:

• Perhaps I could successfully run IrfanView inside a virtual appliance. These would seemingly be subject to the same VMware Workstation problems, but perhaps not, somehow. I searched the VMware Virtual Appliances webpage for IrfanView but, not surprisingly, found nothing. My Google Search for WinXP applications in the VMware catalog didn't seem to turn up anything special, but a search for "Windows 7" indicated that, for $10, I could download something called the Bagvapp RC Windows 7 beta. They said this thing also came with additional software installed. (Microsoft provided additional information on this free (possibly bug-filled) Release Candidate.) For ten bucks, of course, it made huge good sense to just buy the pre-installed VM from Bagvapp; but since I didn't really need it, I contented myself with signing up for Bagvapp's RSS feed. (Most of their stuff was free, but they said they were swamped with orders for the RC and had to pay for a ton of bandwidth.) There also seemed to be other free Windows 7 beta virtual appliances, such as one from Tuxdistro, although not all appeared to be as fully tricked-out as the one from Bagvapp. The Win7 RC, in any case, was said to be valid for another eight months, until March 2010.
• In March 2009, Jonathan DiPrizio discussed four virtualization options in Linux. Those four were Qemu, Parallels, VMware, and VirtualBox. DiPrizio found VMware and VirtualBox to be the clear winners among these four, and actually preferred the latter. So I would have the option of trying to run IrfanView in VirtualBox, if the VMware problems continued.
• I had also located Wikipedia articles on application virtualization and platform virtualization. These led to consideration of other possibilities, such as Microsoft Virtual PC and DosBox.

Paradox for DOS Viewer in Ubuntu 9.04 and VMware Workstation

At the start of this project, I wanted to run Paradox for DOS 4.0 in Windows XP. I had WinXP running in VMware Workstation 6.5. For a while, my old Paradox was running, but then, I don't know, something changed, and it no longer worked. Instead, I got an "Access denied" error inside the WinXP DOS (i.e., CMD, command) window whenever I tried to run Paradox. It was probably something I could have fixed easily in the old days, but I had not devoted much time to Paradox and DOS in recent years, and the solution looked like it would take more re-learning than I cared to do. My reason for wanting to use Paradox was to convert some old files to a current format, so I could view them as needed. Getting them into a current database format (e.g., Microsoft Access) would have been good, but most of them could just be archived as PDF reports, as far as I was concerned.

I couldn't find a freeware Paradox for DOS converter, so I posted a question on the pnews.paradox-dos webpage. Rodney Wise advised me to try DOSemu. The idea here was that, instead of running Paradox in a DOS window in WinXP on Ubuntu, I would drop down to Ubuntu and run Paradox in a DOS emulator there. Before going with DOSemu, I noticed that DOSBox was the SourceForge Project of the Month for May 2009. It appeared, though, that this might mean DOSBox was a work in progress. I followed several links, but didn't get much detail, and finally I got a 404 error. So I decided to stay with Rodney's suggestion of using DOSemu. To install my DOS emulator (DOSemu) on Ubuntu 9.04 (Jaunty Jackalope), then, I proceeded as follows: 1. In Ubuntu, go to System > Administration > Synaptic Package Manager. 2. Search for dosemu. Click, mark for installation, and apply. That installs a menu pick for Applications > System Tools > DOS emulator. 3. That menu pick won't work until you enter some additional commands. The advice I got was to enter it all on one line, like this: echo 0 | sudo tee /proc/sys/vm/mmap_min_addr In case it's not clear in your font, that line begins with "echo zero," not "echo oh." But that gave me a password error. So instead, I did it in two steps: sudo -i echo 0 | tee /proc/sys/vm/mmap_min_addr 4. Now you can click on that menu pick. This gives you a window in Ubuntu entitled "DOS in a BOX." DOSemu defaulted to the following disk assignments: A: Floppy drive, if any C: A 2GB virtual drive with DOS config.sys and autoexec.bat files D: Uses /home/ray (my username) as a read-write drive E: CD/ROM drive The documentation provided some instructions to change these assignments, but I didn't need to. I could just move the old Pdx DB files I wanted to convert to that /home/ray drive in Ubuntu and tinker with them there using DOSemu. (I noticed, incidentally, that the DOSemu documentation dated from 2003 and earlier, so I did wonder if I should have been more patient in researching the DOSBox option. Basic DOS commands seemed to work normally. I created and deleted a couple of directories and then used Ubuntu's File Browser (Nautilus) to move some Paradox data files into a new folder called D:\PDXDB. I also copied over my Paradox program files to a folder called D:\PARADOX. But while DOSemu seemed to run fine, I was not able to get Paradox to run inside it. At best, my attempts to run Paradox within DOSemu resulted in an error message about PDOXUSRS.NET. This seemed to be a problem of Paradox rather than DOSemu. When I tried running Paradox from a batch file with additional commands I had used previously, I got an "Unexpected Condition" error. I had seen the latter error many times before, but it had been quite a while, and I could not remember how to get around it. Ultimately, instead of troubleshooting that, I hunted around for freeware alternatives. Unfortunately, I didn't find many. First, I downloaded and used a 30-day trial shareware utility, Paradox Viewer from BrotherSoft - Scalabium (about $15 if you buy it). I had large memo fields in the old Paradox tables, so I saved them in Microsoft Access format. (Other options: comma-delimited, plain text, HTML, XML, Excel, SPSS, SQL, ADO, and Lotus 1-2-3.) For the old data that definitely needed to be archived as PDFs rather than kept in a database, I exported from Access to .rtf format, cleaned them up, and printed them as PDFs. Note: 100 records maximum export per table in the free trial -- and unlike some of the other products mentioned here, there's no pop-up dialog to say so. You just lose that extra data in records 101+. For the most part, Paradox Viewer was a professional, easy-to-use program. One problem I had was that it would not export fields to Access if the fieldname had a period or other punctuation in it; but it would export them to Excel. (In other words, it's a viewer, not an editor; it wouldn't let me change field names.) Another problem was that it would not read BLOB (Binary Large OBject) fields. Maybe if they had been all text, it would have been fine, but they were from WordPerfect for DOS 6.0 -- that is, they were WYSIWYG. So a Paradox-to-text converter wasn't the answer either: the graphics would be lost in the conversion to plain text. BrotherSoft also offered a direct Paradox-to-Access converter, but it seemed safe to assume that it would be using their same technology to read BLOB fields. I tried another one: ABC Amber Paradox Converter. The trial version on this one would only let me export 10 records at a time. Also, batch mode was not available in the trial. Worse, when uninstalling it, I ran into a problem that is apparently with the Wise Uninstall program, not with Amber: I got a "Could not open INSTALL.LOG file." The solution was, I hoped, to reinstall the program, just like before, and then try again to uninstall it, but that didn't do it. So I wouldn't advise trying this product at this point. I tried Data Import & Export 2.0, but it wasn't able to do anything with Paradox. I don't know why it came up in my Google search. DTM Data Editor, too, was shareware. I decided not to try installing to see what its demo version would let me do. Next, I tried Paradox dBase Viewer, but it said "Unsupported database file." It did recognize that my files were Paradox 4.0 tables, but it could not read some of them. (For the ones that it could read, it worked well. See below.) Paradox Converter would only let me export 50 records without spending $60 for the full version; it also wouldn't export to Access, so I would have had to convert DB to DBF and then import from there into Access. I did have WordPerfect Office X4, standard version, but that didn't include Paradox, and trying to open DB files in WordPerfect X4 gave me an "invalid file name" error. Upgrading to the professional version of WordPerfect Office X4 would have cost me $260. I wondered whether an old copy of Paradox 7, which I could get for $14 (including shipping) at Amazon.com, would be able to read those old BLOB fields. I dug around for a while but found no answers on that, so I posted a question on it. After three or four days, my post still had no reply (though the website said lots of people had viewed it), so I suspected there might not be too many people who knew the answer for sure. So I went ahead and bought a copy of Corel Wordperfect Office 7 Professional, which apparently did include Paradox 7. While Office 7 Professional was installing, it showed me a series of promotional blurbs, including one that did confirm that Paradox 7 was part of the package. But Paradox 7 didn't install. Everything else did -- WordPerfect 7, Quattro Pro 7, etc. -- but not Paradox 7. I did a Google search and saw that a number of others had had some kind of problem along these lines. One suggestion was to right-click on the SETUP.EXE file and choose Win95 compatibility mode, but this seems to have been for Windows NT or Windows 2000 machines. Another possibility was to try to run Paradox 7 in compatibility mode, which involved right-clicking on the program icon under the WinXP Start menu and choosing Properties and then the Compatibility tab. Paradox 7 apparently needed Windows 95 compatibility. This was perhaps a step to take later, but Paradox 7 was not even installed yet, and I didn't know how to make the setup (installation) program run in Win95 mode.

About this time, I received another copy of Corel WordPerfect Office 7 Professional, which seemed to suggest that I had ordered two copies instead of one. Indeed I had, but I thought I had asked Amazon.com to cancel the first order. Anyway, this one was different from the first one in several ways: the seller had kindly included the serial number, which was requested but not required during the installation process; s/he had included the actual printed manuals; and the CDs were labeled differently. In the first copy I received, the CDs were labeled "Applications disc," "Corel A to Z," and "Library disc." In the second copy, the CDs were labeled simply Disc 1, Disc 2, and Disc 3. More about this in a minute.

Someone suggested installing the Paradox 7 Runtime first, and then install Paradox 7. Apparently the Runtime version was originally part of Borland (not Corel) Paradox 7 Client/Server and could also be bought separately. It seems to have come in 16- and 32-bit versions. At this point, though, it seemed to be hard to find. After digging around, I found something called the Rough Enough software system, which claimed to include the Paradox 7 runtime. I downloaded and unzipped it, renamed the resulting folder, and discovered that the installer would only run if I left that folder with its original name. But even then, I couldn't get the program to install.

Using a different approach, I tried the freeware Paradox dBase Access Reader 2.1.0. Or at least that's the name that appears when you hit Help > About in the program itself; but a search turns up no such beast, nor does there appear to be anything out there known as Sportamok Software, and a visit to sportamok.com (which is also named in Help > About) yields a webpage belonging to some kind of sports statistics organization that seems to have no information on any such program.. Yet here it is nonetheless. And you can have a copy if you search for Paradox dBase Viewer 2.1.0 (not exactly what the program calls itself, but what everyone seems to call it).

As Derek Duke kindly pointed out to me, this Paradox dBase Viewer (PDV) program will cough up the contents of a Paradox 4.0 for DOS database if you take the following steps:

1. Start PDV. In its General tab, it will show a list of DB files in the indicated folder.
2. Select one of those files and switch to the Data tab.
3. Right-click on the column titles to sort, exclude a column from viewing, etc.
4. Highlight the records you want. If you want to highlight them all, Ctrl-A is an easy way.
5. There are two ways to get the data into another program. You can copy (Ctrl-C) and paste (Ctrl-V) what you have highlighted, or you can click on the program's HTML File button and export to HTML, Text, Excel, or XML files or to the Clipboard. Copy and paste works with BLOB files (at least with text BLOBs), even though the contents of the BLOB field are not themselves visible onscreen from inside Paradox dBase Viewer.

Consistent with Derek's tip, I exported to HTML and then opened the HTML file in Microsoft Word 2003. Word recognized the data as a table, so I did a Convert to Text (telling it to insert paragraph breaks between data fields). I cleaned it up some more, inserted page breaks, printed it to PDF, and broke up the PDF into individual files. And there, I had PDF files resembling my original data.