Writing a system Extension

[denodster]

I'm an experience programmer on modern hardware, and I thought I would try my hand at creating some classic mac os software. I purchased volumes 1-6 of Inside Macintosh on Amazon and I've been familiarizing myself with the basic ideas.

Heres my current goal. I've got a few macs that will run without a clock battery, and I would like to leave them without a battery. I store my macs for long periods of time and I dont want to install a battery just to take it back out again when I put the mac away.

SOOO, I want to create an extension that sets the time if the current time is before 2016. and I want it to pop up a dialog on startup. I think this is possible because Appleshare will pop up a dialog on startup if appletalk is turned off.

So far, I've managed to write a program that opens a dialog and sets the system clock.

When I go to convert this to an extension, It opens a dialog, however it also causes a bus error and crashes the machine. 

My understanding is that a bus error has to do with memory bounds.

Are there special rules about running code on startup? do I need to do something to increase the available memory? Does anyone on here have experience doing this?

 

[techknight]

Network time extension does a very similar thing...

 

[jamie marchant]

I don't know anything about programming extensions but would it be possible to fix the Y2K bug?  

 

[denodster]

Network time extension does a very similar thing...

yeah? where can I get it? does it work with System 6?

Edit: I still want to make mine work, as I'm a determined programmer.

 

[Gryphel]

There is some documentation about "Writing a System Extension" in Chapter 9 ("Start Manager") of "Inside Macintosh: Operating System Utilities", which is available online. (I provide a link on my Apple Developer Documentation page.

It says that a "system extension does not enjoy the full status of an application" and "it must refrain from calling the InitFonts, InitWindows, InitDialogs, InitMenus and TEInit procedures, as well as other QuickDraw, Window Manager, Dialog Manager, and Font Manager routines."

I guess it is demonstrated that it is actually possible put up a dialog, but it is an unapproved hack. You could try disassembling an extension that does it to see how it is done.

 

[CC_333]

Perhaps it would be better to implement this as a Control Panel of some sort?

I know next to nothing about developing these things on the classic Mac OS, but don't CDEVs have slightly more leeway with regard to displaying dialogs at startup?

c

 

[NJRoadfan]

If you want a configuration interface, you would implement your tool as a CDEV (pre-System 7 term for what became a Control Panel). System Extensions were called INITs pre-System 7.

 

[denodster]

There is some documentation about "Writing a System Extension" in Chapter 9 ("Start Manager") of "Inside Macintosh: Operating System Utilities", which is available online. (I provide a link on my Apple Developer Documentation page.

I'll check this out, I have a copy of  Inside Macintosh volumes 1-6 but I don't have the Operating System Utilities Book, thanks for the link.

I think the next thing I'll try is changing the resource from a dialog to an alert, since appleshare appears to be displaying an alert. I'll see if I get the same issue with an alert.

 

[denodster]

this did it:

https://developer.apple.com/legacy/library/documentation/mac/OSUtilities/OSUtilities-192.html#MARKER-9-66

I needed to lock the INIT resource inside my extension, after doing so it stopped crashing.

 

[denodster]

I don't know anything about programming extensions but would it be possible to fix the Y2K bug?  

aren't all macs y2k compliant? i thought we were good until 2040 or something.

 

[jamie marchant]

Mac OS X should be but I don't think Classic is not. A workaround most people use it to set the date to four digits this works with most programs. At most all you end up with is files coming up in the wrong order. 

 

[rsolberg]

With the exception of the Mac XL, (essentially a rebadged Lisa 2) all Macs are Y2K compliant at a hardware level. The RTC (real time clock) on 68k Macs goes to 2040. I am not aware of any System/Mac OS issues with January 1, 2000. In versions before Mac OS 9, the date/time control panel will not allow dates to be manually entered beyond Dec 31,2019. The clock will roll over on its own, however.

 

[jamie marchant]

Hmm I am probally thinking of some other old OS. 

 

[CC_333]

What do we do after 2040?

Can an extension be made, or patch created, that fixes that problem (at least cosmetically)?

c

 

[denodster]

After pouring over the Inside Macintosh reference, it appears that the time is represented by a 32 bit unsigned long int inside the clock chip. It represents the number of seconds since midnight, January 1st 1904 (Why they chose 1904 is beyond me)

The Date/Time controlpanel that ships with 7.6 however rolls over at 2020. This appears to be due to the fact that the control panel itself is based on two digit year between 1920 and 2020. It would be fairly easy to devise an alternate control panel that sets the Date/Time and allows the user to enter any year between 1904 and 2040. This would keep us going for another 20 years. And I think I'm going to go ahead and do this with the code I've already devised.

As for beyond 2040... thats a lot trickier. Maybe extension could be written to patch the system's Date/time functions on startup, but we are stuck with a 32 bit unsigned long int inside the internal clock chip. Maybe we could move it's represented value forward by 56 years, but I think this would mess up all of the dates set by the system prior to the extension installation. Maybe a companion program could be written to in turn bump back file timestamps by 56 years so that they remain accurate. This all depends on how the timestamps are stored, if they are stored as some sort of string literal then this might be a problem at all. Does anyone know anything about how system timestamps are stored for individual files?

 

[Floofies]

You have piqued my interest...

If you could patch the Finder to use the UNIX Epoch instead of Apple's home-brewed scheme, that could fix the problem for awhile. It uses January 1 1970 as it's start date instead of 1904, so you would be moving your start date forward by 65 years instead of 56. Or, if you want to be more efficient, you could change the start date to January 1 2016, which would give you a lot more headroom.

While I don't know enough C/Pascal to write any code (for now), I'm going to start researching this. While storing the time-stamps for files may be a property of HFS, the resource manager also makes sense, and may offer some clues.

EDIT: That was fast. Looks like it is stored as a property of the filesystem. Here's a note about HFS+ that may be of interest:

HFS Plus Dates

HFS Plus stores dates in several data structures, including the volume header and catalog records. These dates are stored in unsigned 32-bit integers (UInt32) containing the number of seconds since midnight, January 1, 1904, GMT. This is slightly different from HFS, where the value represents local time.

The date values do not account for leap seconds. They do include a leap day in every year that is evenly divisible by four. This is sufficient given that the range of representable dates does not contain 1900 or 2100, neither of which have leap days.

The implementation is responsible for converting these times to the format expected by client software. For example, the Mac OS File Manager passes dates in local time; the Mac OS HFS Plus implementation converts dates between local time and GMT as appropriate.

http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html
Search that page for Catalog Folder Records and Catalog File Records, for information about how this value is stored per-file.

 

[denodster]

Since my last post I've also put some thought into it, I hate the idea of screwing up the timestamps on everything so I was actually leaning toward reusing some of the dates prior to 1984 since it's impossible for any timestamps to actually occur before the mac itself.

The Gregorian Calendar repeats itself every 28 years, so it might be easiest to simply set the clock back to the earliest compatible calendar year prior to 1984, and then hack the display routines to add however many years to the system year to make it display the current year whenever it encounters a date that occurs before 1984.

Depending on if it's possible to override system routines with an extension, I believe the routines in question would be DateToSeconds() and SecondsToDate()

 

[Scott Squires]

Attemting to change the interpretation of timestamps is going to be an extremely painful exercise. You can patch the system software, but then there will be piles of applications that decide to handle dates and times themselves. Either fully or partially and in all combinations. It will be a complete disaster.
 

If you could patch the Finder to use the UNIX Epoch instead of Apple's home-brewed scheme, that could fix the problem for awhile.

The idea that the Finder is the only application that uses timestamps... you realize how rediculous this is, right?

 

[denodster]

there will be piles of applications that decide to handle dates and times themselves.

I'm sure that there will be some, however the amount of effort that is required to actually write a calendar routine with no bugs in it when apple supplied a perfectly good one in the macintosh toolbox on day one makes me wonder if there were really that many people who felt the need to reinvent that particular wheel.

Choosing to repurpose a block of compatible dates from before 1984 would allow the apps that handle their own calendar to still have a correct month, day, and day of the week, while things that don't reinvent the wheel would display the correct year.