🚀 go-pugleaf

Hello all,
I'm the product manager at Microsoft for all DOS Basic products including
QB, PDS, VB/DOS Standard Edition, and VB/DOS Pro.
I've seen some misconceptions about VB/DOS that I'd like to clear up.

>  (1) Seriously incompatable with visual basic. Writing a portable
>      application is not easy. Since I thought (from the Microsoft
>      come-on that I responded to) that it was "visual basic for
>      windows). It isn't!

I would like to hear more about this.  The feedback from thousands
of other users is that they found it shockingly easy to go from
VB/Win to VB/DOS and vice versa.  The two products have identical 
event-driven programming interfaces (i.e. SUB Command1_Click),
have the same 15 standard controls in the toolbox, and have generally
the same Properties on each object.  VB/DOS even supports things that you
wouldn't expect in a DOS product like Drag&Drop, the Clipboard, Icons,
and many other things.  True, you can't call a WinAPI from DOS or use
a DLL (use a standard .LIB file instead).

>  (2) You cannot put graphics on forms. This is a BIG, BAD thing as
>      far as I am concerned.
Very true.  Unfortunately the storing VGA bitmap screens with DOS
memory limitations is not practical.  Additionally, this would offer
little benefit to customers since it would be a subset of what VB/Win
would offer.  If you need graphics on forms, we suggest that you use
VB/Win.  By the way, you can mix full-screen graphics and text-mode
forms within the same application.  Try something like this:

SUB ShowGraph_Click ()
   Screen.Hide  'this is a new Hide method to the VB/Win screen object.
                'as the name implies, it temporarily HIDEs forms so you
                'can pop into full screen graphics
   Screen 12 'VGA hires mode
   circle (300,200),100  'note the syntax for Circle, Line, Pset etc. are
                         'identical for both VB/Win and VB/DOS
   do while inkey$="":loop  'standard QB style code to wait for a keypress
                            'Also demonstrates that you can use standard
                            'QB code within an app that is primarily
                            'VB style code.
   screen 0                 'Restores text mode
   screen.Show              'Restores all the forms exactly as they were.
END SUB
   
>  (3) The forms look tacky - I was hoping for a windows-looking
>      interface, but I have yet to see anything that looks as good -
>      I believe this is because the screen mode used for forms is
>      a low resolution mode.
Obviously this is a matter of preference.  Most people I've shown VB/DOS
to have first asked if it was running in graphics mode or if this was VB/Win.
Most people also seem to like the 3D effect that we put on our buttons and
text fields.
Perhaps the 'tacky' refered to the fact that the VB/DOS controls looked
big relative to VB/Win controls.  By default, VB/DOS runs in 25 line mode.
Try invoking VBDOS like:
VBDOS /H
That tells VB/DOS to use all the lines your video card can handle (43 or 50
for EGA and VGA systems, of course).  Use the WIDTH statement to set
the # of lines for applications that you create.

>  (4) The .EXE file I created on a dead simple, test application, crashed
>      my system whenever MKS Toolkit shell is running. This seems a bit
>      unfriendly.
>
I'm not familiar with that system but I'm not aware of any crashing
incompatibilities at this time (plenty during Beta testing, of course).
I would be interested in any more information you have on this.

>Now, I realize that having event orientation and a forms designer is
>better than not having it, but come on, Microsoft, why did you try
>to sell this to me as if it were Visual Basic running on DOS? Why didn't
>you advertise that this is really just basic with a forms front end and some
>event handling?

You understand, of course, that VB/Win is QB plus forms plus an event-driven
programming model.  VB/DOS is the same except that it ALSO has complete
backward QB/PDS compatibility.  Can you be more specific about how VB/DOS
isn't really VB?  I heard a few people make that comment early in the product
design but this is the first time anyone who has actually seen the finished
product has made that statement.

Thanks,
Steve Podradchik