It is obvious that this post speaks for itself as to the complexity
involved. There is no generally accepted API for DOS and there is no easy
installation. It can be done, has been done, and is impossible for the
average user and a nightmare for the coder due to all the different
machines. This is one thing we can thank Bill for , even if we do not like a
lot of what he did, he did give a standard api FOR EVERYTHING (COMPLEX
THOUGH IT MAY BE) AND THAT IS A HUGE STEP AND WHAT HAS MADE THE pc
REVOLUTION POSSIBLE , LIKE IT OR NOT.
> -----Original Message-----
> From: owner-trlog@contesting.com [mailto:owner-trlog@contesting.com]On
> Behalf Of Kevin Hemsley
> Sent: Tuesday, December 11, 2001 13:02
> To: trlog@contesting.com
> Subject: Re: [TRLog] Ethernet Network
>
>
>
> We were writing DOS programs for networks long before Windows was
> invented.
> I have written many DOS programs that work over a network just
> fine. In fact
> many of my programs were network utilities. It can actually be a VERY
> simple process. Your program doesn't "have" to know anything about
> "Ethernet" or any of the ISO network layers. All a DOS program needs to
> know is how to handle simultaneous writes to a single file - which is
> simple. If you can specify a full path for where the logs are
> stored, then
> you can save logs across a network - i.e. C:\TR\logs or F:\TR\logs, etc..
>
> The difference between a network drive and a local hard drive is
> "invisible"
> to the program. In order to support networking multiple PCs together, you
> do need some type of network driver. You can even boot in DOS and use
> Windows 3.x's built-in "DOS" commands to start the network
> services and map
> a network drive. Or your can run TR in a DOS shell in any of the newer
> Windows operating systems and have full network support. The
> bottom line is
> that there are MANY ways to provide network services under DOS. Remember
> that providing network services is NOT the function of a DOS application
> like TR. Network services are provided by the operating system and
> subsystems - not applications.
>
> Once you have a network drive mapped, each instance of TR can be
> configured
> to write to the same log file. The secret to supporting multiple
> simultaneous writes to a single file is to have your program be
> patient. In
> other words, if your program tries to open a file for writing,
> and the file
> is "locked" because another program is busy writing to it, then
> you create a
> loop that keeps trying until it successfully writes to the file. You can
> also utilize a "lock" file to flag when the file is busy. You eventually
> need a time out so that if the network is down, the program
> doesn't lock up
> trying to write to the log file. In the event the network goes down, you
> have your program write to a log file on the local hard drive. When the
> network connection has resumed, you can reconcile the local and
> network log
> files. I have written DOS programs (in Pascal even) that had hundreds of
> PCs logging to a single file. With logging such as TR does, the
> file access
> times are VERY quick. By changing the routines that perform the
> actual file
> writes to loop if it can't open the file for a write, you
> essentially create
> a network version of the program with literally a handful of code lines.
> The other change you need to make is to change the appropriate
> file formats
> to support logging of a new field which identifies which "workstation"
> logged the contact.
>
> This is the basic operation of a network logging program - perhaps a bit
> oversimplified. From here, once you have a contest system on a
> network, the
> imagination starts running wild. I can envision a separate program running
> on another PC that monitors the network logs and displays real-time stats
> for observers to watch. This can be displayed on a TV monitor for
> the larger
> observation crowds. :-)
>
> Another interesting feature for a network contesting logger would be to
> include instant messaging. This feature would be nice if you
> wanted to send
> the message "N6TR waiting for your call on 28.500" from the 20M
> workstation
> to the 10M operator's workstation who needs the station for a mult. A
> messaging function like this can be accomplished two ways. One
> way is to get
> somewhat fancy and send live TCP or UDP packets to each workstation to
> facilitate instant messaging. Another more simple method would be to
> maintain a message file and each workstation would check that
> file by doing
> a periodic read every few seconds. If there is a message waiting for the
> workstation, the workstation deletes the message from the file,
> and pops up
> the message. The latter method is simple, though not very efficient.
>
> Adding network support to a DOS program can be fairly simple, and
> evolve to
> include lots of additional network features. Just don't be fooled by all
> the fancy Windows software into thinking that DOS programs can't support a
> network. The truth is that DOS programs can be made to run on a
> network, and
> be very stable. Something Windows programs with all their
> complexity often
> have difficulty with.
>
> Thanks,
> Kevin.
> ------------------------------------------------------
> Kevin Hemsley
> Systems Engineer
> Microserv Computer Technologies, Inc.
> kev@ida.net
> KB7TYA
>
>
>
> --
> FAQ on WWW: http://www.contesting.com/FAQ/trlog
> Submissions: trlog@contesting.com
> Administrative requests: trlog-REQUEST@contesting.com
> Problems: owner-trlog@contesting.com
> Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
>
>
--
FAQ on WWW: http://www.contesting.com/FAQ/trlog
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|