TIP: Click on subject to list as thread! ANSI
echo: geoworks
to: ALL
from: ANNE PAGE
date: 1996-09-08 11:39:00
subject: GEOS CLOCK

Since I am no longer the official "cross-poster" from comp.os.geos,
I am not cross-posting what I just saw there (yes I started reading
it again a few days ago as a lurker but probably won't stay there
long), but I am going to summarize and maybe even quote a few comments
from the post I read in case it doesn't get cross-posted by Chris in
its entirety.  My reason for doing so is that I remember someone here
commenting a few months about the GEOS clock not keeping proper time
and this information might be helpful to that person.
The comp.os.geos message was written by GWREP Steve Main in reply to
a question by someone who upgraded to WIN 95 and noticed that the
GEOS system clock is never right.  The problem is not one limited
to WIN95. I use WIN 3.1 and my GEOS system clock is never in sync
with my others. Just as the inquirer in comp.os.geos said, mine drifts
as to time but keeps track of the date. In his reply, Steve Main
said,"Windows does not actually multitask Geos. Therefore, when you
task out of Geos back to Windows, the clock in Geos stops running.
It starts running again when you switch back to Geos. Then when you
exit Geos, Geos writes the wrong time back out to your hardware clock."
Then Steve gave these fixes which range from horrible to okay. 
The first one, the worst one, is totally unacceptable to me. He
said: "One is to never exit Geos properly, but always crash out of
Geos instead -- not very elegant."  Personally, FWIW, I'd rather
live with a drifting system clock than deliberately crash and come
back each time.  As you've seen by my descriptions of how I work in
GeoFile, I try to work on all my files in ways that avoid crashes.
Then GWREP Steve mentioned that Marcus Groeber had written a little
DOS file called Time Guardian that prevents all software (including
GEOS) from writing to the hardware clock.  He pointed out that it
works but interferes with some other software.  His example was a
statement that Magellan GS won't launch with Time Guardian in place,
but I don't know what that means because I've never heard of Magellan
GS. Can someone here tell me what that is and what it does?
The final "clock fix" suggested by GWREP Steve was to use a patch for
the Geos kernel that prevents just Geos from writing to the clock. As
he put it, "[T]his is the most elegant solution, though keep in mind
that thereafter you can no longer use Geos' Preferences to change
the clock." Although he credited this patch to Marcus Groeber in his
original message, he followed it up with this correction message
later in my packet: "In a previous post, I said that Marcus Groeber
had developed a patch to the Geos kernel to prevent it from writing
to the hardware clock. I was wrong. The patch was authored by James
A Zuan. I apologize, James. The filename, on AOL, is CLKPATCH.ZIP."
The clock drift isn't a problem for me although I know it is for a
lot of you who use WINDOWS and other applications because the work I
do in GEOS isn't time sensitive. I only use an automatic date for
letters, so it is always right when I start a letter to someone.  None
of my canine newspaper work or anything else I do ever needs to have a
footer showing the date and time of creation. But I know that some of
you do work in Ensemble where you want your drafts or final documents
labeled with the date and time, so maybe this information will help you
solve your clock problem if you don't want to simply reset it each time
you start a time sensitive project after leaving GEOS and coming back.
                                                Anne Page
 * SLMR 2.1a * The *best* mini-vac for after-meal cleanup is a dog!
--- QScan/PCB v1.16b / 01-0075
---------------
* Origin: PSL Online Houston, TX 713-442-6704 @psl-online.com (1:106/6256)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.