As easy as a "port" of the code? No, it's not, I agree
wholeheartedly. It's a redo of an excellent DOS program onto a
different technology base.
But, this "timing" bugaboo I've heard enough of over the years. From
Windows 95 on forward (98 and NT) it has been quite possible to write
timing-sensitive programs routinely. It requires a knowledge of
Windows, just like writing TRlog required a knowledge of DOS. This is
not a big deal, IMHO. Other aspects having to do with screen
real-estate management are actually easier in Windows 95/98/NT than
DOS. In fact much of the code is already written to do what Tree
undoubtedly had to do himself!
It takes just a quick peek at all these video-game-like, 3D games, in
which scenary and figures move very quickly in 3 dimensions, to
realize that the ability to prioritize tasks, manage the interrupt
stack, etc., all can be done in an environment where "windows" are
being painted continuously. I dare say a TRlog Windows 95/98/NT
analog would not even come close to loading up a system like these
applications do. The timing aspect, with proper design (not
necessarily a pile of code per se, just attention to tasks/threads and
their priorities), is a no-brainer. It will require, in all
likelihood, more powerful computers having more resources, a statement
typical of any Windows 95/98/NT system when comparing it to a DOS
system.
Well, my ham shack gets all the hand-me-downs and it just got a
Pentium 200, my current slowest machine. I suspect others are in a
similar situation, perhaps not with Pentium 200s, but with slower
Pentiums. That's a big jump from a 286 machine! I understand one
gets a larger market if the program can run on 286s, but in today's
time, when Celeron processors up to 500MHz are being sold without
monitors for something like $450 (with 64MB,8GB HDD...), the size of
the "entry" system has changed drastically over the past year!
It's time to move forward. As comfortable as I am with using the
current TRlog program, it will be set aside like so many other archaic
programs when I see a competitor come out that lets me do most of the
work with a point/select device, eschews these CTRL/ALT key strokes,
etc. Just look at all the extra screen space one would have if TRlog
would support 1024x768, a fairly coarse screen size by today's
standards. I believe I would be able to have more info on the screen,
make better-informed contesting decisions, etc., as well as being more
productive, with a new-technology TRlog. Windows 95/98/NT lets that
dynamic screen management be done so easily compared with the
hard-wired "features" of DOS. A TRlog-like program (in capability) is
going to happen, for sure.
Tree, I'd say you need to face what lots of businesses have faced over
the past 10 years. Do you milk the cash cow while you get into
something new, do you update your technology base (requiring a helluva
investment) using whatever cash the cow is bringing in, or do you
figure technology improvement will not take place in your timeframe of
interest and continue with the status quo and let someone else take
over a new market slot? Good luck with that one, HI!
73,
Gary Ferdinand W2CS
Apex, NC
>Tom, N0SS wrote:
<<SNIP>>
> As one who has written a number of fairly large and involved DOS
> programs, including several, like TR, which depend upon
> system TIMING
> in order to accurately send CW, I must state that making the switch
> from DOS to a Windows-based operating system is NOT all that it's
> cracked up to be. And in many instances, what you're asking for in
> NOT merely a simple "well, let's just 'port' the program from DOS
> to Windows and be done with it" proposition. Making the switch from
> DOS to Windows can often require a COMPLETE top-to-bottom of the
> software, e.g. you start with a completely clean slate and go from
> there.
>
<<SNIP>>
> And, so far, I've not even addressed the TIMING constraints which
> are presented by Windows programming, which are not presented by
> DOS. Sometimes, without a LOT of 3rd party coding support these
> constraints can require a significant amount of time to address and
> overcome.
>
> Yes, there are times I'd acknowledge that it'd be nice to have a
> 'moderm' logging program which ran in Windows, but I'm not sure
> that it'd be significantly better than TRLog as it stands now.
> If we could financially support Tree in the manner to which he
> has become accustomed (as a result of the paycheck he receives from
> his employer), maybe he could quit his paying job and devote all
> of his time to writing nothing but TRLog code. However, I doubt
> that this will happen.
>
<<SNIP>>
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|