🚀 go-pugleaf

In <1992Sep1.013315.25064@julian.uwo.ca> wlsmith@valve.heart.rri.uwo.ca (Wayne Smith) writes:

>It's probably futile, but if there ever will be a version 5, it should have...

Definitely futile. QuickBASIC is, essentially, a non-product. Microsoft
is going to be announcing a Visual BASIC for DOS (that's right, for DOS)
that will put the final nails into QuickBASIC's coffin. That should
happen any day now (early September according to my sources).

>- pointer (mouse) support

Said to be in VB/DOS. QB has the support for it (the rodent) in the
environment. If you mean rodent support for your own programs, you should
get Microsoft's PDS 7.1. It has a nice rodent module (user-interface
toolbox if you prefer).

>- more choice in screen editor modes (up to 132 X 66 ?)

I'd kill for 132x66 on my monitor. But this bloody Paradise VGA card only
goes to 132x43 and even then I get these little CHR$(254) characters at the
head and tail of each line. And the BLINK! Nasty!

>- support for in-line machine language code? (Wow, that would be cool)

Uh, I dunno if I like that idea. Much prefer external asm routines.



-- 
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 -*-  :)

In article <jfoy.715320808@glia> jfoy@glia.biostr.washington.edu (Jeff Foy) writes:
>>It's probably futile, but if there ever will be a version 5, it should have...
>
>Definitely futile. QuickBASIC is, essentially, a non-product. Microsoft
>is going to be announcing a Visual BASIC for DOS (that's right, for DOS)
>that will put the final nails into QuickBASIC's coffin. That should
>happen any day now (early September according to my sources).

I have VB (version 1 I guess, it doesn't say on the box) and I don't
like 
a) won't do peeks/pokes/in's/out's
b) can't do a CALL ABSOLUTE
(I do heavy duty data aquisition from custom hardware, and use debug
to write high speed aquisition/storage routines.  I then use bload
and bsave to move the routines into 'unused' memory areas (&h6000 to
&h9000), where they can be called from QB.  I use peek's and poke's to
set/alter the routines and to retrieve collected data.  Hey, it's fast,
painless, it works, no assembler to mess with, etc).
It would be nice to use VB to make a front-end for data display and
instrumentation control, but I guess it won't work the way I'm
doing it.

>>- pointer (mouse) support
>Said to be in VB/DOS. QB has the support for it (the rodent) in the
>environment. If you mean rodent support for your own programs, you should
>get Microsoft's PDS 7.1. It has a nice rodent module (user-interface
>toolbox if you prefer).

If there are no mouse functions in VB/DOS then it's a crock
(ie, let's say you've got a bit-map and you want to do image
analysis, so you want to display the coordinates of the mouse on the 
screen regardless of wheather or not you click any buttons).
like can you do this: x = MOUSEX : y = MOUSEY  ???

>>- more choice in screen editor modes (up to 132 X 66 ?)
>I'd kill for 132x66 on my monitor. But this bloody Paradise VGA card only

I've got a cheap ($70) 1 meg Trident based card that I can set to
132 X 66 (jeeze what small letters!), but when I go
qb /h, it goes into 80 x 50 (why can't it stay in 132 x 66?)

>>- support for in-line machine language code? (Wow, that would be cool)
>Uh, I dunno if I like that idea. Much prefer external asm routines.
I'd rather not mess with external libraries and junk.
If I wanted to do that, I'd also slide down the sharp end of a razor
blade on my balls, or learn C.

In <1992Sep1.052408.12646@julian.uwo.ca> wlsmith@valve.heart.rri.uwo.ca (Wayne Smith) writes:

>I have VB (version 1 I guess, it doesn't say on the box) and I don't
>like 
>a) won't do peeks/pokes/in's/out's
>b) can't do a CALL ABSOLUTE

I've never *personally* found a need for that stuff myself but I can see
why they didn't included that stuff in VB/Windows. Someone could go about
indiscriminately poking/peeking in/out-ing and possibly crash Windows
without realizing it. Not good for Microsoft's image of Windows being 
the perfect (sic) OS. [Shell, dammit, shell. :)]

>(I do heavy duty data aquisition from custom hardware, and use debug
>to write high speed aquisition/storage routines.  I then use bload
>and bsave to move the routines into 'unused' memory areas (&h6000 to
>&h9000), where they can be called from QB.  I use peek's and poke's to
>set/alter the routines and to retrieve collected data.  Hey, it's fast,
>painless, it works, no assembler to mess with, etc).

And, I'm sure, takes a helluva lot of patience. :) I'm pretty handy
with assembler code and couldn't see writing anything more than a
"hello, world" program with debug. [Fwiw, I consider debug to be
just one minor step up from cp/m-80's ddt.com]

>If there are no mouse functions in VB/DOS then it's a crock
>(ie, let's say you've got a bit-map and you want to do image
>analysis, so you want to display the coordinates of the mouse on the 
>screen regardless of wheather or not you click any buttons).
>like can you do this: x = MOUSEX : y = MOUSEY  ???

I don't know if it has that or not. I sure would like to see that
kind of thing though. What I'd really like to see, though, is direct
DOS calls for the rodent rather than the 0x33 Interrupt (mouse driver).
Your thought of x=MOUSEX:y=MOUSEY just gave me an idea. :)

>I've got a cheap ($70) 1 meg Trident based card that I can set to
>132 X 66 (jeeze what small letters!), but when I go
>qb /h, it goes into 80 x 50 (why can't it stay in 132 x 66?)

Considering that QB is at least four years old, I suspect we're very
lucky that we get 80x50 support. I'm sure there's a program out there
that can "lock" the video mode to whatever you like. Only problem is in
finding (and distributing! :) it. :)

>>>- support for in-line machine language code? (Wow, that would be cool)
>>Uh, I dunno if I like that idea. Much prefer external asm routines.
>I'd rather not mess with external libraries and junk.

I couldn't live without my external libraries. But then I'm not into
the environment mode of QB anyway. (I have PDS but the idea is the same)
Adding inline asm might be ok *if* they leave it as an option rather
than a requirement. (i.e. if the user wants to use external asm functions
they can or they can use the internal/inline asm)

>If I wanted to do that, I'd also slide down the sharp end of a razor
>blade on my balls, or learn C.

Learning C is fine. I make my living working in C++ but, at home, use
a combo of BASIC and ASM (Microsoft all the way! :)

Jeff

-- 
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 -*-  :)

and 
	- support for pointer. That is a must.
	- array inside structure (only available in PBDS7.1)
	- conditionnal compilation like in C
	- Some sort of Object Oriented feature


---
Robert Meunier                     Institut de Recherche d'Hydro-Quebec
Ingenieur                          1800 Montee Ste-Julie, Varennes
Internet: robert@ireq.hydro.qc.ca  Qc, Canada, J3X 1S1 
maintainer: BASIC mailing list request to basic-request@ireq.hydro.qc.ca

In article <Bu21uG.CCr@ireq.hydro.qc.ca> robert@ireq.hydro.qc.ca writes:
>
>and 
>	- support for pointer. That is a must.

	Actually I'd rather *not* see pointers in BASIC. As a person who codes
	all the time in C and likes it, I nonetheless like the purity of
	BASIC's call - by - reference, no - pointers syntax. Call by reference
	provides power enough at the scale BASIC is intended to work. (Indeed,
	it covers most of the normal uses of pointers.) Yes, I know a heap would
	be handy, but the language also has variable length strings, another
	common reason for pointer usage... I'd say it would be a mistake.

>	- array inside structure (only available in PBDS7.1)

	Agreed. It's a very nice touch. I'm also tempted to ask for anonymous unions,
	but they might be more trouble than they're worth.

	I'm told there's a shareware BASIC compiler out there. Perhaps if we 
	supported that author we might get the features we're asking for.

	Some of these features may well be in Power BASIC already, come to think 
	of it. Anyone know?

>	- conditionnal compilation like in C

	Ah, the eternal #ifdef. The problem here, with both conditional compilation
	and macros, is that they're somewhat at odds with the threaded -
	interpreter environment. Not saying it's impossible, but doing them inside
	that environment would, I suspect, be very tricky indeed.

	However, it's quite easy to write your own preprocessor, if you're willing
	not to use the environment.

>	- Some sort of Object Oriented feature

	Not a bad idea. Visual BASIC is already moving in this direction. But
	you can write very object - oriented code with the existing user - defined
	types and a strong naming convention, again thanks to the wonders of
	call by reference.


-- 
Tom Boutell, boutell@cshl.org

Clausthaler is the best non - alcoholic beer in the known universe.