Thread

Figuring Out How a CDEV Resource Works

68kMLA Development 13 posts Oct 11, 2013 to Oct 23, 2013

#1 Fri, 11 Oct 2013 - 22:04 68kMLA

If I wanted to study a CDEV resource inside the resource fork of a CDEV, as shown by ResEdit, what would be the best way to approach it?

My programing background is limited, but I understand the basics (not Basic).

I'm looking to try and figure out how a particular instruction is executed by this CDEV resource.

#2 Fri, 11 Oct 2013 - 22:13 68kMLA

The following resources document control panels:

Inside Macintosh: Operating System Utilities, Chapter 5

Inside Macintosh: Volume VI, Chapter 10

Inside Macintosh: Volume V, Chapter 18

The cdev resource is a code resource that is jumped to by the Finder in System 7, and by the control panel desk accessory in System 6. The the arguments to the cdev are passed in registers.

#3 Fri, 11 Oct 2013 - 22:23 68kMLA

Ugh, this is looking much more ugly than I thought...

Software wise, what environment would be my best choice for starting to make sense out of what is there? With ResEdit, I get the hex dump, but that isn't much of a starting point for me.

#4 Fri, 11 Oct 2013 - 22:30 68kMLA

Grab your favorite 68k disassembler and have at it.

I use macsbug for anything in memory, and fdisasm for everything else. Ye Olde Resorcerer can also disassemble some resources.

#5 Fri, 11 Oct 2013 - 22:34 68kMLA

Sounds like fun. I'll keep plugging away at it. Worst thing I can do is just have to restart.

#6 Tue, 22 Oct 2013 - 19:57 68kMLA

How do emulators work for debugging? If you have to reboot a Mac a bunch of times, doing it on a modern machine would only take a few seconds.

#7 Tue, 22 Oct 2013 - 22:30 68kMLA

Terrible.

BII and SheepShaver don't work with macsbug, the system crashes when triggering a macsbug breakpoint.

MESS can run macsbug, but there's other issues. 1) there's no power button or NMI interface in MESS to break into the debugger. 2) keyboard and mouse inputs in MESS are a bit flakey and unreliable. It makes trying to code/debug/really use the emulator frustrating at best.

#8 Tue, 22 Oct 2013 - 23:27 68kMLA

If the emulator has a built in debugger, it might be a better option.

#9 Wed, 23 Oct 2013 - 01:41 68kMLA

MESS does and the others don't. However, MESS' is setup for debugging MESS and the emulated environment, not for developing code locally. You'll have to enjoy decoding call stacks and debug symbols by hand if you want to use MESS' debugger.

#10 Wed, 23 Oct 2013 - 02:34 68kMLA

I'm actually surprised that Basilisk II lacks a debugger given how mature of an emulator it is. It should be fairly trivial to emulate a native "debug switch" and its NMI though.

#11 Wed, 23 Oct 2013 - 05:36 68kMLA

They take patches, particularly trivial ones.

#12 Wed, 23 Oct 2013 - 05:47 68kMLA

I eventually ended up using Super ResEdit. However, I dumped the project after a few days of staring at the code since it was way over my head. I just bought the software. I guarantee for you guys what was needed would probably have been quite simple, but you only use your powers for good.

#13 Wed, 23 Oct 2013 - 15:56 68kMLA

but you only use your powers for good.

lol :lol:

Sort of off topic, but this is a GREAT book about reverse-engineering software: http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817

Of course it's about PC software, not 25-year-old 68k Mac programs, but the general concepts are the same for reasoning backwards from a disassembly to reconstruct a program's high level behavior.