stevek@amiglynx.UUCP (Steve K) (06/02/91)
Would it be possible to construct a ResEdit (MAC) type program for the Amiga? If your not familiar with ResEdit (which I doubt) it is a program that lets you edit the aspects of other programs such as colors, icons, window types, window positions, menus, fonts, buttons & fields, etc. in a nice icon driven enviroment. Can this be done on the Amiga, or are Amiga executables not standardized enough to tell one thing from another? -=*> Steve Krulewitz -------------------- UUNET!tronsbox!amiglynx!stevek <*=-
231b3678@fergvax.unl.edu (Phil Dietz) (06/04/91)
In <stevek.4958@amiglynx.UUCP> stevek@amiglynx.UUCP (Steve K) writes: >Would it be possible to construct a ResEdit (MAC) type program for the Amiga? >If your not familiar with ResEdit (which I doubt) it is a program that lets >you edit the aspects of other programs such as colors, icons, window types, >window positions, menus, fonts, buttons & fields, etc. in a nice icon driven >enviroment. Can this be done on the Amiga, or are Amiga executables not >standardized enough to tell one thing from another? >-=*> Steve Krulewitz -------------------- UUNET!tronsbox!amiglynx!stevek <*=- If you didn't know, the MAC resources that ResEdit uses, are simply a header at the start of a program. All ResEdit does is load the header of a file, lets the user change the values, then re-saves. ^^^^^^^^ One side-effect of having these resources at the head of a file is that the program you are editing is being tampered with. If a person changes a value to a bad value, the whole program is ruined (as a Mac's System seems to do often). Being a CS major and a computer nut, you learn that stuff shouldn't be tampered with (either by someone or by the computer as in self-modifying code). Any data that should be configurable by the user should be in an external config file. This method guarentee's a 100% safety for the main executable, while offering configurability..... But can the Amiga have a ResEdit? It could, but the only things it could possibly tamper with would be IFF files (picts, sounds, anims, etc.) Each IFF file has a configurable header that players use to show them.....but who needs to tamper with a sound file? Phil Dietz --- I don't like to flame! Phil Dietz You know what? 231b3678@fergvax.unl.edu Newton and Leibniz suck big time! Univ. of Nebraska
fletcher@netcom.COM (F. Sullivan Segal) (06/04/91)
> >>Would it be possible to construct a ResEdit (MAC) type program for the Amiga? >>If your not familiar with ResEdit (which I doubt) it is a program that lets >>you edit the aspects of other programs such as colors, icons, window types, >>window positions, menus, fonts, buttons & fields, etc. in a nice icon driven >>enviroment. Can this be done on the Amiga, or are Amiga executables not >>standardized enough to tell one thing from another? > >If you didn't know, the MAC resources that ResEdit uses, are simply a >header at the start of a program. All ResEdit does is load the >header of a file, lets the user change the values, then re-saves. > ^^^^^^^^ > >One side-effect of having these resources at the head of a file is that >the program you are editing is being tampered with. If a person changes >a value to a bad value, the whole program is ruined (as a Mac's System >seems to do often). For editing the executable get a program like NewZap. There are a variety of tools for working with icons, IFF files, and AmigaDOS hunks. If you are interested in changing the loading order of the hunks in an executable, there are some hunk editors available in PD. Most programs will allow you to set their colors, or will use the WorkBench color set. For any programs which are recalcitrant, you can try looking for the NewScreen structure in the executable and modifying it. For windows you can either look for the NewWindow structure, or use one of the window moving/resizing programs like 'wsize', 'wlist' and 'wmove'. Note that these programs are incompatible with the data caches on 68030's. > >Being a CS major and a computer nut, you learn that stuff shouldn't be >tampered with (either by someone or by the computer as in self-modifying >code). Any data that should be configurable by the user should be in an >external config file. This method guarentee's a 100% safety for the >main executable, while offering configurability..... > A religious issue. Keeping a backup also guarantees that an original executable will remain available. Most programs do store their initialization parameters in a file in "s:" rather than in their own executable however. -- -F. Sullivan Segall _______________________________________________________________ _ /V\ E-Credibility: (n -- ME) The unguaranteed likelyhood that ' the electronic mail you are reading is genuine rather than someone's made up crap. _______________________________________________________________ Mail to: ...sun!portal!cup.portal.com!fletcher or fletcher@cup.portal.com fletcher@netcom.com
gt1619a@prism.gatech.EDU (James is just this guy, you know...) (06/04/91)
In article <stevek.4958@amiglynx.UUCP> stevek@amiglynx.UUCP (Steve K) writes: >Would it be possible to construct a ResEdit (MAC) type program for the Amiga? >If your not familiar with ResEdit (which I doubt) it is a program that lets >you edit the aspects of other programs such as colors, icons, window types, >window positions, menus, fonts, buttons & fields, etc. in a nice icon driven >enviroment. Can this be done on the Amiga, or are Amiga executables not >standardized enough to tell one thing from another? > >-=*> Steve Krulewitz -------------------- UUNET!tronsbox!amiglynx!stevek <*=- It's an entirely different ballgame, since a program can use either information from a library to create or within the program itself. The status of the window screen or gadgets can also be determined by the program and have it generate gadgets on the fly (they don't actually need to be hard coded into the program so that you can handle differentt configurations or graphics modes, etc.). The ways of doing all this on the Amiga are probably too complex to do something like the Mac's ResEdit. ResEdit also does several other things, like installing device drivers to a program, etc. for which there is no need or Amiga equiv- alent. The Amiga's system for handling the information contained within the Mac's resource fork are more flexible and more complex at the same time. It would be rather difficult to write a package that could patch programs in that way, I should think. ------------------------------------------------------------------------- James D. McIninch ------------------------------------------------------------------------- School of Applied Biology Georgia Institute of Technology, Box 31619 Atlanta, Georgia 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt1619a Internet: gt1619a@prism.gatech.edu ************************************************************************** * The goal: to design CAD/CAM software and hardware for the creation * * of living things... * **************************************************************************
farrier@Apple.COM (Cary Farrier) (06/04/91)
In article <231b3678.676013157@fergvax> 231b3678@fergvax.unl.edu (Phil Dietz) writes: >If you didn't know, the MAC resources that ResEdit uses, are simply a >header at the start of a program. All ResEdit does is load the >header of a file, lets the user change the values, then re-saves. > ^^^^^^^^ No, they aren't. The macintosh files are composed of two distinct parts, the data fork and the resource fork. All of the resources (such as window parameters, icons, etc.) are saved in the resource fork as discrete records that are accessed through operating system code in a fashion similar to a database. The program code is also saved as a resource. The resource fork and data fork are actually two physically different files in terms of sdisk information, but are accessed via the same file. ResEdit accesses these resources through the OS, it doesn't just "change a header" at it's own discretion. > >One side-effect of having these resources at the head of a file is that >the program you are editing is being tampered with. If a person changes >a value to a bad value, the whole program is ruined (as a Mac's System >seems to do often). You seem to be under the impression that the file's object code is being tampered with. That is not the case, I suggest you read a copy of Inside Mac volumes 1-3 and get familiar with the concept of resources. I don't intend that to sound like a flame, just a suggestion. Resources are a pretty good idea, and they make programming a heck of alot easier when designing a GUI. -- Cary
m0154@tnc.UUCP (GUY GARNETT) (06/05/91)
On the other hand, it would be very useful to have an Amiga programmer's utility with which you could design menus, gadgets, requestors, and other Intuition objects, play with them on the screen, and write the definitions out to an object file. Then you simply link your code to the "intuition resources" you have created, and away you go. It might even be possible to write it so that the editor could recognise its "resources" in a program, and allow you to edit them without re-linking the program. Wildstar
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/06/91)
In article <stevek.4958@amiglynx.UUCP> stevek@amiglynx.UUCP (Steve K) writes: >Would it be possible to construct a ResEdit (MAC) type program for the Amiga? >If your not familiar with ResEdit (which I doubt) it is a program that lets >you edit the aspects of other programs such as colors, icons, window types, >window positions, menus, fonts, buttons & fields, etc. in a nice icon driven >enviroment. Can this be done on the Amiga, or are Amiga executables not >standardized enough to tell one thing from another? > >-=*> Steve Krulewitz -------------------- UUNET!tronsbox!amiglynx!stevek <*=- Actually, I've been discussing somethine like this with a friend of mine who programs X-Windows. There is a program called PowerWindows which does some of what ResEdit does, except it generates source code. The Amiga doesn't provide both CODE and RESOURCE forks, so a ResEdit program would have to work with external/separate resource files. The Amiga does support a Debug HUNK in the middle of your executable, which is normally used by debuggers. So what I have been thinking is that you sould make a ResEdit type program that works with an external file. The application program would use the resources from the external file during development, and the debug hunk in the application is used for debuggers. When you want to ship the product, the resource file could easily be stored in the Debug HUNK so when you drag the icon for the program, its resources go with it. The "ResEdit" program could then be used to alter the data in the Debug HUNK at a later time... -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/06/91)
In article <53626@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >In article <231b3678.676013157@fergvax> 231b3678@fergvax.unl.edu (Phil Dietz) writes: >>If you didn't know, the MAC resources that ResEdit uses, are simply a >>header at the start of a program. All ResEdit does is load the >>header of a file, lets the user change the values, then re-saves. >> ^^^^^^^^ > >No, they aren't. The macintosh files are composed of two distinct >parts, the data fork and the resource fork. All of the resources >(such as window parameters, icons, etc.) are saved in the resource fork >as discrete records that are accessed through operating system code >in a fashion similar to a database. The program code is also saved >as a resource. The resource fork and data fork are actually two >physically different files in terms of sdisk information, but are >accessed via the same file. > >ResEdit accesses these resources through the OS, it doesn't just >"change a header" at it's own discretion. You are both right. The Mac logically supports two forks to each file, but physically it is ONE file with the information at the front as described. The OS provides a consistent set of routines for manipulating the data at the front of the file. When you add stuff to the resource fork of your system file, the finder tells you that the whole file gets bigger, because it is ONE file. >> >>One side-effect of having these resources at the head of a file is that >>the program you are editing is being tampered with. If a person changes >>a value to a bad value, the whole program is ruined (as a Mac's System >>seems to do often). > >You seem to be under the impression that the >file's object code is being tampered with. That is not the case, I suggest you >read a copy of Inside Mac volumes 1-3 and get familiar with the concept of resources. I don't intend that to sound like a flame, just a suggestion. Resources are a >pretty good idea, and they make >programming a heck of alot easier when designing a GUI. > > -- Cary If you check out Inside Mac yourself, you will find that there are routines for reading Mac files as if it were one big file (which is the way it really is). You can open a file and read bytes sequentially and you get the header block first, followed by the data and resource forks (not necessarily that order). In fact, this is how modem software (like ZTerm) reads a mac file to send it somewhere else. When you call a MS-DOS bbs and upload a Mac file to it, someone else can call up and download it intact to his mac later on. It is because the WHOLE file is intact - data and code forks. But more interesting to me is the benefits of resources. People seem to think that the Amiga's methodolgy for handling the GUI is unique to the Amiga. Well, the only thing that makes the Amiga unique is the fact that it DOESN'T have a ResEdit program or Resource compiler. I'm not familiar with the windowing systems under Unix, but I do know that GEM, the MAC, and WINDOWS all support the ability to define data structures for NewWindow (similar to amiga) and call OpenWindow or to put the data structure into a resource and call GetOpenWindow. I agree that a ResEdit application would be nice and Resources would be a great thing to add to the OS. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) (06/07/91)
In article <stevek.4958@amiglynx.UUCP> stevek@amiglynx.UUCP (Steve K) writes: >Would it be possible to construct a ResEdit (MAC) type program for the Amiga? [...] Then, In article <mykes.3174@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >Actually, I've been discussing somethine like this with a friend of >mine who programs X-Windows.... [...] >So what I have been thinking is that you sould make a ResEdit type program that >works with an external file. The application program would use the resources Let's not. I have recently been forced to suffer through Motif development, and find this entire descussion extremely nauseating. Motif currently supports two highly involved and painfully slow methods to make alterations to programs without changing the executable. The first is the resource file. Each X toolkit program reads up to a half dozen different text files containing references to UI objects' (windows, buttons, sliders, etc.) properties (color, size, position, text strings, etc.) This means that attempting to execute a program is *slow*. Any attribute of any UI object could be set by C code or in a resource file. This means that there is an awful lot of code executing that is unnecessary, very seldom makes its presence felt, but chews up gobs of MIPS. Then there is the UIL file. UIL (User Interface Language) was designed to simplify the building of user interfaces by describing the widgets as a single data structure, rather than building them up, one at a time. Because of the miserable "object-oriented" design of the X intrinsics toolkit, each widget requires a complex tag-based data structure and an extremely awkward function call to create in C. While UIL makes the design of windows and buttons simpler, a reasonably sized UID file (a compiled UIL file) can take over a minute to be loaded by an aplication. The nice thing about the Amiga is that it is lean and mean. The OS takes up very little space compared to anything else with a GUI, and although your average $50,000 20MIPS machine has a much larger number crunching ability than an Amiga 500, it is much less responsive to input. If you want to put up with waiting 60 seconds to load a program's UI, why not switch to one of these other machines? To answer the question of how resource editing could be handled on an Amiga, to start with PowerWindows could use an update. I am not particularly happy with its overemphasis on the menu as the end-all in man-machine interfaces. Secondly, debug information could be used, or some new hunk could be added, that points at and describes the data structures used in creating the UI. There could be a little program that allows the user to go in and modify those values in the actual executable. Yes, you could totally trash the program, but since when has AmigaDOS prevented you from shooting your own foot off? 8^) -- ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/08/91)
In article <2971@public.BTR.COM> eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) writes: >In article <stevek.4958@amiglynx.UUCP> stevek@amiglynx.UUCP (Steve K) writes: >>Would it be possible to construct a ResEdit (MAC) type program for the Amiga? > [...] > >Then, >In article <mykes.3174@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >>Actually, I've been discussing somethine like this with a friend of >>mine who programs X-Windows.... >[...] >>So what I have been thinking is that you sould make a ResEdit type program that >>works with an external file. The application program would use the resources > > Let's not. I have recently been forced to suffer through Motif >development, and find this entire descussion extremely nauseating. Motif >currently supports two highly involved and painfully slow methods to make >alterations to programs without changing the executable. The first is the >resource file. > [ discussion of why X-Windows sux :) deleted ] > To answer the question of how resource editing could be handled >on an Amiga, to start with PowerWindows could use an update. I am not >particularly happy with its overemphasis on the menu as the end-all in >man-machine interfaces. Secondly, debug information could be used, or >some new hunk could be added, that points at and describes the data >structures used in creating the UI. There could be a little program >that allows the user to go in and modify those values in the actual >executable. Yes, you could totally trash the program, but since when >has AmigaDOS prevented you from shooting your own foot off? 8^) > The only reason I suggest an external file is for development purposes only. Compilers and assemblers generate Debug hunks which will wipe out what your ResEdit program would put there each time you compile/assemble. When you SHIP the program, you would delete the compiler debug hunk and move the resource file into the debug hunk... There is NO way I'd want to have to copy lots of resource files, or even just one resource file, anytime I want to move the application to a different location. You describe exactly what I did before. By the way, it should be possible to add similar resource/debug hunks to .library files, too, thus making public access Resource possible. > >-- >========================================================================= >Eduardo Horvath eeh@btr.com > ..!{decwrl,mips,fernwood}!btr!eeh > "Trust me, I am cognizant of what I am doing." - Hammeroid -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
gt1619a@prism.gatech.EDU (James is just this guy, you know...) (06/09/91)
If you wanted to write a program for the Amiga that had something akin to the Macs resource fork it would have to be a second file, I think, but it could be done. As a matter of fact, you could put any information you want, including new bits of code in there that have hooks into the old code (which seems like it would be easier in 2.0...). The question is, would it be worth it? After all it could make things as difficult as on the Mac or even worse. And, if folks get carried away with it, there will be all sorts of extraneous data filling up these files and taking up space on my harddisk (as is sometimes the case in a Mac...). - James McIninch Georgia Institute of Technology, School of Applied Biology
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (06/10/91)
In article <1991Jun9.135411.24607@wehi.dn.mu.oz> baxter_a@wehi.dn.mu.oz writes: >In article <30939@hydra.gatech.EDU>, gt1619a@prism.gatech.EDU (James is just this guy, you know...) writes: >> If you wanted to write a program for the Amiga that had something akin to the >> Macs resource fork it would have to be a second file, I think, but it could >> be done. As a matter of fact, you could put any information you want, including >> new bits of code in there that have hooks into the old code (which seems like >> it would be easier in 2.0...). The question is, would it be worth it? After all >> it could make things as difficult as on the Mac or even worse. And, if folks >> get carried away with it, there will be all sorts of extraneous data filling >> up these files and taking up space on my harddisk (as is sometimes the case >> in a Mac...). > >I will be using this sort of system to handle gadget images because we don't >have a resonable overlay manager. The idea is to allocate memory and copy >one set of images if in interlace, and another set if in non-interlace, thus >avoiding filling memory with data that would never get used. The file could >also hold the title screen image, and anything else not worthy of stuffing >up memory the whole time the program runs. > >Regards Alan I always thought it was a waste of RAM to keep NewScreen and NewWindow structures around after they were used... -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
ridder@elvira.enet.dec.com (Hans Ridder) (06/11/91)
In article <30939@hydra.gatech.EDU> gt1619a@prism.gatech.EDU (James is just this guy, you know...) writes: > [is it a good idea to have ResEdit on the Amiga?] >The question is, would it be worth it? After all it could make things >as difficult as on the Mac or even worse. What's difficult? You can change the layout of windows and requesters, you can internationalize without recompiling the code (or without access to the code even.) You can change menus around, etc. Currently none of this can be done in a consistent manner from one application to another on the Amiga. This would make both the developer's and the users' lifes alot nicer, in my book. >And, if folks get carried away with it, there will be all sorts of >extraneous data filling up these files and taking up space on my >harddisk (as is sometimes the case in a Mac...). I don't see where the "extraneous" data comes from. All of these data are currently constants in the executable anyway, we're just talking about moving them into an external file, and adding a bit of housekeeping information. It would be plenty fast and small to make an IFF RSRC form, and define a few new chunks to hold the things we currently "hardcode" into the program (eg. NWIN, NSCR, and MENU chunks for NewWindow, NewScreen, and Menu structures.) >- James McIninch -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
espie@ibis.Stanford.EDU (Marc Espie) (06/11/91)
In article <3341@shodha.enet.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) writes: >In article <30939@hydra.gatech.EDU> gt1619a@prism.gatech.EDU (James is just this guy, you know...) writes: > >> [is it a good idea to have ResEdit on the Amiga?] >>The question is, would it be worth it? After all it could make things >>as difficult as on the Mac or even worse. > >What's difficult? You can change the layout of windows and requesters, >you can internationalize without recompiling the code (or without access >to the code even.) You can change menus around, etc. Currently none of >this can be done in a consistent manner from one application to another >on the Amiga. This would make both the developer's and the users' lifes >alot nicer, in my book. > >>And, if folks get carried away with it, there will be all sorts of >>extraneous data filling up these files and taking up space on my >>harddisk (as is sometimes the case in a Mac...). > >I don't see where the "extraneous" data comes from. All of these data >are currently constants in the executable anyway, we're just talking >about moving them into an external file, and adding a bit of >housekeeping information. > >It would be plenty fast and small to make an IFF RSRC form, and define a >few new chunks to hold the things we currently "hardcode" into the >program (eg. NWIN, NSCR, and MENU chunks for NewWindow, NewScreen, and >Menu structures.) > >>- James McIninch > >-hans >------------------------------------------------------------------------ > Hans-Gabriel Ridder Digital Equipment Corporation > ridder@elvira.enet.dec.com Customer Support Center > ...decwrl!elvira.enet!ridder Colorado Springs, CO Let's put it that way: there are lots of programs out there which DON'T hardcode this kind of information in the code. Taking into account the fact that the system fonts can change their size NOW means that you can't decently hardcode a window size or a menu position. Also, there are different amiga out there. Different display sizes, different monitors with different abilities. Different applications with different needs. The issue of internationalization is another issue. It's perfectly possible to put every message in another text file for easy translation (witness: Lattice C error messages), but translating these messages will change lots of display parameters (what about a gadget text ?) so that hardcoding anything is a BAD idea indeed. Furthermore, get a look at 2.0 code about that. ALL the OpenWindow OpenScreen SetMenuStrip calls have been superseded by much more supple stuff, for which you only need to code the part which is not standard. There is not the amount of support (or lack of) for these things that exist in the MAC OS. This makes for a faster OS, with lots of capabilities that the mac OS lacks, for instance some diversity in looks so that I don't get bored too soon :-). More seriously, the application and its programmers are the only ones who know how to change this kind of stuff. Specifying any kind of standard now means designing a straigthjacket. You won't get people to agree about the way to achieve ``resourceness''. The mac solution is not a solution. It's just another way of life and programming. Guess why I bought an amiga... ---- Marc Espie (espie@flamingo.stanford.edu)
mikeh@touch.touch.com (Mike Haas) (06/12/91)
In article <829@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: > >On the other hand, it would be very useful to have an Amiga >programmer's utility with which you could design menus, gadgets, >requestors, and other Intuition objects, play with them on the screen, >and write the definitions out to an object file. Then you simply link >your code to the "intuition resources" you have created, and away you >go. It might even be possible to write it so that the editor could >recognise its "resources" in a program, and allow you to edit them >without re-linking the program. There was a developers project years ago called the "Gadget Editor", spearheaded by crunch (John Draper). It was really cool for C-programmers...nice intuition interface to create a visual prototype of your window as well as gadgets, intuitexts, etc. You could then save the session, and C-source code would be produced that you could include in your programs. Don't know what ever happened to it...several folks were involved... undoubtedly some that listen to the net... Crunch ?!!?
ravi@TECHUNIX.TECHNION.AC.IL (avi rozen) (06/13/91)
I would like to add an asspect to this discussion. One of the main reasons that the mac is so popular in countries outside of the US, Especialy in countries like Israel and Far east countries is that after you develope a system (fonts and keymaps) and in other cases also enables writing in different directions (right-left, top bottom) translating an application would be just running the ResEdit program and editing the menus, requesters and there you have it, a full application that could be used by everyone. I think that the Idea that a program shouldn't be opened to changes by users could be safe but dissables the distribution of the amiga and the amiga software outside of the US and UK. Commodore ! Please!!! take this point under consideration especialy when you think of the soon due release of os2.0. Avi Rozen .