🚀 go-pugleaf

>I will have to agree with this. I'm a big fan of Basic PDS 7, but am
>quite disappointed with VBDOS Pro. It does provide something of a path
>toward migrating Basic DOS apps to VBWIN, but provides little else. 
>As far as I can tell, none of the serious memory limitations of PDS 
>have been solved, with the exception of a slightly smarter overlay
>linker (still not at good as RTLink). All the 64k DGROUP limitations
>persist. 

The primary purpose of VB/DOS is to allow developers to simultaneously
develop appliction for the 2 most popular PC platforms -- DOS and Windows.
Our research showed that most developers have to create DOS applications
today because their customers demand that.  But they can see the writing on
the wall -- that Windows will be the dominant platform in a few years.
Additionally, VB/Win was hailed as an incredibly productive development
tool because you could literally draw the user interface (previously
the most time consuming part of creating most apps) then add code that
tells each object how to respond to specific events.  That same capability
is now available for DOS.  Certainly it's a matter of personal preference
but I would rather just draw a command button then use lots of
LOCATEs, PRINTs, and INKEYS.  Of course, you could also add a 3rd party
screen creation library to PDS.  While that solution may make sense for
some people, I see it as having some sever drawbacks:

1.  Harder to use because you must make Calls to use the routines.  In
VB/DOS, just like in VB/Win, controls that you draw on the form simply
work ... command buttons 'know' how to press and do so with no code,
scroll bar scroll, forms know how to maximize and minimize themselves,
etc.

2.  Even the addons that have visual design tools generally GENERATE
Call code for you.  All the messy underlying code is still there.  As you
know, the # of bugs in an app is proportional to the # of lines of code
in it.

3.  Code-generating screen tools do not allow you to go back and
edit a previously created form without wreaking havoc on the code
you put in between the generated lines.

4.  Cannot be as robust as the VB/DOS implementation unless they
wrote the tens of thousands of lines of assembly code required to
effectively recreate almost every nuance of the Windows intereface.
That means Icons, Drag & Drop, Clipboard, Max and Minimize buttons,
etc.

5.  Most importantly...Forces you to throw away all your work when
you move to Windows.  The whole point of VB/DOS is that today's
DOS code is very highly protected when you move to Windows.  Will it
be perfect?  Probably not but you're 95% of the way there.

We also did add some pretty cool new features like OPTION EXPLICIT --
this tell VB/DOS to disallow on-the-fly variable generation.  Variables
must be declared (DIM foo as integer, etc.) before being used.  THis is 
a great typo saver.  This is an optional statment that you can add to
modules individually so you can mix older code without Option Explicit
with new code that uses Option Explicit.  And now string literals like
Print "STEVE" will be stored in Far memory in compiled apps.  In PDS, that
line would have consumed dGroup space.

And, of course, VB/DOS Pro is the first Microsoft compiler to offer
386-specific code generation.

Honestly, unless you're convinced that DOS will live forever and
you will never need to develop for both DOS and Windows, you owe yourself
at least looking at VB/DOS.  Remember that, if you don't like VB/DOS,
it can be returned (60 day money back guar.)

Thanks, Steve Podradchik