HDTenEightyP/NetNews huggingface dataset:
From: anbo@wuee1.wustl.edu (Albrecht Jander)
Subject: Why not glass? (Was Re: Light Hoods)
Organization: Washington University, St. Louis Mo.
Date: Wed, 12 Aug 1992 15:03:05 GMT

In article <1992Aug12.062214.9349@mr.med.ge.com> bednarek@bonfire (Dennis Bednarek Mfg 4-6971) writes:
>harlow@waikato.ac.nz writes:
>: I've finally getting things worked out for my first tank. I've decided on a 35
>: gallon tank with a Fluval 203 filter (BTW, out of curiousity, how much is this
>: mail order from the States?). But the sticking point is lighting, or more
>: particularly a light hood. I can't find a aesthetically pleasing one--the best
>: I've seen are plastic manufactured by Marin--and since I'm not too fond of
>: artificial wood grain it looks like my only option. So what does everybody
>: use? Have you made your own? If so, how?
>: 
>: Thanks for your time,
>: 
>: Stephen
>Steve
>I built up several hoods for 30 and 55 gallon tanks using hardwoods (oak, and
>walnut) for the frame and visable parts.  For the interior lighting I used
>commercially available lighting fixtures available at the local hardware 
>store.  Total costs were under $1.00 US per gallon tank size.  Also I strongly
>advise a piece of plexiglass (not window glass) between the lights and the
                               ^^^^^^^^^^^^^^^^
Why not?

Albrecht

>water.
>Good Luck
>Dennis
>
>--
>
>  
>###############################################################################
>### What were the Raven's last imortal words????????????????????????????????###
>###############################################################################
>   Please note that any comments are not my employeers or even mine at times.
>


---------------------------------------------------------------------------
                        Peltier was a cool dude!!
Newsgroups: alt.aquaria,rec.aquaria
From: kncarp@nicsn1.monsanto.com (Kevin N. Carpenter)
Subject: Re: Kalkwasser (Kent Marine)
Organization: Monsanto Company
X-Newsreader: Tin 1.1 PL3
Date: Thu, 20 Aug 1992 13:39:15 GMT

grendal@iat.holonet.net (Grendal) writes:

: I add kalwasser to my tank to replace evaporated water. The kalwasser
: is added very gradually (its in an airtight container that has a line 
: that just meets the surface of the water in the tank. As the water 
: in the tank evaporates, air gets into the line and allows some 
: kalwasser in). I don't don't usually see any pH fluctuation.
: 
: grendal@holonet.net

Could you describe your setup a bit more.  I can't quite picture it,
what I keep thinking of is somethink like a barnyard animal watering
device - but that wouldn't work with a line (at least not something
like airline).

--
Kevin Carpenter       Internet:  kncarp@nicsn1.monsanto.com
Monsanto Company 
St. Louis, Missouri, U.S.A.
Opinions expressed are those of the author, not the company he works for.
From: cichlid@pine.circa.ufl.edu (KUTTY)
Newsgroups: alt.aquaria
Subject: (F) Misc. Malawian stuff...
Date: 14 Aug 92 15:01:07 GMT
Reply-To: cichlid@pine.circa.ufl.edu
Organization: University of Florida  (ufl.edu)
News-Software: VAX/VMS VNEWS 1.3-4




Bad news first: apparently there are plans to drill for oil in Lake
Malawi.  I saw some plans for it and a paper that dealt with 
the potential ecological damage if a hypothetical spill happened
to occur.  The paper was in some International Limonology something...


Good (?) news: a friend of mine lost a male Haplochromis (Sciaenochromis)
ahli...Electric Blue Hap...due to old age. He bought it full grown back
in 1982 (!) for a whopping $75. He believed the fish was atleast 2
years old when he purchased it. He says he has made over $2000 in the
last 10 years from selling fry. 





                                            Vinny Kutty


Newsgroups: alt.aquaria,rec.aquaria
From: bednarek@picard.med.ge.com (Dennis Bednarek Mfg 4-6971)
Subject: Re: Kalkwasser (Kent Marine)
Organization: GE Medical Systems, Magnetic Resonance
X-Newsreader: Tin 1.1 PL5
Date: Fri, 21 Aug 92 05:13:09 GMT


What is Kalwasser?

Dennis


--

  
###############################################################################
###NEVER - NEVERMORE###########################################################
###############################################################################
####################################What are the contents of the oblong box?##
###############################################################################
  The usual disclaimer of self and employer applies to all above comments.
#
Newsgroups: alt.lang.asm
From: spc@pineal.sci.fau.edu (Sean 'Captain Napalm' Conner)
Subject: Re: Intel 386/486 timing
Organization: Florida Atlantic University, but who cares?
Date: Fri, 14 Aug 1992 19:33:11 GMT

In article <1992Aug14.101918.5618@coli.uni-sb.de> chbl@sbustd.rz.uni-sb.de (Christian Blum) writes:
>tjalveg@ifi.uio.no (Tjalve Godager) writes:
>> 
>>     Me and a friend are writeing some 32-bits assembler code on a 486
>> for the first time. Due to the 386/486 instruction set, it is easy to
>> "optimize" many instructions into just one or two, ie:
>> 
>> 	MOV    	AL, value
>> 	XOR    	AH, AH
>> 	ADD    	BX, AX
>> 	MOV    	AL, BYTE PTR [BX]
>> 
>> into something like this:
>> 
>> 	MOVZX   AX, value
>> 	MOV     AL, BYTE PTR [EAX+EBX]  (assuming EAX=AX, EBX=BX)
>> 
>> What we would like to know is, which of the two soulutions are the
>> faster? Does anybody have the complete 386/486 instruction times, or
>> a ftp address?
>> 
>First of all, te above can be written with one cycle off on 8086s:
>xor ax,ax
>mov al,value
>
>Second: the second one is surely faster.
>
>Chris
>

  Wouldn't

	move	ax,value

be faster?  Or is value a variable somewhere else in memory?
(in which case, the syntax should be mov al,[value] 8-).

  -spc (I've always hated that syntax that Microsoft uses .. )



Newsgroups: alt.lang.asm
From: tjalveg@ifi.uio.no (Tjalve Godager)
Subject: Intel 386/486 timing
Followup-To: alt.lang.asm
Keywords: Intel 386/486, timing
Organization: Dept. of Informatics, University of Oslo, Norway
Date: Thu, 13 Aug 1992 10:19:17 GMT
Originator: tjalveg@yrsa.ifi.uio.no


    Me and a friend are writeing some 32-bits assembler code on a 486
for the first time. Due to the 386/486 instruction set, it is easy to
"optimize" many instructions into just one or two, ie:

	MOV    	AL, value
	XOR    	AH, AH
	ADD    	BX, AX
	MOV    	AL, BYTE PTR [BX]

into something like this:

	MOVZX   AX, value
	MOV     AL, BYTE PTR [EAX+EBX]  (assuming EAX=AX, EBX=BX)

What we would like to know is, which of the two soulutions are the
faster? Does anybody have the complete 386/486 instruction times, or
a ftp address?

Thanks,
       Tjalve
From: terra@diku.dk (Morten Welinder)
Newsgroups: alt.lang.asm
Subject: Re: Intel 386/486 timing
Keywords: Intel 386/486, timing
Date: 17 Aug 92 11:34:40 GMT
Organization: Department of Computer Science, U of Copenhagen

tjalveg@ifi.uio.no (Tjalve Godager) writes:


>    Me and a friend are writeing some 32-bits assembler code on a 486
>for the first time. Due to the 386/486 instruction set, it is easy to
>"optimize" many instructions into just one or two, ie:

>	MOV    	AL, value
>	XOR    	AH, AH
>	ADD    	BX, AX
>	MOV    	AL, BYTE PTR [BX]

>into something like this:

>	MOVZX   AX, value
>	MOV     AL, BYTE PTR [EAX+EBX]  (assuming EAX=AX, EBX=BX)

>What we would like to know is, which of the two soulutions are the
>faster? Does anybody have the complete 386/486 instruction times, or
>a ftp address?

>Thanks,
>       Tjalve

The timing of the first version on a 486 is
  1+1+1+(1+1) = 5 cycles.
The last instruction takes 1 extra cycle to execute since it
uses Bx as an index register and Bx was changes by the third 
instruction.

The timing of the second is
  (?+3)+(1+1+1-1) = 5+? cycles
where ? is 0 if the previsous instruction took mare than one cycle
and 1 otherwise. The reasons for this is that Movzx uses a prefix.

Consider
	Add	Bl,value
	Adc	Bh,0
	Mov	Al,[Bx]

or even

	Xlat

Both execute in 3 cycles (assuming a code segment of the correct size).

All timing are from memory but they should hold --- give or take 1 
cycle.

Morten Welinder
terra@diku.dk
From: funni@vixvax.mgi.com
Newsgroups: alt.lang.asm
Subject: LOCAL BUS DEVICE DRIVERS?
Date: 13 Aug 92 08:20:59 CDT
Organization: Management Graphics, Inc.

i am about to buy a 486-50 with local bus and an s3 card.

my problem is i don't know how to ask or even if they have the technical
information on how to write the device drivers for my own programs.

i know how to write device drivers but i need the information on their
specific card.


CAN ANYONE GIVE ME INFORMATION ON HOW TO DO THIS, WHEN I ASK THE SALES PERSON
THEY NEVER KNOW VERY MUCH TECHNICAL INFORMATION.

IS THERE A BOOK ON THE S3 COPROCESSOR?
From: terra@diku.dk (Morten Welinder)
Newsgroups: alt.lang.asm
Subject: Re: Intel 386/486 timing
Keywords: Intel 386/486, timing
Date: 18 Aug 92 10:11:34 GMT
Organization: Department of Computer Science, U of Copenhagen

terra@diku.dk (Morten Welinder) writes:


>Consider
>	Add	Bl,value
>	Adc	Bh,0
>	Mov	Al,[Bx]

>or even

>	Xlat

>Both execute in 3 cycles (assuming a code segment of the correct size).

SORRY!           4 cycles

>Morten Welinder
>terra@diku.dk

Morten Welinder
terra@diku.dk
From: amodra@ucs.adelaide.edu.au (Alan Modra)
Newsgroups: alt.lang.asm
Subject: Re: Intel 386/486 timing
Date: 18 Aug 92 01:56:19 GMT
Organization: Information Technology Division, The University of Adelaide, AUSTRALIA

From article <1992Aug13.101917.10369@ifi.uio.no>, by tjalveg@ifi.uio.no (Tjalve Godager):
>
>     Me and a friend are writeing some 32-bits assembler code on a 486
> for the first time. Due to the 386/486 instruction set, it is easy to
> "optimize" many instructions into just one or two, ie:
>
>       MOV     AL, value
>       XOR     AH, AH
>       ADD     BX, AX
>       MOV     AL, BYTE PTR [BX]
>
> into something like this:
>
>       MOVZX   AX, value
>       MOV     AL, BYTE PTR [EAX+EBX]  (assuming EAX=AX, EBX=BX)
>
> What we would like to know is, which of the two soulutions are the
> faster? Does anybody have the complete 386/486 instruction times, or
> a ftp address?
>
> Thanks,
>        Tjalve
                          Clocks
                        386     486
mov     al,value        2/4     1
xor     ah,ah           2       1
add     bx,ax           2       1
mov     al,[bx]         4       1

movzx   ax,value        3/6     3
mov     al,[eax+ebx]    5       1 (maybe 2)

Clock counts assume CPU doesn't have to wait around for anything, i
instruction is prefetched, no waits on any bus cycle etc.  The 486 adds
cycles sometimes depending on the destination of the preceding instruction.

Just looking at clock cycles doesn't tell the whole story: Really good
optimisation is a tricky business.  Some of the things you need to
consider:

        1) algorithm - spend 90% of your time tuning this
        2) register usage - try to minimise memory access (and push & pop)
        3) word & dword alignment of instructions and data - this isn't
           always obvious - the 386SX sometimes does better if the start of a
           code loop is aligned on an odd multiple of 2 boundary rather than
           a dword.
        4) length of instruction
        5) instruction ordering
        6) clock counts (tip: DEC CX; JNZ DEST usually faster than LOOP DEST)
        7) where code/data is in memory - system architecture can affect
           fetch times.  eg. page mode DRAMs
Newsgroups: alt.lang.asm
From: chbl@sbustd.rz.uni-sb.de (Christian Blum)
Subject: Re: Intel 386/486 timing
Organization: Studenten-Mail, Rechenzentrum Universitaet des Saarlandes
Date: Fri, 14 Aug 1992 23:13:21 GMT

spc@pineal.sci.fau.edu (Sean 'Captain Napalm' Conner) writes:
> In article <1992Aug14.101918.5618@coli.uni-sb.de> chbl@sbustd.rz.uni-sb.de (Christian Blum) writes:
> >First of all, te above can be written with one cycle off on 8086s:
> >xor ax,ax
> >mov al,value
> 
>   Wouldn't
> 
> 	move	ax,value
> 
> be faster?  Or is value a variable somewhere else in memory?
> (in which case, the syntax should be mov al,[value] 8-).

From the context I exspect value to be a byte, not a word. If it's a
word, you're right. The syntax with [] is not necessary with most
(all) assemblers.

Chris

P.S. Follow-ups useless. I'm off for 4 weeks... from now on.

Newsgroups: alt.lang.asm
From: chbl@sbustd.rz.uni-sb.de (Christian Blum)
Subject: Re: Intel 386/486 timing
Organization: Studenten-Mail, Rechenzentrum Universitaet des Saarlandes
Date: Fri, 14 Aug 1992 10:19:18 GMT

tjalveg@ifi.uio.no (Tjalve Godager) writes:
> 
>     Me and a friend are writeing some 32-bits assembler code on a 486
> for the first time. Due to the 386/486 instruction set, it is easy to
> "optimize" many instructions into just one or two, ie:
> 
> 	MOV    	AL, value
> 	XOR    	AH, AH
> 	ADD    	BX, AX
> 	MOV    	AL, BYTE PTR [BX]
> 
> into something like this:
> 
> 	MOVZX   AX, value
> 	MOV     AL, BYTE PTR [EAX+EBX]  (assuming EAX=AX, EBX=BX)
> 
> What we would like to know is, which of the two soulutions are the
> faster? Does anybody have the complete 386/486 instruction times, or
> a ftp address?
> 
First of all, te above can be written with one cycle off on 8086s:
xor ax,ax
mov al,value

Second: the second one is surely faster.

Chris

Newsgroups: alt.lang.basic
From: markh@csd4.csd.uwm.edu (Hunk)
Subject: BASIC <-> C translators
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Thu, 13 Aug 1992 16:24:11 GMT

   Is there any public domain software that does even rudimentary BASIC to C
translation?
Newsgroups: alt.lang.basic
From: philco@microsoft.com (Phillip Cooper)
Subject: Re: Linking in C code with QB.
Date: 20 Aug 92 15:14:41 GMT
Organization: Microsoft Corporation

In article <1992Aug18.200009.19106@news.cs.brandeis.edu> cos@chaos.cs.brandeis.edu (Ofer Inbar) writes:
>
>philco@microsoft.com (Phillip Cooper) writes:
>>The way our interlanguage calling capabilities are implemented, 
>>each new product is designed to be compatable with whatever the
>>current version of other languages are when it is released.
>>
>>In other words, when QB 4.5 was released, QC 2.10 was the current
>>version of QuickC.  QuickC 2.5 was just a twinkle in our language
>>developer's eyes. :)  Obviously, it would be a little difficult to
>>ensure compatability with a product that didn't even exist!
>
>  You've just contradicted yourself in these two paragraphs, though.
>When QuickC 2.5 was designed, QuickBASIC 4.5 was the current version
>of QuickBASIC, so QuickC 2.5 should have been designed to be
>compatible with it.

Not at all.  When doing interlanguage calling between Basic and another
language, Basic must be the startup language.  This means that any 
object module linked in must be compatable with it, not the other way
around.

>  I would construe this little tidbit as
>confirmation of my view that Microsoft thinks PDS is the "current
>version of QuickBASIC".  That is, QuickBASIC has been discontinued and
>replaced with PDS.  If this is so, then QuickBASIC's price has jumped
>*very* dramatically, and this does indeed "suck".
>

That *would* suck.  I agree.  Fortunately, nothing could be further
from the truth.  

>Yet another reason why QuickBASIC is desperately in need of upgrading...
>And why we desperately need another Borland in this market.
>

As has been (prematurely) brought up in this group before, it is quite
likely that a major product announcement regarding our DOS Basics will
be made quite soon.  Like, in the next couple of weeks or so.

>  --  Cos (Ofer Inbar)  --  cos@chaos.cs.brandeis.edu
>    double value;                /* or your money back! */
>    short changed;               /* so triple your money back! */
>      From cons.c in the perl source code, by Larry Wall
From: pharris@roseworthy.adelaide.edu.au (Paul Harris)
Newsgroups: alt.lang.basic
Subject: Quickbasic/Qbasic
Date: 20 Aug 92 05:45:33 GMT


First, Thanks for the FAQ. It clears up a few things.

If QBASIC is a cut down QuickBASIC why does QB read GWBASIC files but not
QuickBASIC Files?

I am fairly new to NEWS, but to add to the argument being COMP.LANG.BASIC
may help the acceptance of BASIC as a "true" programming language now that
"proper subroutine calls" and structured programming are supported. In my
simple view (and I have done little FORTRAN lately) FORTRAN and BASIC have
moved toward common ground in some ways.

Regards, Paul Harris
PHarris@Roseworthy.Adelaide.EDU.AU
Newsgroups: alt.lang.basic
From: philco@microsoft.com (Phillip Cooper)
Subject: Linking in C code with QB.
Date: 11 Aug 92 18:26:15 GMT
Organization: Microsoft Corporation

Someone responded to my post about not being able to link object
modules created with QC 2.5 with QB4.5.  I've since lost the
article, but I wanted to respond.  His viewpoint basically was that
this "sucked" (tm).  I couldn't agree more, but here is a little
explanation about why this is.  

The way our interlanguage calling capabilities are implemented, 
each new product is designed to be compatable with whatever the
current version of other languages are when it is released.

In other words, when QB 4.5 was released, QC 2.10 was the current
version of QuickC.  QuickC 2.5 was just a twinkle in our language
developer's eyes. :)  Obviously, it would be a little difficult to
ensure compatability with a product that didn't even exist!

Just an FYI...
Phil Cooper
From: ebazergh@gmuvax.gmu.edu
Newsgroups: alt.lang.basic
Subject: WANTED: Serial port data exchange code
Date: 22 Aug 92 17:34:54 -0500
Organization: George Mason University, Fairfax, VA.

I'm looking for code which can help me add an HEAD-TO-HEAD modem play
feature to a game I am currently writing for IBM Compataibles.
What I need is the basic way of getting the computers on both sides to wait
until the other is ready, then the actual exchange of info while the
game is being played. I already have a library of serial routines, so please
don't send me a reply with library names. I need actual code or even
pseudo-code in order to help me implement this feature.
 
Can anyone help me?
 
THANX!

P.S.  Please reply by E-MAIL, I rarely visit this newsgroup...

 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Eric R. Bazerghi                    |      BitNet:  EBAZERGH@GMUVAX.BITNET
 Student                             |    InterNet:  EBAZERGH@GMUVAX.GMU.EDU
 George Mason University             |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 4400 University Drive               |  What do you have when a room is half
 Fairfax, VA  22032                  |  full with women who have PMS and half
                                     |  full with women with yeast infections?
                                     |  A whine and cheese party!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From: cermak@gandalf.rutgers.edu (Rob Cermak)
Newsgroups: alt.lang.basic
Subject: Overlays
Keywords: PDS 7.1
Date: 19 Aug 92 17:35:22 GMT
Distribution: usa
Organization: Rutgers Univ., New Brunswick, N.J.

Getting into Overlays:

I'm working with Microsoft's PDS 7.1.  Here is a list of questions that
I need answered.


1.   If the main routine is say X.BAS and you have a function in
	Y.BAS.   Do you just compile X and Y and obtain OBJ files
	and then just LINK X + (Y)?  With the correct options of course.

     Then if X calls the function in Y, Y will load and do what it can
     and return to X?

2.   If X opens files & device(COM1 & COM2).  Are these preserved
     across overlay boundaries?  Just wondering if file pointers are
     preserved with the data, and hoping that the COMMUNICATION BUFFERS
     are PRESERVED ALSO!??

3.   In the restrictions, it says that overlays only work in MID/LARGE
	models?  I don't think this BASIC knows the difference if it is
	mid/large...should I worry about this?  I'm programming in 
	straight BASIC.

4.   Are communication buffers preserved if a DOS BASIC program shells
	out to another program?

5.   Are all the COMMON SHARED variables preserved across overlays?

Thanks indefinitely,
		Rob.

Please restrict comments to the PDS package.
-- 
Rob Cermak			        EMAIL : cermak@gandalf.rutgers.edu
Prog/Tech Rutgers-Cook College		USMAIL: Rutgers University
FAX             :908 932-7922 	 	        Department of Meteorology
Meteorology Dept:908 932-9387			Cook College  PO BOX 231
"Anticyclones make for great vacations."        New Brunswick NJ 08903-0231
Newsgroups: alt.lang.basic
From: philco@microsoft.com (Phillip Cooper)
Subject: Re: 1-900 number support
Date: 11 Aug 92 18:10:02 GMT
Organization: Microsoft Corporation

In article <1683E12E4F.ST21519@VM.CC.LATECH.EDU> ST21519@VM.CC.LATECH.EDU writes:
>>arrow keys.  Normally, this would not be a problem because you would
>>expect both keys to behave identically anyway.  If you are a registered
>>QuickBasic owner, you can call our programming support line (900)896-9999
>>for example code on this process.  Alternatively, you can access the
>>entire Microsoft knowledgebase on Compuserve by typing "Go MDKB" at
>>any prompt.  Query on "inkey$ trap quickbasic".
> 
>What information do we need to be prepared to offer when dialing this number?
>And what is the charge for this access? (1-900 number)
> 
>Thanks!

At this time, you do not need anything.  No registration number, etc.
That may change in the near future, however.  The charge is $2.00/minute
with the first minute free.  If you are blocked from calling 900 numbers,
there is a credit card line available where you are charged a flat fee
of $20.00 for the call.  That number is (206)646-5102.  

Again, this is for programming consulting services.  Not simple startup
or installation problems.  For those issues, you can call (206)646-5101.

Phil Cooper
jhsegal
Newsgroups: alt.lang.basic
Subject: Mouse In Basic
From: jhsegal@wiscon.weizmann.ac.il (Livy)
Date: Fri, 21 Aug 1992 19:11:58 GMT
Organization: Weizmann Institute of Science, Computation Center

Howdy!
Can anybody tell me how the hell I can use a mouse in GWbasic or QBasic?
I mean,something whch is for mouse like inkey$ for keyboard...
Well??...Can anybody help?
Thanx
Livy

Newsgroups: alt.lang.basic
From: philco@microsoft.com (Phillip Cooper)
Subject: Re: Quickbasic/Qbasic
Date: 21 Aug 92 15:05:44 GMT
Organization: Microsoft Corporation

In article <pharris.714289533@tellus> pharris@roseworthy.adelaide.edu.au (Paul Harris) writes:
>
>First, Thanks for the FAQ. It clears up a few things.
>
>If QBASIC is a cut down QuickBASIC why does QB read GWBASIC files but not
>QuickBASIC Files?
>

QBASIC can only save/read true ASCII files.  GWBASIC can save it's files
in either a tokenized format or as an ASCII file.  QBASIC (and Quickbasic
for that matter) can read the ASCII files, but not the Tokenized ones.

>I am fairly new to NEWS, but to add to the argument being COMP.LANG.BASIC
>may help the acceptance of BASIC as a "true" programming language now that
>"proper subroutine calls" and structured programming are supported. In my
>simple view (and I have done little FORTRAN lately) FORTRAN and BASIC have
>moved toward common ground in some ways.
>

>Regards, Paul Harris
>PHarris@Roseworthy.Adelaide.EDU.AU
From: boutell@cshl.org (Tom Boutell)
Newsgroups: alt.lang.basic
Subject: Re: Linking in C code with QB.
Date: 12 Aug 92 20:46:59 GMT
Organization: Cold Spring Harbor Laboratory

In article <1992Aug11.182615.19919@microsoft.com> philco@microsoft.com (Phillip Cooper) writes:
>In other words, when QB 4.5 was released, QC 2.10 was the current
>version of QuickC.  QuickC 2.5 was just a twinkle in our language
>developer's eyes. :)  Obviously, it would be a little difficult to
>ensure compatability with a product that didn't even exist!
>

True.

But ensuring that QC 2.5 could have backward compatibility with
QB 4.5, which *did* exist, would have been possible.

It seems more likely it just wasn't a priority.

In light of the fact that the PDS is being offered pretty cheaply
right now, though, it actually doesn't "suck" quite as much as I initially
thought, so I don't see the decision as callous neccessarily. It just
would've been a good idea to keep 2.5 backward - compatible, or
simply do a maintenance upgrade of QB 4.5 to meet it.


-- 
Tom Boutell, boutell@cshl.org

Clausthaler is the best non - alcoholic beer in the known universe.
Newsgroups: alt.lang.basic