At present, yes. However, we hope to develop Whisker using a cross-platform tool to allow it to run on Linux and Mac OS X as well, if adequate hardware control proves technically feasible.
Whisker runs on the Windows NT/2000/XP/Vista/7/8 family of operating systems. Use a recent version of Whisker (e.g. 4.5.0). However, there are special considerations under Vista and higher, as follows:
There are a few outstanding problems:
If you are using old versions of the server, be aware):
And if you are using old behavioural clients from us (prior to Jan 2009):
The same special considerations apply as for Vista:
As above, there are hardware devices/drivers that have not yet been tested with Whisker under Windows 7; testing is ongoing.
Yes; source code for all Whisker components is available on request to customers who have purchased them.
Whisker is continually updated and improved in response to customer requests. We are in discussion with our new supplier, Campden Instruments to provide an enhanced update service; at present, the supplier will contact all customers as updates become available.
Information on basic installation and configuration is given in the README.TXT file.
Current software version numbers are detailed in the Version Tracker files; there is a version tracker file for each component of Whisker, including the server and all behavioural tasks.
Frequently-asked questions about installation are given in the current Whisker manual, under "INSTALLING WHISKER SOFTWARE" and "HARDWARE INSTALLATION".
See the README.TXT file; you probably need to add "C:\Program Files\UPDD" to the path.
This has been observed with Whisker v3.6.0, multimedia edition, configured for UPDD v4.1 or later, with UPDD v4.01.06 correctly installed, but with an old (incompatible) TBAPI.DLL copied into C:\Program Files\WhiskerControl. In general, it implies that the TBAPI.DLL being found is the wrong one for the actual version of UPDD installed. Whisker will look for this DLL in its own directory (where it should not be found!), then on the PATH. Check for spurious versions of TBAPI.DLL; you probably want the one in C:\Program Files\UPDD.
A path problem (ace.dll is part of UPDD); see the README.TXT file; you probably need to add "C:\Program Files\UPDD" to the path.
You need to install the Visual Studio 2008 redistributables. (This option was suggested to you in the installation.)
The current FAQ list is in the current Whisker manual, under "TROUBLESHOOTING - FAQ".
See the current manuals for individual tasks.
We used to use Microsoft Visual C++ 6.0, and (as of 2009) now use Microsoft Visual Studio 2008 (Visual C++ 9). Whisker, the client libraries, and most major tasks have been converted across; a few have not. Conversion to any edition of Visual C++ between those ranges is possible (e.g. VS2005) and fairly simple for the end programmer. The major difference between VC6 and VS2008 is that VS2008 is much more compliant with current C++ standards - though the compiler no longer runs on versions of Windows before Windows XP.
Install the public-domain Boost library from http://www.boost.org/.
If you're running Windows Embedded XP, you probably need to install the normal Windows default font, MS Sans Serif.
This is an infrequently asked question, but an important issue. We have seen instances where tasks go curiously wrong – for example, when they choose a random number (e.g. a time) between A and B, a number outside that range is returned, and throws everything off. You'd think this is a task bug, and sometimes it is. But we've seen one other, very nasty, situation.
It is a golden rule of operating systems that different programs shouldn't mess up each others' operation simply because they run at the same time (and are not intentionally communicating). It's the operating system's job to enforce the independence of processes (programs): program A shouldn't be able to write to program B's memory space, and so on. However, under Windows, there are situations in which a process can corrupt another process. It works like this.
If a device driver, running in "kernel mode" (a privileged mode of operating reserved for device drivers, and distinct from the "user mode" that normal processes run in), uses the floating-point hardware (floating-point processing unit, FPU), it may corrupt the state of the FPU for user-mode processes, unless it makes specific operating system calls to save the FPU's state beforehand, and restore the FPU's state afterwards (detailed here). (This is true of Windows 2000 and later: earlier versions of Windows simply do not allow device drivers to use the FPU, or they will corrupt user processes or crash the computer.)
We've seen this problem (see here, searching for "v5.1" and "v7.6", and here, searching for "2.12.9"). MonkeyCantab was going wrong, and we assumed it was a MonkeyCantab bug, but it wasn't. We created a simple program that did some floating-point calculations. It ran fine on its own, but when we used Windows Media Player to play a sound through a Creative Labs SoundBlaster card (this was in November 2010) the floating-point calculations went wrong – in a separate program. Whisker was also configured to use that sound card, and when Whisker was using that sound card, our floating-point test program went wrong. We infer that the SoundBlaster driver illegally used floating-point calls without saving and restoring the floating-point state (using the KeSaveFloatingPointState() and KeRestoreFloatingPointState() calls. Disabling the driver fixed the problem.