GEM program and resource files |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GEM Program and Resource FilesMark Baines takes a beginner's look at files you use every day...A GEM program (a file with the file name extender *.PRG or *.APP) issomething you are all familiar with. It consists of menus, windows and dialogs through which you and the program communicates. The program uses this input to process various instructions which eventually produces some kind of output which may be characters or images on the screen (soft copy), or control signals to disk drives or the printer to produce a letter (hard copy) or maybe noises through the speakers. Low-level languagesThese instructions are supplied by the programmer and processed by theCentral Processing Unit (CPU). These instructions are sequences of bits (such as 10010011) called machine code and control what the processor does, what you see on your screen and how a program behaves. Each type of processor has its own version of machine code. These patterns of bits are very hard for programmers to use directly - they are just series of 1s and 0s. So over the years programmers have developed forms of codes that represent these bit pattern instructions that the computer understands. These representations are called programming languages and use characters, words and numbers more familiar to us. There are many languages and many more variations or dialects of them. Some are not far removed from the patterns of bits themselves using very short character sequences and numbers. These are termed low-level languages and assembly language is the most common example. On the whole, one line of assembly language carries out one machine code instruction. Here is some assembly code for the 68000 processor chip, the kind that controls the ST. clr.l -(sp) move #32, -(sp) trap #1 addq.l #6,sp move.l d0,-(sp) eori.b #1,$484 move #32, -(sp) trap #1 addq.l #6,sp clr -(sp) trap #1 The "trap #1" line, for instance, is a far easier way of remembering this instruction than its machine code bit pattern of 0100111001000001 which the processor itself requires. Getting any one of those 1s or 0s wrong would mean a totally different instruction! High-level languagesEven so, many programmers, including myself, don't find assemblerlanguage easy to understand and remember and need something a little more like English. These languages add extra layers between what you write and the ultimate machine code instructions it generates so that a word or "phrase" usually brings about many machine code instructions. Such languages are termed high-level languages and include C and BASIC. Here is an extract from C which more or less does the same as the assembly code above: int click; unsigned char oldconterm; volatile unsigned char *conterm = 0x484; void *save_ssp; save_ssp = Super(NULL); oldconterm = (*conterm) &~ 0x05; if (click) oldconterm |= 0x01; *conterm = oldconterm; Super(save_ssp); Immediately you will see that it contains some familiar expressions, an "if" statement, brackets and equals signs, for instance. These program languages are written in a text editor and the resulting files are called source code. On their own they are useless. What is required is a means of converting or translating these text files into the machine code instructions that the computer needs so that it can execute the program. There are two types of these translators - interpreters and compilers. Interpreters are programs that enable you to type in programming language instructions and have the computer carry them out one line at a time. No program file is made - your program only exists in the computer's memory at run time and then disappears. The source code only works when run from within the interpreter program. Compilers are more common and take the source code text file and translate it into a file called object code which are the machine code instructions of your source code. This object code is then joined together or linked with other object code files that come with the compiler that contain the machine code instructions for many of the language key words that you may have used in your source code, such as Super(NULL); above. The program that does this is called a Linker and the resulting single file is the program file which can be run from the desktop by double-clicking on it. Resource filesA resource file is a separate file with the *.RSC filename extenderthat contains the objects that form the graphic user interface of GEM programs. These objects consist of the menus, dialog and alert boxes, icons, images and text strings that are drawn and manipulated by the resource file's program. Each GEM program has its own *.RSC file although some programs have the resource data embedded within it rather than a separate disk file. CPXs and most accessories are like this. To look at the contents of these files you need a Resource Construction Set program such as WERCS, Interface, NRCS or ORCS - the latter being shareware and available from all PD/Shareware libraries. These are graphical programs that enable you to draw and paste the required items on the screen to create the forms and other objects of the GEM program interface (apart from the windows which are supplied by the AES part of TOS itself). Before you start to investigate resource files for yourself you must work from copies of the files you intend to explore. It is very easy to load a resource file into, say ORCS, and alter it in some way and accidentally save it in a state that the program file will not recognise. One of the reasons for this is that all the objects in a resource file are strictly ordered and numbered. The program file contains the number of these objects hard coded into it. So, one thing you must never do is to alter this order by sorting, deleting or adding objects. By the way, be careful with ORCS as it does have the nasty habit of sometimes altering the order of objects without your knowledge particularly if you use the Next buttons in the "Edit" dialog. You have been warned! Editing resource filesThere are several reasons for editing resource files, not leasttranslating German text into English. Another is that the patterns, size of borders and other attributes may not be to your liking. For instance, one thing I have done is to redraw the icons at the bottom of the NeoDesk windows (quite tricky), changed border sizes, changed some text from American to English Ok! to OK), made several dialog buttons the default ones, altered patterns, hidden other objects and generally tidied it up (quite easy). It is best that you have some idea of the different terms used for the various objects and states they can exist in (such as "Default" or "Radio") to help you understand what you can and can't do and programmers' books and program documentation may help here. However, if in doubt - leave it alone! More than anything, make sure that your efforts do not in any way add to or subtract from the resource file (except text lengths which can be changed). Items can be edited not added or deleted. If you must remove unwanted objects you can use the "Hidden" attribute so that they become invisible but you mustn't delete them from the file altogether. Another thing I often do is to go through the menus of programs and change the symbol for the [Alternate] key short-cut symbol to my own liking. Some programmers use the Atari character set character 5, others character 7 or the letter "a" or "[Alt]". It is an easy matter to load the resource file into WERCS and edit them. Again, I must stress that the word I keep using is "edit" - not "create". If you edit an object and effectively change its meaning or purpose then the program won't recognise it and act on it. There is no point in changing a menu item short-cut key from ^W to ^U and expect the program to use ^U from there on (although some programmers have catered for this, but this is rare). The key command ^W is coded into the machine code by the programmer, what appears in the resource file is not program code but only a visible reminder to you of what the programmer intended at compile time. You cannot change his intention. The Can's and Can't's box offers a general guide, some of the "Can" list may cause problems, especially the Hidden and Default flags. It's no co-incidence most of the "Cans" are cosmetic changes and most of the "Can'ts" are functional. You certainly won't be able to change the way a program operates, that was determined long ago by the programmer. Finally, any changes you make to resource files should be for personal use only. If you intend to pass copies of an edited resource file to anyone you must obtain permission from the programmer. True public domain programs can be altered and redistributed in any state you wish - that's the meaning of public domain -but true PD programs are few and far between. Most non-commercial software is released as shareware or freeware and the programmer retains copyright - they are not public domain.
Using ORCSLoad ORCS, click on a drive icon and folder until your reach the *.RSCfile icon (look for a dog and the letters RSC).  Drag the icon to the desktop and a window appears with five types of object at the top. These are for creating resource files and must not be used here. The forms that make up the resource file are shown before the horizontal line. Double-click on one. As you move the mouse a cursor shows the bottom right corner of the object rectangle.
Other attributes can also be changed to suit. Here, a button in a
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[Home]](pics/images/i_info.gif){kind=small} |
![[Info]](pics/images/i_home.gif){kind=small} |
![[Back]](pics/images/i_prev.gif){kind=small} |
![[Next]](pics/images/i_next.gif){kind=small} |