neil@cs.hw.ac.uk (Neil Forsyth) (08/03/88)
Question for Allan Pratt (Atari) but is of general interest (?) so here it is netwide: Will Pexec() in the new ROMs be able to run a program that has its hidden or system bit set in the file attributes? I used to think that hiding ahdi.prg or accessories on our hard drives would stop the students trashing them but Pexec just ignores them. I can understand that when running \auto programs and looking for accessories that sfirst() anf snext() are used with some attribute but I can't seem to get one hidden program to run from Pexec() explicitly. Am I missing something (that's my insurance statement :-) or is this a failing in the old ROMs (that's the possible flamable offence :-). Neil _____________________________________________________________________________ / "I think all right thinking people in this country are sick and tired of \ ! being told that ordinary decent people are fed up in this country with ! ! being sick and tired. I'm certainly not and I'm sick and tired of being ! ! told that I am!" - Monty Python ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh ! ! Scotland ! \_____________________________________________________________________________/
gert@nikhefh.hep.nl (Gert Poletiek) (08/22/88)
To Allan Pratt (are you listening????)
Would you mind telling the net which applications would break when Malloc is
fixed?
If old software breaks when Malloc is fixed, did Atari tell the developers of
those applications that their applications go bezerk on a fixed OS?
Why shouldn't serious developers have their software fixed in a reasonable
amount of time? Or is it that Atari does not want to loose applications of
companies that gave up the ST line long ago??
I believe that the OS should be fixed NOW, without looking back at all the
fancy stuff from companies that have gone out of the ST business. Atari won't
loose any important (read business [that's what atari is aiming for eh?])
applications: serious business applications are served better by providing a
reasonably well performing OS than support for backward comaptibility with an
OS that has so many weak areas.
And PLEASE, do provide documentation with it. Something like 'Inside ST;
telephone book edition' like for the MAC is what is needed. Look what chaos is
created now: lots of books are available for GemDos and all other parts of
the ST's OS. And all have sections in them that tell people that such and
such undocumented feature works this way or that way.
Atari should document it's OS (BTW they promised to have docs 2 years ago;
some outside company would do that; did that company drop the ST line too??)
and boldface print that 'this is what this call is for, and nothing else'.
If Atari does not do that you're bound to end up with ill behaving programs.
(Look for example at the old 'db' debugger of Mark Williams Co.: that didn't
work right on Mega roms because they had to do things that could not be done
with a system call, so they had to use some undocumented features...)
I don't think that developers are to blame for that (e.g, if I want to get
the current settings of the serial port and find that there is no call in the
OS to get me that information, I simply have to dig that out of the
Hardware): if there are OS calls to get something done developers will use
that, not their own work around.
And PLEASE, don't say that the OS is documented in the developers package. Even
the GemDos 'manual' that goes with it contains bugs.
Gert Poletiek
NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics
Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands
UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert
bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet
From september 1st 1988:
Gert Poletiek Dept. of Math. and Computing Science, University of Amsterdam,
Kruislaan 409, NL-1098 SJ Amsterdam, The Netherlands
UUCP: {decvax,cernvax,unido,seismo}!mcvax!uva!gert
bitnet: uva!gert@mcvax.bitnet, U00025@hasara5.bitnetrwa@auvax.UUCP (Ross Alexander) (08/23/88)
In article <525@nikhefh.hep.nl>, gert@nikhefh.hep.nl (Gert Poletiek) writes: [many quite reasonable and verifiably true observations elided] > And PLEASE, don't say that the OS is documented in the developers > package. Even the GemDos 'manual' that goes with it contains bugs. Yes. Atari, please _Excite Me_ once again; build a 68030 box or something. It's hard to maintain momentum on a 68000 based box obsessed with the past. Our institution (a university, charged with moulding the minds of poor sob's (read "students")) doesn't really think your stuff is very interesting anymore. Honestly, any 80[23]86 box is more interesting from an academic viewpoint, especially if aforementioned academic is trying to use the box as a platform for CAI or CAL delivered from a central server; where's the equivalent of Sun's PC-NFS ? Replies of 'well, there\'s Moses\' Promise-LAN' will be met with derision (not my own; the users can manage some things quite handily on their own ;-). And further more, you can't argue that you're working against a huge retroactive force ( an arguement that I*M can use with perfect sincerity). Really, my impression of the installed Atari {520,1040} base is twofold: games fiends, who run the same binaries _over and over_, and who don't know Malloc from SetPhysBase (:-), and very knowledgable hackers to whom a change in memory allocation semantics would be an upgrade, not an obstacle. ps (to Allan Pratt): since I never mentioned an implementation, but only an implementation _strategy_, I feel that your comments re 'But that won\'t work' et c. are a little bit premature; I never specified how it would work, only what the GOALS were. At the same time, I don't have the exhaustive knowledge of TOS innards that you have (painfully ? :-) mastered; maybe there's no way. But believe me, I _did_ spend some time thinking about implementation; p'rhaps we should talk? (Not really; I'll bet that in the long run your hacks will do beautifully). -- Ross Alexander @ Athabasca University
apratt@atari.UUCP (Allan Pratt) (08/24/88)
In article <525@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes: > I believe that the OS should be fixed NOW, without looking back ... I understand that viewpoint, but I cannot go along with it. The core of the philosophy of fixing the OS must be this: When at all possible, don't make happy people/programs unhappy. In light of this, when possible, try to make unhappy people happy. I think we have done this. See my previous article (manifesto) on Malloc. It shows that we (I) put a lot of effort into making Malloc compatible but also much improved. I think we (I) succeeded. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
ggroup3@charon.unm.edu (Seattle Krenn and 2B) (08/24/88)
I've had my ST for 2 years now. I've bought quite a few things for it; expanded the memory from 512 to 1024, added a battery backed clock, a couple programming tools (Personal Pascal and Mark Williams C), and lots of games. I like the idea of fixed ROMs and making them compatible with old software. I am a college student who bought my ST on the Student Discount that Atari offered me back in '86. I'm a computer science major at UNM, where they use 10 1040 ST's in the Assembly language class (Assembly on the M68000). I was thrilled when I found that out - doing most of the programs on my system at home. I'm glad Atari has decided to go with a compatible OS. I'll want it in my machine for sure AND I don't want to have to shell out tons-o-bucks for my broken software. Now that's what I call power without the price. Thankyou Atari! (Better make it soon - I want my Blitter, too, damnit!) ggroup3@charon.unm.edu Seattle! P-P-P-P-Pleeeeeeaazzzzzzzee????? D.Adams10@GEnie - Roger Rabbit