Mac68k Forums

Home


Welcome, Guest
Guest Settings
Help

Mac68k Forums » Help » Software Help

Thread: Early Mac OS dev notes


Reply to this Thread Reply to this Thread Search Forum Search Forum Back to Thread List Back to Thread List

Permlink Replies: 6 - Pages: 1 - Last Post: Sep 13, 2015 3:23 AM Last Post By: integerpoet Threads: [ Previous | Next ]
bbraun


Posts: 493
Registered: 7/25/12
Early Mac OS dev notes
Posted: Nov 24, 2012 5:09 PM
Click to report abuse...   Click to reply to this thread Reply
These are just some notes from trying to get some of my existing System6 & 7 software working on System 3.3 for a 512KE system. These earlier systems lack a bunch of functionality that became standard with the SE and Mac II.

When trying to get newer software working on older systems, having MacsBug installed to catch unimplemented traps is invaluable. I'm using MacsBug 6.1 and it works great. If there's an unimplemented trap, 1) macsbug will be entered and tell you, and 2) the trap number will be in the register list on the left side of the screen. Look for 0xAXXX.

When building code, whether a code resource, device driver, or an application, the compiler will insert glue code for you. CodeWarrior's glue code for all of the above targets will call the trap _StripAddress, which was introduced with the SE/MacII for 24/32bit address handling. It doesn't exist on earlier releases. If you want to stick with CodeWarrior to build code targeting these older systems, you can replace calls to _StripAddress with nops, since the older system is al 24bit all the time. This is a bad idea on newer systems though. The proper way to do this would be to test for the existence of the trap and call it conditionally. But that's an involved patch for glue code. The easiest way to nop them out is to open your project in Resorcerer, and check out your code resources (DRVR, INIT, CODE, etc.). _StripAddress is 0xA055.

THINK C 5's glue code doesn't do this. However, THINK C's device driver glue code is... involved. And broken. When developing device drivers in THINK C, it will always create a DATA resource, which contains the constant data from the DRVR. Instead of using PC relative constant data (strings, etc), it puts it all into a separate resource, and then has glue code that will load the DATA resource for you automatically when your DRVR is entered. Unfortunately, it makes a bunch of assumptions when doing so. On entry into your DRVR, it will inspect your device control entry parameter (passed to all uses of the DRVR), and find your reference number, from which your Unit Table entry can be found, and then assumes your DRVR resource will 1) be in the currently opened resource file, and 2) will have a resource ID matching your unit table entry number, 3) your DATA resource ID will match all of the above. This all bad and makes actually loading and using DRVRs developed in THINK C very difficult. This driver loading code is easy to use and extensively patches the THINK C driver at load time to make sure things actually work. YMMV

However, for applications, THINK C is pretty easy. Although I'm still trying to figure out how to effectively use THINK C with Resedit created resources. It wants to compile resources from the Rez specification language rather than merge in pre-compiled resources generated with something like Resedit. Additionally, when compiling an application, THINK will overwrite the target rather than merge in the compiled resources. So after every build, you'll need to copy & paste in your precompiled resources by hand.
bbraun


Posts: 493
Registered: 7/25/12
Re: Early Mac OS dev notes
Posted: Nov 25, 2012 5:17 PM   in response to: bbraun in response to: bbraun
Click to report abuse...   Click to reply to this thread Reply
Also interesting is the concept of loading INIT files on boot began with the introduction of the Plus & 512KE and System 3.2. It's initially documented in Inside Macintosh Volume IV.
I guess when writing drivers or other system software for earlier releases, it needs to be put into an application that the user runs.
bigmessowires


Posts: 217
Registered: 10/29/13
Re: Early Mac OS dev notes
Posted: Oct 29, 2013 1:24 AM   in response to: bbraun in response to: bbraun
Click to report abuse...   Click to reply to this thread Reply
Can't find a way to quote previous posts...

> When building code, whether a code resource, device driver, or an application, the compiler will insert glue code for you. CodeWarrior's glue code for all of the above targets will call the trap _StripAddress, which was introduced with the SE/MacII for 24/32bit address handling. It doesn't exist on earlier releases.

What version of Codewarrior are you using? Using Codewarrior 6 (I think), I've built simple floppy disk tool applications that run on hardware all the way back to the 64K ROM in the Mac 128K/512K. Offhand I don't recall if there was some kind of project setting necessary to make this work, but I don't think there was.
bbraun


Posts: 493
Registered: 7/25/12
Re: Early Mac OS dev notes
Posted: Oct 29, 2013 12:11 PM   in response to: bigmessowires in response to: bigmessowires
Click to report abuse...   Click to reply to this thread Reply
I believe I'm using Codewarrior 10 Gold. The whole Codewarrior versioning scheme is a bit confusing since they rebooted with the "Pro" line, which I think is where they dropped 68k support. It makes sense that earlier versions had better support for the earlier systems. I idly wonder where the cutoff was.
bigmessowires


Posts: 217
Registered: 10/29/13
Re: Early Mac OS dev notes
Posted: Oct 30, 2013 10:42 AM   in response to: bbraun in response to: bbraun
Click to report abuse...   Click to reply to this thread Reply
Yeah, it's Codewarrior 6.0, and the about box in the IDE says GUI version 4.1, copyright 2000. I think I got it from Macintosh Garden. If you need a copy of the ISO let me know.
yesitspeter

Posts: 1
Registered: 6/28/15
Re: Early Mac OS dev notes
Posted: Jun 28, 2015 12:16 AM   in response to: bbraun in response to: bbraun
Click to report abuse...   Click to reply to this thread Reply
To use ResEdit resources in ThinkC? I just came across this issue myself. I solved it by using the resource manager's OpenResFIle("\p") and UseResFile(). Now I can just keep a .rsrc file next to my app when I'm developing.
integerpoet

Posts: 12
Registered: 9/12/15
Re: Early Mac OS dev notes
Posted: Sep 13, 2015 3:23 AM   in response to: yesitspeter in response to: yesitspeter
Click to report abuse...   Click to reply to this thread Reply
To merge a resource file into your app during build…

If your project is named "Foo.π", then name a peer of the project "Foo.π.rsrc".

Come on! It's blatantly obvious! :-)


Point your RSS reader here for a feed of the latest messages in all forums