Speculate - What could PB DOS do if DOS Limits didn't Exist?

[Frank Ferrell]

Greetings --

This is just for Speculation -- and Fun! Question Revised

If the limits of DOS (640kb RAM, 16mb EMS and whatever else) did not apply, what could a Powerbasic DOS Compiler - IE one made specificly for such an "Unlimited" DOS - do that the present PowerBasic DOS compiler can't do now?

If you would please (and if this isn't asking too much), answer using fixed-length text {IE, the CODE function} - to show side-by-side "With Limits - NO Limits" comparisons in 16-bit, 32-bit and 64-bit enviroments.


------------------
Thanx-A-Lot and Enjoy, Frank -- My PB

[This message has been edited by Frank Ferrell (edited June 24, 2003).]

[Joe Byrne]

This is totally speculative since "better DOSs" have been made but never adopted by large numbers of people (the old DRDOS --> Novell DOS removed many of the MSDOS limitations). So the reality is that "DOS without its limitations" is, well, frankly, Windows

------------------
Joe Byrne
mailto:[email protected]
[email protected]
</A>

[Michael Mattias]

If the limits of DOS (640kb RAM, 16mb EMS and whatever else) did not apply, what could Powerbasic DOS do that it can't do now?

Nothing.

PowerBASIC compilers by themselves simply translate the programmer's instructions into executable code. They don't know from squat about system limits until it hits one, at which point it returns an error code. What more could they possibly do?

MCM

[Frank Ferrell]

Greetings --

Just realized that the wording of my original inquiry wasn't right - my apologies.

I've gone back and revised the question. Hopefully this will clear up any misunderstandings.



------------------
Thanx-A-Lot and Enjoy, Frank -- My PB

[Michael Mattias]

You still have the question worded as though the compiler is actually doing something other than rote translation of the programmer's instructions. Compilers do not "think" like this. A good compiler faithfully and accurately translates the programmer's instructions into executable code, nothing more. (Not that that is a particularly easy thing to do).

All you could possibly see would be support for longer strings, bigger arrays and in general more use of RAM. How that larger RAM would be used is up to the programmer.

This "mindset change" (or "paradigm shift" to be quasi-trendy) was the biggest change for me when I went from MS-DOS to Windows: I had to set aside all my preconceptions (and hard-earned experience) about how certain tasks should be done, because many of the methods I had acquired were predicated on working in a 640 Kb RAM universe.

MCM

[Jerry Mason]

Because powerbasic can link in object code at compile time, it can do
anything the hardware is capable of. I've used this method to create
flat memory models within my powerbasic programs that can access
all of memory at high speed, I've taken over the timing tick, keyboard and
com port interrupts for my own, nefarious ends , and I control
proprietary hardware devices that lack DOS drivers. Powerbasic then provides
the powerful, easy-to-program front-end that glues these assembly subroutines
together.

<soapbox>
The true strength of DOS as an operating system is that, unlike windows and
linux, it stays out of your way when you don't need it. (If your program doesn't
call any DOS interrupts, are you really running DOS at all?) You don't
have to acknowledge any of DOS's limitations if you have the considerable time
and inclination to do the job at an assembly language level.
</soapbox>

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

[Karl Lessmann]

.

[This message has been edited by Karl Lessmann (edited September 23, 2003).]

[Michael Torrie]

"The true strength of DOS as an operating system is that,
unlike windows and linux, it stays out of your way when
you don't need it."

* * *

Right on.

I recall a friend of mine who wrote assembly language
arcade-quality games who referred to Windows as the
"Great Wall Of Gates" for that exact reason...

I used to think the same thing, and used to really be a fan and proponent of small, fast assembly programming (such as what PowerBASIC for DOS descends from), but after moving to Linux, I would never go back to programming the bare hardware. In today's hardware, you no longer see huge benefits from writing in assembly to bare hardware versus writing through a hardware abstraction layer. For example, 3-d graphics. While you could do it in assembly and poke into the frame-buffer, using a high-level API (which translates directly to hardware functions in today's video systems) results in much faster and more efficient graphics display than assembly under DOS could provide. That and the ability to move programs from platform to platform really has shown me that the advantages outweigh the costs of really using an OS (that's what it was designed for... DOS never has truly been a real OS)

Michael


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

[Donald Darden]

PB/DOS runs fine under Windows, but much of DPS's limitations are
not apparent when you do that. Fact is, I use all three PowerBASIC
products -- PB/DOS, PB/CC, and PB/Win, and find that for certain
requirements, one may be my preferred development platform over
another. So if you love PB/DOS, have a good, fast PC, and have
been debating whether to move up to Windows ...

Wgy Not? You still get the DOS prompt when you want it, can find
new ways (as well as the old ones) for performing your tricks, and
best of all, you do not have to leave PB/DOS behind!

But if you are still hesitant, then consider installing a second
hard drive (or partitioning that huge one) and creating a
multi-boot system. That way you can go any which way that you
want. You can install Linux, BeOS, several versions of Windows,
whatever. It is a whole new experience. You can use PB/DOS
with a good part of it, except Linux and BeOS. And who knows,
you may find that it can be made to work with one of the many
DOS emulators that are evolving out there.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

[Hans Ruegg]

Jerry Mason:
just a curious question.
You wrote, "I've used this method to create flat memory models
within my powerbasic programs that can access all of memory at
high speed". This sounds very interesting, and I've heard before
about that trick - but what can you use it for? As far as I
know, you can run such "flat memory" programs only under plain
DOS, since they will crash every multitasking / protected mode
OS. So who is actually running this kind of programs?
(Or did you find a workaround which prevents your program from
overwriting other programs' memory space?)

Regards,

Hans Ruegg.

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

[Jerry Mason]

Hi Hans,

As you say, you can only use and abuse the hardware like this when running straight DOS.
And that's just what I do. I write high speed data acquisition and reduction programs
for PCs using proprietary hardware. These take and reduce data for the
astronomical instrumentation built here at Ohio State University, which are in place
at six observatories on four continents (at last count). The PCs are dedicated, turnkey devices, so
we have the luxury of specifying the hardware and software installed.

Cheers,
Jerry



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

[Criss French]

What could it do if...?

Well, it could handle the very large data sets I would love to generate
and process in our survey gear. For example a terrain "grid" that
would cover large areas, stored as a x * y 2D array. Or a full set of
soundings at 6 depths per second, for 8 hours, plus pointers to
positions, at 1 per second, in two big arrays. Then process or
traverse them very fast, ie. without VIRTUAL / EMS overhead.

And all without going to ASM, which I don't know, and negates much
of the 'ease of use' beauty of PB.

In the mean time, back here in the real world, I will have to try on
VIRTUAL arrays, and see how well they work for on-site but not real time
data processing tasks. VIRTUAL may satisfy my needs in the end, even
if it's less fast.



[This message has been edited by Criss French (edited July 26, 2003).]

[Michael Mattias]

VIRTUAL may satisfy my needs in the end, even if it's less fast.

You know, disk access technology has improved so much since the 1980's when many "generally accepted programming techniques" for S_DOS programs were developed. Today a random-access disk file may be perfectly suitable for an application which in the past may have required a table in memory (i.e., an array) to evince satisfactory performance.

If an old fart like me 'unlearn'and 'relearn' surely you can, too.

I was a long time ago asked what I thought was the most important skill a systems designer should have. Was it mathematical skills? Specific industry experience? Algebra?

I'll stick with the answer I gave then, and would give you today.

Most important skill? Imagination: the ability to dream.

(Don't even get me started on how design has more effect on performance than any piece of hardware or development software).

MCM