A few years ago I put out an article entitled Partying Like It’s 1987: Running WEAP87 and SPILE (and other programs) on DOSBox, where I describe the use of DOSBox in running engineering software (and also Windows 3.1.) A great deal of engineering software developed in the DOS era can still be used for engineering design and analysis, providing a) the engineer can handle the text-based interface and b) the engineer can get it to run, which is the primary object of DOSBox.
Great engineering software obviously didn’t end with the DOS era, but much of it which was developed for Windows 3.1/NT/95/98/Me/2000 and even XP is no longer usable in Windows 7, 8 or 10. As is the case with the DOS software, this includes programs that are still can be run and free (or can be obtained at low cost) while having user-friendlier interfaces than DOS programs. To get started it’s important to understand the reasons why this is so.
The reason why it isn’t so: Windows 7 and 10 can still run 32-bit software, although how much longer that’s going to be valid is an open question. (Macs have cut off use of 32-bit software much sooner than Windows.) 16-bit software (such as was developed for DOS and Windows 3.1) is another story; unless you have a special version of Windows 7 (I’m not sure about 10) you’re out of luck. Most software developed for versions from 95 to XP and Vista was 32-bit software, but there are still problems.
One of them is that 32-bit software in the day frequently came with a 16-bit installer, which will stop cold in Windows 7 and 10. There exist substitute installer programs to get around this problem for the most common installer of the era.
Once you get past that issue, however, and your software starts, you run into another problem: the Windows interactive Help feature in an older program no longer works. The 32-bit help system began to be phased out with Vista, and in Windows 10 it is no longer available even as a patch. Since in many cases the interactive help is the only “manual” available for a program, this can be a dead end in using an otherwise good program.
So what is to be done? This is where the irony comes in: an excellent way to run these programs is to exit the Windows world altogether and run these programs on Linux or a Mac using a system called Wine, which describes itself as follows:
Wine (originally an acronym for “Wine Is Not an Emulator”) is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.
It takes advantage of the fact that all of these operating systems: Windows, MacOS, BSD, and Linux–use the same Intel and AMD chips. Wine has retained compatibility for both 16-bit software (including the installers) and the old Windows Help system to allow many older Windows programs–16- and 32-bit–to run in non-Windows operating systems better than current Windows!
It’s worth noting that I say “many.” Wine has a reputation of “hit or miss” compatibility with different software packages. It’s gotten better over the years; you can see their current compatibility list here. Most engineering software was focused on the results and tended to operate in Windows in a “plain vanilla” way, so it’s more probable that an old engineering application would work than, say, a game.
For most Linux distros (distributions) Wine is available in the repository, where one draws the software one uses and from whence the updates come. (It’s the best system IMHO out there for both of these processes.) The Mac is a little more complicated, and I’ll get into that below. For now let’s take a look at a few applications that are relevant for the Vulcan world.
Vulcan had been using DesignCAD since 1988, and its use continued during its existence and through the subsequent years of the product line. With a product line now more than 130 years old, continuity of access to “legacy” information is crucial, and being able to run DesignCAD in this way is very helpful.
Driven is the original Windows program put out by the FHWA for the axial capacity analysis of driven piles, and uses the FHWA’s methodology as shown in publications such as the Soils and Foundations Reference Manual. It’s still useful but suffers from the 16-bit installer and the problem with the help function; Wine solves both of these problems.
A software program featured on this site in detail is SPW 2006, the sheet pile software developed by Arnold Verruijt at the University of Delft. This is especially easy to run in Wine because it doesn’t require any installation; you just run the 32-bit executable and go. There is no discernible difference between running this in Windows and in Wine. This is also true of another Verruijt program which I use in my teaching: Slope, a simple slope stability software package.
A good example of a fairly contemporary piece of software that, like Driven, installs in the system, and runs well in Wine is e-Sword, the free Bible software. This is a screen shot from version 12.1.0, released in 2019. Some versions do better than others. The verses I feature are the ones I used in the dedication for my dissertation.
Engineering Power Tools
An old stand-by is Engineering Power Tools, which I feature on another site. Although much of this can be done online now, sometimes this software package is more straightforward to use.
And the Mac?
Now we get to the part of the question that probably interests the larger number of people: will this work on a Mac? To be honest, the support that Wine gives on its site to the Mac isn’t the greatest, but one implementation that I’ve tried that has worked OK is Wine Bottler. The idea behind this software is that you can take a Windows executable and transform it into a Mac one, or you can just run the Windows executable just as it is. Making it into a Mac executable tends to bloat it, but that’s optional for a Mac with Wine Bottler installed.
One thing you have to be very careful about in installing Wine Bottler is that it doesn’t always work on the newest versions of MacOS. At one time Mac was better than Windows in backward compatibility, but that’s no longer the case. As should be evident, the Mac shown above is running Yosemite.
How About a Virtual Machine?
One question that will come up sooner or later in a discussion of this topic is whether a virtual machine would be better. That’s not a simple question to answer, because it depends upon the application and the virtual machine.
If you have a copy of Windows, you can create a virtual machine using a program such as VirtualBox. How well that will work out will depend upon the version of Windows you have and the application. Windows’ backward compatibility is better than the Mac now but it isn’t perfect; I’ve found that Wine will run a wider variety of software (if not always better) than any single version of Windows. Mac virtual machines run into their software licensing issues.
But there’s another way of looking at the problem: why not flip it, install a Linux virtual machine, and run these programs on Wine inside of it? Many Linux distros have “prepackaged” virtual machines available that can just be copied and run; with network access, you can install Wine on these machines and you’re good to go. There are two advantages to this: it’s less intrusive on the host machine, and it avoids any licensing problems for the guest operating system. And you can try Linux’s other features while you’re at it.
This is a quick overview of how to use Wine to run old Windows software. Having that capability can enhance your access to legacy information and save you money on purchasing newer versions that may or may not do much more than the version you have at hand. It’s not the most straightforward thing to do on a computer, but it certainly can be done.