Re: [Alephmodular-devel] CFileDesc landed

[Woody Z. I. <woo...@sb...>]

Yeah Timothy, this is just for backwards-compatibility with existing 
files.  (But still, it has to be handled somehow, in a 
cross-platform-friendly way... which is what the current discussion is 
about.)  Any new AM file formats will be single-forked; I don't think 
there's any disagreement on that.

Woody


On Wednesday, February 12, 2003, at 09:33  PM, Timothy Collett wrote:

>>> Resource fork: look in resource_manager.cpp for the 
>>> resource-fork-parsing routines... see e.g. around line 124, in 
>>> res_file_t::read_map() (which reads a resource-fork-map, not a Map 
>>> file :) ).  (Since my resource forks are in files on my Windows 
>>> machine, and I can play... well this code seems to work.)
>>>
>>> Data fork: look in FileHandler_SDL.cpp, e.g. line 363 
>>> FileSpecifier::Open().
>>
>> That's just cute. Insanely cute :)
>>
>> Hsm. I'm not sure how on earth I would do that with iostreams. I mean, 
>> I know how I might do it, but I honestly have no idea as to whether I 
>> can do it that way, I don't know which kinds of methods I can override 
>> safely. Durn C++.
>
> OK, I know I don't know much about the code, and I know I already 
> griped about resource files, and I know that I'm not entirely sure what 
> you're talking about.  But.  If this is simply for legacy file formats, 
> well and good; we should support those, and you can ignore the rest of 
> my email as meaningless drivel :-).  But if this is for a more future 
> kind of thing, shouldn't we be avoiding resource forks?  Seems to me we 
> should have a fully cross-platform way of making files that doesn't 
> rely on anything that has now completely been dropped by its creator 
> (Apple).
>
> Again, if I'm simply being dense and repetitive, then please ignore me.
>
> Timothy Collett