🚀 go-pugleaf

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

philco@microsoft.com (Phillip Cooper) writes:
>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.

Compatibility is a two way street.  If two software products are not
compatible with each other, pinning the blame on one of them to
absolve the other is ridiculous.  Especially when the two programs
were written by the same company.  QB 4.5 and QC 2.5 are incompatible
with each other, and the QC programmers knew this when they wrote the
thing.

The fact that Microsoft has let this situation go on for so long,
letting QB get further and further behind the times, is to me a very
convincing indicator that Microsoft no longer considers QB to be a
current product.  It's not compatible with current versions of other
Microsoft language products, it's not compatible with current video
standards, and it has picked up no new features in four years.  It
doesn't know 286s or 386s, has no conception of EMS and XMS, and its
only interface to the mouse is through interrupts.

>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.

Over three years ago, a Microsoft programmer told me, unofficially,
that pointer support was planned for a future release of QuickBASIC.
Back then, I was very excited about the product.  In a very short
time, I had upgraded from 2.0 to 3.0 (for $15), and then to 4.0 (for
$25) and then 4.01b (free).  It was being continuously enhanced, and I
had the feeling that it was backed by an active development team
always trying to make it better.  I didn't complain about its flaws,
becuase they were being fixed regularly.  QuickBASIC was alive.

QuickBASIC is now dead.  It has stagnated for four years.  It is
behind the times.  It doesn't know anything about modern hardware.
If Microsoft puts out a perfunctory maintenance release, without
pointer support, and charges some outrageous price like $40 or $50 for
it, that'll be the last straw as far as I'm concerned.  They might as
well let it die a peaceful death, because I'm not going to have
anything to do with them anymore, if I can help it.

  --  Cos (Ofer Inbar)  --  cos@chaos.cs.brandeis.edu
  --  WBRS (BRiS)  --  WBRS@binah.cc.brandeis.edu  WBRS@brandeis.bitnet
 FidoNet: Ofer Inbar on 1:101/310  --  Ofer.Inbar@f310.n101.z1.fidonet.org
 The Boston Computer Society IBM PC User Group TBBS, (617) 332-5584

In article <cos.714791954@chaos.cs.brandeis.edu> cos@chaos.cs.brandeis.edu (Ofer Inbar) writes:
>philco@microsoft.com (Phillip Cooper) writes:
>>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.
>
>Compatibility is a two way street.  If two software products are not
>compatible with each other, pinning the blame on one of them to
>absolve the other is ridiculous.  Especially when the two programs
>were written by the same company.  QB 4.5 and QC 2.5 are incompatible
>with each other, and the QC programmers knew this when they wrote the
>thing.
>
I knew you were going to say that!  And you are absolutely correct.
This whole thing is really an outgrowth of a slight misstatement of
mine in an earler post.  I said:

  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.

What I meant to say was:

  The way that Basic's 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.

Notice that I added the word "Basic's" to the sentence above.  I don't
know what the policy regarding new versions of other languages are, but
Basic is designed to be compatible with the current versions of other
languages when it is released.

If we went the way that YOU want to go we would still be using the object
file format from MASM 1.0.  Obviously, you could never change the format
for new versions because it would break compatability with an earlier
version of some other language product.  This means that no new advances
in linker technology or overlay management could ever be implemented.

Fortunately, the people who design our languages do not agree with you.
 
>The fact that Microsoft has let this situation go on for so long,
>letting QB get further and further behind the times, is to me a very
>convincing indicator that Microsoft no longer considers QB to be a
>current product.  It's not compatible with current versions of other
>Microsoft language products, it's not compatible with current video
>standards, and it has picked up no new features in four years.  It
>doesn't know 286s or 386s, has no conception of EMS and XMS, and its
>only interface to the mouse is through interrupts.
>

QB certainly was a current product until earlier today.  We just announced
Visual Basic for DOS which is the upgrade for QuickBasic 4.5.  It will
run all QuickBasic code, and now comes with built in support for the
mouse, windows, menus, etc.  This is an AWESOME product, people.  i won't
go through your laundry list of QB's defects, but VBDOS now supports
native '386/'486 code generation, the new MOVE overlay manager will
automatically use EMS and/or XMS memory, and it has built in support for
the Mouse (without having to call interrupts).  What more could you
want??

>>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.
>

<paragraph about an unofficial comment Ofer claims an MS programmer
 gave him deleted>

>
>QuickBASIC is now dead.  It has stagnated for four years.  It is
>behind the times. 

  This is all very much true.  QuickBasic is now dead.  There will be
no QuickBasic 5.0 (or any other version of QuickBasic for that matter).

> It doesn't know anything about modern hardware.
>If Microsoft puts out a perfunctory maintenance release, without
>pointer support, and charges some outrageous price like $40 or $50 for
>it, that'll be the last straw as far as I'm concerned.  They might as
>well let it die a peaceful death, because I'm not going to have
>anything to do with them anymore, if I can help it.
>

I can't understand how you could call $40.00 "outrageous" for a software
upgrade.  We can't even pay for the disks, duplication, packaging,
mailing, and administrative overhead for much less than $40.00.  And
if there are additional manuals to be included, forget it.

This is not a perfunctory maintenance release.  This is a gargantuan,
total overhaul of our entire DOS Basic line.  VBDOS is not the next
version of QuickBasic, it is a vastly improved, brand new DOS basic that
current owners of QuickBasic will be allowed to upgrade to.  

Phil Cooper

In <1992Sep01.212456.7812@microsoft.com> philco@microsoft.com (Phillip Cooper) writes:

>This is not a perfunctory maintenance release.  This is a gargantuan,
>total overhaul of our entire DOS Basic line.  VBDOS is not the next
>version of QuickBasic, it is a vastly improved, brand new DOS basic that
>current owners of QuickBasic will be allowed to upgrade to.  

Phil,

As a PDS owner (7.1), I'd be very curious what the upgrade offer will
look like (if it'll be any different). Also would like to find out if
VB/DOS will run on my XT or, as is the current trend, will it require
a '286 or higher.



-- 
Jeffery Foy -- Either: jfoy@glia.biostr.washington.edu -or-
                       foysys!jeffery@cs.washington.edu
             *** FREE BILL & KATHY SWAN ***
-*- Happy as a clam to be using Professional YAM -*-  :)