Versions 0.77 through 0.81 are available
as 32-bit DOS-extender applications only. Version 0.82 and following are native
Windows 98 applications compiled with Visual C++ 6.0 from much the same source
files as the former DOS versions. Windows and DOS are intrinsically different
programming environments. Windows offers a new set of standard features to
the user, thereby creating new "what if"s for the programmer to take care
of. I had to march along these new requirements for a distance, but not the
full way. Instead of writing a completely new program, which would have taken
over a year, I just created a function layer interfacing between the Windows
API and the DOS logic of the existing program. This could happen in a few
months. Consequently, the program still is keyboard operated (except for
mouse-editing of plots). It looks and smells like a DOS application while
executing in a "genuine" Windows window. Unlike the DOS versions, it can
now coexist with other applications on the same screen. This is a gain in
convenience for all users who did not like its previous manner of enforcing
the 640x480 pixel, 16 color graphic mode and taking exclusive control of
the VGA adapter.
Beyond
this, a mathematics application has little to gain from Windows. I'm in no
hurry to restructure the user interface. All the "bells and whistles" Windows
has to offer would become portability problems in case I'll ever have to
migrate again. They would slow me down and create an additional potential
for problems. For instance, Windows has this very sophisticated way of selecting
a font. I hope it's not too sophisticated to work on your system, too!
I would have liked to embed two or three standard fonts in the -.exe file
itself (like I did in the past) and to be independent of whatever is installed
on a user's computer. But Windows doesn't let me do this. So I wish everybody
good luck !
What if the
program was operated through a menu, instead of being keyboard-operated ?
What if the help screens could be moved out of the way and stand by, while
you are working with the program ? Or if the designer plots had their
own, independent window ? Why do the many lists have fixed positions,
instead of being moveable like genuine Windows dialogues ?
The answer is, that all these things
are nice if you don't have to create and maintain them. They don't bring real
potential and benefits, they are just nice. Introducing them opens the door
to a new set of problems, bugs and instabilities which are nonexistent at
the moment.
I did add
a menu and a STOP button. As a consequence, I had to worry about when this
STOP button and other menu points should be enabled or disabled. While the
result is "nice", I had to create a new class to control the menu, add global
variables and add commands to virtually every program part. Still, there
are corners left where the menu doesn't behave quite consistent and logical.
This is what I mean.
You create unnecessary problems when trying to support too much. For proof,
look at the Windows98 operating system. Some things are good (those borrowed
from the Macintosh) while others are a nuisance. They placed things right
in front of my nose that I don't need and can't get rid of. Other things
that I was used to work with aren't supported any more or have become unstable
or hidden between too many other options. The system changes its properties
behind my back and I don't see how to restore its previous behavior. It doesn't
do what I want, it has its own ideas how things should be. It is, in a word,
a bad operating system, teaching me how NOT to write programs. A program
should be fully subordinate and at the user's service, not patronize or keep
him waiting. It shouldn't ask too many questions or fake "intelligence" in
other ways.
A good
program in this sense is Microsoft's Visual studio. It was written to accomodate
a programmer's real needs and offers integrated browsing and debugging features
that are helpful and speed up one's work. So I hope that, in the long run,
I can make up for the time lost in the porting process.
Persuading
Windows to accept a DOS program structure was not easy and required a double
threaded application. While a computation is under way, you may wish to move
or minimize the window. Of course this must not interfere with the computation
- or the program structure is a mess! So there had to be separate threads
to take care of the window (thread 1) and to execute the actual contents
(thread 2) which are dating back to better (DOS-) times.
Despite such complications, the Windows
version is not slower than its DOS predecessor, upon tests I conducted it
was 17% faster.
