🚀 go-pugleaf

In article <1992Sep30.003633.15973@microsoft.com> stevepo@microsoft.com (Steven Podradchik) writes:

>[defense of VBDOS deleted]

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

Steve, I'm not criticizing your move to allow graceful transitions 
to Windows. My product is a sales and marketing tool, currently 
written with Crescent Software's QuickPack Pro, Quick Screen, and 
linked with Pocket Soft's RTLink. Those add on packages give me 
the ability to program a professional DOS application. VBDOS will
probably replace many of those add-ons in my next version.

Moving literal strings to far memory is a huge improvement--I'd missed
that, as it wasn't mentioned in the ads or magazine reviews I read. I
had been using Crescent's preprocessor which converted string literals
to function calls (talk about a kludge!). But having variable length
string array descriptors and such still stuck in DGROUP remains a problem. 

The great limitation of QBX is that I am constantly having to fight
with DGROUP and other memory limitations when programming in the 
enviroment. Once I get it running in the environment, I compile and
have to fight with a new set of memory limitations. A professional
language should not have these problems. (This on an 8MB machine
with about 15K lines of Basic code and some Crescent assembler rountines
linked in.)

No, I won't be sending my VBDOS back in. It's the only game in 
town. But I was expecting to see the memory limitation quirks 
go away.