Thinking of moving to PowerBASIC For Windows?

[Steve Rossell]

Thinking of moving to PowerBASIC For Windows?

Learn the key concepts about event driven programming and how it
differs from DOS programming. See what is involved in creating a
graphical user interface.

Take a look at the PowerBASIC Quick Start Tutorials.
You will get step by step guides on PowerBASIC For Windows Programming.
It all begins at the PowerBASIC Help Desk at http://www.powerbasic.com/support/,
stop by and take a look today.

Sincerely,
Steve Rossell
PowerBASIC Staff

[Chris Holbrook]

Originally posted by Steve Rossell:
Thinking of moving to PowerBASIC For Windows?

Actually I was thinking about moving to PowerBASIC for DOS, if it can do multithreading.

What sort of product life do you envisage for PowerBASIC for DOS?




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

[Mike Stefanik]

As in 16-bit MS-DOS? That operating system doesn't support multiple processes, let alone threads. It's not whether PowerBASIC can do it or not, it's something that simply does not exist in the MS-DOS world. And nope, TSRs don't count.


------------------
Mike Stefanik
www.catalyst.com
Catalyst Development Corporation

[mark pruitt]

Chris, are you looking for something to use in a DOS OS environment?

If you'll still be working in windows, and want to multithread in DOS,
Console Compiler should be able to handle anything you throw at it.



------------------
Mark Pruitt
[email protected]

[Michael Mattias]

>Chris, are you looking for something to use in a DOS OS environment?

I asked in the other thread what he was doing ("the question") to which "multi-threading" was the answer. Maybe he will address that there. Or here.

I mean, a Windows box can run simultaneous time-sharing MS-DOS programs, which sure sounds like (well, actually it *IS*) "multi-threading" except for the potential requirement to share data amongst the multiple processes. So maybe it's not really a "multi-threading" problem so much as it is a "share data across multiple MS-DOS sessions" problem.

Hell, it's a thought.....

MCM

[Mike Stefanik]

If he's specifically asking about MS-DOS, I presume (and admittedly, it may be a bad presumption) that whatever users this application is for would be running old MS-DOS boxes, probably dedicated for some purpose (point of sale, etc.). If they're running Windows, and I can't imagine any reason someone would willingly subject themselves to a 16-bit platform based on personal preference. It'd be like going to the dentist for a root canal and telling him to hold the anesthetic, all you need is a shot of whiskey.

As for the long-term viability of DOS, I obviously can't speak for the good folks at PowerBASIC and what their plans are, but the plaform is dead. You can't even load a 16-bit application under 64-bit versions of Windows, and there's rumors that only the low-end "home" versions of Windows 7 may be 32-bit, if there's a 32-bit version at all (in other words, all 32-bit applications will run under WoW64).


------------------
Mike Stefanik
www.catalyst.com
Catalyst Development Corporation

[Michael Mattias]

Today you can buy a new computer with Windows installed probably for less the cost of modifying the MS-DOS software just to do what you can do with Windows "out of the box."

But methinks the original post may well have been putting the cart before the horse... that is, selecting the HOW ("multi-threading") without considering all the options available to accomplish WHAT (still an unknown).

(Number of users also unknown, but that will DEFINITELY play with the arithmetic).

MCM




[This message has been edited by Michael Mattias (edited June 27, 2007).]

[Chris Holbrook]

The application logs asynchronous events and reports on them. Probably six or fewer concurrent threads.
Presumably to start a thread you need to grab memory for a stack segment and copy the registers, and have a control mechanism which monitors active threads and passes control to the "next thread" (or maybe prioritise threads).
Assuming that each thread calls the scheduler to pass control to another, which is not elegant but in the kind of application which I have in mind would not be onerous, as it could be built in to a monitoring loop or keyboard loop.
I don't need any Windows UI, and could do without the cost of licensing an OS.


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

[Michael Mattias]

>The application logs asynchronous events and reports on them

Not if it's an MS-DOS application, it doesn't. MS-DOS does not support asynchronous anything. (Multi-threading = asynchronous something).

Any time-sharing at the single application level you want to do to make it 'think' it is doing more than one thing is code you have to write. (And IIRC QuarterDeck and Borland both made a few bucks doing exactly that).

[Paul Dixon]

Chris,
<<What sort of product life do you envisage for PowerBASIC for DOS?>>

I bought my PB/DOS 10 years ago and it has shown no signs of wearing out. I expect it to last at least that long again so the life of the product should not concern you.


<<Probably six or fewer concurrent threads. Presumably to start a thread you need to grab memory for a stack segment and copy the registers..>>

Now you're in trouble. If you're going to do the job in DOS then you have to throw off the shackles of Windows and stop using Windows language or you'll be forced into thinking Windows while programming DOS which is not the way to go.
Forget "threads" and think of what your program needs to do.

Mike,
<<You can't even load a 16-bit application under 64-bit versions of Windows>>

That doesn't mean DOS is dead. It means a future Windows will drop support for it. DOS and Windows are 2 different things, they can live independently of each other. DOS will continue to live on in millions of computers for many years. It has already outlived 16-bit Windows. It's still going now 32-bit Windows is in decline and it'll likely outlive 64-bit Windows.


<<TSRs don't count.>>

If they do the job then they count. Whether they match your expectations of a Thread as you might be used to under Windows is a different matter.
There's nothing to stop a DOS program running multiple, independent pieces of code and switching between them far more efficiently than any Windows system ever has. A little ASM and an understanding of interrupts comes in useful here.

Paul.

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

[Chris Holbrook]

Originally posted by Michael Mattias:
>MS-DOS does not support asynchronous anything.

er, it's the events that are asynchronous.

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

[Chris Holbrook]

Originally posted by Paul Dixon:
Now you're in trouble. If you're going to do the job in DOS...

Paul, what on earth do you mean?



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

[Barry Erick]

If you simply want it to "look like DOS", use PBCC. That is the console
window version. And the console window is what looks like a DOS
box. But if you want it to run on a DOS machine, then you are trying something very hard to do in
DOS. For communications in the background, there is event driven statements.. ON COMM and others, although
in DOS, I hated those and simply polled, quite often, the buffers
to see if anything came in, and then go to the routine. That looked like multasking, but wasn't.

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

[Paul Dixon]

Chris,
I mean that you are thinking in terms of how you might do this job on Windows. DOS isn't Windows but may also be able to do the job, just not the same way.


<<Presumably to start a thread you need to .. >>

Since you'll not be running in Windows you can choose how you want to do this. You're no longer restricted to the way Windows would have you do it so you don't need to presume anything about the way it works. YOU decide how you want it to work and write the program accordingly.

I don't know what these events are so it's difficult to be more specific.

If they are external hardware events like key presses, serial port activity, changes on external I/O ports, then DOS can handle these events using interrupts far better than Windows could ever handle them using threads.

If your asynchronous events are people accessing remote websites which you are monitoring or arrival of e-mails or activity on a USB device then it's more complex for DOS because the functionality to do these tasks is built into Windows and isn't built in to DOS.

Paul.

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

[Chris Holbrook]

Paul,
OK, we are talking about the same thing, but "threads" doesn't imply "windows".
What I want is to create a 16-bit DOS application which will run under an MSDOS-like OS and can also run in a Windows environment (as a console application in XP, etc etc). The application has to support task-switching to allow concurrent threads, which will provide a multi-user capability of sorts on the DOS machine. More than one of these "users" will require a physical console of some description for IO. I'm considering this an alternative to licencing an OS which allows concurrency.
I know that it can be done, my question is really to determine whether PBDOS (I don't have a licence for this product) has any features which will help. Built-in assembler may be all that I need for the task switching.

Not having a PBDOS licence, I can't even look at the PBDOS online manual, so I'm prototyping with another 16-bit compiler (shame!).



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

[Michael Mattias]

Well, OK, here's the answer to the original question:

There are no intrinsic verbs, functions or compiler options offerend in the PowerBASIC/DOS compiler designed to support multi-tasking, task switching, asycnronous execution or real or simulated multi-threading.

[Chris Holbrook]

So it's "no" then?



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

[Michael Mattias]

"NO" is the answer to the innterrogative form of your statement, " Actually I was thinking about moving to PowerBASIC for DOS, if it can do multithreading."

As far as accomplishing something, well, all things are possible given imagination, skill and earnestness.

[Chris Holbrook]

My earnest thanks.


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

[Chris Holbrook]

For Steve Rossell

Originally posted by Steve Rossell:
Thinking of moving to PowerBASIC For Windows?

Sincerely,
Steve Rossell
PowerBASIC Staff

No, I wasn't - I already use the PB Windows and CC compilers, and I hope to use the DOS one too, for an application which I am developing - messages above refer. The prototype (non-PB, but developed using an unsupported compiler) works.

What exactly is PowerBASIC's committment to the DOS product? Will it still be supported in two year's time?




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