Doug,
Well, I don't play a professional programmer on TV, but I am one. ;-) I've
been writing Windows software for over a decade that pushes LOTS of data
around from scanners and to printers. The timing demands of moving the
data aren't as critical as, say, keying a keyer exactly right at 50 WPM,
but they're much notbaly than, say, word processors, spreadsheets or
databases (which are primarily processor-bound rather than I/O-bound
activities).
Device driver writers are _very_ familiar with timing issues and with
solving them under Windows. In fact, in many cases they have tougher
timing problems to solve than we do with contesting software. Some other
familiar data transfer (I/O) operations like PC fax have important timing
considerations (handshaking protocols for packet timing). So, yeah,
Windows can certainly do this sort of stuff.
The biggest challenge under Windows is that the way this sort of software
is written is quite different than the approach employed under DOS.
Timeslices of a few milliseconds (and less) are de rigueur under Win32 (Win
9x and Win NT); especially on 486/66 and up classes of machines.
What the programmer must ensure, though, is that their program gets started
back up (swapped back in) and get access to I/O resources (like parallel
ports) often enough so that the program still feels (and sounds) real-time.
This is the part that really requires design approaches particular to
Windows (disregarding for this discussion Un*x, Mac and all those other OSes).
As a semantic note, whether these great DOS programs can successfully be
"ported to Windows" depends, IMHO, on what one means by "port". If we mean
prudently modifying the algorithm/engine code to talk Win32 APIs
(Application Programmer Interfaces) while largely/completely rewriting the
user interface and I/O (input/output) code then sure, it can be done.
Technology already exists and the calls are there. If our expectations are
that a little bit of code is changed and the app simply recompiles as a
Windows app, it ain't gonna happen.
There's also a little issue of solely targeting 32-bit Windows (9x and NT)
or including Win 3.x. But that's another discussion. :) There's actually
non-trivial unique code to be written for each OS, but lots of shared code,
too.
The "profitably" question seems like a big one to me. The investments
these guys have made in their installed base of code is pretty big. Will
hams support (through upgrades) these ports? Nobody's getting rich here,
but it sure makes it easier to run a compiler late at night if you have a
feeling that what you're doing is worthwhile on as many fronts as possible!
Good questions.
73 Kevin K7VI
At 01:07 PM 1/24/98 -0600, Doug Smith wrote:
>I'd kinda like to hear from the programmers (K8CC, N6TR, etc.); is it even
>*possible* to write a reliable native Windows contest program with the
>features we expect?
>
>Contest software does more direct manipulation of the hardware than most of
>the packages you use every day at work. It depends on exact timing to a
>degree unusual among "normal" software. And its efficient use depends on a
>prompt response; you can't wait a second or two for a cache to flush or
>something like that. I guess my point is, TRLog and Excel are two VERY
>different applications; just because one can be efficiently & profitably
>ported to Windows doesn't mean the other one can...
>
>73 Doug
--
CQ-Contest on WWW: http://www.contesting.com/_cq-contest/
Administrative requests: cq-contest-REQUEST@contesting.com
|