FreeLists / openbeosstorage / [openbeosstorage] Re: More stuff to implement [was: Re: latest update]

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

On 2002-04-29 at 13:46:27 [-0700], openbeosstorage@xxxxxxxxxxxxx wrote:
> I'm afraid there are some other things that we will have to implement:
> * class BResourceStrings

Yep, missed that one too... :-)

> * functions declared in Alias.h:
> 
>   - resolve_link(): Certainly traverses symbolic links.
>     I guess, to implement it some code from BEntry::set() can be moved.
>     But I'm unsure about the boolean `block' argument. Any ideas?

A non-blocking/blocking flag doesn't really make much sense, but I can't 
come up with anything else off the top of my head. We'll have to play around 
with them, I suppose.

>   - read/write_alias(): Also have a `block' parameter. But I don't even
>     know what these function are for at all. Something about symbolic
>     links?

Yeah, they look like symlink functions. I'm not sure what use they serve, 
though.

We'll also have to implement the Node Monitor functions in NodeMonitor.h.

> PS: I crawled a bit in the resources of some applications and I'm afraid,
> that the whole thing is a bit weird... at least not as straight forward as
> I thought it would turn out to be. There seems to be a bunch of rubbish
> at the beginning of the resources section. The count of the resources and
> the offsets and sizes of the resources' data can be found in there, but I
> have no clue about the stuff around these. The remainder of the file is
> quite straight forward again: the resources' data without padding followed
> by a table with the type, ID and name of each resource.

Interesting. Do you know if this is executable-type specific (i.e. ELF vs. 
PE, etc etc)?
 
> I will write a little command line tool to play around with some test
> data. Hopefully I can figure out how everything works.

Good luck. :-)

-Tyler