Hi.I want to use some software in SheepShaver but it appears to have a date expiration because it'll work when I put the host Mac's clock back. Is there any way I can have the time in SheepShaver work independently of the host system? Thanks.

That is not possible through any regular user action. I am not sure it is possible at all, but maybe someone with programmer skills can edit the source code with regard to the date and time synchronization and then build SheepShaver from the edited code.

There's another way (other than compiling a custom SS with a transform function) to change the date only inside the emulator: change it at the system level. Hack the system resource with ResEdit that interprets the start date of the epoch, and you've effectively changed the time. All the OS gets from the chip is the tick count; it's the OS that converts this into something usable. So as long as the software is taking a p-string and not a tick count, you should be able to fake an earlier date and have it work.

Hi all,I know it's a rather old thread, but the issue remains.I have the same issue with some old software that has been abandoned long ago and the software companies are defunct.So there is no way expiring codes could ever be made to work and they can't be updated, so the only way is to set that clock back.Could someone explains a bit more how to do this?Editing something with resedit seems feasible, but what to edit? where?Thanks

- Set up SS in a new user account (with admin privileges)- Log out of your main account and into the new account - turn Time Machine off- in SysPrefs Date & Time uncheck "Set date and time automatically"- manually set the date and time to what you want it to be and run SS (but no other OS X software)- when finished, don't forget to re-check "Set date and time automatically" before logging out

It's cumbersome but will be worth it if that software is of value to you.

Does "Network Time" by Pete Resnick work inside SheepShaver? This might allow you to enforce a time change, or set up a rogue NTP server to feed an older time.

Alternatively, let us know what piece of software is expiring, and I'll see if I can use ResHacker to find a patch for it. One of the old school serials/patch tools might also have a patch for older software. Finding an old version of Serial Box may be a bit difficult however.

I am going to severely necro this thread to state that supporting a different time inside the guest OS would be a very useful feature. Any attempt to change the clock inside the emulated OS will immediately cause the clock to jump back to the host computer's clock. Currently the only way to time travel inside the guest OS is to turn back the clock of the host computer. Not only is this cumbersome, it also makes some processes on the host go haywire, especially anything involving certificates.

I'm now trying to play King's Quest V for the first time in ages and apparently many of these Sierra games have a ‘year 1993 bug’ that causes them to stop working after September 18th of that year. There is a patch available that tries to fix this, but obviously the patch only shifts the problematic year and the game again hangs on the intro screen unless I turn back my computer's clock to before 2010.Also to be able to enter my old registration code for EV Nova, I had to turn back the clock to within a few days after the code was originally issued. There are probably many other examples and if Sheepshaver is still in use in the year 2040, then this feature might become a necessity!

I think the most practical solution would be a config item that applies an offset to the clock of the OS inside SheepShaver. Then I could for instance make a specific VM to play those Sierra games.

The immediate solution to your problem is to run King's Quest V using ScummVM on your main system instead of attempting to run it inside SheepShaver; ScummVM doesn't have the bugs that the original SCI interpreter on Mac OS had.

As for running SheepShaver with a particular date and time, you can do so using RunAsDate from Nirsoft on Windows; I haven't figured out how to do this on OS X or Linux. You can write a script that temporarily changes the date during launch, but as you say, SheepShaver patches in the time from the host, so the time will jump back on first clock sync.

It should theoretically also be possible to add a prefs value so you can set this in prefs when you boot, if someone wants to do that.

[edit] to do that, you'd need to add MAC_EPOCH_YEAR to https://github.com/cebix/macemu/blob/ma ... _items.cpp and update prefs_items.h and then include prefs_items.h in macos_util.cpp. That way, the epoch year will be pulled from the prefs file (defaulting to 1904) instead of from the value currently set in macos_util.cpp.

I didn't know about ScummVM, thanks for pointing that out. It seems it also supports quite a few other games of which I still have the diskettes or CDs, including ‘The Beast Within’ which I never managed to finish because the Mac game engine was rife with bugs. Still, the option to shift the date would be nice so maybe I'll try to make it a configurable option.

This would be difficult, because the shift is done by changing the epoch year, such that 0 starts +/- January 1, 1904. You should be able to set the time into the future by adding a negative value, and you *may* be able to change the day based on using a decimal value (although I haven't tested that and depending on implementation it may just fail), but what you're doing here is changing what year time starts on, not doing an after-the-fact calculation of the time.

For specific date, you'd have better luck temporarily changing the date on the host machine and doing it that way.

This would be difficult, because the shift is done by changing the epoch year, such that 0 starts +/- January 1, 1904. You should be able to set the time into the future by adding a negative value, and you *may* be able to change the day based on using a decimal value (although I haven't tested that and depending on implementation it may just fail), but what you're doing here is changing what year time starts on, not doing an after-the-fact calculation of the time.

Unless I'm missing something here, isn't it only a matter of adding the chosen day offset (negative = the past) to the ‘days’ variable in TimeToMacTime(), possibly with some extra bounds checking?

That could be done, but that would have to either be an entirely new function to tie it together with year, or we'd need to do two settings, adding dayofs as well as yearofs. Possible, but not by modifying the current change.

Nice, but could this be changed to an offset in days? This would allow to more precisely set the date inside the emulator.

I understand that the "yearofs" is useful to avoid bugs of certain older applications.However, I don't know how useful the "dayofs" is.Moreover, it is difficult to set this by mental arithmetic.

Most often when I need to change the date inside the emulator it really needs to be more accurate than within a year. I don't want to change the clock on the host computer because then the risk of inconsistent file dates spreads to the host system which is much worse than inside the emulator only.Since this is an advanced feature anyway, an advanced user won't mind having to use an online date calculator to know the number of days between today and a specific target date. The yearofs can be kept for coarse date offsets, with optional dayofs added on top for finer date changes.

Perhaps you could run SheepShaver inside a VM (VMware, VirtualBox) and change the date of the VM? Without knowing exactly why you need a specific date in SheepShaver (rather than just turning back the clock a certain number of years), it's hard to justify asking kanjitalk755 or anyone else to go to the trouble of changing the code.

Perhaps you could run SheepShaver inside a VM (VMware, VirtualBox) and change the date of the VM? Without knowing exactly why you need a specific date in SheepShaver (rather than just turning back the clock a certain number of years), it's hard to justify asking kanjitalk755 or anyone else to go to the trouble of changing the code.

I have implemented the change myself and created a pull request to merge this into kanjitalk755's branch. It adds another item dayofs that works together with yearofs to allow finer-grained date offsets. The code prevents users from trying to cross the 1904-01-01 boundary with too large an offset.Feel free to reject this if deemed unnecessary. In my own SS build I can now at least, without messing up my main computer's clock,

I only considered subtracting from year, so I reversed the sign of yearofs.However, by introducing dayofs, I felt discomfort with it.Therefore, I have changed the sign of yearofs and dayofs to be natural.