Initial Front End

The above decision to use Windows NT as the development platform and to have a graphical user interface meant that it was necessary to program a Windows GUI. Thankfully the tools provided with Visual C++ take a lot of the pain out of such a task. The creation of a basic Windows shell program can be done in a matter of minutes. I decided to create a Single Document Interface program (SDI) over a Multiple Document Interface (MDI). MDI offers the advantage that a user may have several documents open simultaneously. However, quantum circuit simulations would be exponential in both time and space so it would seem unlikely that a user would ever want to run two or more simulations simultaneously (the competition for system resources would result in simultaneous executions being far slower than sequential execution). SDI applications are also easier to implement than their MDI equivalents and I did not want to spend too much time developing the user interface.

Provided with Visual C++ are a set of classes called the Microsoft Foundation Classes (MFC). These classes characterise a program in to three major areas; the program itself, a document in the program and a view of such a document. It is then down to the programmer to match his application to these classes. In light of my decision to have the simulation code distinct from the front end, and portable to non-Windows platforms, I decided to have a practically empty document. Although the document class would be responsible for starting a simulation and setting user preferences no simulation data would be kept within the document class.

The view of this empty document was then the textual output from the simulator. Within the confines of MFC the easiest way to achieve this is to derive the view from a CEditView class. This base class provides all of the functionality of a basic Windows editor such as the Notepad application. By making the text in the display read-only and by setting the text a scrollable view of the output of the simulation is obtained. An extra bonus is that MFC automatically takes care of saving the text out to a file and cutting and pasting the text in to other applications. The only disadvantage is that there is a 64-kilobyte limit on the text length.

Other options included not using MFC as a base for the application (i.e. programming the Windows code from scratch) or deriving the view of the document from some other MFC class. Both of these options would have required more work than the option that I chose. The first would have involved duplicating a lot of MFC code, the second would have involved deriving the view of the simulator from one of the more general view base classes and drawing the textual output on a graphical output window.

There were a number of requirements for the front end that I decided would be desirable at this stage. A simulation would be expected to require a large amount of processor time. If it was to run for hours then it would be useful to give some sort of visual feedback to the user. It would also be nice if the simulation did not monopolise the computer's resources throughout this time, which suggests that the priority of the thread that is running the simulation should available for the user to change.