misc, Looking for a free basic compiler for DOS

I am looking for a free basic compiler for DOS which includes a 386
inline assembler. The applications shall run without DPMI installed.

Is there a basic compiler I can use for this?

FreeBASIC does this and has most of the same syntax as QBasic,
Quick Basic, etc. so you should already be familiar with it.

http://www.freebasic.net/

Tom Lake

In the FreeBasic documentation I read:


A DPMI (DOS Protected-Mode Interface) server must be present to run
fbc.exe and any executable generated by it. When running in raw DOS
(ie:
not a Windows 3x/9x/NT/XP/etc command-prompt), the CWSDPMI server
( http://clio.rice.edu/cwsdpmi/csdpmi5b.zip ) must be on your PATH
environment variable (note: FreeDOS comes with it already installed).


My intention is to generate real mode programs which need no DPMI.

> In the FreeBasic documentation I read:

Ah, I missed that. Sorry. If you don't mind obsolete software, Microsoft
PDS
is still available on the Web. That generates standalone DOS programs.

Tom Lake

Hi Tom,

thank you for answering to my post. I am afraid PDS is not free, I
think only QBasic is that. Does PDS have an inline assembler?

Georg

G'day Tom,

I bought PDS 7.1(?) some years ago. Are you saying if I had waited
until now I could have got it for free? ;-)

[Actually, this is not entirely flippant. I know Borland made some of
its old programming stuff available as "freeware"; so I'm just
wondering if Bill's mob have been as generous with their legacy apps?]

Cheers, Phred.

--
XXXX@XXXXX.COM

On 16 Mar 2007 04:01:56 -0700, "Georg" < XXXX@XXXXX.COM >


<snip>


No.
--
ArarghMail703 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

On Fri, 16 Mar 2007 11:48:46 GMT, XXXX@XXXXX.COM (Phred)


<snip>
AFAIK, no. Never. Nothing.
--
ArarghMail703 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

I started to write my application with Moonrock Basic now. However, I
use it with TASM which is not free. The other assemblers supported by
Moonrock do not seem to support 386 instructions.

Georg

Did you check here for free assemblers:

http://www.thefreecountry.com/compilers/assemblers.shtml

Moonrock is said to work with most masm-like assemblers. Masm itself
is free for non-commercial apps, but NASM is always free and widely
used.

Eric

As far as I could test, Moonrock will always generate the same
assembler code, no matter what config file you have selected. The
config file has different batch commands to run the various
assemblers.

I could just get Arrowsoft and TASM to compile these assembler files,
different versions of MASM did not work.

Georg

By the way: I downloaded MASM 8 from the Microsoft site. It will only
install and run if Visual C++ Express has been installed before.
Visual C++ is a 90 MB download and takes 390 MB on the disk - without
IDE and optional files. MASM 8 and LINK just require one MB of that.
If you run MASM 8, it first checks if it can find Visual C++. I guess
it is simpler to download MASM32 and take ML.EXE, which is MASM 6.14,
and Link from that.

Georg,

MS Prof Basic PDS 7.1 is by far the best basic ever created for dos
apps. The IDE runs about 25%-50% of compiled speed, and compiled
speed is as fast or faster than compiled C.

It doesn't have inline assembler, but interfaces very easily to any C,
Pascal, or Basic compatible library. I used to do all my screen
output for line graphics for realtime marine survey navigation
applications in assembler (Masm 5.0), with the apps in Basic.

I found I could run production in the IDE - it was plenty fast enough,
and actually had the confidence to make sw changes on the fly with a
running program.

With proper use of EMS, the apps could get H-U-G-E.

I wrote an app once that processed a data feed from a stock exchange
in real time, and maintained transaction data during the day on a
trade-by-trade basis for over 700 companies (at the time) each with
their own data file, and never got behind. That one ran on a Pentium
130mhz cpu, and could also keep up (just barely) running in the ide.
Used DOS 6.2 with a somewhat large FASTOPEN pool.

The ease of debugging with this ide is unbelievable, and should serve
as a model for ide's everywhere. It gives you the power, speed and
ease of use to quickly put together 20,000 line apps in a single
compile run (recompile all routines).

And, at version 7.1, it was practically bug-free!

If you could purchase, used, an old copy, it would be the best way to
go. If you could actually find a copy WITH THE ORIGINAL MANUALS, MS's
lawyers even would have a hard time charging you with copyright
infringement.

You will need the manuals Language ref AND programmer's Ref, to use it
in any complicated way.

- Tom

On Wed, 21 Mar 2007 11:53:03 -0500, Happy Trails < XXXX@XXXXX.COM >


It always seemed faster than that to me.

Can't be. Compiled basic consistes of a large number of far calls to
the runtime. About the only inline code are operations on integers,
and longs. Most everything else results in a runtime call. Just look
at a /A listing.

Likewise with use of XMS. I once had a program that did an incore
sort of a 50 meg database. Yes, MEG.

Very true.

Remember, if you compile from the IDE, the link uses /EXEPACK, and you
can't turn it off, unless you patch a copy of qbx.exe.

The only bug I ever ran across with 7.1, MS refused to acknowledge as
thiers. But they did send a fix. Said fix applied to a lot of 16 bit
apps from MS. But, they didn't tell me that. I found out on my own.

Was 7.1 ever sold standalone? I got mine as an upgrade, and there
were no manuals, just a readme file.


A lot of the info from the books is buried in the help system, but
somewhat hidden.
--
ArarghMail703 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

n Wed, 21 Mar 2007 19:10:11 -0500,
XXXX@XXXXX.COM wrote:



Can't be! Can't be?

Way back in the 60's I once bet an IBM 360 assembler programmer that
my COBOL program would run faster than his assembler code. I made up
a simple example with input of sequential records from a disk file and
multiplying numbers together - floating point literals of my choosing.

I knew the COBOL would automatically use a more efficient type of
input than he could be bothered to code, if he knew how, and that
COBOL would use floating point arithmetic by default on the
calculations, which he didn't even know how to code.

Guess who won the bet?

Circa version 6, the MSC compiler, (which stands for "C"ryptic, btw),
did not use 80x87 instructions by default, so all you had to do to
kick it's ass was make sure your comparison example program had some
heavy calculation loops in it and run it on a 486 or better cpu. The
BC for 7.1 had a lot of compiler switchable options, one of which was
to use 80x87 instruction codes if the cpu had one. Very easy to do.
Another switch, btw, was to use near calls instead of far calls under
certain circumstances - can't recall offhand.

One thing that was much easier with basic was to rewrite loose code
and make it more efficient, whereas with C it seem to be the habit of
programmer that once a routine was working they were afraid to tweak
it ahgain and again, and didn't have the instant gratification (and
verification) of running many different tweaks in the ide to see which
worked best.

Basic always did pretty efficient I/O also, whereas with C it was
again whatever the programmer managed to get working.

So MY Basic applications were always at least as efficient as anyone
else's C, and usually significantly faster.


Core!! Core?? You're gonna have to explain to the youngsters where
that one came from, hahahahaha.


Oh - want some real good advice? NEVER compile from the ide. Never!
Learn how to do it from the command line.

And don't even think about trying to keep a library of separately
compiled modules up to date unless you have multiple programmers and
have to do it for political reasons.

A complete recompile and relink of a system of, say 100 to 200 modules
of varying sizes and complexity took about 1 to 3 minutes.

In the IDE, source modules that were each less than 16k bytes long got
loaded into ems, whereas quicklibs always got stuck in low memory, so
it was actually easier to run bigger source programs in the ide than
to run systems with many compiled routines, and infinitely easier to
maintain a test & development system.

And this way you could trace code into and out of the subroutines,
instead of disappearing into a black hole each time a call was made.


7.0 manuals and 7.1 upgarde manual - same blue and white covers, about
70 pages. Mostly all that useless PWB/Codeview crud. Which wasn't
really needed with the ide if you knew how to tweak the memory limits.

EMS is offering a complete 7.1 package still in the shrink wrap with
manuals AND the license registration letter in the original envelope,
as well as several partial kits on various sizes of diskettes. They
want $1595 for the cherry package, which is about 3 times original
price.


Believe me, it is buried a lot deeper in the manuals, especially on
topics like making up your own .qlb's and .lib's. That used to get a
little tricky when a bunch of subs would be pr

On Wed, 21 Mar 2007 19:10:11 -0500,





Curious - I never used it in the IDE
- always used SideKick Plus for coding



I suppose it depends on the type of App, compiled C also uses a load
of Far Calls

We could beat PDS7 with our own Assembler





<snip>




I would be very interested to know what the bug was



I bought a standalone copy in 1993 - it came with two manuals