Under Vista you must run geockw32 as administrator when you first setup or modify the screen saver
This seems to run on Vista 64 (so far).(2008/11/20)
PROGRESS!! 2009/01/29 Found memory size allocation problem in map load/resize code. Seems to solve mouse zoom problems, but the errors should have been MUCH more serious.
2009/08/11 - Some windows destroy themselves after first use. This was not a problem under Win16 because memory limitation caused me to use a different invocation method that recreated the window before EACH use.
| 2009/10/31. I am not satisfied with the current state of geockw32.exe. There are still many mysterious errors, that seem to depend on exactly how the computer is configured. It always starts fine, and displays simple maps, but polar and ortho maps sometimes produce errors on the screen, and dragging the window borders sometimes produces GPFs. We also lack serious testing by experienced users (many of the errors reported are because the tester did not bother to read or follow the instructions). As I said before, it is hard to stay motivated |
| 0 | Task | complete | problems |
| 1 | Clean Compile | 2008/07/08 | pointers, inline, 16 bit asm, data sizes |
| 2 | initialize | 2008/07/13 | GPF after initialize but before program start, must preserve esi and edi |
| 3 | Spinning Globe | 2008/07/21 | absolute, shortint <> smallint |
| 4 | access violation on activation |
2008/07/24 | incorrect stack handling in CRC routine |
| 5 | character display | 2008/07/26 | small font OK, large font numbers OK, letters not word vs integer and coincidence made the problem hard to isolate |
| 6 | Date/Time wrong | 2008/07/27 | change to Delphi now function |
| 7 | GPF on shutdown | not yet | Have not seen in a while - maybe solved by (12) |
| 8 | 8-15 sec delay on some menus lose sunlight&city |
2008/11/15 | Interruption control on 16 bit version
does not work on 32 bit version, eliminated function as not necessary with current HW speeds |
| 9 | sunlight on spinning globe distorted |
2008/09/09 | 16/32 integer sign extension/truncation |
| 10 | sunlight on polar, VFS, and eqaz | 2009/01/04 | Converted fill16 rather than fill32 |
| 11 | Distance function | 2008/10/01 | Delphi4 defective OnMouseMove handling Handle WM_MOUSEMOVE myself |
| 12 | GPF sometimes on mouse zoom | 2009/01/29? | resize map buffer allocation size error why wasn't this problem more manifest?) |
| 13 | Program closes for no obvious reason | not yet | no clue! Have not seen in a while - maybe solved by (12) |
| 14 | Shift-Right Click | 2009/01/30 | Changes to old Delphi code instead of asm.
Should have converted asm |
| 15 | Shift-Left Click | 2009/05/21 | Centered VFS map, clear reg by and rather than mov 0 Do not use absolute for trivial performance improvement |
| 16 | HLP not supported | thinking | Delphi only
supports HLP, some OSs do not support HLP MicroSoft strikes again |
| 17 | minimize/resize problems | 2009/04/10 | Eliminate timer function on when resizing |
| 18 | Screen Saver | 2009/04/30 | New name: geosvrwin32; must run as administrator under Vista |
| 19 | Test Maps | 2009/03/04 | Forgot to convert 16 bit asm! |
| 20 | HAM CD detect | 2009/07/07 | Sometimes the simpleminded way works fine |
| 21 | Sometimes GeoClock will not close | 2009/08/11 | About Box destroys itself after first viewing |
| 22 | Startup errors on incorrect installation |
2009/08/21 | Form creation order changed on 32 bit |
| 23 | white blocks and lines on some maps and times |
not yet | Having problems reproducing symptoms |
| 24 | Gazetteer puts southern hemisphere cities at North Pole |
2009/11/16 | word autoconverts to 32 signed integer |
| 25 | Options menu produces GPF | 2009/11/16 | tricky address calculation |
1) The 64 bit version of Win7 is installed by default. The 64 bit compatible version GeoClock is still being tested, and the current (8.4d) version of GeoClock will not even load under a 64 bit OS.
2) Win 7 (like Vista) does not by default include the winhlp32 engine GeoClock (and many other programs) require. You can download it from microsoft, but they prohibit us from making it available.
3) Except for these problems, the limited testing by experienced users has been positive.
The registration number is printed on the program (#1) diskette, and on the cardboard sleve for the CD. If you have a registered windows version running, click Help, then About, then Info, and the registration number will appear in the list of data in the window.
For newer versions, you should have a GEOCLOCK.KEY file (between 8 and 512 bytes). If you email this to us, we can determine the registration number. Similarly, older versions will have a REGISTER.EXE file (about 3000 bytes) from which we can determine the registration number.
Finally, we can usually determine the registration number from the name and address you used when you first ordered GeoClock.
The clock sync problem is also an NTDVM bug - the windows clock is not synced with the hardware
clock when it returns from a DOS box, a suspend, or a hibernate.
We now have a possible solution to these problems. Download
GEO84D.ZIP
and see if it solves the problem for you. Please report your findings.
Both versions require downloading and running an install program, and entering a registration code sent via e-mail
You can download the your purchased HAM package by following the instructions in the e-mail. It requires downloading and executing one file, retrieving another ZIP file attached to an e-mail, the then unZIPping the file over your installed GeoClock.
If you do not think about it at all, January 1, 2000 seems the obvious date for the first day of the third Millennium. If you think about it just a little, January 1, 2001 seems the right date (since the first AD day of the current BC/AD calendar was January 1, 1 AD). However, a little thinking is often dangerous, and this is one case where it leads to the wrong conclusion.
Until about 1200 years ago, the years were marked by reference to some historical event (5 years after the flood, 2 years after the new king, etc). A monk about 1500 years ago first advocated numbering the years from the birth of Jesus, and this was adopted several hundred years later. Since new years were marked at the beginning of spring, the first date in this new calendar was at the spring equinox (about March 21, 1 AD. In 1582 AD, 10 days were dropped from the calendar (due to errors between the calendar and the sun's apparent position), and New Years Day was changed to January 1. All the years before 1582, including BC, were renumbered so that January 1 was the first day of the year. (The "April Fools" were the people who still celebrated New Years Day on April 1, since the spring equinox had precessed to about April 1 by then.)
It is now well documented that Jesus was not born in 1 AD. There are good cases made for many different years for Jesus's birth, all of which are between 8 BC and 2 BC.
So why should January 1, 1 AD be celebrated? It was: defined about 525 years after the fact; changed about 1582 years after the fact; 3 months earlier than the original first day of 1 AD; evidently a day like any other day; not the birth year of Jesus. Is this really something whose 2000th anniversary ought to have a world wide celebration? NOT!
Since there is no reasonable start date for marking the millennia (or centuries, for that matter), the only rational choice is just to celebrate the zeros. This has been called the odometer method. Regardless of how many miles were on the odometer when you got the car, you celebrate the zeros as they roll by.
The beginning of the second millennium was feared (in the Christian world) because it seemed to be a likely time for the second coming of Christ (1000 years after what? - birth, death, resurrection, ascendance). The beginning of the third millennium is feared for a much more concrete reason (Y2K computer problems) and also on a very specific date (Jan 1, 2000).
I am going to celebrate the new millennium on the evening of December 31, 1999. I am going to celebrate at home, because I am not sure about any software except GeoClock!
"63.251.171.164 blocked by blacklist.mail.ops.worldnet.att.net. 550 - Blocked for Abuse"
Attempts to get this fixed
has resulted in lots of finger pointing between ATT and MyDomain,
and in the meantime I (and many others) am caught in the middle.
Eventually, I will change to a new ISP. In the meantime, I have
rerouted
joe@geoclock.com to a non-AT&T address, and
geoclock@att.net
continues to work (provided your ISP is not on ATT's blacklist).
