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

On Mon, 29 Apr 2002, Tyler Dauwalder wrote:

> > * 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.

Before reverse engineering them, we should ask on the main mailing list.
Perhaps someone has used them or has at least I good idea, what they are
intended to do (especially, what the block flag is good for).

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

Argh, I thought, they belong to the kernel, but you're right, they use
BMessenger, BLooper, BHandler and friends.
Fortunately our job should be done with passing the supplied data to the
instance that is responsible for node monitoring. Whatever this might be.
This topic should be worth a chat with the IK and kernel teams.

> > 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 guess not, but it needs some more investigation. Fortunately I've got a
PPC box as well (I hope it still works, I haven't used it for months), so
I will also be able to tackle endianess and PE format problems.

At the moment I believe, that the resources are just added at the end of
an ELF binary, without any modification to the data before (ELF header,
section header table,...), but that needs some verification.

> > 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. :-)

Thanks.

Probably I won't even need to write such a tool, since QuickRes might do.
But what I want to write, when I think I understand the format good
enough, is tool, that examines existing resource files and checks, if they
indeed look as expected. To be safe I will then ask the people on the OBOS
main list to try it on some of their files.

CU, Ingo

Other related posts: