Looking for the document "Macintosh Worldwide Development: Guide to System Software"

David Cook

David Cook

Tinkerer
Jul 20, 2023
124
167
43
I've been researching the Apple system routines that use LongDateTime as part of a potential solution to the 2040 problem. Because it is first documented in Inside Macintosh Vol VI, I assumed that those routines first appeared in System 7. But, on closer inspection and with some testing, those routines seem to first appear in System 6.0.

There is a big gap between the year that Inside Macintosh Vol V was published (1986) and Vol VI (1991). During that gap, other documents reveal the routines and features added in the meantime.

I am looking for a copy of "Macintosh Worldwide Development: Guide to System Software", which apparently covers the ScriptUtil during the period that LongDateTime was introduced.

I'd appreciate any help locating a copy,

David
 
  • Love
Reactions: JDW
N

NJRoadfan

New Tinkerer
Feb 6, 2022
75
21
8
Looking at period documents, this would sold under APDA #M7047/B. I also found references back in 1989 for an earlier document called "Script Manager Developer's Package" under APDA #M7047. This is likely an earlier revision of the document going by the order number and might also cover LongDateTime.
 
David Cook

David Cook

Tinkerer
Jul 20, 2023
124
167
43
Thank you.

I'm trying to lock down the definitive System release that includes those functions, as well as which structure fields are actually output-only (PM for example). The more I think about it, the more I believe any documentation will be untrustworthy and I just need to reverse engineer the actual functioning.

I wonder if the LongDate code also got converted to PowerPC at some point, and whether it broke anything.
 
David Cook

David Cook

Tinkerer
Jul 20, 2023
124
167
43
Bummer. Why didn't they just use a 64-bit integer at that point. It is slightly understandable when the 128K Mac came out. But, by the time of the Newton, they didn't need to save four bytes.
 
David Cook

David Cook

Tinkerer
Jul 20, 2023
124
167
43
Here is what I’ve learned. Unless noted otherwise, all of this information is based on System 6.0.0 and Inside Macintosh Operating System Utilities. It may have changed in later systems, particularly when PowerPC came along.
  1. LongDate2Secs (aka LongDateToSeconds) and LongSecs2Date (aka LongSecondsToDate) were added in System 6.0. They do not exist in System 4.3 (aka System Software 5.1)
  2. In System 6.0 specifically, those routines are located in the System file, resource ‘INIT’ id 2 (@ 158E and 1754 respectively). That’s anon 51 & 54 in ResEdit; anon 21 & 23 in Resorcerer. This code moved to 'ptch' 4 in System 6.0.2 and 6.0.5. I did not check other systems. Searching for the hex sequence 2F3C00023AB1 usually finds it.
  3. In System 6.0 and some other systems, at the ends of the routines are some old style (?) Macsbug symbols. For example, at offset 18EC, you’ll find the name of LongSecs2Date as the slightly cheeky “LSEX2DAT”. These symbols should help you track down other routines.
  4. Based on some quick tests (running System 8.1), despite implying otherwise in Inside Macintosh, LongDateRec only uses a portion of the fields when calculating LongDate2Secs. Specifically, it uses era, year, month, day, hour, minute, and second. The dayOfWeek, dayOfYear, weekOfYear, and pm are all ignored as inputs to that routine. Those fields do not need to be initialized per List 4-7 on page 4-16. This makes sense, as some of those fields could contradict other fields. For example, List 4-7 initializes dayOfYear=1 when clearly July 4 is not the first day. It also sets PM=1 but the text below says correctly that the returned value is AM. Why not just initialize PM to 0?
  5. Page 4-5 is wrong about some field ranges. dayOfYear can go to 366 and weekOfYear can go to 53. For example, Dec 31, 2020. LongSecs2Date works correctly for that date.
  6. 0xCDFFFFFFFF is the most positive seconds you can pass to LongSecs2Date. It results in January 11, 29941 AD. Inside Macintosh incorrectly claims the maximum year is 29940 AD. Passing 0xCE00000000 results in January 1, 1904 – intentionally. That is, there is code that checks for the limit and clears out the seconds before continuing.
  7. 0xFFFFFF1500000000 is the most negative seconds you can pass to LongSecs2Date. It results in January 3, 30081 BC. Passing the more negative 0xFFFFFF14FFFFFF results in January 1, 1904 – again intentionally.
  8. These limits on the year seem arbitrary; likely rough approximations of the limit on the year field (two bytes signed) which can go to +32767.
  9. As documented, year zero is handled in the Anno Domini system, meaning 1 BC. I have not found documentation as to how 64-bit timestamps in Unix or C handle year zero. My guess is that they follow the astronomical conventions of including 0. But this is really too far down the rabbit hole, as I can’t imagine any vintage software used Apple’s LongDateTime to hold archeological data.
  10. For completeness, the era field is -1 for BC and 0 for AD. Negative years results in an off-by-one result. See 4-26 and 4-27. This is dumb. They could have used negative years for BC and dropped the era field to make LongDateRec backward compatible with DateTimeRec. They also could have followed the naming convention and called it LongDateTimeRec. C'est la vie,
  11. The field, weekOfYear, follows the convention that Sunday is the first day of the week. So, if the first day of the year is Saturday, that is week 1 (a partial week). Then, the next day (Sunday) is week 2 (a full week).
Based on this, it would be possible to standardize on LongDateTime and LongDateRec for a 64-bit time patch. One could copy the routines out of the System file and include them in glue code or an init that patches _ScriptUtil (trap A8B5). I will try back-porting them to System 0.97 and see if they work on a Macintosh 128K. That trap is undefined (hopefully unused) on the 64K ROMs.
 
You must log in or register to reply here.
Top Bottom