HDTenEightyP/NetNews huggingface dataset:
From: davids@cats.ucsc.edu (Dave Schreiber)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: physical memory protection with MMU
Date: 16 Nov 1992 03:37:53 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: as215-ws-17.ucsc.edu


In article <paulk.27ok@terapin.com> paulk@terapin.com (Paul Kienitz) writes:
[Somewhere, I wrote:]
>> The real problem with memory protection on the Amiga is that it is
>> possible for one task to share its memory with another without
>> explicitly telling the OS that the shared memory is in fact shared.
>> This is a big nono under a protected OS.  However, it is an
>> exaggeration to say that 99.9% of Amiga programs do this.
> 
>Almost every program shares memory -- any time you do IO at either
>the dos or exec level, any time you listen to IDCMP events, or look
>at any system list, you're sharing memory between tasks.
> 
>But of course, we ALWAYS remember to use MEMF_PUBLIC in those cases,
>right?

Intuition allocates the memory used in IDCMP messages.  If it doesn't use
MEMF_PUBLIC for that memory now, it will by the time Exec implements 
protected memory.  In any case, it isn't an application issue. 

Now, as for I/O, I'm assuming that you're referring to the buffer that
holds the data to be transferred.  In that case, what does the device
driver receive eventually?  A structure of a known length with a pointer
(in a known place in the structure) to a memory buffer that is also of a
known length.  In short, the device driver knows exactly what memory it
will need to access, so it should be possible to include an OS call that 
would allow the driver to check to see if the memory it has received is
MEMF_PUBLIC.  If not, give the driver another call that will make it sharable.
This could blow system security out the window, of course, but for the
moment it seems that most people want memory protection to stop errant
programs, not malicious ones.

The real problem stems for two (or more) tasks that pass their own
privately defined structures around.  If a structure like that contains
a pointer to memory that needs to be declared shared, Exec will never know
and won't be able to pull off the protections-changing trick, and the
receiving program will generate a protection violation and be terminated.

As for system lists, make them (and the things they point to) publically
readable but not writable, or make them readable and writable after
the calling process performs the appropriate Lock*() call.


-- 
Dave Schreiber  "Look.  Don't touch."  davids@cats.ucsc.edu (until 6/20/93)
From: Walt.Namitz@launchpad.unc.edu (Walt Namitz)
Newsgroups: comp.sys.amiga.programmer
Subject: gcc2.2.2 Opening Intuition
Date: 23 Nov 92 13:40:29 GMT
Organization: University of North Carolina Extended Bulletin Board Service

Does anyone have a working code fragment which opens the intuition library
that they could email me. I have tried using the examples in the Amiga
ROM Kernel Reference manual however I haven't had any success. Thanks in
advance to those who respond.
--
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  laUNChpad.unc.edu or 152.2.22.80
Newsgroups: comp.sys.amiga.programmer
From: breese@monet.imada.ou.dk (Bjoern Reese)
Subject: Re: New hardware reference guide?
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Mon, 16 Nov 1992 13:07:52 GMT

In article <1992Nov15.104025.10090@sth.frontec.se> bjst@sth.frontec.se (Bjorn  
Stenberg) writes:
> breese@monet.imada.ou.dk (Bjoern Reese) writes:
> > Consider this: "The more knowledge people have about the hardware the more
> > likely their programs will work well."
> 
> Well, this HAS been tested for the past seven years, with little success...

IMHO, there are four reasons to this lack of success:

1) The Seka assembler.
   It was extremely popular in the demo scene, because it
   gave you the feeling of total control over the machine.
   Most of the coders came from the C64, or a similar 8 bit
   machine, and they wanted to know exactly what was going
   on at any time. The Seka assembler allowed the continuation
   of the bad programming style of the 8 bit machines.

2) The "Machine Language" book from Abacus.
   Being the only book easily available which claimed to
   teach you Assembly Language, it rose to fame. Sadly it
   a) contained a huge amount of bugs, and b) supported
   the Seka assembler.

3) The early version of the Hardware Reference Guide.
   This manual is amoung the worst documentations I've ever
   seen. Cryptical explanations, lousy (even buggy) examples.
   Anyone having tried to figure out how to draw lines, or
   using the CIAs, will know what I mean.

4) The demo scene was/is a learning ground for upcomming
   programmers.
   People make mistakes; beginners more than experienced.
   Some of these mistakes continued to flourish as sourcecodes
   and tricks were shared amoung coders. Problem was/is, that
   many coders rather get famous quick, than learn the craft
   well, so they just copied the code of other coders.

Now, this shows us that C= was partly to blame, because of
their incomprehensive Hardware Ref Guide. Well, the Hardware
Ref Guide was partly unusable, and besides only a minority of
the upcomming coders had a copy, but did that stop them? NO!
My prediction is that it will not stop them either, if C=
doesn't release a new Hardware Ref Guide, featuring the AGA
chips. As the AGA chips are made available in low-price
machines, and hence available to new upcomming coders, there
will a massive interest in how to program the chips, and
with or without a Guide, they will try. So I say, it is better
to release a new Guide, in order to set guidelines and to
prevent fatal errors.

Also, I think this discussion is biased. Most of the people
on Internet are students at college or university level, or
employees at a commercial company. This kind of people are
well educated in programming, and if some of them were raised
in the demo scene, they most likely have converted (like me.)
Even though we are Amiga users, I don't think that we
represent a very wide variety of the common Amiga users.
I am not complaining, just trying to set things in perspective.

--

Bjoern Reese                   |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)
From: jamie@cdevil.unx.sas.com (James Cooper)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Lattice 5.10 upgrade
Keywords: upgrade
Date: 23 Nov 92 16:42:16 GMT
Organization: SAS Institute Inc.
Originator: jamie@cdevil.unx.sas.com


In article <sims.722527621@sauron.msfc.nasa.gov>, sims@sauron.msfc.nasa.gov (Herb Sims) writes:
>I have a favor to ask of some-one concering SAS C V5.10(x) upgrade.  Somehow
>SAS did not send me the upgrade from 5.04 to 5.10 is there someone out the
>there who would be kind enough to send me the upgrade disk?  If it cost money
>to get the upgrade from 5.04 to 5.10(x) then I am sorry and please put this
>note in the :dev/null bin.  Before anyone tells me to call SAS I already have
>and they do not have any more 5.10(x) upgrades since the 6.00 has come
>out.

5.10 was a $40 upgrade from 5.04.

The price to upgrade from 5.<anything> to 6.0 is the same no matter what
the <anything> is.

6.0 is a *much* better compiler than 5.10, and the documentation alone
is worth the upgrade price (according to customers), and in fact, is the
main cause of the upgrade price.

Please consider upgrading directly to 6.0.

-- 
---------------
Jim Cooper
(jamie@unx.sas.com)                             bix: jcooper

Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
and not necessarily those of my employer.
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: New hardware reference guide?
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Tue, 17 Nov 1992 02:23:13 GMT

In <1992Nov13.211221.1609@freenet.carleton.ca> aa302@Freenet.carleton.ca (Russell McOrmond) writes:
>  I myself don't know much about the reasons why other hardware is hit, but
>from this simple example I bet there are legitimate reasons for getting
>around bugs in the O.S.

This is not a bug. Bugs are things that do not work as documented.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."
Newsgroups: comp.sys.amiga.programmer
From: wille@june.cs.washington.edu (Robert Wille)
Subject: Alt to Meta conversion
Organization: University of Washington Computer Science
Date: Tue, 17 Nov 92 01:12:27 GMT

Does someone have a program that converts alt-key to ESC-key?  I hate
having to use escape when I'm using emacs over a modem.  This would be
such a trivial program I doubt that someone hasn't written something like
this.

-- 
Robert

There is evidence that the brain is like a computer.  If that's true, 
then there really aren't any stupid people.  Just people running DOS.
From: gad@fncrd6.fnal.gov (greg deuerling)
Newsgroups: comp.sys.amiga.programmer
Subject: CDRom SCSI Commands ???
Date: 20 Nov 1992 14:59:26 GMT
Organization: Fermilab
Distribution: world
NNTP-Posting-Host: fncrd6.fnal.gov


We have a few SGI Indigo's around here, and they all come with CD Rom drives.
Only one drive is hooked up, so we have a few just sitting around collecting
dust.  What I'd like to do is to write a program that I play Audio CD's.  I
could buy one of the CDRom file systems, but for $60 I can almost go out and
buy a portable CD player.
My question. Does any one know that SCSI commands used to do this ???
The drive is a Toshiba 3301.  No drive documentation comes with the Indigo,
so no luck there.
Any help, info, or insults welcome !!!

Thanks...


								gad
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=	     Greg Deuerling, Fermi National Accelerator Laboratory	      =
=	   P.O.Box 500   MS#368  Batavia, Il  60510   1(708)840-4629          =
= 			    Computer R&D Group				      =
=		            gad@fncrd6.fnal.gov				      =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.sys.amiga.programmer
From: dnavas@oracle.uucp (David Navas)
Subject: Re: Subtasks, IEEE library pointers - y.a.Q
Keywords: Libraries
Organization: Oracle Corporation, Redwood Shores CA
Date: Mon, 23 Nov 1992 17:46:25 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <1egvqcINNfos@hpsdln.sdd.hp.com> denson@sdd.hp.com (Craig Denson) writes:
>In article <1992Nov19.150345.19491@samba.oit.unc.edu> Todd_Lewis@unc.edu (Todd M. Lewis) writes:
>  this is where i lose the thread. what is in these libraries that
>  must be the same. if it's a copy of the same code at a different
>  location why should you care? are the bits a different color? :-) 

Not usually, no.

>  what's in the libraries that isn't relocatable? or are you using 
>  library data as part of your application's data structure? - that
>  doesn't sound too good.

Your right, it isn't good.
And it is what is going on.
Basically, the OS Process structure is not extensible at run-time.
This is a brutal mistake, and -that- is where the change ought to be made.

Forking off the multiple-library-base problem to developers when what we
really need is an extensible Process structure which is something the OS
should provide is to me (and not to sound too disenchanted) obscene.

This is an OS problem, it is NOT an application's problem.
Writing single-threaded code is something WINDOWS is great at, I will NOT
treat my Amiga like a bad WINDOWS port.

I would like someone from Cmdre to give me one (1) good reason not to have
done this already, given that they realize this problem.
Possible answers:
	1.3
		my response, the new libraries are >3.1 only
	compatibility 
		my response, no one is going to magically start
		using new libraries unless they recompile, at which
		point they can start using the OS properly instead
		of allocating process structures on the stack....
	Process, what about Task?
		DOS is a Process-only library, other libraries can be too....
	If you have lots of local libraries what's the difference between
	searching a local and searching a global list?
		O(logn) if you're smart and start using a decent search
		structure (like an AVL tree, or even better, a
		radix sorted/searched array of some kind).

I think what I'm asking for here is completely reasonable -- that new OS
structures and definitions provide -solutions-, not merely well-defined
problems.

>craig

David C. Navas						dnavas@oracle.com
Working for, but not speaking on behalf of, Oracle Corp.
From: mks@cbmvax.commodore.com (Michael Sinz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: New hardware reference guide?
Date: 18 Nov 92 14:20:06 GMT
Reply-To: mks@cbmvax.commodore.com (Michael Sinz)
Organization: Commodore, West Chester, PA

bjst@sth.frontec.se (Bjorn Stenberg) writes:
>podesta@qut.edu.au writes:
>> Come on now!! How many advanced system software, that was written on a
>> 1.3 A500 with no harddrive will work on a A4000???
>> I bet there's not much.
>
>Browse through the early Fish Disks and you'll find a lot of stuff
>still working like a charm.

Yes.  And other than a few things that were packed with an older
version of PowerPacker, all of my things still run great.  (From 1985 even)

>> And don't forget that demo coders don't get any wonderful Developers info.
>
>Why not? Become a registered developer and you'll get the info.
>If you want to know how your machine works and how to use it, go get
>info where info is to get: Commodore.

The best thing is that you can walk into a book store and get the RKMs.
Yes, it is lots of reading.  But it is also the bible when it comes to
the Amiga and programming it.

/----------------------------------------------------------------------\
|      /// Michael Sinz  -  Senior Amiga Systems Engineer              |
|     ///                   Operating System Development Group         |
|    ///   BIX:  msinz      UUNET:  mks@cbmvax.commodore.com           |
|\\\///    Programming is like sex:                                    |
| \XX/     One mistake and you have to support it for life.            |
\----------------------------------------------------------------------/
From: n298ad@tamuts.tamu.edu (John Jordan)
Newsgroups: comp.sys.amiga.programmer
Subject: ANSI Cursor Controls
Keywords: DOS, documentation
Date: 16 Nov 92 06:26:18 GMT
Organization: Texas A&M University, College Station


	Could someone please post or email a list of ANSI commands?
Specifically I am looking for commands to adjuct the cursor position.
Is there a command to do an exact (x,y) position of the cursor in 
a shell window???
Thanks in advance, 
-JOhn
n298ad@tamuts.tamu.edu
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: MatchFirst/MatchNext questions...
Date: 21 Nov 92 07:45:24 PST
Organization: BBS

> trouble with the pattern matching routines MatchFirst and
> MatchNext.  I seem to get some quite wierd stuff back from them at
> times (garbage file names etc).  I'm a bit stumped by this, and
> wondered if it may be due to my program moving/creating/deleting
> files within pattern matching.  What I wish to know is are all file
> operations legal during pattern matching (ie can I create a new
> file as a result of each MatchNext call, for example).
 
I'd say avoid this.  I remember noticing that the 1.x Ram-Handler
filesystem would lose its place in ExNext scans if you renamed files
in the directory during a scan ... I think that has to be considered
a not-really-safe operation.
 
Now this SHOULD be safe, or else the filesystem can misbehave when
two perfectly correct programs both happen to access the same
directory at the same time.  But apparently there are times when some
filesystems are not bulletproof.
 
I have no idea whether there is any such problem with the v37 rom
filesystem and MatchNext.
From: tron@uni-paderborn.de (Matthias Scheler)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: ParNet FileSystem Source Code
Date: 17 Nov 1992 13:44:03 GMT
Organization: Uni-GH Paderborn, Germany
Distribution: world
NNTP-Posting-Host: gold.uni-paderborn.de

In article <wuth.22pc@castrov.cuc.ab.ca>, wuth@castrov.cuc.ab.ca (Brett Wuth) writes:
|> I've installed parnet between my two Amigas and the file system
|> that allows one to access to the drives of the others.  It works
|> well enough.  But there appears to be some bugs.
|> 
|> 	* You can't do a dir of the current directory.  It
|> 	  says:
|> 	  Any other directory works, so instead you must do 
|> 	  something like "dir /thisdir".

Try NetPatch V1.1 (on amiga.physik.unizh.ch).

|> 	* The Amiga being accessed, slows down over time.
|> 	  There's some evidence that filelocks are not
|> 	  being released.

Yes, that's possible.
 
|> Versions:
|> Kickstart version 37.175. Workbench version 37.67  (DOS 2.04)
|> hdisk: fs 37.26
|> parnet.device internal string "parnet.device 2.0 (23 Dec 1990)"
|>       but "version parnet.device" reports "version 1.0"

If it causes no enforcer hits, it's 2.0.

|> If need be, I'll fix the source I have to work with ParNet and then fix
|> the bugs described above.

The source is not avaible :-(

-- 
Matthias Scheler                                         tron@uni-paderborn.de
University of Paderborn (Germany)
Newsgroups: comp.sys.amiga.programmer
From: den@cci632.cci.com (Dennis J. Buttery)
Subject: ASL Hook Functions
Organization: [Computer Consoles, Inc., Rochester, NY
Distribution: usa
Date: Mon, 23 Nov 1992 21:59:13 GMT

  I am using a hook function with an ASL file requester and everything is
working fine so far...  However, I wanted to be able to open each file and
read out an ID value to determine if I really want the filename to show in
the requester or not.  When I try to open the file from inside the hook
routine it just returns an error.  Should I assume that DOS routines are not
allowed from within a hook function or am I missing something here????

BTW - I am setting the ASL_FuncFlags to DOWILDFUNC. Is this sufficient?
 
Thanks in advance for any info you can provide.
 
                                        -DJB-

Newsgroups: comp.sys.amiga.programmer
From: Todd_Lewis@unc.edu (Todd M. Lewis)
Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
Organization: UNC Office of Information Technology
Date: Thu, 19 Nov 1992 14:18:31 GMT

In article <37138@cbmvax.commodore.com> spence@cbmvax.commodore.com (Spencer  
Shanson) writes:
>I am no UNIX expert, but is there a reason why the display side of a UNIX port
>could not sit on top of the graphics.library? After all, to bring up a UNIX
>screen would involve duplicating the work that has already gone into the A4000
>kickstart.

Are you saying that the graphics.library can be used without Exec running?
Doesn't graphics.library rely on other parts of the Amiga OS being around.
Is there then any reason why the display side of anything (say a boot-off-
the-floppy game) could not sit on top of the graphics.library without 
Exec?
>Spencer Shanson - Amiga Software Engineer     | email: spence@commodore.COM
--
     Todd M. Lewis / Todd_Lewis@unc.edu / utoddl@guitar.oit.unc.edu
 Another Month Ends / All Targets Met / All Systems Working / All customers  
Satisfied / All Staff Eager and Enthusiastic / All Pigs Fed and Ready to Fly
From: jamie@cdevil.unx.sas.com (James Cooper)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: snapshot and SASC 6.0
Date: 23 Nov 92 16:46:13 GMT
Organization: SAS Institute Inc.
Originator: jamie@cdevil.unx.sas.com


In article <10069@blue.cis.pitt.edu.UUCP>, stern+@pitt.edu (Eric G Stern) writes:
>Hi,
>
>    Has anyone come up with a strategy for being able to take
>snapshots of programs that GURU with the catch.o startup module of
>SASC 6.0 without clobbering their hard disk?  I thought I'd be able to
>do that be running the program from the removable RAM disk and then
>copying the file to the hard disk, but I still ended up clobbering the
>hard disk.  What is the mechanism that causes this?  Would locking the
>hard disk with the DOS command LOCK prevent hard disk damage?  How
>about working from floppies?  Any insights would be useful.

When catch.o tries to write the SnapShot.tb file, it first tries to
write to the Current Directory, and if that fails, to the root of DF1:,
and if that fails, to the root of DF0:, and lastly, it just exits.

If your current directory is on a floppy, that is the first place it
will try to write.

It sounds, though, like your system is so trashed, it has affected the
HD controller software, which is why your HD is getting trashed.  In
that case, setting the CD to a floppy is probably your best bet.  At
least if the Write() trashes that, you won't have lost much...

-- 
---------------
Jim Cooper
(jamie@unx.sas.com)                             bix: jcooper

Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
and not necessarily those of my employer.
Newsgroups: comp.sys.amiga.programmer
From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Subject: Re: GCC 2.2.2 Patch3
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 16 Nov 1992 21:47:33 GMT

In article <1992Nov16.233246.4252@darwin.ntu.edu.au> hoffmann@nutmeg.ntu.edu.au (Arthur Hoffmann) writes:
>Hi, I just applied the third patch to the GCC 2.2.2 port of Markus Wild.
>I really would like to know if the following are Error messages or if they are ok
>the way they are.
>
>ar: gcc:lib/libc.a: operation not supported by device
>ranlib: gcc:lib/lib.a: operation not supported by device
>ar: gcc:blib/libc.a: operation not supported by device
>ranlib: gcc:blib/libc.a: operation not supported by device
>
>Thanks a lot.
>
>Arthur.
>
>					Arthur Hoffmann
>					hoffmann@nutmeg.ntu.edu.au

Hmm... are you doing this under 1.3?? I think ar/ranlib might do an
ftruncate() somewhere, and if you run them on a real old filesystem, 
ftruncate() is not implemented by the FS, and then the functions fail. Note,
this doesn't mean it won't run under 1.3, you'd just have to switch to a 
newer FS. 

The above were guesses, if you want to know for sure, load ixemul.trace
instead of ixemul.library (see the README in the usr:bin directory), and
run the tracer while you execute one of the above commands. You should
then see exactly which command really fails.

-Markus
-- 
Markus M. Wild    -  wild@nessie.cs.id.ethz.ch  |  wild@amiga.physik.unizh.ch 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.
Newsgroups: comp.sys.amiga.programmer
From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Subject: Re: Gcc 2.2.2 and gnu make 3.62
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Distribution: comp
Date: Mon, 23 Nov 1992 17:39:52 GMT

In article <PS106363.92Nov23130604@ruosterastas.cs.tut.fi> ps106363@cs.tut.fi (Sainio Pasi) writes:
>	Has anybody been able to compile a running binary from gnu
>make with gcc under Amiga.  It compiles just fine with -DPOSIX and
>-DNO_LDAV, but the binary just sits in a busyloop.  If I use
>ixemul.trace and trace, the trace dies with Illegal instruction after
>make has called nice() -function.  Any ideas?
>
>Setup:
>	A2000 with KS1.2, WB1.3  (could this be the problem)

I didn't try recently, but gmake uses vfork/exec, which is currently not
working under 1.3. If you're using v39.45 of ixemul.library, you should get
a requester telling you about this problem. 

-Markus
-- 
Markus M. Wild    -  wild@nessie.cs.id.ethz.ch  |  wild@amiga.physik.unizh.ch 
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.