Re: [Alephmodular-devel] CFileDesc landed

[Timothy C. <tco...@ha...>]

>> Resource fork: look in resource_manager.cpp for the=20
>> resource-fork-parsing routines... see e.g. around line 124, in=20
>> res_file_t::read_map() (which reads a resource-fork-map, not a Map=20
>> file :) ).  (Since my resource forks are in files on my Windows=20
>> machine, and I can play... well this code seems to work.)
>>
>> Data fork: look in FileHandler_SDL.cpp, e.g. line 363=20
>> FileSpecifier::Open().
>
> That's just cute. Insanely cute :)
>
> Hsm. I'm not sure how on earth I would do that with iostreams. I mean,=20=

> I know how I might do it, but I honestly have no idea as to whether I=20=

> can do it that way, I don't know which kinds of methods I can override=20=

> safely. Durn C++.

OK, I know I don't know much about the code, and I know I already=20
griped about resource files, and I know that I'm not entirely sure what=20=

you're talking about.  But.  If this is simply for legacy file formats,=20=

well and good; we should support those, and you can ignore the rest of=20=

my email as meaningless drivel :-).  But if this is for a more future=20
kind of thing, shouldn't we be avoiding resource forks?  Seems to me we=20=

should have a fully cross-platform way of making files that doesn't=20
rely on anything that has now completely been dropped by its creator=20
(Apple).

Again, if I'm simply being dense and repetitive, then please ignore me.

Timothy Collett

"99 times out of 100, a hero is someone who's hungry enough and cold=20
enough and tired enough not to give a damn.  I don't give a damn!"
=97Hawkeye Pierce, _M*A*S*H_=