[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::atarist

Title:Atari ST, TT, & Falcon
Notice:Please read note 1.0 and its replies before posting!
Moderator:FUNYET::ANDERSON
Created:Mon Apr 04 1988
Last Modified:Tue May 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1433
Total number of notes:10312

176.0. "Saving configuration data" by MILRAT::WALLACE () Thu Jul 28 1988 17:11

    Anyone have any thoughts on saving setup/configuration data in the
    program itself as apposed to having a seperate configuration file.
    
    My first thought is that it was dangerous in the sense that if
    something went wrong (I don't know what) when the user saved the
    configuration data that the executible file could become corupted.
    However I just read an article in DDJ (Feb-1988) that describes
    a technique for storing the data at the end of the file. This seems
    to be safe since you never write in the middle of the file, so the
    worst that can happen is the config info gets screwed up.
    
    In case it's not clear what I'm talking about:
    	In uniterm when you save the phone numbers the numbers are written
    	to a file called UNITERM.TEL.
    
    	Some desk accessories (I can't thing of any names) in order
    	to change the configuration data you must run a seperate program
    	that writes the configuration data to the desk accessory program
    	file.
    
    	What I'm thinking of doing is sort of a combination of the above
    	two methods. When you save configuration data (phone #'s et.al.)
    	the data is written/modified in the file/program you are running.
    
    Has anyone had experience with doing this or just have some thoughts
    on it (I'm mostly woried about the integrety of the executible file)?
    
    	Ray
T.RTitleUserPersonal
Name
DateLines
176.1Jeff knows how to do it.PANGLS::BAILEYThu Jul 28 1988 17:526
    Jeff's Whack does just that.  When you tell it to save the setup,
    it modifys the .PRG (or .ACC).
    
    Superboot does that also.
    
    Steph
176.2Why and How of Whack's non-volitle set-up codePRNSYS::LOMICKAJJeff LomickaFri Jul 29 1988 11:3797
I never had any qualms about storing the data in the executable.  After
all, what could possibly go wrong (click) go wrong (click) go wrong
(click) go wrong (click) go wrong (click) go wrong (click)...

I do this in Whack for the following reasons:

	- It makes finding the data easier.  It's always there when you
	want it, right in your address space.  No complicated user
	instructions about where to put the data file where the program
	can find it.

	- It makes startup time faster, particulary for floppy users,
	since I don't have to do anything special to READ the data.

	- I HATE resource files.  I like having the program all in one
	place.  It's so easy for a resource (or a set-up file) to be
	inaccessible, and that tends to make the program crash or
	otherwise not work.

	- Not that for Whack, I'm assuming that each user will set
	their preferred setup values once, when they receive the
	program, and essentially never bother with it again.  Therefore,
	I'm not worried about anything going wrong.  If a user has two
	or three favorite SET-UP settings for different users, they can
	rename a copy of WHACK.PRG for each one.

Here's how I do it:

1 - I use Mark Williams C.  I can't say if this will work for any other.

2 - I declare the block of data as initialized and "readonly", as follows:

typedef struct setup *SETUP_ID;
readonly struct setup default_setup =
    {
    80, 24,		/* Columns, Rows */
    592, 768,		/* Sixel window size (Width must be a multiple of 16) */
    0, 1,		/* Font, wrap */
    WHITE, BLACK,	/* drawing colors, delete key */
    2, 4,		/* DEL key mode, minimum slider width */
    1, 1,		/* flourish, titlebar */
    2, 4, 1, 0x98, 0, 3,/* SSU, speed, flow, ucr, local, reset */
    256, 256,		/* Input buffer & output buffer sizes */
    50, 1,		/* Long and short times in ms */
    48, 24,		/* Max received, transmitted per iteration */
    600, 400, 20,	/* Cursor on, off, delay times */
    32000L,		/* Private arena */
    2,			/* Desktop fish count */
    'w', 'h', 'a', 'c', 'k', '.', 'p', 'r', 'g', 0
    };

3 - I make sure that this is the FIRST readonly data to be encountered
by the linker.  It's at the beginnning of the first file specified to
the "ld" program.

4 - I use the following routine for either saving new default setup
values in the executable, or for restoring the saved default setup
values from the executable.  Note that I don't have to restore them
unless they have changed and we want the original values back. 
Normally, you just access the structure "default_setup" in the usual
way.  The way this works is that it reads in the image header, which is
a fixed structure defined by GEM, and dereference the pointer to the
initialized data block.  Fseek() to the data block, and do my I/O there.

#include <gemout.h>	 /* Contains struct gemohdr */

int setup_permanant( settings, writecontrol)
SETUP_ID settings;	/* Settings to save */
int writecontrol;	/* TRUE to write, FALSE to read */
    {
    struct gemohdr head;	/* WHACK program header */
    int hand;			/* WHACK.PRG file handle */
    long where;			/* Fseek position in file */

    hand = Fopen( settings->filepath, 2);
    if( hand < 0)
	{ /* Unable to open file */
	char err[ 100];
	sprintf( err, "[3][Failed to open Whack image file|%s][Grumble]",
	    settings->filepath);
	form_alert( 1, err);
	return( hand);
	}
/*
	Read file header
*/
    Fread( hand, (long) sizeof( head), &head);
/*
	Locate first element of readonly data psect, assume it is setup
*/
    where = Fseek( (long) head.g_ssize[ GO_TEXT], hand, 1);
    if( writecontrol) Fwrite( hand, (long) sizeof( *settings), settings);
    else Fread( hand, (long) sizeof( *settings), settings);
    Fclose( hand);
    }