Announcement

**Lance Edmonds** · 11 Dec 2001, 03:14 AM

Some good ideas, Javier. A couple of points though:

- DOS Protected mode IDE to increase the limit of 64K per file and allow to debug big programs easily.

The IDE uses EMS/XMS already - it can open pretty large files - certainly much more than 64kb.

- Ability to generate DOS protected mode executables.

Thats a big ask. Simply put, all the RTL would need significant rewrite, and I'm not sure that such an undertaking would be taken given the potential market for the DOS compiler is shrinking as compared to Windows compiler.

If protected mode 32-bit code is required, then PB/CC would be the best answer... PB/CC gives you 2Gb of flat memory to play with without the need to switch in and out of protected mode to call DOS functions, etc. Also, native Win32 protected mode apps run faster than 16-bit DOS apps and this level of performance and features can be realized TODAY!

- Benchmarks in your web site, comparing it with QuickBASIC 4.5, Microsoft PDS 7,1, and Turbo Basic 1.1, in the way of the features table already available.

Benchmark against long-since-discontinued products? Interesting idea.

- Special bundle including PB/DOS 4.0 (?) and PB/CC 3.0 (?) at a special price.

Anything is possible...

And now the impossible suggestion: better executable speed and less size, seems impossible, but you guys, have been done it since my first PB/DOS version 2.0!

Thanks for the compliment, we do appreciate that!

JFYI, PB/DOS has to fit it's entire RTL within a single 64K segment, so adding "big" features means increasing the RTL size (and this means lots of far-addressing changes and more memory consumption), or R&D would need to drop some features to make room for the new features.

Finally, I will forward your entire list of suggestions (some are already on the wish list!) but I'm not going to suggest that I can anticipate what R&D will come up with - they are a bunch of very clever and dedicated folks - we'll just have to wait and see what they decide is the in the best interests of the compiler whilst being commercially viable.

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

**Javier Gutierrez** · 11 Dec 2001, 03:43 AM

What about the ability to link PB/CC executables against a DOS extender instead?

Why? Since Windows 95 or better would need to be running, I can't imagine why you'd want to saddle a 32-bit Windows app with a DOS extender? I'm not even sure it would be technically possible.

"Benchmark against long-since-discontinued products? Interesting idea.

"
These are the only competitors available.

Since they are basically extinct products, I'd personally not classify them as "true" competitors.

Additionally, none of those products are still suppported by the manufacturer, whereas PB/DOS continues to be supported and PowerBASIC are committed to <U>at least</U> one more major upgrade in the future.

In this respect, we'd prefer to leave the benchmarking as an exercise for the reader - we know we have a proven winner with PB/DOS.

**Gary Akins** · 20 Dec 2001, 12:38 PM

Javier - perhaps because not everyone is using PB/DOS programs within the Windows environment?

Pure, non-Windows-contaminated DOS is still very much alive in the embedded-systems space, where it is highly desirable to be able to get your entire O/S, application program(s), and user data into a cheap 16 or 32Mb FlashRAM module attached to a tiny 386 or 486-based single-board PC. (PC/104, DIMM-PC, or other such form factors). In this kind of application, no, Windows 95 (or worse) would not be running, nor would there be room to install it.

If there are insurmountable technical reasons why PB/DOS, or PB/CC, could not be upgraded to create 32-bit executables that can run under Phar Lap or one of the other common 32-bit DOS extenders, that's one thing - but to just blithely assume that everyone is using Windows now and so the feature would be of no benefit to anyone is simply not true.

------------------
"Too often those in the high-tech industry view their work as an unquestionable contribution to the greater good, without regard to long-term effects on the way we all live."
--Chad Dickerson, InfoWorld CTO

**Michael Mattias** · 21 Dec 2001, 02:33 AM

It doesn't offer the same kind of control, but you can SHELL a PB/CC (or PB/DLL) application from PB/DOS applications. If you have some operation requiring access to either lots of memory or the WinApi, this might be a solution.

MCM
P.S. I did not think of this. I got it from something Lance Edmonds posted maybe two years ago. I used it to SHELL the sort of a large file from a DOS program.

**Don Ewald** · 21 Dec 2001, 05:53 AM

greetings javier!

i used to program in quickbasic 4.5 until i found pds 7.1 at a garage sale for the bargain price of five bucks! i used that predominantly until i became frustrated by not getting enough of my questions answered. i came across powerbasic for dos and used it predominantly until i was able to afford a crossgrade to pb/cc. i'm sure that i'll program in pb/cc much of the time now.

mr. gutierrez:
- syntax highlight in the editor with colors, in order to improve the coding productivity...

i had a few programs that i really liked to load with pb/dos and i discussed it previously here.

me:
currently, i've a batch file that loads up bonbon and pqsyntax. bonbon is a tsr that allows you to easily move to your various subs and functions. pqsyntax is a syntax colourizer for powerbasic. this combination allows me to easily add some more features and still use the powerbasic compiler.

mr. gutierrez:
- multi file edit, able to open various files simoultanelly.

not to sound like a simpleton; but, i always just opened two instances of pb/dos through windows. granted this didn't allow comparing of the two files; but, it worked decently. i'd also drop back to far, a console-based shell that facilitates a large number of operations with files, folders and archives, to do any large amounts of merging code from one application to the next.

anyhow, there's a few thoughts to chew on.

------------------
don ewald
mailto:[email protected][email protected]</a>

**Jessica Gonzalez** · 22 Dec 2001, 07:18 PM

Don,

Those sound like some interesting workarounds that you've
come up with. My question is this: why do we need to come
up with workarounds? Is it too much to ask for a product
that has at least a few of the same features included with
every other IDE? Take a look at the RHIDE IDE, a free,
open source IDE for the GNU C/C++ compiler for DOS. It
includes such amazing features as multiple files open at
once, source code highlighting, regular expression searches,
projects, etc. (and it was not even written for profit).

Now, I love PowerBASIC, but it does seem as though we have to
do a lot of work to have the same things that everyone else
considers to be standard.

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

**Michael Mattias** · 23 Dec 2001, 04:11 AM

Those sound like some interesting workarounds that you've
come up with. My question is this: why do we need to come
up with workarounds? Is it too much to ask for a product
that has at least a few of the same features included with
every other IDE?..it does seem as though we have to
do a lot of work to have the same things that everyone else
considers to be standard

How about cost? Both PB/DOS and Pb/Win are very reasonably priced relative to "everyone else".

And if you like other editors, use them: PB/DOS includes a command-line compiler. I haven't used PB/DOS but a little bit in a while, but when I have I've noticed that I do not rememeber the Wordstar-hot-keys. If I have to do another DOS project, first thing I'm going to do is set up another editor and the appropriate batch file or command line to compile from it. (If I don;t get multi-edit, I'll use PFE).

MCM

**Jessica Gonzalez** · 23 Dec 2001, 09:45 AM

Michael,

I agree with you, and I'm not just trying to rip on PowerBASIC
(although I must say that Borland's C/C++ compiler for DOS and
Windows is something like $30 - $50 with a book at Best Buy).

As for other editors, that's great, but I love having the
context-sensitive help right there at my fingertips, as well
as the watch, and a few other things. I just wish that the
editor had those three features as well (it just seems odd that
everything else is so great, but they left out things like that).

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

**Lance Edmonds** · 24 Dec 2001, 01:54 AM

Out of curiousity, does the license for the compiler that comes with the book allow you to distribute applications built with the compiler? Most "learning" or "academic" editions don't (such as Delphi, VB, VC, etc), and the cost to buy a license/version that allows distribution is a LOT more expensive.

My $0.02

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

**Michael Mattias** · 24 Dec 2001, 04:16 AM

As for other editors, that's great, but I love having the
context-sensitive help right there at my fingertips, as well

You could run the PB IDE with file "NONAME.BAS" (the default)in another session. When there's a help lookup you need, switch to that window, type the word anywhere in NONAME.BAS and press F1.

That's maybe not too fair and might well be pretty clumsy for someone who has not written in PB/DOS as long as I have.

MCM

**Chua Puay Kiang** · 26 Jan 2002, 09:02 AM

Hi,

Waiting for pbdos upgrading, please add long file name feature, so
that I can update my newdos.exe to support long file name.

My website: http://call999.com

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

**Eric Pearson** · 26 Jan 2002, 09:37 AM

> Waiting for pbdos upgrading

In the meantime, have you considered using DOSBox? It allows you to add several types of Windows functionality to PB/DOS programs, including Long File Names. It is available from PowerBASIC, just click on one of the links below.

-- Eric Pearson, Perfect Sync Software

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

**OTTO WIPFEL** · 26 Jan 2002, 09:38 AM

Well here is one suggestion: Will somebody please blow up MS :-)

No seriously, as long as there is need for fast, efficient and
Bug Free :-) text only based software there is room for DOS 6.+
or DR-DOS.

Who needs Graphics dealing only with Text and Numbers ? My clients
don't ! Not to mention the spiralling costs of using unreliable,
buggy and insecure Windows Software in any shape or form.

All my PB-DOS 3.5 programs run 100% from any Windows up to 98 SE
Desktop, if you must have a Windows machine in crammed retail
environments. Not encouraged by me :-)

So lets have more PB for DOS, DOS ain't dead yet :-) !!!

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

**Petar Petrenko** · 27 Jan 2002, 04:04 AM

Hello friends,

First, I would like to thank you for making Power BASIC. You made my programming tasks much pleasant and much easier. These are my first licensed programs I ever bought and it means a lot of to me and it should mean much more to you. Because of this, I am concerned in improving it to be the best programming tool ever, for me, and for the others.

Do you now why Tesla, Beethoven, Newton, among many others, are so famous? They are, because they didn't try to copy anyone else. Their work is unique. But you are not. Because you are trying with all your efforts to be just another version of Microsoft Basic. You always compare with them. You even say that you are 99% compatible with them.

I would like to ask you what your goal with Power BASIC is. I do not think that you want to improve Microsoft Quick BASIC, or on the other hand, maybe, to glorify it. However, what you have already done is just that - much faster Quick BASIC and nothing more. If your goal is to beat Microsoft, you must make a unique product, which will distinguish you from them. Making programs running faster is really cool, but power does not mean only that. It also means that programs should be simplified by making small code and it can be done only if you put inside Power BASIC everything that is "invented" by now - matrix math, statistics, trigonometry... Programmers should be concentrated only on the specific job they have to do. Why should we have to waste our precious time for inventing hot water again? There are lot of statements and functions in Power BASIC that must be thrown out and replaced with ones that are more effective.

Now, I would like to make a few suggestions about your applications. Some of them are for PB DOS, some for PB/DLL and some for both.
ONLY two kinds of variables, numeric and string. (No more integers, real, double, extended precision and so on. How many question marks or at signs or percents are you going to put to some new kind of variables you are going to invent?). Why do I need variables that can hold numbers up to 10^4932 when I can see only 16-18 digits of precision on screen? Processors are so powerful today and RAM is very cheap that you can freely make numeric variables to work with and show, let's say 65535 digits of precision. And it will result in throwing away all those conversion and declaration functions and statements like MK???, CV???, DEF???, C??? (CDBL, CINT...).
Removing all functions and statements that provide compatibility with earlier versions of BASIC. LET, line numbers.
Array of elements!!! Like in PASCAL. Array(fruits, vegetable). It will save a lot of time, space and effort.
Dynamic arrays. Make all arrays dynamics by default. No more $statements for this purpose ($dynamic, $static, $huge...).
Trigonometry. Why it is too complicated to you to implement complete trigonometry? SIN, COS, TAN, COT, SEC, COSEC, Arcus, Hyperbolic and ArcusHyperbolic of all of them. It will take you about 30 minutes to do it.
Choice for angles and other international characters. While working with trigonometry functions it will be nice to choose between degrees, radians and grades. You can do it through Internal variable like pbvUsingChrs "*$,." or inside Option menu.
Statistics and financial functions. Complete implementation of these functions (like in EXCEL).
Improve some functions. The second parameter of ROUND function should get negative values because of rounding whole digits. Functions LOG, LOG2, LOG10 could be done in only one function LOG(number, base) in which case you can use any positive number for base. The same should be done with EXP functions. INPUT function should be improved to control input of data, default values, range of values and so on like in database programs. Conversion functions like OCT$, BIN$ and so on should be replaced by only one function like CONV$(number, inputbase, outputbase) - CONV$(25, 10, 8) in which case you can use any integer number for input and output base in range 2-16. Let make VAL function solve equations while converting from string to numeric: Answer = VAL(25 + SIN(12,234) * LOG(256,65345234)).
Arrays. Make all arrays dynamic by default and make them use all the available RAM memory (>= 16 Mb) even under DOS.
PRINT & LOCATE. Combine these two functions into one PRINT AT x, y; text...
Make EXE files as small as possible. If the program contain only one statement or function like PRINT "Hello", than in EXE file should be implement only the call to this function (like C++) and not the complete set of statements and functions.
Working with screens. PowerBASIC, as well as QuickBASIC, has a lot of screen modes which makes work very clumsy. You should reduce this only on one screen SVGA mode with 25/43/50/60 rows. My opinion is that nowadays almost everybody has SVGA monitors and display cards. You MUST correct the choice 43/50 in Options/Environment/Screen size to work with output window too not only in the working environment only.
Visit the TeraTech, Inc. site and see what they have under Products. You should implement all those FinLib, ProMath and ProBas routines considering all mentioned above.
And now, at the end, all these enhancements will result in smaller, faster and much reliable BASIC code than ever, easy to maintain, less bugs and really unique and POWER BASIC.
After all this changes you should consider of thinking about making completely new GUI instead of WINDOWS that will be done entirely with PowerBASIC. It sholud not be bigger than 10 Mb, with all the positive characteristics of WINDOWS.

There was nothing about using internal variables and internal procedures in PB for DOS manuals.
In PB/DLL manual there was nothing about working with colors (coloring backgrounds, frames, boxes etc.).

Best regards,
Petar Petrenko

**Tony Burcham** · 27 Jan 2002, 07:07 AM

Originally posted by Lance Edmonds:

JFYI, PB/DOS has to fit it's entire RTL within a single 64K segment,
so adding "big" features means increasing the RTL size (and this means
lots of far-addressing changes and more memory consumption), or R&D
would need to drop some features to make room for the new features.

Lance,
Could you work around the RTL size limitation by having the compiler
itself be a Win32 app though still generating dos compatible code? The
ability to support all the Pentium instructions would be a great leap
in product quality. It seems you'd also need to include the Dos version
of the compiler for those who, for some reason don't have Windows or need
to work on a dos system. This would be an odd work-around, but worth it
I bet.
TB

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

**John Lee** · 27 Jan 2002, 08:45 AM

Wish List....

>1. Try to understand and fully utilize the latest version
before making suggestions on new version.

>2. Any suggestions are appreciated but please make it short.

Thanks

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

**Lance Edmonds** · 27 Jan 2002, 02:00 PM

Tony: the RTL (runtime library) forms part of the compiled code. Whether the compiler is a Windows app or a DOS app is of little consequence in this regard, however, converting the compiler (itself) to Windows would immediately remove 8086, 80286, and plain-DOS compatibility with the compiler. Such compatibility is still important for developers, even in these days of the predominantly Windows desktop.

John:

Petar: Thanks for the suggestions. However, many of these would break existing code so would be less likely to be implemented.

BTW, your idea of using just one class of numeric variable with 65535 digits of precision is interesting. Have youy considered than you'd probably only be able to use a handful of them in a DOS app running with 640K of RAM, since each would require a lot of memmory to be stored?

Further, processing speed would be terrible with such large numeric variable sizes... a statement such as X% = X% + 1 using such a data class would convert from 1 ASM instruction to dozens or hundreds, with loops, and all kind of palava.

BTW, this is just my $0.02... I'll still pass your suggestions along to R&D.

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

**Tony Burcham** · 27 Jan 2002, 03:37 PM

Quote from Lance...
Tony: "the RTL (runtime library) forms part of the compiled
code. Whether the compiler is a Windows app or a DOS app is of
little consequence in this regard, however, converting the
compiler (itself) to Windows would immediately remove 8086, 80286,
and plain-DOS compatibility with the compiler. Such compatibility
is still important for developers, even in these days of the
predominantly Windows desktop."

I see your point about the RTL. I thought the problem was not
having enough memory during actual compilation, not in the
resulting program. There's no reason why a 32-bit app can't
generate 16-bit code, that's what I don't understand about the
reply. Having all that p-mode RAM would allow a larger app
needed to expand the supported asm instructions both, for
processor-specific EXE's, and for inline asm statements. IOW,
i'f you need multiple sets of RTL's to use selectively based on
the processor your compiling for. Then again, my great ignorance
of compiler structure may be showing

TB

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

[This message has been edited by Tony Burcham (edited January 27, 2002).]

**Pat Bruening** · 27 Jan 2002, 04:14 PM

Has anyone ever noticed that this forum as of January 27, 2002
has had 3583 questions? And that the PBCC forum has had 8783 as
of January 26, 2002? Since PBCC is much newer and has had more
questions about it, why is it being promoted more than PBDOS?
I have purchased PBCC and PBDLL and PBDOS 3.2 and PBDOS 3.5 and
have a hard time trying to make PBCC work. When it does, it works
most slowly where speed should not be a factor; namely in INPUT
and OUTPUT. Why PBCC when PBDOS is yet so much easier and reliable?

Announcement

Maintenance

PB/DOS suggestions

PB/DOS suggestions

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment