🚀 go-pugleaf

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