#DissidentsReqLib
63 messages in this thread
Can anyone tell me where to find the FileIO dissidents (requester.library)
mentioned in rx_intui.library docs. I tried the REQLIB in Lib 11 but it
doesn't work. I don't really want to be downloading lots of experimental
libraries in the hopes of getting the right one so if anyone knows where it
is you could save me a little time and "compuBucs". I'd really appreciate
it. Thanks Tom
Tom,
I believe you will find it as just fileio.lzh. However, if you are
unable to locate it let me know and I'll upload it for you. Do a search on
'dissidents' to try and find it. In any event if you can't let me know.
I've been using it together with rx_intui for a while now. They're nice!
FileIO can even be used from a Basic program! Did you find the
color.library and printspool.library files as well? They are also required
for some of rx_intui functions. Let me know and I can upload those as well.
Steve,
actually the following diatribe belongs in Ramblings and I apologize in
advance to posting it in a reply to you. Actually, this is addressed to
our community at large.
<stepping on soapbox> Hrmmmp. I have a real problem with the
proliferation of custom libraries by varied individuals. The 'dissidents'
are only a sign of the problem at large. Lately, looking at my libs:
directory, I have become convinced that I will need a 20 MB harddisk just
to support the explosion of library files that I have to have to run my
favorite software. Currently, they occupy over 1050K, yes, over a
megabyte.
The situation will grow worse, if I really go whole hog and download all
the lib files I need to have to run my current software. Frankly, I've
gone on strike. With the exception of the kd_freq.library, I will not
download another library until such time as we agree on a standard. I'm
tired of seeing yet another file requester, yet another console handler,
etc ad nausuem.
Rexx has made the situation worse, if anything. Now I have to have 6 or
8 libraries from the 'dissadents' to run their code. The same applies to
other programs. No more. Even with a 600 MB removable drive, I have the
feeling that I could fill it with libraries within the next few years.
It would be nice if we could get our act together and prevent
schizophrenia on our systems. While we are about it, would someone shoot
arp.library?
<stepping off of soapbox>
Brian J. Bartlett
Brian:
I agree with you. I just looked in my libs: directory, and it too was over
a meg! Actually there were more than 70 files in there! There are many of
those files that make sense (like a few that are for specific hardware like
the fc24.library or xspecs.library, mimetics.library) so that others can
program their devices, but the majority of them could/should be combined
into one library. For example, why the need for all those rexx libraries,
there should be ONE arexx.library, or the math libraries, there should be
only one of those. Ideally there'd be several actual math.library files,
and depending on what hardware you had in the system would depend on which
one you'd use (have one for no FPU, one for a 68882 FPU, and one for a
68040's FPU emulation). They'd all be called the same thing, and other
programs could then call the library without the parent program knowing (or
needing to know) what hardware the system had. If the system has better
hardware, the system will run faster, but if not the user could still use
the stuff, only slower.
-Mike Schiller
In sunny Fort Lauderdale
Mike & Brian,
I agree that a proliferation of libraries is bothersome, I'm baffled as
to what you guys have there. I just checked my LIBS: and it's got less
than 700K in there _including_ a 180K library for Chris Gray's Empire (not
your normal sort of thing) and a 'one version old' copy of kd_freq.
Mike, I strongly disagree that 'one library' is an answer. If there
were, I suspect we would hear (justifiably) a lot of flack about needing
all that disk space for the library when it was always in memory.
Vic,
I also have Chris Gray's Empire library sitting in my libs here. I also
have rexxarp.library, mxm.library, pic.library, arp.library, the xpr stuff,
the normal 3 rexx libraries, etc. I glossed over a whole bunch on my
list, but that gives you a feel.
Why couldn't the 3 rexx libs have consolidated their code into one,
presumably smaller, library? Or at least share functions? Near as I can
tell, each is totally independant of the other, but god help you if you try
to do real ARexx coding without all three.
You also have to have the arp.library and the rexxarp.library to run
most of the programs I download these days, if they don't require their own
custom libraries (I've tallied the 'Dissidents' and it comes to at least 4
or 5 libraries).
One library isn't the answer, but how about a common ground here?
Perhaps a team effort to develop a basic system library to handle all those
extensions that our OS needs so dearly. CBM added ARexx to the fold when
it became obvious that it should be in the OS, couldn't the same be done
with all those hacks out there that we cant seem to live without?
Brian J. Bartlett
Brian, I've whipped up a quick program that'll tell what what libraries
another program is trying to open. It'll help you in finding out which
program is using which library. It's in your mailbox. (grin)
Khalid.
Khalid,
that program needs a little work. I'll see if I can figure out which
program is killing it since I know that you take my particular flavor of
machine into account.
Brian J. Bartlett
Brian,
I'm sure you've figured out that all those libraries ARE what people
think the system _needs_. I see any attempt at 'standardization' to fail
miserably.
*Three* standard Rexx libraries? I only have two here… (Under both my
2.0 and my 1.3 setups…) And my LIBS: directory is only 400K, of which
over a quarter is the Cando.library, which I could just as easily do
without… <grin>
As for arp/rexxarp: I hope people are winding down on these two
libraries, as they certainly won't be needed for 2.0, and everyone will
soon convert to 2.0, right? <grin>
My personal opinion is that if developers create a library specific to a
single application, it should be stored in the same place as the
application and NOT in the LIBS: directory. I'm all for much less clutter
there.
–>Steve Bennett
Speaking of Library sizes….
When I get 1.3 and 2.0 on my HD at the same time (RSN, I hope), I'm going
to need to do assign's to LIBS: to the correct OS lib drawer, right? Well,
as noted in this thread, there are a bunch of other non-system specific
stuff I have in LIBS: right now…. am I expected to duplicate these non-OS
specific files in both the 1.3 AND 2.0 libs directories? A real pain and
REAL WASTE OF SPACE, unless there's a solution I'm not aware of? Any
thoughts?
–jp–seattle–
Solution: once you have 2.0 installed, DELETE 1.3
<not neccesarily joking>
Keith
Yeah, but NJY. (Not Just Yet) 🙂
–jp–seattle–
That's what I've done, all right. But then again, I keep 2.0 on a Syquest
44MB removable, so it's not as if it's eating any real extra space… 🙂
OTOH, in all probablility, many of those libraries become even more
redundant under 2.0 (if they even work…) and the programs which use them
really *ought* to be rewritten to use the 2.0 libraries instead. IMHO.
–>Steve Bennett
Like you, I'll keep them around. I wish just saying "the programs which
use them really *ought* to be rewritten to use the 2.0 libraries instead"
was enough to cause it to happen. I wish my pennies were nickles too. 🙂
–jp–seattle–
Steve,
I just solved my problems here as well. The Quantum 210 showed up on my
door step and I've partitioned out the required space assuming worst case
for all my software space requirements. 40 MB for 1.3, 40 MB for 2.0, and
160 MB for everything else (applications and data).
That outta hold things for a while (now looking for a DAT drive 🙂
Brian J. Bartlett
Worst case for all your software space requirements???? There is no such
thing. Since you devoted 160 megs for everything else, expect to need 161
RSN 🙂
–jp–seattle–
I thought about the libs problem between the 2 OS's for awhile also John,
but didn't come up with any viable solution. You might think that you can
get away with it by creating a libs: directory on a shared partition and
using an assign, but what about the system specific libraries. Since some
of them share the same names with their 1.3 counterparts, then you can't
have both the 1.3 and 2.0 version in the same directory. So during the time
I was using 1.3 & 2.0 I had a copy of the non-system specific libraries in
both libs directories. I think you will find that 2.0 will shortly become
your favorite OS, and the 1.3 partition will disappear. I found that most
of the stuff that wouldn't run on 2.0 wasn't worth using anyway.
John (in beautiful downtown Walla Walla) – via Whap!
Thanks John. I was afraid of just that; that the system libs would get in
the way…. but….
did you see the message from Martin Warnett re PathMan, a utility that
comes with WShell? Sounds like the answer.
–jp–seattle–
I've heard about PathMan John, but haven't received my upgrade notice from
Bill yet. I imagine he is holding back on the release of WShell until 2.0
becomes officially available. Remember I was telling you about problems I
was having with 2.03 and the Hard Drive? Well my suspisions were confirmed
today when I found out that someone else is having the same problem with
his new 3000. He has heard that 2.03 does have bugs causing this problem,
and as well with floppy drives. Also causes the mouse pointer to freeze up.
You can move the mouse, and maybe 10 minutes later the pointer will move.
I've seen this before on mine, but it's fairly random. So as I stated in
AmigaUser I'm not very happy about this situation. I certainly hope CBM
does something soon to correct the problem, and if it exists in 2.04 heaven
help them. If not, they had better release it REAL soon, like next week.
John (in beautiful downtown Walla Walla) – via Whap!
John:
One of the programs that comes with WShell is called PathMan, it enables
you to assign multiple directories to system devices such as LIBS:.
I have my 3000 set up so that the operating system is in it's own small
partition, everything else is in another partition. I have two LIBS
directories, 2 FONTS: etc., but PathMan makes them look as one.
I used to have 1.3 on my system, I have since deleted it, but PathMan works
fine under both 1.3 and 2.0, so you can put all your common libraries in
one LIBS directory and use PathMan in your startup-sequence to assign LIBS
to the correct operating system directory and your common directory.
Even if you don't like WShell, PathMan is worth the price alone.
-=Martin=-
– via Whap!
THAT'S IT! THAT'S EXACTLY THE UTILITY I WAS LOOKING FOR!
Thank you. I knew I remembered something like that, (I have WShell), but
couldn't remember where. Bill Hawes comes through again.
–jp–seattle–
I agree wholeheartedly Brian! Seems like everyone wants to write their own
library when they distribute software, and the bad part is that a lot of
times the function is already available in either the system libraries or
another popular library. It would be nice if some standards could be
established for libraries, but I'm not too optimistic it will happen.
John
Brian,
Well, you certainly have said a mouth full. However, I can't say
that I disagree with the nub of your complaint. Unfortunately, it seems
that we don't have just one library that provides the wealth of helpful and
needed adjuncts to ARexx. RexxArpLib certainly does virtually all that
rx_intui does, but the latter seems to do it more elegantly from the users
perspective. Perhaps with the advent of most of these helpful items such
as file requesters, list boxes, gadgets, etc. being provided in one library
under 2.0 the need for library proliferation will be lessened. Of course
with such an "open" system as the Amiga programmers seem to feel a need to
make things that are peculiar to their individual brand of doing things. I
don't think that's likely to stop any time soon! I haven 't really tallied
up the disk space allocated for libraries on my system, but it's a lot
judging from the count of files. I'd like to have it all in one or at
least a few. But library makers don't all seem to want to provide what may
be needed by all library users, so one needs different libraries often for
the same job, but because one does what another doesn't. I personally want
libraries with .bmap files and that are written so they may be used in
Basic programs. That's a peculiar need of mine, tho not of most others.
Because I'm not a power programmer, I need libraries that are easy to use
and integrate into my programming with Basic or ARexx. So, is there a
reasonable solution?
Steve,
I wouldn't mind seeing .bmap files at all here. I program with whatever
tool happens to suit what I am trying to accomplish. This week it's an
assembler, last week it was C. I'd love to program basic since it's great
for the quick hack that I'm so fond of, but there isn't much support from
the libraries.
I can't suggest any solution except a strike. I just don't know what to
do.
Brian J. Bartlett
Brian,
Humph! A strike you say? I hope it doesn't take that, although
I'm not sure even that would help matters. Seems like the power hitters
sneer at basic, so they don't even consider us poor basic hackers. I will
say that dissidents at least provided .bmaps for their libraries, other
than the ARexx ones. Oh well, I guess that's a reality we will have to
live with, especially now that CBM won't, apparently, be supporting basic,
unless that rumor proves false. I don't mind ARexx, though. It's about as
friendly as basic for the quick hack, tho it isn't set up for basic type
programming. The libraries like rexxarplib and rx_intui provide intuition
for ARexx, which is more than you can find in basic, and there's a new
company out there starting to market a true native code ARexx compiler. I
put in an order for one a couple of weeks ago and am supposed to get the
beta version until the real version comes out in a couple of months. The
author says that it really speeds up ARexx programs except for large
compound stems and produces true native code. I'm looking forward to
seeing how it works.
Steven, could you supply more info regarding the company that is starting
to market the Arexx compiler? I've tried using ExecRexx from dissidents,
but my 190K of code seems to have a disagreement with it 🙂
Ken Cooper – Vancouver
Ken,
Let me get back to you on the info, I can't seem to lay my hands on
it quickly.
Steven,
I'm VERY interested in a native code ARexx compiler.
Brian J. Bartlett
Brian,
I left a message for Ken Cooper with the address and phone number
for the company. They had an ad in the August Amazing Amiga on p. 27. The
product is still a couple of months away from release, however.
Hi Steven, I called the company and spoke to Mark Downing. Nice fellow. He
was from the IBM world and had rexx experience. Once the Amiga came out he
got the idea to write an interpreter, but heard a rumour that some guy had
already started writing one (Bill Hawes). Mark then decided to work on a
compilier, which now after 5000 hours is just about ready for release.
I could get a beta version for $90 but since I am somewhat of a novice user
of arexx (even though I've written 197k of arexx code for an accounting
program), Mark suggests that I wait for the release version, which should
be ready in about a month. He has beta testers already, but will sell a
beta copy if requested. The release price will be around $150.
An arexx program is turned into assembler, resulting in speed increases of
up to 2.5 times. This program currently does not support the Interpret
function, of which I have only one in my program – at Main:
Bill had long ago suggested that I use Interpret instead of Select, as a
better method to get to my labels, of which I have 219. Main: is now only 7
lines of code, and changing to Select and having 219 When's will be a drag.
He said he would look into my problem 🙂
I mentioned trying the ExecRexx program on Money.rexx and it choking. He
explained at ExecRexx converts your arexx code to a string, which Arexx has
a string length limit of (I believe) 64k. No wonder my 197k died 🙂
A set of manual proofs were delivered last Friday, and contained several
typos in the first 3 pages! All that has to be fixed up (as usual).
That's all for now folks…
Ken Cooper – Vancouver
Steven,
thanks, I kept the message and I'll make it a point to mark the article.
Brian J. Bartlett
Ken,
Sorry, but I couldn't find the ad right away. Here it is:
Dineen Edwards Group 19785 W. Twelve Mile Rd., Ste 305 Southfield, MI
48076-2553 313-352-4288
When I talked with them a few weeks ago the compiler was still in beta
test. The release wasn't expected for a couple of months, so there may not
yet be a product available. I bought a beta version with the agreement
that I could upgrade to the finished product. However, they said the
manuals were being printed and it would be about two weeks until they could
ship the beta version out. It's been about three weeks now and I haven't
yet received anything from them.
Steven, thanks for the info. I'll give them a call. BTW, you mention an ad.
Which magazine did they advertise in?
Ken Cooper – Vancouver
Ken,
It appeared on p. 27 of August Amazing Computing.
Good point, Brian. Same is true of programs that insist on their own
special fonts. My Fonts: directory has dozens of fonts that were required
for some program I was testing for CIS, many times copied there with an
installation script without my even knowing their names, and the directory
is just overflowing with fonts I never have the slightest intention of
using. Just as sure as I erase one, though, something I really do use
refuses to work without the one I erased.
Betty
Betty,
Hehehe — that's why I always test stuff in ram: and manually make the
assigns.
Betty,
I just found that out a couple of nights ago here. I went to look at my
fonts directory and PenPal had _two_ font's menus and that's just my normal
fonts: directory. I have a second just as large.
Every game I like has it's own font, sometime several, ditto
shareware/freely redistributable software. It's sad really. Apple really
laid down the line on the way a Mac would work and it's a straitjacket on
development there. Now I'm asking for the same straitjacket.
<Waiting for the guys in the white coats>
Brian J. Bartlett
If only I knew what program put all those fonts there, I might be able to
get rid of the ones I don't ever use!
Betty
Betty, wasn't there a utility that would allow you to take libraries and
fonts, and put them in several different directories, but the system still
found them? (ie. I'd have 2-3 font directories, and when I listed FONTS: I
would get all of them. – same thing for libraries….) Would at least
make font/library HD management easier.
–jp–seattle–
John,
The easiest way to make Fonts: into lots of directories is to use (ouch!
have forgotten its name – but I can look it up for you later. It was
written by Steven Vermeullen.) a program that lets you keep only the font
definition files in your fonts: directory, and that definitition file
contains the path to the actual font. The definition files (the xxxx.font)
are short, always. The font files themselves are always pretty long. This
is an extremely efficient way to need only one Fonts: directory assigned,
yet have your actual fonts scattered to whatever place you want them. Even
if they are on floppies, this method will prompt you for the floppy when
you need the font. Of course, this only works for the Amiga bit-mapped
fonts. The Postscript fonts don't use xxxx.font files.
I have a vague memory of the program you asked about, but I cannot recall
its name or its author. I'll keep an eye out as I go through the libraries
and see if I spot it.
Betty
Brian,
I must admit that 1 meg of lib files is a lot. I've got about 600k in my
libs: directory. Some of them just shouldn't be there, I agree. But
libraries are a very good thing in general. A case in point would be the
xpr protocol libraries.. I wouldn't mind if I had a dozen of those in my
libs: directory.
The important point is that if a piece of code is only going to be used by
a single program then it shouldn't be in libs:.. the WP files in libs:
bother me every time I do a 'list libs:'.
(scratching head) That's all I got to say right now.. (huge yawn)
Khalid.
Khalid,
bingo (hand that man a prize). Fundamentaly, that's the whole problem.
I'm buried in software that demands it's particular library and not a
single other program I have will use it. Secondly, as Betty pointed out,
we have the same situation with fonts.
Open ended systems are great, if your the programmer, but not as much
fun if your the user. Frankly, I'm scared of what would happen if I weeded
my libraries and fonts directories. I know I have to do it, but I'm going
under protest.
Brian J. Bartlett
Khalid;
Actually though, the wp.libraries should be there. Ignoring that WP Corp
does currently plan on releasing library for 2.0 of course). All of the WP
Corp programs use the same libraries so that they don't have contain
redundant code. Thus, IMHO, wp did do the right thing with libraries.
An Amiga message processed by Whap!,
bill
Bill, I just found out that if you removed your WP lib files from libs: and
stuck them in WP: they will still work, as WP searches for them in WP: and
WP:libs if it can't find them in LIBS:
Khalid.
Khalid;
Now thats interesting. Probably a pretty good idea on their part too.
An Amiga message processed by Whap!,
bill
That is a feature I am greatly in favour of … it certainly makes disk
maintenance very much easier to have all the files relevant to a single
application strand available in the one place … and it requires so very
little from the software author … if not in LIBS:, then check a
designated volume, if not in there check in the current directory, if not
in there then tell the user you can't find them but give them an option to
retry (so that you can nip behind into a CLI and do a quick re-assign :-))
As a very general point, I'd rather have my disk set up the way I want and
not have to do things the way the author does them … that makes for
consistency in a single environment. For those who don't have a clue about
all this stuff, by all means have sensible defaults, of course, but don't
limit the guy with the 100Meg+ HD who has many applications on there and
who may want to keep things rather tidier than some software allows.
A good example of how this has gone badly wrong is the use of S: … this
was supposed to contain only scripts (actually, Sequence files which
contain command sequences for use by EXECUTE) yet my S: directory is now
full of all sorts of data and configuration files which would be far better
of not being there.
Mike (Whapping from the UK)
Mike,
RE: S: — you're totally correct. What (I think) is needed is a system
supported logical device for configuration files and program data files.
Maybe a D: ? Maybe T: was intended for this but since it's almost always
assigned to ram: it would not work well for that purpose.
-sja
Agreed. I'm guilty of using s: (for Access!) for configuration file
default path, mostly because there was no clear direction/suggestion given
for a path to use.
I believe the current direction (from the Amiga Style Guide) is for
programs to create a directory within ENV: (long term storage being in
ENVARC:).
Keith
Leaping to Keith's defense…I seem to remember that in SOME early
documentation that someone from C= suggest that S: was NOT for 'S'cript
files only, it was for 'S'ystem type files and WAS, in fact, the correct
place to store one's 'configuration' files. Odd that system-configuration
has been in DEVS: since day one, isn't it?
T: was always intended for Temporray workspace, therefore one shouldn't
expect anything put there to remain after a reset.
I personally set up and assign a CONFIG: directory into which I can put all
those configuration files, and a DATA: dir for program data stuff.
Unfortunately, there are very few programs which allow one to relocate such
files.
Mike (Whapping from the UK)
Steve, why shouldn't CONFIG files just be put in the programs drawer? I
don't really want them in S: or T: or D:…. I want them in the
applications drawer.
re a programs data files…. I'm a big fan of using ASSIGN to point to
program specific stuff, rather than requiring it to be in fixed locations.
Just so long as everybody doesn't use DATA: or such 🙂
The only problem I see with this is that many installation instructions end
up telling the user:
After you've run the Install program, be sure to add the line
'assign mydata: xxx' to your Startup-Sequence'.
… shoot, for many users you may as well tell them to program in
Assembly, cause they have no idea how to add those lines to their SS.
Maybe 2.0 will help, cause an install program could just put a quick batch
file in WBStartUP that does the required assigns?
–jp–seattle–
John
I think I'd agree with that … but more importantly, the software should
give the user the option of where he puts all that stuff since different
people would clearly prefer to have it in different places.
For instance, let's say you have a word-processor with a configuration file
called config.wp, and your word-processor is in a volume called WP:, then
…
if exists "config.wp" then load "config.wp"
else if exists "WP:" then if exists "WP:config.wp" then load
"WP:config.wp"
else if exists "S:config.wp" then load "S:config.wp"
else if exists "CONFIG:config.wp" then load "CONFIG:config.wp"
else print "cannot find config.wp, using defaults"
That allows everyone to be happy … and is very simple to do, and doesn't
have to confuse anyone.
Although the ENVARC: idea is not a bad one, I would still hope that the
option to save such files in the current directory or master volume would
be retained.
Mike (Whapping from the UK)
Mike,
I think the search path is a good idea. I _think_ that looking in the
'current' directory (the drawer which holds the 'project') first would be a
VERY good idea. There are many programs for which 'configurations' would
be more usefully 'applied' to projects than the tool. I offer as an
example, an editor which MAY have different 'rules' for editing assembler
versus C versus ARexx versus etc. I'm sure you can think of others which
you use.
One problem at this point is that it's difficult to test for the
existance of a 'volume' without bringing up the _dreaded_ "Please insert
volume XXX: in some drive" requestor. If we solve that, I think we can
make everybody happy.
I agree completely. If the config file is in the program's source
directory, then use it, otherwise start searching the system for it – ie.
ENVARC, etc…
Vic makes the point that under 1.3 a program cannot tell what directory it
started from (if CLI started), so that this option may not be as viable as
I'd wanted. I know I use several programs (Imagine, IP, etc) that will
only find their config files if I start the program while IN the programs
directory…. (ie. if I'm in RAM: and I type:
RUN DH0:ANIMS/IMAGINE/IMAGINE
then the program runs, but the config file (which exists in the program
directory) isn't loaded.
Of course one could require an ASSIGN of Imagine, which the system could
use to search for the config, etc…. or one could do a quick batch file
to switch to/from the directory. Not elegant, though.
Anyway, I'd vote with you; allow me to put CONFIG's in the program
directory if possible, and otherwise in some system-generic place.
–jp–seattle–
John,
Well, _I_ have not particular problems with having a HUGE C: directory,
but I know of some people who do. Further, until 2.0 (and I'm not sure how
well it's implemented in 2.0) there was NO way to tell which directory a
program had been executed from. Oh, I see, you said 'drawer', my
mistake…that would work fine for those programs which are executed by
'clicking on the ole icon'. Still leaves the CLI/SHELL user up in the air
tho (no I don't want to get into an RWAR over which UI is better).
Steve,
I think that's what ENV: is intended for – just like the 2.0 software
uses it for Preferences settings. There's the "permanent, non-volatile"
maintained in envarc:, to get around the problem of ram:'s volatility.
…BobR
Steve,
T: was explicitly to be used for TEMPORARY files. Like SPAT and DPAT
use it.
Mike,
Problem is, we were told by Commodore to put them there… (and I think it
_is_ important to have a central location to hold parameter-type files,
although I'd be happy to move them out of S: if an official repository came
along)
Tim.
I can't recall any instructions from C= regarding putting configuration
files in S: … I thought the only "standard" that C= ever establihsed was
that configs went into DEVS: (by their own inclusion of system.config).
Why do you think it important to keep parameter files in one place? I can
actually see no good reason why they should be stored thus … one ends up
with a major hotch-potch of files sat in S: … when I do my periodic
stock-take of the HD it's often difficult to work out which config file is
being used for what.
As has already been suggested, sometimes I want two or three different
set-ups of the same software … and allowing me to keep a config file in
the application directory or a volume makes life very much easier.
It is just _so_ easy for programs to allow configs almost anywhere the user
wants, but still retain the ability for it to reside in S: … which means
all those who it in S: can have it there … but other users who have
different needs can have the file somewhere else.
A major requirement of user-friendly software is its configurability over
and above a sensible default … forcing users to have their configs in S:
has the "I-know-better-than-you-what-you-really-want" syndrome which
afflicts so many programmers these days.
Mike (Whapping from the UK)
Boy I couldn't agree with you more Mike!! I hate it when a program just
puts its 'config', 'data', 'macro', etc files whereever it wants, without
allowing me any choice. My S: isn't so bad, but it does have a file called
'Serial-Number' (?), among others, that I wish were not there.
I'd be able to live with it a little bit better if they would just IDENTIFY
THEMSELVES! Can anyone spell 'F I L E N O T E'???
Give me an ASSIGN, and put all your config stuff there, any day.
–jp–seattle–
Thanks for the support … actually, I just looked in my S: directory and
found five files that have obviously been put there out of my control and I
have no idea by what!
There should be a law against programs generating files call
"Serial-number" 🙂
All program related files should be forced to start with the program name.
Mike (Whapping from the UK)
Now *that* is the correct way to handle application specific libraries.
Thank you Word Perfect!
–>Steve Bennett