[deleted stuff about "cd .."]
Quote:>| Should one only supply full pathnames to the file selector,
>| or should the described behaviour be considered a bug?
>I think this is a case of "Doc, it hurts when I do this..." As Allan
>has said, if the file selector misbehaves when you pass it a relative
>filename, don't pass relative filenames to the file selector. It
>bothers me when I see programs doing this, because what does "." mean
>when a program brings up a file selector? For all I know, the program
Ken, "." is Atari's terminology, not mine. I didn't make it
up. Actually Atari didn't either, but according to your literature
you support it. If you're going to support something, then do so.
This seems to be something I keep saying year after year to many
companies. If at all possible, do what you say you are going to do.
Call it "integrity", call it "dedication", call it "honour", I don't
care. But if you say you're going to do something, then do it.
Otherwise, don't say you're going to do it.
As for what "." means, it means what it says. :-) Go look it
up in an MS-DOS manual. That's the system you people seem to be
emulating. Or look it up in a Unix manual. I'd prefer that you got
past this MS-DOS silliness anyway. Or better still, look it up in
an OS-9 manual. I like OS-9. :-)
Quote:>could change directories numerous times for its own devious purposes.
>How the heck do I know what its idea of the current directory is?
Well gee Ken, when you start up a program like "ed" in a Unix
system, how do you know what the current directory is for that
program?
>Please use fully qualified pathnames in the file selector. I know that
>means you can't go very deep, but that's life on one line of a 40
>column screen.
>|Wouldn't this be an idea for a dc week utility. A TSR that parses all pathnames
>|before calling the system routine. So these commercial applications will not
>|cause problems to anyone.
>I'd like to echo Allan's sentiments on this one, too... fixing "bugs"
>for no other reason than to allow buggy programs to run is A Bad Idea.
Overall, I disagree with your reasons, but I come to the same
conclusion. I think the better statement for not creating yet another
patch is because you just end up causing confusion. Look at this
mess we have with GDOS. Some people have it. Some people don't.
Some programs run with it, some don't. Some times I get bombs because
I booted with a German GDOS and either the system or a program can't
find its fonts. And then there's the Pool Patch and the Rainbow TOS
patch -- enough. End users want to run applications, not go hunting
around BBS's for patch programs and then piecing them together.
Quote:>Believe it or not, I may even be more rabid about this issue than Allan.
>I think Atari should do everything in its power to discourage lazy
>programming. Our goal should be able to point at programs available on
>our computers and show how easy they are to use, and how robust they are.
>We shouldn't be required to apologize for the number of auto folder
>programs that you need to patch various bugs/features/whatevers so that
>programs X.PRG, Y.APP and Z.PRG can all coexist peacefully.
Well, again, I have to disagree with something of your reasoning.
Programmers have better things to do than waste their time trying to
get around system bugs. But the real solution is for you guys to
bring out a more bug-free version of TOS in ROM, so we can get rid
of at least the Pool patch and the Rainbow TOS patches.
You know, I've owned over a dozen computers, most on different
systems (unique from each other), and only 2 Atari products (the
Portfolio and the 1040ST) and you know, the *only* 2 computers I
own that *need* system patches are the Portfolio and the ST. That's
not to say that all the others were entirely bug free, but the bugs
in the others (sometimes after revisions) were *so* obscure that
often I could run any major program on them without problems. That
is the kind of performance I expect at this stage -- 5 odd years
after I bought my ST. Yet here I am with this TOS 1.4 ROM set.
Quote:>I think people who write little TSR helper programs shouldn't waste
>their time writing auto folder patches that let DB Master One run
>under TOS 6.7. They should spend their time enhancing the utility
>of TOS machines, so we move forward.
Well that much is what we all want. So the first step should
be to fix the bugs and bring out a set of ROMs that lets me get
on with writing applications. That and a good set of manuals.
But that's Lattice's problem right now. :-)
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura
by