Forest Projection and Planning System (FPS) on WINE

The time has come to try and branch out some.  So we here at FSD chained out IT penguin to a computer this week with a few tasks to do.  One of those tasks requires some serious computing power.  So the work around was to leverage all the computer cores around the nest to crank out some numbers.the real problem was to do that would have meant a minimum of 16 virtual machines plus cranking up a few extra machines.  The penguin in charge of the electricity here was excited.  He always likes ramping up a nuclear reactor or two to power the computing.

However,  to the disappointment of the power department here at FSD an alternative was developed.  While all work with FPS here at FSD is done in MS Windows it is contained in a virtual machine.  Specifically VMWare Workstation.  This has allowed some amazing things.  Some of those are the ability to have every version of windows since win98 (yes 98 couldn’t find my 95 disk) and every version of MS Office since 97 to test client problems.  Once long ago out of interest FPS was tested in Linux using WINE or the Windows Emulator.  It sort of worked and I thought wow that is neat.  But it was clunky.  Let 11 years pass and convert all of your machines to Linux and things become more viable.  The solution here is based on the fact that FPS is still compiled as a 32 bit program and doesn’t leverage more than 1 core.  As I type here the machine Thneed Weekly comes to you from has 7 of the 8 cores cranking along on FPS processes.  I always leave one for other processes.

Now we here at FSD don’t promote this and have not fully tested the process but for the current project things seem to be working well.  So continue at your own risk.  If your computer melts that isn’t my fault.


Only takes a few seconds when you know what you are doing.  Takes four days when you don’t.  Learn from our failures.  Here is a BASH script to do the install.  We will talk about it after.


export WINEPREFIX=~/.wineFP7
export WINEARCH=win32
export FP7Path=C:\\FP7\\
export FP7Data=C:\\FP7\\Data\\


winetricks jet40 mdac28

wine regedit ODBCINST.INI.reg

wine Fps_731.exe

wine ~/.wineFP7/drive_c/Fp7/Fp7Post.exe

Ok that is nice what does that mean.  well the Splat Bang /bin/bash as my father would have put it tells the system what kind of script this is.

The export statements set environment variables for the session.  Specifically where to install the WINE folder and what architecture as well as the FPS environment variables.  We had tried many other combinations preferring the 64bit but one of the patches we will talk of soon couldn’t handle 64bit.  Now you will see soon why we chose not to define the export statements in the .bashrc file.

winecfg configures WINE and builds the wine area defined in the export statement.  The configuration screen comes up.  We verified Windows XP and set a Username and Organization.

winetricks is the winner here.  This statement will install the necessary components for the MS Jet and ODBC to work for FPS to talk to a database.  This was the part that was not compliant with 64bit.  Probably could have made it work but the frustration level was through the roof at this point.

Now this is when i thought all was good and could just install FPS and all would work.  Well no.  It would pop up and an error message would show up after accepting the error FPS would just close.  Come to find out that when the ODBC is installed not all of it is installed.  so there was a necessary wine regedit.  Here it is.


[HKEY_LOCAL_MACHINE\Software\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb)]

The ODBC install didn’t define the driver for Microsoft Access in the registry.  Technically it would have been better to do the next one up that includes the ACCDB format but that wasn’t necessary for the work here.

This is all finished up by installing FPS and registering it with FP7Post.

Now if you have gotten this far you have probably run FPS and found a big error message comes up.  This is OK.  It comes from a non-standard out of date graphics library called quickwin.  All of the FPS routines use it for the GUI portion of the interface instead of the standard Windows API.  However, no problems have been encountered thus far by ignoring the error.  Maybe some window corner isn’t as smooth or something.  No big loss.


Another problem you may encounter is that since FPS requires MS Access to create the Database.dsn file that directs the software to the database to be processed.  well that is pretty easy.  DSN files are a standard.  Here is an example.

DRIVER=Microsoft Access Driver (*.mdb)
FIL=MS Access

Note the double \ or the \\.  Remember in Linux the \ is the start of an escape sequence.  So a \\ is the escape sequence for the Windows \.

All fine and good how did you get so many processes running at the same time.  Actually you have all the information you need.  But lets get you all the way.  FPS depends on environment variables to find itself.  The FP7Path and FP7Data.  The key here is how Linux and most modern OSes work.  Every process is separated from every other.  So all that is necessary is to have code like the following.


export WINEPREFIX=~/.wineFP7
export WINEARCH=win32
export FP7Path=C:\\FP7\\
export FP7Data=C:\\FP7\\Data1\\

wine ~/.wineFP7/drive_c/Fp7/Fp7Crus.exe

Note the FP7Data setting.  FPS will look to the Data1 folder for the Database.dsn file.  So the IT Penguin here created 7 Data folders and each script had a different Data folder defined.  Because of the nature of the work we still decided to break the data out in to 7 databases and so there is no cross talk between the processes but it is all a matter of timing if you are real brave.  For example.  Start growing the database.  once the system starts growing all the data has been read in.  Change the regimes and grow in a different thread.  Rinse and repeat.  But that all has to do with timing.  We are not that brave here.

If you have any questions shoot us a note on the contact form.