Hawaii MULTI 1.36M time stamp fix

For all the others out there suffering over MULTI 1.36-M versions, here's a fix I found. The server apparently checks time stamps on files to confirm correctness. You can confirm this by looking error.log in your NASCAR directory. You should see a number of lines such as the following: FTR DELTA DATE 31d878e2 31d86ad2 The numbers are hex values of timestamps, actual and expected, for a number of files. The following list is the expected value and translation for each file: MULTI.EXE 0x31d86ad2 =====> 07/01/96 19:18:26 SCHED.HLP 0x31826488 =====> 04/27/96 13:16:40 AGREE.TXT 0x3198ee94 =====> 05/14/96 15:35:32 TERM.EXE 0x31d063b2 =====> 06/25/96 17:09:54 DBITERM.EXE 0x31d063b8 =====> 06/25/96 17:10:00 SCHDCLI.EXE 0x31d063b6 =====> 06/25/96 17:09:58 The problem is apparently with Daylight Savings time in one of the executables, either pkunzip, pkzip, term.exe, or dbiterm.exe. MS link libraries have a known bug with daylight savings time on some systems. We've apparently just been bit by that. To workaround the problem, you'll need a program that can change file dates for you. I used touch.com, included with Borland C++ compilers. Use the following command to change the file date on MULTI.EXE, for example: touch -c -t19:18:26 multi.exe I can't send you the program to do this; you can probably find a shareware version someplace. A DOS port of GNU's UNIX utilities might be a good place to start looking, or maybe browse through programmer's utilities on your local shareware site. Good luck. Mike.

Quoted text (10 lines)

>The problem is apparently with Daylight Savings time in one of the >executables, either pkunzip, pkzip, term.exe, or dbiterm.exe. MS >link libraries have a known bug with daylight savings time on some >systems. We've apparently just been bit by that. >To workaround the problem, you'll need a program that can change file >dates for you. I used touch.com, included with Borland C++ compilers. >Use the following command to change the file date on MULTI.EXE, for >example: > touch -c -t19:18:26 multi.exe

Boy, sometimes its hard to do the simplest things, eh? Sorry about that one, we have been using timestamps for the DBITERM version checks all along, and hadn't heard of any problems, but last week was the first time when we tried to enable a check which forces correct file versions before letting you proceed beyond the message of the day. We've disabled this check again until we can figure out what's going wrong with timestamps. I'll might need assistance from a couple of folks who got zapped by this one; if you were one of 'em and you're willing to try a test version later, please send me an email message; use "TIMESTAMP" as subject. The symptom was not being able to go to scheduler last Thursday even after updating to MULTI V1.36M. Thanks... By the way ... I've gotten enough replays with the teleport bug for now, thanks to all who have sent those in ... don't know when I'll find more time to work with them, but with a bit of luck we'll flush something out before NASCAR II release. Charlie Heath Papyrus Design Group