Announcement

**Michael Mattias** · 13 Oct 2002, 04:26 AM

i have no clue re the number of monitors, but isn't looking at three (or four) monitors the hard way to find differences in files?

i mean, wouldn't it be a lot more efficient to extract the values from the three files and compare them programatically?

or am i missing something?

mcm
ps: not for pb/dos, but here is some pb/cc code you can adapt to do these kinds of comparisons:
http://www.powerbasic.com/support/pb...ad.php?t=22637

**Lance Edmonds** · 13 Oct 2002, 04:45 AM

Not with the built-in PRINT statement, sorry!

It is possible to use a mono (Herc) card and a VGA card and use both cards from PB/DOS... they key in this instance is to POKE characters directly into the video memory of the non-current card (ie, if the VGA card is the current card, you'd POKE data to &H0B000; if the current card is the herc card, use &H0B800 to poke data to the VGA text-mode. Note that Windows NT/2000/XP virtualize the hardware and wil not permit direct hardware access, so this scheme only works on plain DOS, Windows 3.x, and 95/98 (and maybe ME).

Note that the PB/DOS IDE natively supports this VGA+MONO dual-monitor setup... the IDE runs in one, and the run-time output screen appears on the other... see the /D option in the documentation).

Unfortunately, there is no way to achieve this kind of functionality for for dual-head and triple-head VGA graphics cards, except possibly by controlling the hardware directly (addressable memory will only cater to the primary screen).

However, if the manufacturer provides documentation on controlling the card in real-mode, then you might be able to write a custom solution... but I'd seriously doubt that any given solution would work with more than one specific model of card.

Using a pair of cards (PCI+AGP, or PCI+PCI, or ISA+PCI, etc) is yet another set of scenarios... it might be possible to manipulate the second card by direct hardware access, but I've never tried it...

But... if the PC is running 32-bit Windows then it would likely be a lot easier to write GUI applications with PB/Win and simply position each of the windows where you need them simply by adjusting the origin coordinates of each window.

Background: In Win32, dual monitors usually means that the desktop is simply larger (either wider or taller, depending on the configuration of the graphics card). In my case (Matrox G550 dual-head), I have an effective desktop resolution of 2048x768 (1024x768 per monitor)... however, in text mode (Screen 0), the second monitor shuts down, whereas on my old G450 dual-head card, the second monitor duplicates the main monitor in SCREEN 0.

Matrox have recently released the new "Parhelia" series of multi-head cards out now (dual and triple-head models), and they also operate an [apparently] excellent developer program... you might look there for assistance if you wish to get into direct hardware control.

I hope this helps!

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

**Robert E. Carneal** · 13 Oct 2002, 08:26 AM

Originally posted by Michael Mattias:
I have no clue re the number of monitors, but isn't looking at three (or four) monitors the hard way to find differences in files?

I mean, wouldn't it be a lot more efficient to extract the values from the three files and compare them programatically?

Or am I missing something?

Michael- you are not missing anything. I just offered a incompletely described scenario. How about if I put it this way: The information on person frequently takes up 3/4ths of the screen or more. Using multiple screens would stop my having to clear one and display the name from another file.

LANCE- You may have given me a clue! I just went to START >> MS Dos and opened the window. Then I repeated that and ended up with TWO windows, one I dragged over to the second monitor. Having two dos windows means I could run two different PB programs, AS LONG AS both do not access the same file? Does that make sense? Does that sound "doable"?

Thanks for the thoughts guys.

Robert

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

**Mike Luther** · 13 Oct 2002, 12:07 PM

I've been using multiple instances of PB 3.5 for DOS in separate
DOS-VDM windowed sessions in OS/2 for as long as PB 3.5 has been
in my posession. The ability to do just what you are attempting
was one of the reasons I chosd PowerBASIC long ago, for use with
OS/2.

Provided you use OPEN for RANDOM ACCESS SHARED file techniques,
it it may be trivial to use simultaneous read operations on the
same file, either by separate sessions on the same desk top or
separate system plus separate session across a LAN. Works fine.
The superb offering by PowerBASIC for what it can do with record
lock and so on, also makes it possible to seed your program with
flags which designate that a particular record is locked in the
middle of update for such operations.

By combining advance notice of that in a pre-written record, you
can keep track of who may be in a position to corrupt a record
for future write, between simultaneous reads of the same record.
That, together with locked records and error trap catch routines
which delay action on the record until the previous user writes
it, can make for very sophisticated multi-session uses of
simultaneously accessed records with PowerBASIC in DOS.

The problem has always been to me that this sort of brute force
operation when done in a WIN-95-98 game, completely seems to fall
flat on its face when more than one or two such incidences are
tried on the same WIN box. Where we've tried this multiple 'use'
same-box game on ant least WIN-95-98, it just crawls. Where as
with OS/2, you can operate even a dozen or so and it seems that
the more you load it, the better the operation gets under OS/2's
superb thread-oriented task splitting.

Contrary to the ever-present continual comment about the demise
of OS/2, it is VERY much still in development and support. The
current promise for supporting exactly what I'm talking about as
to DOS-VDM's and so on is now officially posted through December
31, 2004. It's less formally know to be there through 2006 or
maybe 2008. Depending wholely on how well your application can
be postulated as to the specific task at hand to the use of these
techniques, even Heritage applications of code still needed back
to the '386 era and into the early 1980's are still fully usable
and supportable under OS/2 .. and will be for many years even
beyond those dates. Yes, USB, fire-wire, the whole nine yards.

Specifically, under the issue of multiple screens and monitors
from the same box, you'll find that the brand new Sci-Tech Graphics
driver solution offically endorsed and supported by IBM for OS/2
will, in fact, let you use the Matrox dual-head video cards to
accomplish this task. That even with a dozen PB 3.5 applications
simultaneously in use on the same desktop and with and spanning
both monitors! So noted. you can split the screen for the entire
desktop across them. Although I've never done it, the use of a
Monchrome monitor in common use, using the split video page techniques
suggested by Lance for memory video writes, should work beautifully.
My industrial care single board CPU CIRRUS chipset dual flat panel
and conventional monitor output is fully supported. That much I
do know for fact.

I use the old page shift video windowing techniques in all my work
and have been doing so with PowerBASIC for all these years. There
has never been, to date, a single instance of trouble with popping
whole screens and chunks of them back and forth on the desktop at
will ever for me. That's how HELP is enabled in all my programs.

One other, I suspect, VERY important milestone on where OS/2 is
going in the future may be of interest to you as well. Recall,
that as a totally OBJECT oriented operating system, orchestrated
by threads, one of OS/2's really beautifully designed functions is
to assign even complete operating systems, such as DOS .. into a
complete emulation within the host system of OS/2. That's partly
how this is so beautifully orchestrated in it! WIN-3.1 is nothing
more than an OBJECT to it, as was and is, the initial experience
of WIN-95, some of the programs for that and early WIN-NT, of
which run as native code in it anyway.

By the way, if you really want extremely reliable roll forward and
transaction processing enabled plus indexed files which have this
same capability, Btrieve's 6.15 for DOS does this horribly well
even with no need, on the average, for any Btrieve Server based
instance of this for OS/2. It combines really well with OS/2
when based upon 4K data read/write blocks were are the target for
the HPFS file system and write through caching for it.

And please note! Just released, through CONNECTIX and cross-licensed
by INNOTEK in Europe for OS/2, is a complete HOST/GUEST toolset.
The complete mission-critical OS/2 operating system may now host,
as a secured OBJECT, any flavor of WIN or MULTIPLE flavors of it
you may desire, as well as RED HAT LINUX 7.3 too ... under OS/2.
What happens is that you simply create an OS/2 HPFS disk partition
of any size. You "install", the GUEST operation under OS/2 as if
it was on an 'invisible' system. The entire WIN-XP, or NT, or
ME, or 95, or any version or SIMULTANEOUS comination of them then
becomes only a DISK IMAGE to the OS/2 thread hosted host! You
may wipe that, restore it, do whatever you like with this 'phantom'
complete guest or guests. The HOST does not care a whit about it,
nor can any of the pest problems of the virus or hack game or
whatever .. pass the barrier to the HOST .. as was/is noted.

As far as I know, it's noted that full C-2 level security does exist
for this thing on the OS/2 side. However what you do with a GUEST
must, I suppose, open that disucssion to what isn't posted for C2
for OS/2 proper.

The entire GUEST experience is nothing more than a WIDOW on your
OS/2 Desktop; that's all. That is the same sort of thing which
was created way back then for WIN 3.1 and DOS and so on.

Processor and memory requirements are as follows. All you'll need
is minimum of a 400Mhz CPU and either 128MB or perhaps 256MB for
OS/2. It's nice to have more, but not for OS/2 at all unless for
certain complex applications. Then on top of that, you will need
to upgrade the CPU for whatever level is called for as minimal for
the GUEST operating system you wish to use. Obviously, code and
processor bloat has inflated that horribly from WIN-95 upward.
For memory, you will need to simple add whatever de-minimus
extra memory is needed for each of the operating guest systems
you intend to run simultaneously!

The CONNECTIX toolset takes care of all the rest. It handles all
of the hardware and driver requirements, converting them to standard
such tools as is found in the OS/2 game .. and ... handles all
networking and LAN operations as well. The systems appear to be
nothing more than simultaneous connections or drives on the LAN
you have on OS/2 (And your guest as well). As noted in the demos,
all the required translation between file systems and so on are
handled on the fly for you by the toolset(s). Your common file
with the date you postulated will simply be a resource across
that internal LAN for the various things you can dream up, and
... if you are using OS/2 for the RANDOM SHARED ACCESS networked
file operations, I suspect ypu'll have no trouble with that if
WIN doesn't have trouble with that in native use with PB 3.5 either.

You may choose to use the same SCI-TECH dual head monitor approach
across the combined HOST-GUEST(S) operation. So noted in the
OS/2 Usegroups, this seems to work out very well across even
Flat Panel displays.

Actually, you can go in the reverse and use the WIN operation as
the HOST and then run OS/2 of any flavor under it. There are
only certain versions of WIN which can be used to do this ... I
didn't note that as I'm not a WIN afficienado at all. I'm not
sure that you can use Red Hat 7.3 as the HOST yet. I didn't
notice that.

We live in interesting times. At, of all things, a FidoNet Net
382 BBQ monthly meeting in Austin recently, I theorized that the
entire IBM 64 Bit CPU internal hardware and operating system
game ... would be simply a 64 bit extension of OS/2 as what is
now the "Z" IBM operating sustem for it. It is already known
that this sort of emulation and HERITAGE assurance for code work
is postulated to work under it, whatever "it" turns out to be.

I have no official knowledge of that, but two of the table guests
both work in systems development at the Austin campus. There was
this puzzled huge smile on their faces when I popped off with the
theory ..

Further affiant sayeth not, but if you REALLY want to do cool things
with what you posted needed to be done, for a VERY long time in
the future you should be able to do all you can dream of with
OS/2 and this game.

Thinking "Out of the box", maybe?

------------------
Mike Luther
[email protected]

Announcement

Three monitor output possible?

Three monitor output possible?

Comment

Comment

Comment

Comment