DGROUP usage: PB vs. QBX; DOS vs. LINUX

[William Schmidt]

I am using Microsoft's PDS 7.1 (QBX, QuickBasic Extended)
with the DOS 6.22 operating system to implement a powerful
and proprietary system for trading the financial markets.
I absolutely refuse to use any Windows operating systems;
in my experience, they are all unstable; they are impossible
to use for an application that requires 24/7 reliability.

I have purchased PB 3.5 for DOS but have not implemented it,
prefering to work in the more familiar, albeit miserable,
Microsoft environment. I have gone as far as I can with
PDS 7.1, and am now looking at PowerBasic for the final
working version of this software.

There are several memory limitation problems with the
QBX 7.1/DOS 6.22 environment. Our fully implemented
software will involve 25-30 program modules and data files.
Most of these program modules and data files can be divided
into blocks of less than 16K so that they are put into EMS.
But every program module must be supplied with variables and
data using a $INCLUDE file; this exhausts the 64K of DGROUP
memory and limits the number of program modules to 15 maximum.

Am I overlooking some programming trick that will work
around part or all of this DGROUP memory limitation problem?

I understand that PowerBasic is sparing of DGROUP usage.
How much improvement can I expect with PB vs. QBX?

I also understand that LINUX does not have the arbitrary
memory constraints of DOS. Do I assume correctly that the
forthcoming LINUX version of PowerBasic will abolish this
DOS/QBX DGROUP memory limitation problem?

This is my first post to this forum. I have checked all
the archived posts but found no reference to this topic.
I would appreciate any comments or suggestions. Thank you.

Bill Schmidt

[email protected]

------------------

[Lance Edmonds]

AFAIK, Dgroup is always limited to 64Kb. I cannot answer how DGROUP usage in PB compares to QBX/PDS since I'm not a MS-BASIC programmer.

However, it is not altogether clear, but it does sound like you are compiling one HUGE application. Possibly you could consider splitting the program up into smaller modules, with one EXE and a set of CHAIN (.PBC) files, complete with COMMON statements to pass data between modules. This may be enough to alleviate the constriction of a large DGROUP allocation that is common to all modules, but the best choice of approach will really depend on your app design.

There may be other tricks you can use to minimize the memory "hit", but we'd have to know a lot more about your app to make any specific/worthwhile suggestions. For example, using 1-subscript arrays instead of scalar fixed-length strings or ASCIIZ strings may help.

Anyway, please let us know more about the "internals" of your project, and we'll see what we can do to help further.

That said, for such a large and demanding application, dismissing a compiler like PB/CC for Windows is a serious oversight IMHO. Stability of PB/CC apps is chiefly determined by the robustness of the code, not the compiler. When set up correctly, Windows can be a very stable platform, and offers many features that are just too difficult to implement in DOS.

IOW, if your finished apps will run under Windows 9x or better, you might find that PB/CC will lift the barriers your current app design faces, for example, because you can use up to 2Gb of flat memory for arrays and data, there is no 64K Dgroup limit, you get native TCP/UDP communications functions to create email apps, http apps, ftp apps, etc.

Thanks!

PS: The Linux version of PowerBASIC is not yet ready for shipping, but I can tell you it is modeled along the same lines as the Console Compiler...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[OTTO WIPFEL]

Bill,

I started programming with Quick Basic back in 1982, Bob Zale's Borland's
TurboBasic, tried Microsoft's PDS 7 and quickly realised what their way of
programming was all about, BLOATWARE.

Changed to the first version of PowerBasic for DOS and have not regretted it
since ! It has helped me make a bit of money from Very Satisfied clients.

I have written many complicated Accounting Systems, using up to 50 PB-DOS 3.5
EXEs each, linked to a Central MENU.EXE and each other. All in DOS 6.22 and at
Windows up to 98 SE Command prompts.

Have a look at: www.ottowipfel.btinternet.co.uk

I am EXECUTING from EXE to EXE and as Lance points out, there is also CHAIN.

Unless you need GRAPHICS, Non-Epson ESC/P2 printer support and complicated
communications procedures between sites, you are better off sticking with
PURE DOS, either DOS 6.22 or Booting Windows straight to a PURE DOS prompt.

But there is also Lance,s DOSPRINT if you need to print to an non ESC/P2
Inkjet or Laser from PURE DOS. BTW, the new EPSON C80 Inkjet is still ESC/P2
compatible, fast, brilliant, 4 separate ink cartridges and cheap, bought one
last week.

However, Multi-ply continuous stationery does need DOT MATRIX printers, most of
which are EPSON ESC/P2 capable.

And as I just learned from Lance's article in the PowerBasic Gazette #28 there
are also many ways of SHELLing Windows APIs from within a PB-DOS 3.5 application !

My client sites, including my computers, link with each other and their Head
Offices by means on Analog Modems, using PcANYWHERE 5.2 for DOS on ordinary
Analog Phone lines or the Analog Services also provided as part of the U.K.
British Telecom Business and Home ISDN Services.

I prefer to keep WINDOWS out of everything I am doing for my clients. Hardware
and Software requirements are a fraction of what Windows must have.

NETWORKING ? I would use NOVELL's NETWARE, now Version 6 !

Schmidt ? Not a relation of ERIC at Novell ?

The choice is yours !


------------------




[This message has been edited by OTTO WIPFEL (edited April 09, 2002).]

[Lance Edmonds]

Thanks for the plug Otto! In essence, DOSPRINT enables DOS applications to print to any kind of printer that has a Windows printer driver installed - your code only needs to cope with ESC/P or ESC/P2, and DOSPRINT will handle the rest of the task for you, even with USB printers, Windows-only, and networked printers, etc.

DOSPRINT is really a 32-bit Windows application (which uses the techniques described in Gazette #28), and therefore requires that Windows 95 or better is running (yes, it supports 2000 and XP!).

For more info and a fully functional demo version, please see http://www.dosprint.com

Thanks!

Regards,
Lance