Subject: Re: ADBisms..
To: None <port-mac68k@netbsd.org>
From: Riccardo Mottola <rmottola@spm.it>
List: port-mac68k
Date: 07/29/1999 12:59:00 
eaves a few questions.
>> 
>> Scroll Lock is over F14, and Num Lock over clear; should I even bother
>> with those?
>
>well, i wouldn't really bother, since i'm not too sure what the proper
>sequence is to even get scroll lock or numlock, even under macos.
>

theoretically it should be alt-clear and alt-f14
alt = option

really few mac progframs support this, usually not even numlock is
supported

"ins" (over help) is quite useful too, especially in a text-oriented
interface.

ric
directories to Macs). Oh, well. I think I'm asking this question way > > > too early. > > > > netatalk and CAP do treat the resource forks differently. Paul Hargrove's > > hfsfs will actually export the resource forks differently as per mount > > options. :-) > > You mean, hfsfs exports the resource forks in either netatalk way or > CAP way? To change the subject, one thing that annoys me about netatalk is that it creates an .AppleDouble/file for every single file, whether it has or had a resource fork or not. Does CAP not do that? What is CAP anyway? Is that the AppleServer? > Well, anyway, that'll come in much later. We need a data-fork-only > implementation of hfs first, I guess. If you tell the user to remember the HFS path before booting, then all that's needed is to access the raw partition, walk the directory btree to find the root node, walk the bitmap btree to construct the sector map, then pull the file out. Being able to list directories would be even nicer, but that's as far as it goes.