1. asm.e questions
- Posted by Nick Metcalfe <metcalfn at ALPHALINK.COM.AU>
Oct 19, 1999
-
Last edited Oct 20, 1999
It may be that nobody has any answers to these questions, but it also may be
that they could have been missed them the first time. Anyway, having
recieved no responses, I will ask again....
>
> I would like to access INT #21 for dos file operations and
> wish to do so from within an assembly routine, not using the
> dos_interrupt() function. Are there any special procedures that must be
> undertaken with regards to the Causeway extender to do this? It is to
> be accessed from an interrupt service routine.
>
> Also on the same topic, how do I initialize a segmented pointer to a
> low-memory buffer [ds:si] for what I assume is 16-bit code when all I
> have is the linear 32-bit address of the buffer and I want to sort of
> keep my data segment? I'm not sure how to use the lea instruction in
> this context. Also all in assembly for the same direct-to-disk
> recording or playback ISR...
>
--
Nick Metcalfe <metcalfn at alphalink.com.au>
http://www.alphalink.com.au/~metcalfn
2. Re: asm.e questions
On Tue, 19 Oct 1999 23:51:55 +1000, Nick Metcalfe
<metcalfn at ALPHALINK.COM.AU> wrote:
>> I would like to access INT #21 for dos file operations and
>> wish to do so from within an assembly routine, not using the
>> dos_interrupt() function. Are there any special procedures that must be
>> undertaken with regards to the Causeway extender to do this? It is to
>> be accessed from an interrupt service routine.
Nick
I don't know what you mean by not using the dos interrupt because
int 21 is the dos interrupt?
If you mean to call real mode from protected mode you can use causeway
interrupt 31 FF01 ( INTXX ) or FF02 ( FARCALLREAL ). See Ralph Brown's
intterupt list for details. You may be interested in looking at
Jacques Deschenes doswrap.e that has code for block reads and writes.
Jacques Deschenes also has a file for cdaudio that uses real mode calls
in the the RMCALL.E. Jacques has alot of good code in the archive.
Also his code may give you ideas about using the segments.
PS Have you ever considered writing a TSR or Driver that you load and
call from Euphoria with software interrupts.
Bernie
3. Re: asm.e questions
Can anybody tell me if I need to enter real mode using the method described
below in order to use INT #21 file operations from 32-bit assembly?
Bernie Ryan wrote:
> I don't know what you mean by not using the dos interrupt because
> int 21 is the dos interrupt?
I mean not using the Euphoria dos_interrupt() function, which I assume provides
some insulation from protected/real mode problems and of course is inaccesible
from within an interrupt service routine.
>
> If you mean to call real mode from protected mode you can use causeway
> interrupt 31 FF01 ( INTXX ) or FF02 ( FARCALLREAL ). See Ralph Brown's
> intterupt list for details.
I would first like to know if this is strictly necessary for file handle based
dos operations before writing mountains of unneeded assembly. Is it the case?
> You may be interested in looking at
> Jacques Deschenes doswrap.e that has code for block reads and writes.
> Jacques Deschenes also has a file for cdaudio that uses real mode calls
> in the the RMCALL.E. Jacques has alot of good code in the archive.
>
> Also his code may give you ideas about using the segments.
>
I have studied the doswrap.e code, but it is based on the dos_interrupt()
function and reveals nothing more than what's already in my old book on
assembly. I will have a closer look at rmcall.e and Ralf's list and hope they
provide some new insights.
>
> PS Have you ever considered writing a TSR or Driver that you load and
> call from Euphoria with software interrupts.
I did consider this, and it would probably be a better environment for coding
this kind of thing, but I would prefer a neat, readable and especially hackable
include file for all Euphorians to use. A TSR system would have just the
wrapper and some inacessable com or exe file that must be loaded and unloaded
seperately.
Thanks all,
--
Nick Metcalfe <metcalfn at alphalink.com.au>
http://www.alphalink.com.au/~metcalfn
4. Re: asm.e questions
Bernie Ryan writes:
> If you mean to call real mode from protected mode you can
> use causeway interrupt 31 FF01 ( INTXX ) or FF02 (
> FARCALLREAL ). See Ralph Brown's interrupt list for details.
Euphoria's dos_interrupt() uses CauseWay
interrupt 31 with AX=FF01. Jacques seems to use
some other method in his rmcall.e. Ralf Brown's
description of FF01 is rather skimpy.
My CauseWay printed manual has a lot more detail on it.
Nick Metcalfe writes:
> I would first like to know if this is strictly necessary
> for file handle based dos operations before writing
> mountains of unneeded assembly. Is it the case?
I'm pretty sure that you must switch into real mode
before doing any DOS interrupts. DOS is totally
16-bit based.
The idea of doing file operations while in the middle of
handling a hardware interrupt, sounds pretty scary.
Maybe you should store some information in memory,
return from the interrupt, then do the file operations
at your leisure, outside of the interrupt handler.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: asm.e questions
Robert Craig wrote:
> My CauseWay printed manual has a lot more detail on it. [int 31]
>
I may be asking for some of that detail if I run into troubles :)
>
> I'm pretty sure that you must switch into real mode
> before doing any DOS interrupts. DOS is totally
> 16-bit based.
>
Great, thanks. I know what I need to do now, shouldn't be too much
difficulty.
>
> The idea of doing file operations while in the middle of
> handling a hardware interrupt, sounds pretty scary.
Scary is right, but it's doing no actual damage by experimenting. Good
thing, too. I do hope to end up with a stable library though.
Unfortunately, I must assume that because the task to be performed is
pretty intensive, getting Eu to handle the file operations would
probably drink way too much cpu power. It also means it could not be
made totally background and would need some kind of polling loop, the
very thing I want to eliminate.
Briefly, the isr's file section will need to page large sections of any
long waves from disk for mixing and playback in real time. It will also
be used for recording, although this will not be as strenuous, and could
probably be done the way you suggest, although I would prefer that to be
background as well leaving plenty of cpu power for vu meters, fancy time
displays and the like. B-)
--
Nick Metcalfe <metcalfn at alphalink.com.au>
http://www.alphalink.com.au/~metcalfn
6. Re: asm.e questions
Nick
Another thought if you are running in DOS why couldn't you use a
RAM disk ?
Bernie
7. Re: asm.e questions
Nick Metcalfe <metcalfn at ALPHALINK.COM.AU> wrote:
>
>Unfortunately, I must assume that because the task to be performed is
>pretty intensive, getting Eu to handle the file operations would
>probably drink way too much cpu power. It also means it could not be
>made totally background and would need some kind of polling loop, the
>very thing I want to eliminate.
>
>Briefly, the isr's file section will need to page large sections of any
>long waves from disk for mixing and playback in real time. It will also
>be used for recording, although this will not be as strenuous, and could
>probably be done the way you suggest, although I would prefer that to be
>background as well leaving plenty of cpu power for vu meters, fancy time
>displays and the like. B-)
>
>--
> Nick Metcalfe <metcalfn at alphalink.com.au>
> http://www.alphalink.com.au/~metcalfn
Nick,
I would like to know what you mean about IO routines eating up too much CPU.
I don't know how efficient Eu's file routines are, but IO typically is more
a consumer of clock time than CPU cycles. Finding ways to make IO efficient
on any particular configuration is no simple job, but CPU cycles are not
usually the most prominent concern. Also, from what I can tell, all Eu
driven file IO is synchronous...meaning Eu waits on the completion of IO to
proceed to the next instruction. Buffering and caching external to Eu can
improve the efficiency of such IO, but if the CPU has nothing else to do
other than wait on the IO, much will go to waste. Even if you do all the IO
in the background through some asm routine, you will still have to write
some polling routine to tie the IO to the Eu code. I think that you said
that this was to be done in DOS, where you have no call back ability. I
don't see how you will get to what you want to do without moving to a
Windows type setup.
Everett L.(Rett) Williams
rett at gvtc.com
8. Re: asm.e questions
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, October 24, 1999 12:21 AM
Subject: Re: asm.e questions
> Nick Metcalfe <metcalfn at ALPHALINK.COM.AU> wrote:
>
> >
> >Unfortunately, I must assume that because the task to be performed is
> >pretty intensive, getting Eu to handle the file operations would
> >probably drink way too much cpu power. It also means it could not be
> >made totally background and would need some kind of polling loop, the
> >very thing I want to eliminate.
> >
> >Briefly, the isr's file section will need to page large sections of any
> >long waves from disk for mixing and playback in real time. It will also
> >be used for recording, although this will not be as strenuous, and could
> >probably be done the way you suggest, although I would prefer that to be
> >background as well leaving plenty of cpu power for vu meters, fancy time
> >displays and the like. B-)
> >
> >--
> > Nick Metcalfe <metcalfn at alphalink.com.au>
> > http://www.alphalink.com.au/~metcalfn
>
> Nick,
>
> I would like to know what you mean about IO routines eating up too much
CPU.
> I don't know how efficient Eu's file routines are, but IO typically is
more
> a consumer of clock time than CPU cycles. Finding ways to make IO
efficient
> on any particular configuration is no simple job, but CPU cycles are not
> usually the most prominent concern. Also, from what I can tell, all Eu
> driven file IO is synchronous...meaning Eu waits on the completion of IO
to
> proceed to the next instruction. Buffering and caching external to Eu can
> improve the efficiency of such IO, but if the CPU has nothing else to do
> other than wait on the IO, much will go to waste. Even if you do all the
IO
> in the background through some asm routine, you will still have to write
> some polling routine to tie the IO to the Eu code. I think that you said
> that this was to be done in DOS, where you have no call back ability. I
> don't see how you will get to what you want to do without moving to a
> Windows type setup.
Maybe you can call DMA routines if your motherbd supports such things, and
call the DMA *before* you need the data, so it's ready when you are. Maybe?
Kat
9. Re: asm.e questions
>Kat wrote
>Maybe you can call DMA routines if your motherbd supports such things, and
>call the DMA *before* you need the data, so it's ready when you are. Maybe?
All motherboards support DMA
10. Re: asm.e questions
On Sun, 24 Oct 1999 10:14:15 -0400, Bernie Ryan <bwryan at PCOM.NET> wrote:
>>Kat wrote
>>Maybe you can call DMA routines if your motherbd supports such things, and
>>call the DMA *before* you need the data, so it's ready when you are.
Maybe?
>
>All motherboards support DMA
What DMA routines have to do with the original subject I can't discern,
other than that they asynchronously access RAM. I still don't see how,
especially under DOS, one can be certain of what has been read and what not
without doing some kind of polling. Since DOS doesn't support event oriented
coding, I can't see how the DOS IO routines, running separately even, can
notify the Eu routines of the status of the IO. The only way to ascertain
whether data is there is with some kind of polling routine. Then there is
the task of determining whether the data is that which was wanted in the
first place... and I just can't really see how that would work.
Everett L.(Rett) Williams
rett at gvtc.com
11. Re: asm.e questions
----- Original Message -----
From: Bernie Ryan <bwryan at PCOM.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, October 24, 1999 9:14 AM
Subject: Re: asm.e questions
> >Kat wrote
> >Maybe you can call DMA routines if your motherbd supports such things,
and
> >call the DMA *before* you need the data, so it's ready when you are.
Maybe?
>
> All motherboards support DMA
>
True DMA on a motherbd with only ISA slots?
Kat
12. Re: asm.e questions
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, October 24, 1999 11:04 AM
Subject: Re: asm.e questions
> On Sun, 24 Oct 1999 10:14:15 -0400, Bernie Ryan <bwryan at PCOM.NET> wrote:
>
> >>Kat wrote
> >>Maybe you can call DMA routines if your motherbd supports such things,
and
> >>call the DMA *before* you need the data, so it's ready when you are.
> Maybe?
> >
> >All motherboards support DMA
>
> What DMA routines have to do with the original subject I can't discern,
> other than that they asynchronously access RAM.
Easy- if you can have the data already in memory by the time you need it,
there is no waiting. Tell the hardrive you want "x" loaded into %y , then go
play another frame, and the hd loads the data while you are doing that,, or
whatever. You do need some sense of how much lead time is needed.
>I still don't see how,
> especially under DOS, one can be certain of what has been read and what
not
> without doing some kind of polling. Since DOS doesn't support event
oriented
> coding, I can't see how the DOS IO routines, running separately even, can
> notify the Eu routines of the status of the IO. The only way to ascertain
> whether data is there is with some kind of polling routine. Then there is
> the task of determining whether the data is that which was wanted in the
> first place... and I just can't really see how that would work.
DRDOS by Caldera does do event processing, msg passing, and time slice
multitasking. Just like windoze, but with a smaller footprint and easier
API,, and no oem gui.
Kat
13. Re: asm.e questions
On Sun, 24 Oct 1999 12:29:37 -0500, Kat <KSMiTH at PELL.NET> wrote:
>
>True DMA on a motherbd with only ISA slots?
>
>Kat
Then how do you think the floppys work on your motherbord ?
The dma controller is on the motherboard.
14. Re: asm.e questions
----- Original Message -----
From: Bernie Ryan <bwryan at PCOM.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, October 24, 1999 1:11 PM
Subject: Re: asm.e questions
> On Sun, 24 Oct 1999 12:29:37 -0500, Kat <KSMiTH at PELL.NET> wrote:
>
> >
> >True DMA on a motherbd with only ISA slots?
> >
> >Kat
>
> Then how do you think the floppys work on your motherbord ?
> The dma controller is on the motherboard.
>
I've never seen a DMA with a floppy. I know there is chip to handle the DMA,
it's been on motherbds at least since the ZX80 in one form or another. But
you couldn't tell the hard drives to DMA to a memory location inside your
program. On the early motherbds with PCI slots, not all the slots supported
DMA *from* sound cards, hd cards, etc,, because they couldn't get that
chip's attention to shut it off. What he needs to do is set the hd as a buss
*master* , not under the control of that chip. When the hd is running buss
master dma, the dma chip on the motherbd does one job, the cpu does another
job, and the card doing pci buss mastering does it's job. For instance, you
could have the motherbd chip doing an ems page swap, the cpu running your
app, and the hd dropping data into xms somewhere.
Kat
15. Re: asm.e questions
On Sun, 24 Oct 1999 13:48:19 -0500, Kat <KSMiTH at PELL.NET> wrote:
>----- Original Message -----
>From: Bernie Ryan <bwryan at PCOM.NET>
>To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
>Sent: Sunday, October 24, 1999 1:11 PM
>Subject: Re: asm.e questions
>
>
>> On Sun, 24 Oct 1999 12:29:37 -0500, Kat <KSMiTH at PELL.NET> wrote:
>>
>> >
>> >True DMA on a motherbd with only ISA slots?
>> >
>> >Kat
>>
>> Then how do you think the floppys work on your motherbord ?
>> The dma controller is on the motherboard.
>>
>
>I've never seen a DMA with a floppy. I know there is chip to handle the
DMA,
>it's been on motherbds at least since the ZX80 in one form or another. But
>you couldn't tell the hard drives to DMA to a memory location inside your
>program. On the early motherbds with PCI slots, not all the slots supported
>DMA *from* sound cards, hd cards, etc,, because they couldn't get that
>chip's attention to shut it off. What he needs to do is set the hd as a
buss
>*master* , not under the control of that chip. When the hd is running buss
>master dma, the dma chip on the motherbd does one job, the cpu does another
>job, and the card doing pci buss mastering does it's job. For instance, you
>could have the motherbd chip doing an ems page swap, the cpu running your
>app, and the hd dropping data into xms somewhere.
>
>Kat
Kat,
What is the relevance of this discussion? Soundblaster has been DMAing sound
data for lo these many years on the ISA bus, no less. Many SCSI cards and
some IDE/MultiIO cards supported DMA for IO on the ISA bus. Yes the PCI bus
with bus-mastering extended the control to a small extent and the speed to a
much greater extent. And there are only so many paths to memory...two to be
exact. As long as the two buses are not writing to the same leaf of the
tree, they can operate somewhat independently, but there are strong timing
considerations involved...AND NONE OF THIS IS WITHIN CONTROL OF MOST
PROGRAMS. Most of it happens at the BIOS level and most of it is as they say
is "hard" coded. Regardless of their pretended sophistication and "event"
orientation, most things that happen at the user program level are truly
procedural or interleaved at best. Simultaneity is not happening except at
the machine Rommed level. That is why Eu is so beautiful. It tends to make
explicit what is really happening for most programs...that is that they are
"proceeding" from beginning to end without ever having two things happen in
parallel. However sinuous the path, it still can be stretched out linearly
as if it had been written that way.
Yes, it would be nice to have explicit means of handling "threaded" code to
take advantage of IO and other wait times, but at the moment, I don't know
of any such facilities native to Eu. Thats what operating systems are for.
Where and how can this be related to programming in Eu, or for that manner
most other programming languages.
Everett L.(Rett) Williams
rett at gvtc.com
16. Re: asm.e questions
Wow. I've been away a day, look what happens 
Ok, one at a time. My apoligies to the repeated.
Bernie Ryan wrote:
> Nick
> Another thought if you are running in DOS why couldn't you use a
> RAM disk ?
> Bernie
By the stage I can consider using a ram disk, all the hard file-handling
work will already have been done. If the ram disk cannot offer me more
space than available physical memory without it, what benefit to use
it? It is much simpler and probably more efficient to store the sample
in allocated ram if it is smaller than what is available. The Direct to
disk recording / playback will be for samples longer than physical
memory. I often work with samples of many hundreds of megs as our band
records jam sessions on a hard drive. I would ideally like to take one
of these huge samples, play it back and mix other sounds with it in real
time for a post-mix with a live sound, or a really cool kareoke.
Everett Williams wrote:
> Nick,
>
> I would like to know what you mean about IO routines eating up too
> much CPU.
> I don't know how efficient Eu's file routines are, but IO typically is
> more
> a consumer of clock time than CPU cycles. Finding ways to make IO
> efficient
> on any particular configuration is no simple job, but CPU cycles are
> not
> usually the most prominent concern. Also, from what I can tell, all Eu
>
> driven file IO is synchronous...meaning Eu waits on the completion of
> IO to
> proceed to the next instruction. Buffering and caching external to Eu
> can
> improve the efficiency of such IO, but if the CPU has nothing else to
> do
> other than wait on the IO, much will go to waste. Even if you do all
> the IO
> in the background through some asm routine, you will still have to
> write
> some polling routine to tie the IO to the Eu code. I think that you
> said
> that this was to be done in DOS, where you have no call back ability.
> I
> don't see how you will get to what you want to do without moving to a
> Windows type setup.
The efficiency bottleneck is not really in Euphoria's IO routines, even
if they may be a fraction slower than pure dos, but in the wholesale
movement of large blocks of data between allocated memory (needed for
asm) and Euphoria variables (needed for IO). The added peek and poke
stages could slow down the whole operation many times over, as I have
found with trying other such asm / Eu interfaces. Thus the possibility
increases of buffer over/underrun on slower systems. All this could be
mostly avoided by using the dos file routines from within the ISR
itself.
The actual ISR will avoid the need for any polled servicing by being
completely self-contained. The interface to Euphoria can then consist
of simple "current operation is" flags, and Eu "trigger" functions to
begin the various real assembly routines. The ISR on it's own is the
callback routine, in a sense. There will be no Euphoria code in the
core routines anyway, so minimal inter-language juggling should be
necessary.
Kat wrote:
> Maybe you can call DMA routines if your motherbd supports such things,
> and
> call the DMA *before* you need the data, so it's ready when you are.
> Maybe?
I expect at least two dma channels to be very busy during direct-to-disk
recording / playback, one for the sound card and one for the hard
drive. I don't expect to program the hard drive dma directly though
(unlike the sound), not with DOS providing some very convenient
block-style transfer commands built right in.
> What he needs to do is set the hd as a buss
> *master* , not under the control of that chip. When the hd is running
> buss
> master dma, the dma chip on the motherbd does one job, the cpu does
> another
> job, and the card doing pci buss mastering does it's job. For
> instance, you
> could have the motherbd chip doing an ems page swap, the cpu running
> your
> app, and the hd dropping data into xms somewhere.
I'm fairly sure that knowledge of this kind of sophistication is not
really necessary.. I tells it what to do with a simple dos interrupt,
let it work out exactly how. The conceptual design of the library
should preclude possible dma conflicts between input and output, and I
am blissfully shielded from most of the rest.
----------
Many may consider this to be going about things the hard way, and I
admit it poses quite a challenge but it was for these kinds of
challenges that I started programming anyway, the ideal project
teetering on the edge of one's ability. I was dissapointed at the lack
of a callback in dos Eu, until I realized ways around it. Now to make
something useful of this, I decided, and myself. I have yet to produce
a real quality library...
Thanks all for the interest. :)
--
Nick Metcalfe <metcalfn at alphalink.com.au>
http://www.alphalink.com.au/~metcalfn
17. Re: asm.e questions
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, October 25, 1999 11:50 PM
Subject: Re: asm.e questions
> Kat,
>
> What is the relevance of this discussion?
Someone asked about speed in getting data off the hard drive into memory, i
think. I said tell the hard drive ahead of time to read it and have it
already in memory by the time it's needed.
I have several apps which run two or more instances of a non-threadable
language, and they are linked together with dde (for now) so, overall, the
languages are doing more than one thing at a time (well, time-sliced,
anyways),,, and i can prove this by locking one down with an infinite loop
and watching the others keep going. It's definitely non-linear. So a high
level coding shortcut for whoever asked about how to get the data faster is
to have instance #1 of Eu to start another instance of Eu and tell the
instance #2 to go get the data from the hd and put it in memory, then have
#2 tell #1 it's location,, or #1 tells #2 what to do with it,, or send it to
#1 from #2, or whatever else you can think of.
Without getting into a discussion of hardware with you, i was trying to
offer help to someone who asked for ideas. I'm dropping this thread now.
Kat
18. Re: asm.e questions
kat wrote
>I have several apps which run two or more instances of a non-threadable
>language, and they are linked together with dde (for now) so, overall, the
>languages are doing more than one thing at a time (well, time-sliced,
>anyways),,, and i can prove this by locking one down with an infinite loop
Nick is try to do this in DOS there is no DDE in DOS
19. Re: asm.e questions
----- Original Message -----
From: Bernie Ryan <bwryan at PCOM.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Tuesday, October 26, 1999 3:31 PM
Subject: Re: asm.e questions
> kat wrote
> >I have several apps which run two or more instances of a non-threadable
> >language, and they are linked together with dde (for now) so, overall,
the
> >languages are doing more than one thing at a time (well, time-sliced,
> >anyways),,, and i can prove this by locking one down with an infinite
loop
>
> Nick is try to do this in DOS there is no DDE in DOS
*sigh* , let me repeat myself just one more time...
dos: disk operating system: Microsoft is not the only company to have
written one, several companies have.
DDE: direct data exchange: not in *microsoft* dos, no,, but there is message
passing like dde in Caldera's drdos, and drdos is 100% compatable with
msdos, and it's been around for 15 years or so,, and it does multitasking,
plus it has a gui, an internet browser, email clients, networking, etc..
and you can run it with dosemu/linux. And it's free. Caldera has a
long-running lawsuit against Microsoft, and i expect Caldera to win. But
you'd better get it soon if you want it, it looks to me as tho Caldera is
shifting it's focus to linux sales and support. Linux has great publicity,
no dos does.
Take a look at:
http://www.lineo.com/products/drdos.html
If you do load up drdos, your Eu dos apps can msg back and forth in two ways
from what i understand,, msg mailboxes that require polling by the recieving
app, or priority msgs where the app is banged on by drdos to get it's
attention.
Kat
20. Re: asm.e questions
Then all nick has to do is convince everyone who uses his software
to use DRDOS.
21. Re: asm.e questions
- Posted by M King <boot_me at GEOCITIES.COM>
Oct 27, 1999
-
Last edited Oct 28, 1999
Hi Kat,
I was wanting to share info between a dos32 version of Eu and a Win32
(internet) program, so my dos game could talk over the net. I found out
that once you set a eu program to running, it locked down the memmory, and
you couldn't use that chunk anymore...but I found that you can share
information through accessable memory locations...ie unused printer port
address :)
tnx
Monty
>I have several apps which run two or more instances of a non-threadable
>language, and they are linked together with dde (for now) so, overall, the
>languages are doing more than one thing at a time (well, time-sliced,
>anyways),,, and i can prove this by locking one down with an infinite loop
>and watching the others keep going. It's definitely non-linear.
