HDTenEightyP/NetNews huggingface dataset:
From: john@proteus.jpl.nasa.gov (John Veregge)
Subject: Is utility.library/Stricmp() broken?
Reply-To: john@pluto.Jpl.Nasa.Gov
Organization: Jet Propulsion Laboratory, Pasadena CA
Date: Fri, 25 Dec 1992 22:52:39 GMT

Is the AmigaDOS 2.04 utility.library/Stricmp() broken?

I used the following code fragment as the comparison
routine passed to qsort() (STDC lib). I interchanged
strcmp(), Stricmp(), and Strnicmp(). I opened the
utility.library, OpenLibrary( "utility.library", 37 ),
prior to calling qsort(). The below three columns
show the output of their respective sorts.

I am using Aztec C 5.2a on a 2000HD with DOS 2.04.

Does anyone know what is going on?

  qsort_comparison( void * s1, void * s2 )
  {
    return (int) Stricmp( *(char**)s1, *(char**)s2 );
  }

  strcmp(s1,s2)   Stricmp(s1,s2)  Strnicmp(s1,s2,100)
  ==============  ==============  ==============
  README          sh.dbg          amigaregex.c
  amigaregex.c    sh2             sh
  amigaregex.doc  sh1             test.out
  amigaregex.o    test.out        makefile
  makefile        sh              amigaregex.o
  sh              amigaregex.doc  amigaregex.doc
  sh.dbg          README          README
  sh1             makefile        sh1
  sh2             amigaregex.o    sh2
  test.out        amigaregex.c    sh.dbg

____________________________________________

John R Veregge  -  john@pluto.jpl.nasa.gov
From: beust@aurora.unice.fr (Cedric Beust)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AmigaDOS library functions and ANSI-C programming
Date: 31 Dec 1992 14:15:29 +0100
Organization: University of Nice Sophia-Antipolis, France
Distribution: world
NNTP-Posting-Host: aurora.unice.fr


In article <C03uy8.9xF@agora.rain.com>, robart@agora.rain.com (Joe Bob) writes:

>  AddHead has to modify your node in order to add it to the list.
>And it can't in general use a copy of the node since it does't
>know how big it is.  The node could be a Task, a Message, an IORequest,
>a Font, or just about anything.

	Good point! I hadn't thought of that. Maybe C= could put your
	sentence as is in the Autodocs? :-)

	Anyway, I knew that const couldn't apply in that cas, but I just
	wanted to illustrate one of the numerous functions which documentation
	would need some rewriting. Thanks for your answers!

--
Cedric BEUST, beust@sa.inria.fr, Bull Research Koala proj, KoalaBus & xforum
Pho:(33) 93.65.78.07(.66 Fax), INRIA, B.P.93 - 06902 Sophia Antipolis, FRANCE.
From: chris@132.236.236.123 (Christopher A. Wolf)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Getting a valid FileSysStartupMsg pointers.
Date: 23 Dec 92 05:27:14 GMT
Article-I.D.: mail.1992Dec23.052714.25037
Reply-To: chris@alchemy.tn.cornell.edu
Organization: none
Content-Type: text/plain; charset=iso-8859-1
Nntp-Posting-User: tc13@cornell.edu
Content-Transfer-Encoding: 8bit
X-Newssoftware: GRn-beta 1.16g (13.12.92) by Michael B. Smith & Mike Schwartz
Mime-Version: 1.0

In article <1992Dec22.143308.26492@rzu-news.unizh.ch> cschneid@amiga.physik.unizh.ch (Christian Schneider) writes:
> Angela Schmidt (ry53@rz.uni-karlsruhe.de) wrote:
> > or not. TypeOfMem() only works with RAM, but some of the entries in
> > the fssm can be in ROM or even in the expansion space as well. So
>
> But a valid fssm is always in ram, wrong?
> I'm currently using TypeOfMem() for dn_Startup only, I don't think
> this should miss some devices.

I -think- that a valid FSSM and a valid DosEnvec vector (obtained from
the FSSM) are always in RAM and thus only check those two entries with
TypeOfMem.  So far haven't run into any problems using this method.

> > for now, I assume that non-zero-values mean that there is a valid
> > fssm. I tried TypeOfMem() but I really missed some devices after that,
>
> This is rather dangerous. No enforcer hits? Did you have devices
> with all (five?) possible dn_Startups (NULL, four letter ASCII, char *,
> int, valid fssm are the possibilities I think to remember).

Assuming that non-zero-values means valid FSSM -WILL- cause enforcer
hits in many cases.  This is what I was originally doing and my inquiry
about a "better" way started this thread.

Four letter ASCII????  Ack!  Randell didn't mention this as a valid
possibility in his original reply.  Can anyone give me some examples of
devices which use this?

> > :     \ /&\   Angela Schmidt cand. inf.   (Nessy@IRC) | Amiga //
> Chris Schneider - cschneid@amiga.physik.unizh.ch BIX: hschneider IRC: cschneid

-- 
------------------------------------------------------------------------------
Christopher A. Wolf   mail: chris@alchemy.tn.cornell.edu   IRC: cwolf (#amiga)

The rec.arts.sf.starwars Frequently Asked Question List is available via anon.
FTP from the Star Wars archive site at wpi.wpi.edu. "May the FAQ be with you!"
------------------------------------------------------------------------------
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: App(Icon|Window) and Style Guide.
Date: 23 Dec 92 10:42:28 PST
Organization: BBS

> I agree, lets standardize the drop system by making AppIcons and
> AppWindows have the "lip".  More importantly, if, someday, C=
> decides to make an icon type (when .info files are no more, and
> everybody uses 2.0 std. functions for accessing them) that allows
> "dropping" onto them (The WB's copy function would simply examine
> the icon's type, and if it was of type STD_DropApp, do whatever),
> that icon could have a lip too.
 
I strongly agree!  Tool icons and AppIcons should ideally behave the
same and should be visually distinct from project/drawer/etc icons.
I don't care what the visual distinction is as long as it exists.
From: bloc1469@ee.ee.uwm.edu (Gregory R Block)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: App(Icon|Window) and Style Guide.
Date: 24 Dec 1992 06:54:04 GMT
Organization: Electrical Engineering Dept. University of Wisconsin - Milwaukee
NNTP-Posting-Host: 129.89.2.33

In article <paulk.2woe@terapin.com> paulk@terapin.com (Paul Kienitz) writes:

In an unattributed segment of my own article, to my astonishment... I
sounded a little too lucid for my own good, methinks.  ;)  I didn't
even reconize that I had written it, at first.  It just seemed
"familiar"...
>> I agree, lets standardize the drop system by making AppIcons and
>> AppWindows have the "lip".  More importantly, if, someday, C=
>> decides to make an icon type (when .info files are no more, and
>> everybody uses 2.0 std. functions for accessing them) that allows
>> "dropping" onto them (The WB's copy function would simply examine
>> the icon's type, and if it was of type STD_DropApp, do whatever),
>> that icon could have a lip too.
> 
>I strongly agree!  Tool icons and AppIcons should ideally behave the
>same and should be visually distinct from project/drawer/etc icons.
>I don't care what the visual distinction is as long as it exists.

Right.  If it's going to FUNCTION differently than a normal icon, then
it should LOOK different than a normal icon.  And all of the "drop"
types should be just that--a set of similar types.  Similar functions.
Similar looks.

Oh, I'll just copy this icon over onto this icon, and make myself a
copy on that drive.

Wait a sec.

Why is BLAZEMACS loading that?  (BLAZEMACS had been set in "lets fool
the user by using the standard drive icon for the appicon" mode by
Customer Service on their last visit)...

Greg
--
(: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
(: "Our father, who art in Iowa, Hollow be thy head, Thy ideas run    :)
(:  Thy will be done, At Commodore as it is at Apple"  -Dan Barrett   :)
(: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
Newsgroups: comp.sys.amiga.programmer
From: RSTACKHOUSE@JAGUAR.ESS.HARRIS.COM ( 57577 Stackhouse ke)
Subject: SAS 6.1 upload to wuarchive?
Date: Thu, 24 Dec 1992 14:18:44 GMT
X-News-Reader: VMS NEWS 1.24
Organization: Harris Information Systems Division

Can someone please tell me where the 6.1 update was uploaded to?
The FTP site /directory and filename would be perfect.  thanks.
please post or send private mail to my address above.
Newsgroups: comp.sys.amiga.programmer
From: mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst)
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Organization: Max-Planck-Institut f"ur Radioastronomie
Date: Mon, 4 Jan 1993 03:15:43 GMT

In <doiron.0kmz@starpt.UUCP> doiron@starpt.UUCP (Glenn Doiron) writes:
>This is a *general purpose* scaling algorithm.  It uses no predefined
>tables.

Correct. It also makes the effect of chunky vs. bitplane quite invisible.
It is however not the preferred method. If the rectangles in question
are large enough it is faster to precalculate the tables and use them.

>The rendering is a small fraction on the chunky system, however getpixel()
>and putpixel() on a planar system may even take *more* time than the
>multiplications due to the time needed to ([shift/mask/extract]x8) then
>([shift/mask/insert]x8) do those operations in planar.

Hardly. You forget the time needed to calculate pointers from x,y
coordinates.

>It's a general purpose algorithm that will scale/rotate bitmapped images.
>It suffers no limitations unlike your precalculated table.

And it is not used when performance is an issue.

>I can assure you that on a chunky display, that will be the case.  On a
>planar display, that is a different story entirely.

While it is different the overhead isn't that high.

>Notice how **NO** processors support parallel operations on several
>arbitrary bits at different memory locations.  Even if there were there
>would still be overhead due to the extra data accessed that wasn't even
>considered.

You don't need to do operations on several arbitrary bits at different
memory locations in parallel. And, for many things, you don't even
work on single bits because you do not handle a pixel at a time.

>Suppose you have a blit that takes 20ms on chunky and 30ms on planar
>(planar is accessing 1/3 more data than neccessary) on a 256 color display.
>Jump up the pixel depth to true-color (32-bit), and you're suddenly wasting
>4x as much time, since now it's taking 80ms on chunky and 120ms on planar.
>Still in a 2:3 ratio, but your time wasted has jumped from 10ms to 40ms.

Still don't see your point here.

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."
From: fheitkamp@desire.wright.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Big mistake - A compromise (of sorts)
Date: 21 Dec 92 06:34:21 EST
Organization:  Wright State University 

In article <cg.0i2x@ami-cg.GraySage.Edmonton.AB.CA>, cg@ami-cg.GraySage.Edmonton.AB.CA (Chris Gray) writes:
> In article <1992Dec18.211223.29630@clipper.ingr.com> kontos@clipper.ingr.com
>  (Thorne K. Kontos) writes:
>>
	[hardware banging]

> CBM has said they are working on two new chip sets/architectures. One is low
> end and one is high end. OK, so deliberately make the two sets as incompatible
> as possible! Then, release the full specs on the low-end architecture, but
> not for the high-end one. The hacker/demo folks can then hack away on the
> low-end systems, and their stuff will be shared with and appreciated by all
> the folks with such systems. Folks like me who want a very stable system for
> software development will likely have a high-end system anyway (I'm typing
> this on my A3000/25). If the two architectures are quite different, there is
> much less chance of any hackers developing something for the high-end systems,
> which appears to be one of the main concerns about releasing hardware specs.
> Things like big role-playing games, which can make good use of extra memory
> and hard disks, don't really need hardware access, and should run just fine
> on the high-end machines by going through the OS for everything.
> 
> Folks with lots of money will buy one of each, and will have a stable system
> on which to run BBS's, develop software, run WP's, spreadsheets, etc. and
> will have a possibly highly unstable (boot all the time) system on which to
> run arcade games, demos, mods, etc.
> 
> Aside from it not solving the problem for AGA, anyone see problems with this?

	IMHO, why don't you give it up?  Non of the OS vendors, even Microsoft
	are not recommending hardware banging in the future.  Commodore is doing
	you a favor by helping garrantee that your software has the best chance
	of running on a future Amiga/Commodore.

> 
> --
> Chris Gray   cg@ami-cg.GraySage.Edmonton.AB.CA
Fred Heitkamp, ** Not an organization **
From: Gene_Ruebsamen@republik.fidonet.org (Gene Ruebsamen)
Newsgroups: comp.sys.amiga.programmer
Subject: Subliminal Messages
Date: 1 Jan 93 20:05:58 PST
Organization: Eiffel Media of Orange County

I am trying to figure out a way to get my A3000 to flash a text
message on the screen for a brief period of time (about 1/15th to 1/30th)
of a second, and then wait a few seconds and flash the message again.
Can I just display the text and then quickly clear the screen? or is it
more complicated than that, must I time the message with the screen
interupt so that I am sure that the message is displayed?

Anyone have any source?

Thanks in advance!

Gene

p.s. Happy New Years!

 * Q-Blue v0.7 [NR] *

-- Via DlgQWK v0.65a
From: paulk@terapin.com (Paul Kienitz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Going to the metal
Date: 2 Jan 93 10:43:04 PST
Organization: BBS

> > Imagine if you will a "spec" that says that address X contains
> > the X position of the mouse, Y contains the Y position, and Z
> > contains the state of the buttons. Further, J contains the bits
> > associated with joysticks 1 and 2 in the upper and lower 4 bits
> > and at address I is the bits for the display plane 0, I+n plane
> > 1, etc. Now using this virtual machine is just as easy as using
> > the actual hardware, except that now, the changes in the O/S are
> > "invisible" to games that use them.
 
> I think this is a great idea, and an acceptable one at that.
> Perhaps a library of sorts, a hardware.library?
 
This is only applicable to the simpler hardware operations where
performance isn't an issue in the first place.  I doubt you could
model the blitter and copper in a general way that would be
applicable to other hardware, without getting a lot closer to an
abstract model like the real OS uses.
 
At best it would simplify the job of making other graphics devices
have an ECS compatibility mode.  That might be worth doing but it
aint a general solution ...

Maybe there could be an aga.library to let people do stuff similar to
what they do with hardware banging on the old chipset, with the new AGA
features.  Then they could make the next chipset less compatible and
provide a new aga.library with compatibility glue and tell people "well
if you hit the registers instead of using aga.library then of course it's
not going to work."
Newsgroups: comp.sys.amiga.programmer
From: walker@twix.unx.sas.com (Doug Walker)
Subject: SAS Institute holiday schedule
Originator: walker@twix.unx.sas.com
Date: Thu, 24 Dec 1992 17:42:24 GMT
Organization: SAS Institute Inc.


SAS Institute will be closed December 25 and the week of December 28.
The technical support crew will be back at work on Monday, January 4,
1993, to handle your calls and letters.  EMITS will continue to accept
and track problems automatically, but you won't get a non-automated
followup until the new year.

On behalf of the Amiga development and technical support teams
at SAS Institute, I'd like to wish each of you a happy and safe
holiday season, and the best of luck in the new year.

-- 
  *****
=*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
 *|. o.| ||                                          1200/2400/9600 Dual
  | o  |//     For all you do, this bug's for you!
  ====== 
usenet: walker@unx.sas.com                            bix: djwalker 
Any opinions expressed are mine, not those of SAS Institute, Inc.

Newsgroups: comp.sys.amiga.programmer
From: wild@nessie.cs.id.ethz.ch (Markus Wild)
Subject: Re: GCC wont create executable
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Tue, 29 Dec 1992 21:54:46 GMT

In article <1hqc7oINNt7r@crcnis1.unl.edu> tbills@cse.unl.edu (Trent Bills) writes:
>I have compiled and worked with GCC2.2.2 on several
>system, and have found the 2.2.2 c++ compiler to
>be somewhat unreliable.  I tried to compile a version
>of libg++ with it, and it failed (core dump) on several
>modules.  I have had no such problems with GCC2.3.2, but
>I don't think anyone has ported that version to the
>Amiga yet.

I intend to upload 2.3.3 this night, since I'm away afterwards for about
5 weeks. I don't have time to recompile the C++ library though, so you'll have
to live with the 2.2.2 one, or recompile yourself.

-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.
From: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Access to BIX developer sections or Developer's Mailing lis
Date: Tue, 22 Dec 92 09:07:00 PST
Organization: The Portal System (TM)
  <72132@cup.portal.com> <1992Dec22.033305.45847@kuhub.cc.ukans.edu>

I would like that too.  I even mentioned it to someone I talked to
once a couple of years ago.  I don't think C= CATS would go for a
private news group or mailing list since it really would not be private.
 
The hardware service techs have a support BBS but they pay $150 or something
like that to access it.  I am sure if you become a commercial developer
and get other comms to push for something like that, C= Cats will listen.
From: jtp@cs.hut.fi (Jukka Partanen)
Newsgroups: comp.sys.amiga.programmer
Subject: LockIBase
Date: 23 Dec 1992 00:55:28 GMT
Organization: Helsinki University of Technology, Finland
Distribution: comp
NNTP-Posting-Host: laphroaig.cs.hut.fi


	What's the correct locking protocol if one wants to find a
	particular screen, and then do something with it? The RKM
	states that one shouldn't call any high level calls while
	holding the IntuitionBase lock.

	Currently I'm using

	LockIBase();
	Find_The_Screen;
	Forbid();          /* so it won't be closed */
	UnlockIBase();
	Do_The_Magic_Involving_High_Level_Calls;
	Permit();

	but this seems very ugly to me. Isn't there a better way to
	make sure that a particular screen (not necessarily a public
	screen) isn't closed while I'm referencing it?

	Thanks,
	jtp

Zippy quotation:
- if it GLISTENS, gobble it!!
Newsgroups: comp.sys.amiga.programmer
From: juncewic@turtle.cis.ohio-state.edu (thomas michael juncewicz)
Subject: Re: task communication and forbid()
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Wed, 23 Dec 1992 13:49:58 GMT

I thought the use of forbid() in effect 'turned off' multitasking.  Wouldn't
it prevent a subtask from being executed, and therefore waiting for a signal
from that task would be in vain?  Or am I misunderstanding the question
entirely?  Please excuse my ignorance..
Tom

Newsgroups: comp.sys.amiga.programmer
From: monster@mbear.apana.org.au (Martin Ozolins)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: ramlib & FreeMem
Distribution: world
X-NewsSoftware: GRn-beta 1.16g (10.12.92) by Michael B. Smith & Mike Schwartz
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: 3 Jan 93 10:46:13 PST
Organization: Bears Incorporated

In article <38251@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
> monster@mbear.apana.org.au (Martin Ozolins) writes:
> >FreeMem points to ROM code
> >Run PPMORE V2
> >FreeMem gets SetFunctioned ( by ramlib )
> ...
> >So far, it only happens when PPMORE is run.
> >It only happens ONCE no matter how many times PPMORE is run.
> >And yes, ramlib does the SetFunction
> >I am just curious as to why this happens and why ramlib does not 
> >do the SetFunction when it first starts
> 
> 	When a library/device is loaded, ramlib is the process that loads it
> and calls the init point.  The SetFunction is probably in a library init.
> 

Tanx, just checked my MLog output and found that it loads powerpacker.library

I now have a lodlib in my user-startup so all is now OK

-- 

Martin Ozolins :Internet monster@mbear.apana.org.au
Victoria       :FIDO 3:633/359.6 AMIGANET 41:300/359.6 TRINET 42:8699/8.6
Australia      :Amiga Programmer, UniSYS 1100/2200 Systems Programmer
From: winikoff@cs.mu.OZ.AU (Michael David WINIKOFF)
Subject: Re: CISC and RISC
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 22 Dec 1992 05:57:56 GMT

jimomura@tndb.UUCP (Jim Omura) writes:

[Lots of quotes deleted]

>     Putting this into context, with the current trend to multiple
>processing to handle graphics and sound (DSPs are coming), you can
>isolate the various processors to an extent, but there are going to
>be times where the various busses are going to be the main bottlenecks.

They already are. Bus bandwidth limitations is why you don't see any 20
processor shared memory machines.

In shared memory machines one relies heavily on caches to reduce the demand
on the bus.

Another solution to having multiple processors is to build distributes
memory machines. 

>Fancy DMA schemes will have to be used to optimize the resolution
>of the contentions.  But the less a processor needs to access the
>buss the better.  Well now, doesn't it sound like a good idea if
>I can have 1 instruction that requires 2 buss cycles, leaving the
>buss free for the graphics or sound processors, while the CPU does
>the work of maybe 3 or 4 instructions?  Superscalar is going to mean
>even more buss contention problems for such situations.  So at bottom,
>there are going to be a lot of good reasons to have CISC processors
>in some systems.  In fact, I expect we have seen the last of the
>"everbody will either have either type X or type Y CPUs" and there
>are going to be a fairly wide range of processors commonly used.

Essentially what (I think) you're saying is "we shouldn't use the fastest
CPUs we can on a multiprocessor machines since they'll be tying up more
bus bandwidth then slower processors"

Essentially the "advantage" of the CISC boils down to having an on chip
"microcode cache". RISCs simply have room for larger instruction caches.


>--

>Jim Omura, (416) 652-3880
>'jimomura@lsuc'

Michael
winikoff@cs.mu.oz.au
-- 

--------------------------------------------------------------------------------
Software Engineering: Quality through Deforestation.

Newsgroups: comp.sys.amiga.programmer
From: umsmigi0@ccu.umanitoba.ca (Trevor Allan Smigiel)
Subject: SASC6.1:  Unfreed memory with cpr.
Keywords: SAS bug
Organization: University of Manitoba, Winnipeg, Canada
Date: Wed, 23 Dec 1992 11:48:56 GMT

     Is there some memory problems with cpr?  Everytime I run it,
Cpr seem to not Free 136 bytes, and sometimes more.
From: disk@lakes.trenton.sc.us (Diskraker)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Supra problems wanted
Date: Sat, 02 Jan 93 04:54:12 EST
Reply-To: disk@lakes.trenton.sc.us (Diskraker)
Organization: Lakes Public Access

I also have Supra hardware that I have no problems with.  I have an 
ancient supradrive interface for my 500, a Supraram500RX and a v.32bis 
modem.  The only thing I don't like is that I have to handshake every 16k 
with ZModem when I'm downloading or I get an error when the interface 
writes to the hard drive.  It's not a 
"hardware" problem, just the methods...
Newsgroups: comp.sys.amiga.datacomm
Subject: Dnet What is the current Version? and Where?
From: hoffmann@nutmeg.ntu.edu.au (Arthur Hoffmann)
Date: 27 Dec 92 18:16:35 +0900
Distribution: world
Organization: Information Technology, Northern Territory University

Hi, does anyone know which version of DNet is the current one and where I can get
hold of it?
I also would like to know if there are simillar programmes around to connect a
normal Amiga to a Sun UNIX station ?
Thank you very much for your help.

Arthur.

					Arthur Hoffmann
					hoffmann@nutmeg.ntu.edu.au