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?  

Edited November 8, 2016 by jamie marchant

[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.

Edited November 8, 2016 by denodster

[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.

Edited November 17, 2016 by denodster

[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. 

Edited November 17, 2016 by jamie marchant

[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.

Edited November 19, 2016 by rsolberg

[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.

Edited December 1, 2016 by Floofies

[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()

Edited December 1, 2016 by denodster

[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.

[Scott Squires]

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.

It's the opposite of impossible. It happens all the time. Any database, spreadsheet, accounting ledger, library catalog, etc. will have the need to store timestamps before 1984.

 

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.

I read this sentence several times but still don't understand it. Why would you want all years before your new epoch to appear as the current year?

[jamie marchant]

I don't know that much about the inner workings of the Classic Mac OS but is there no universal place that one could patch the time mechanism. 


Also I think Denodster was talking about the date stamp on files in which case he is correct. 

[denodster]

It's the opposite of impossible. It happens all the time. Any database, spreadsheet, accounting ledger, library catalog, etc. will have the need to store timestamps before 1984.

 

I was talking about file timestamps specifically its impossible for a file created on a mac to have an actual creation date prior to 1984. If I have any scrap of success it's obviously going to be a hack and have downsides, so if someone is using an LC to keep track of an accounting ledger in the year 2040 they can weigh it as an option.

 

I read this sentence several times but still don't understand it. Why would you want all years before your new epoch to appear as the current year?

 

I'm leaning away from moving the epoch, because it would cause a lot of problems with existing data. Instead, the idea is to repurpose dates between 1904 and 1984 to represent 2016 through 2096 since the calendars for said year ranges are the same. obviously this has it's own set of problems but its just an idea at the moment.

Edited December 2, 2016 by denodster

[Scott Squires]

I don't know that much about the inner workings of the Classic Mac OS but is there no universal place that one could patch the time mechanism.

 

In theory, yes there is a single official place one could patch. In practice, programmers have things they want to do that aren't possible or are less efficient with the api functions. Or they think they have a better way. Or they just do it their own way because they can, they have an ego, or they don't know any better. The end result is that applications use the api functions some of the time and do their own thing at other times. It's the resulting mix of using the official (patched) api and their own code that will cause havoc.

 

Also I think Denodster was talking about the date stamp on files in which case he is correct.

 

There isn't separate date and time code for file timestamps. It's all the same code. Well, unless it's combined with custom code as above. Which would not be surprising.

 

I'm leaning away from moving the epoch, because it would cause a lot of problems with existing data. Instead, the idea is to repurpose dates between 1904 and 1984 to represent 2016 through 2096 since the calendars for said year ranges are the same. obviously this has it's own set of problems but its just an idea at the moment.

OK, that's what I was expecting your reasoning to be when I started reading your description, but I couldn't figure out how to align that with what you wrote. This is a much better explanation.

 

I was talking about file timestamps specifically its impossible for a file created on a mac to have an actual creation date prior to 1984. If I have any scrap of success it's obviously going to be a hack and have downsides, so if someone is using an LC to keep track of an accounting ledger in the year 2040 they can weigh it as an option.

 

Yeah. Some people might just want to have filesystem dates correct. Users can make their own choice as long as it is made clear what the change is, that it is mainly intended for filesystem dates, and that it could really confuse application date handling.