Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!widener!ukma!memstvx1!utkcs2!emory!samsung!cs.utexas.edu!usc!ucsd!nosc!dog.ee.lbl.gov!lbl.gov!jnmoyne From: jnmoyne@lbl.gov (Jean-Noel MOYNE) Newsgroups: comp.sys.amiga.programmer Subject: Re: ResEdit for the Amiga? It's not impossible... and it's desirable Message-ID: <14692@dog.ee.lbl.gov> Date: 26 Jun 91 00:00:50 GMT Distribution: comp.sys.amiga.programmer Organization: Lawrence Berkeley Laboratory Lines: 79 X-Local-Date: Tue, 25 Jun 91 17:00:50 PDT References:<14224@dog.ee.lbl.gov> <1991Jun17.083311.7113@grasp1.univ-lyon1.fr> First, sorry for the delay of my answer, unfortunately I don't have much time for the news... In article dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > The whole problem is that of convenience and extensibility. Unless the > system can be made convenient to the programmer and also be extensible > and easily modifiable, nobody will use it. I've had my go at > resources, both attempts didn't work too well, but here's a new idea: Agreed ! The first step should be to make the programmer's life easier. Having separate resource files for the developpement phase, that would be linked at the end is a very good idea. In fact, it is the way most (all?) of the Mac compilers work now. And this resource file produced by the ResEdit (or whatever you call it) should be directly linkable (no compilation phase involved). > (1) embedded program resources are a great idea but not easily editable. Also true, that's why they should be in a different hunk of the program file, and NOT in the middle of the data section. The ResEdit program can for example read the whole ressource hunck in memory, let the user do all the modifications he wants, and then link it back into the binary file. Of course, that means you'll have to modify the linkers. > (3) solution: Here is where a library comes in. In the program declare > a structural array of editable resources, like this: > > struct Resource { > char *res_Type; /* type of resource (name) */ > union { > void *Ptr; /* pointer to resource */ > long Offset; > } u; > long res_Size; /* size of res. in bytes */ > long res_Flags; /* user, system, whatever */ > } ResAry[] = { > > #define res_Ptr u.Ptr > #define res_Offset u.Offset > > Since resources are edited run time, this array will have been > resolved even if the program is residentable. In this manner, > a single library call can be made to 'edit the resources'. > A resource such as an IntuiText structure may contain a pointer > to a TextAttr structure which itself may or may not be a resource, > depending on whether it is in the Resource array or not. And what about having a library call like 'LoadResources()' at the beginning of the program (startup code?) that would allocate the memory and read the hunk (containing an Array like the one you described), and return a pointer to the array (the file has only offsets, and the LoadResources() convert these in pointers (for example)). If you want to modify one element of the array, then modify it in memory and when you write it back, change the pointers to offsets. But the floor cleaning guy is here ! Damn ! I'm kicked out of my desk ! I can't continue my message. I recognise that I don't know exactly how the AmigaDOS loader works, and that what I say may be quite difficult to implement. But that's the way I see it. I also don't think that having a X-window kind of file allowing you to have different configurations is a great thing: too much files (confusing for normal user) and Amiga is multitask, NOT multi-user.... I really got to go now .. or he's gonna wax my power cord .. JNM (in a hurry!) --- #include JNM: jnmoyne@lbl.gov - The postmaster always pings twice (soon in your mailbox!)