harrow@exodus.dec.com (08/06/86)
A recent article indicated that you could put INIT resources in a file separate from the system file with a particular TYPE signiture, in the same folder, and the system would make use of these INIT resources as if they were in the system file. Now this is a good idea in that it reduces the number of things you have to diddle with each time you upgrade the System (and I'd LOVE to see this for DAs and Fonts, too, for the same reason!), but when I put my various INIT resources in this separate file, removed them from the System, and rebooted, they WERE utilized but (of course) a problem: When I then ran Keeper (to reduce return-to-finder time with my HD20) it quickly returned to the regular Finder, acting (I suspect) as if there wasn't enough memory (which Keeper uses a chuck of). Obviously SOMETHING is different when the INIT resources are external to the System, but this SHOULD not be the case. Any ideas or other experiences? Jeff
werner@ut-ngp.UUCP (Werner Uhrig) (08/07/86)
> Obviously SOMETHING is different when the INIT resources are > external to the System, but this SHOULD not be the case. Any > ideas or other experiences? when I saw the announcement of this new feature, I was very happy also, and tried to make use of it to avoid having to install the Tecmar resources every time .... it didn't work! I don't know why yet. (just to add another experience, for which I suspect the Apple software may not be to blame )
dorner@uiucuxc.CSO.UIUC.EDU (08/11/86)
/* Written 11:26 am Aug 7, 1986 by werner@ut-ngp.UUCP in net.micro.mac */ > >> Obviously SOMETHING is different when the INIT resources are >> external to the System, but this SHOULD not be the case. Any >> ideas or other experiences? > >when I saw the announcement of this new feature, I was very happy also, and >tried to make use of it to avoid having to install the Tecmar resources >every time .... it didn't work! I don't know why yet. I must have missed something--I, too, would really like to use this, but have never heard of it before. Would one of you in the know please post the gory details on how to do this? Thanks, Steve Dorner dorner@uiucuxc.CSO.UIUC.EDU
werner@ut-ngp.UUCP (Werner Uhrig) (08/15/86)
In article <96900032@uiucuxc>, dorner@uiucuxc.CSO.UIUC.EDU writes: > > /* Written 11:26 am Aug 7, 1986 by werner@ut-ngp.UUCP in net.micro.mac */ > > > >> Obviously SOMETHING is different when the INIT resources are > >> external to the System, but this SHOULD not be the case. Any > >> ideas or other experiences? > > > >when I saw the announcement of this new feature, I was very happy also, and > >tried to make use of it to avoid having to install the Tecmar resources > >every time .... it didn't work! I don't know why yet. > > I must have missed something--I, too, would really like to use this, but > have never heard of it before. Would one of you in the know please post > the gory details on how to do this? [ from Technical Note #57: Macintosh Plus Overview in the Dec. 1985 SS, p. 18 ] INIT Mechanism When the system starts up, it looks for files with types INIT and RDEV in the system folder. If it finds any, it looks in those files for resoources of type INIT. If it finds any of those, it executes them. [ from the December 1985S Software Supplement Additions - ERRATA, page 5 ] Installer Script doesn't install DSAT 0 and INIT 31 The current Macintosh Plus installation script "Mac Plus Update" doesn't install resouces DSAT 0 or INIT 31. Thus disks that have been updated with that installation script comes up with "Disassembler Installed" when booting from the HD20 and never laods any file-based INITs. Note: as describe in the enclosed Technical Note 57 under INIT-mechanism, INIT 31 in the System file looks for files of file type INIT at boot time and executes INIT resources in any that it finds, allowing for driver installation at boot time without modification to the System file. An installer script which installs INIT 31 correctly and additional information about this INIT 31 mechanism should be available in the near future. Developers who wish to make use of this INIT 31 mechanism should check for updates on one of the Macintosh developers' bullitin [sic] boards (on services such as CompuServe [MAUG], Delphi, GENIE, BIX, or MacQueue) or write to: Macintosh Technical Support, Apple Computer MS 3-T, 20525 Mariani Av., Cupertino CA 95014, ATTN: INIT 31 Installer. [ from Technical Note #14, release June '86 ] Ever since the first Macintosh System Update, Apple has tried to dissuade developers from writing to the System File. We found that some third-party installation utilities tended to somehow corrupt the System File, making it difficult for us to update our system software there. Since then, we've been working on ways to help developers avoid writing to the System File, such as Font/DA Mover, the Installer and INIT 31. What is INIT 31? In the Macintosh Plus System File, we added a new INIT resource (INIT resources are resources containing code which are loaded and run at boot time by the system startup code). INIT number 31 is one of the last to be executed by the startup code. It looks at all the other files in the System folder for files whose type is "INIT"; when it finds one, it opens it and checks for resources of type INIT. If any exist, it loads and JSR's to them, before closing the resource file and looking for the next one. This allows you to create a single file, containing your driver and INIT, which a user can simply drag into the System folder without having to run an installer. To un-install your software, the user simply drags your software out of the System folder. How to write an INIT 31 INIT resources are resources containing executable code, beginning with the first byte of the resource. An INIT resource is not locked down by the code that loads it, so the "locked" bit in its resource attributes should be set. Also, if it is desired that the INIT's code remain in memory "permanently", the INIT must call DetachResource to detach itself, so that it will not be disposed of when its resource file is closed. [ there were 3 further sections, titled: "How to write an INIT 31", "Boot-time Driver Number Arbitration", and "Allocating "Permanent" Memory" but I'll leave that to someone else to "quote" ---Werner ]
tim@hoptoad.uucp (Tim Maroney) (08/15/86)
As per Steve Dorner's request, I am posting information on INIT resources
outside the system file.
A new INIT resource, INIT 31, was written at Apple some months ago. It
searches for files of type 'INIT' and 'RDEV' at system startup time, and
executes any 'INIT' resources in those files. The files may be anywhere on
the volume under MFS, but must be in the blessed folder under HFS. (I don't
think putting them in the root works, but it might.) That's really about
all there is to it. I have written two different ones for projects at
Centram, and the initialization for Centram's main project, the file
server/client TOPS, is in another of these external INIT resources. I don't
know what the recently alluded-to problems were, but we never had any
trouble getting ours to execute.
The INIT 31 resource is in the new ROMs, but in the old ROMs the INIT
resource has to be in the system file. There are slight differences between
the two versions; mostly, in the ROM version, the files will be opened in
alphabetical order, but not so in the RAM version.
The INIT resource is assumed to contain 68000 object code; the entry point
is at the first byte of the resource. Naturally, the resource should be
locked and unpurgeable. Return to the operating system is via an RTS. No
parameters are passed to the INIT resource. The OS handles disposing of the
resource, so you don't have to.
The environment of an INIT resource is a little strange, but not very.
Avoid the Window, Dialog and Control managers; if you need them, simulate
them in QuickDraw (which isn't all that hard). Obviously, you shouldn't do
application-specific things like messing with the segment loader or the
scrap. There are also weirdnesses you won't expect. For instance, I was
doing some graphics in an INIT resource and for boring reasons I wanted to
avoid having to go to the disk to get a font in the middle of them. So I
called SetFontLock. This caused a fun explosion on the Hyperdrive, because
it used a startup screen and so there was no "last font used"! So it pays
to be on the conservative side, and to test your resource in a variety of
environments before selling it. (If you give it away free, let the receiver
beware can be your motto...)
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)
Give me food, or give me slack (or kill me).marchesi@cernvax.UUCP (marchesi) (08/15/86)
In article <96900032@uiucuxc> dorner@uiucuxc.UUCP writes: > >I must have missed something--I, too, would really like to use this, but >have never heard of it before. Would one of you in the know please post >the gory details on how to do this? > >Thanks, > >Steve Dorner >dorner@uiucuxc.CSO.UIUC.EDU Summary from Macintosh Tech Note #14: 'The INIT 31 Mechanism' In the System files version >= 3.0 there is an INIT resource with ID 31 which during startup looks at all files in the System Folder for files of type 'INIT'; when it finds one, it looks inside them for resources of type 'INIT' - if there are any, they are loaded and 'JSR'ed to before the file is closed and the next one is looked for. INIT resources contain executable code, beginning with the first byte of the resource; their 'locked' bit in their resource attibutes should be set, and if the code should remain in memory permanently, the INIT must call _DetachResource (and it should be allocated on the system heap...) - also, if the 'permanent' space needed is bigger than 1K, you should consider allocating it on the top of the memory, subtracting the value you need from BufPtr ($10C) and moving your code above this new BufPtr value. Warning: space allocated in this way cannot be moved, enlarged or deallocated; since other INITs may use this same technique, you cannot rely on BufPtr always pointing to 'your' space; finally, the secondary screen and sound buffers may not be used if this approach is taken. (there is some additional info regarding boot-time driver number arbitration) hope it helps ciao Paolo ---------------------------------------------------------------------------- Paolo Petta p-mail: DD Division CERN CH-1211 Geneva 23 Switzerland e-mail: ...{seismo,philabs,decvax,...}!mcvax!cernvax!marchesi