Sign in to follow this  
clapton

Communication between programs

Recommended Posts

Hello At first I wanted to say that this thread is completly not realted to games. I am really sorry but I just couldn't find any better forum in the Net than this one. :) What's more I didn't even know how to google to find the answers. :/ The problem is quite rare. I would like to know if there is any way of creating a bridge for communication between two programs (written in different langauges) in a good ole' DOS system? The thing is I would like to simulate something like 'threads' but as far as I know DOS doesn't work like this. Generally, the situation is as follows : There are 2 programs - one is controling an external device (thermometer in this case) and second is making some calculations. Since it's a research project both programs would be probably working for whole days (or even weeks) and communication through hard-drive wouldn't be the best solution. I was thinking if there is any chance of creating a layer of memory shared by two different programs? A couple of bytes would be enough! :) I would appreciate Your help/advice! Thanks!

Share this post


Link to post
Share on other sites
You could let one program hook an free interrupt and let the other call that interrupt with params.

We're talking 32bit? With DOS-extender? Then you have to check if the extender supports that particular interrupt number. I seem to remember that those extenders didn't provide access to all interrupts.

Share this post


Link to post
Share on other sites

DOS isn't a multitask OS. I would want to help you but I need to know how do you plan to execute two programs at once (driver, resident application, some multitasking enviroment...).

In DOS there is no memory protection, so you can access the memory addresses that you want.

Share this post


Link to post
Share on other sites
Quote:
Original post by jjmontesIn DOS there is no memory protection, so you can access the memory addresses that you want.


We have a winner!

If you want to be a little more advanced, you could use Freedos. Freedos is multitasking, so you could have your two programs running and use pipes for IPC (InterProcess Communication)

Share this post


Link to post
Share on other sites
Quote:
Original post by smr
Quote:
Original post by jjmontesIn DOS there is no memory protection, so you can access the memory addresses that you want.


We have a winner!


When you're using protected mode that memory will be proctected (hence the name). This'd make things a bit more difficult then.

Share this post


Link to post
Share on other sites
Hi, guys! Great thanks for your replies. I'll try to answer your questions as best as I can. So ...

Quote:
Original post by Endurion
You could let one program hook an free interrupt and let the other call that interrupt with params.


Hmmm. I've heard something about interrupts (when reading some old, old book about graphics I guess). Though, I have no clue how to use them really. I gonna' check that out. 'Looks' promising. :)

Quote:

We're talking 32bit? With DOS-extender?


Not really. :/ It's only the simple 16bit DOS. :) Computers that will be using this 'software' are hardly anything more than just a motherboard (some 286/386 probably - I am not sure what exactly do they have since it's where my father works, I mean in an institute of chemistry :P).

Quote:

Original post by jjmontes
DOS isn't a multitask OS. I would want to help you but I need to know how do you plan to execute two programs at once (driver, resident application, some multitasking enviroment...).


Well, every working method would be good. :]

To be frank, (1) one of the programs was written in BASIC (it's not me ...) while (2) second one (which is actually controlling the device) is in C. The task of (2) is to pass the current temeptauture (or whatever) taken from the device to (1). For now (1) calls (2) by DOS shell and the data is passed through a file. You see that this solution is not good at all. :/ Each 'shell command' and 'file i/o' requires a few disk operations. Let's assume that the whole operation (I mean 'talking') is done every 8 seconds. After a few weeks of working I am not sure if the hard drive would be fine. :P

Quote:

In DOS there is no memory protection, so you can access the memory addresses that you want.


Really? You mean that I can allocate some memory in C and after running a different program it will still be there? It would be great! :D

Quote:
smr
If you want to be a little more advanced, you could use Freedos. Freedos is multitasking, so you could have your two programs running and use pipes for IPC (InterProcess Communication)


Nice idea but - unfortunately - I can only use 16-bit DOS system. :)

Thanks !! :)

Share this post


Link to post
Share on other sites
If all you want to do is avoid the disk io then just setup a ram disk (~5 minutes of work) or communicate through a pipe.

Otherwise you should probably make a tsr out of the c program and communicate through an interrupt. There's gotta be a few ancient tutorials laying around on the net, it's just a matter of extensive googling ;)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Endurion
Quote:
Original post by smr
Quote:
Original post by jjmontesIn DOS there is no memory protection, so you can access the memory addresses that you want.


We have a winner!


When you're using protected mode that memory will be proctected (hence the name). This'd make things a bit more difficult then.


Not exactly true. While protected mode has memory protection, it just isnt DOS unless the first megabyte is read/write/execute. And there arent any 'threads' to distinguish one program from another. All there is is CS:EIP.

In regards to his problem..

..The way I see it the TSR/DRIVER should offer a simple ISR that returns a far pointer to the data to be shared. The TSR itself allocates the block of memory and the main program just gets this pointer from the TSR as needed.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
..The way I see it the TSR/DRIVER should offer a simple ISR that returns a far pointer to the data to be shared. The TSR itself allocates the block of memory and the main program just gets this pointer from the TSR as needed.


My God, what does it mean? :P Hey, I am not laughing or something because I really appreciate your effort and time spent on trying to help me. The point is I have no clue what is TSR or ISR and I feel that it would take a lot of time to learn how to cope with it. :)

I think I'd go for doynax's suggestion. Creating a ram drive seems to be a preety simple solution. Do you know any links in the Net or could you explain be this a bit ?

Great thanks guys! :)

Share this post


Link to post
Share on other sites
Well, when he was talking about DOS, I assumed that he wasn't going to be writing protected mode programs. And like the other guy said, the first megabyte isn't protected. He shouldn't have any trouble finding a few unused bytes in the < 1MB address space.

Share this post


Link to post
Share on other sites
Heh, he could hook the timer interupt (8 i think) and do simple round robin multitasking :P
As far as sharing memory goes, If you allocate a block of memory in DOS16, anyone can access it.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Anonymous Poster
When you're using protected mode that memory will be proctected (hence the name). This'd make things a bit more difficult then.


Not exactly true. While protected mode has memory protection, it just isnt DOS unless the first megabyte is read/write/execute. And there arent any 'threads' to distinguish one program from another. All there is is CS:EIP.

In regards to his problem..

..The way I see it the TSR/DRIVER should offer a simple ISR that returns a far pointer to the data to be shared. The TSR itself allocates the block of memory and the main program just gets this pointer from the TSR as needed.[/quote]

This is the best solution to this problem so far. It is fairly easy to setup a TSR (Terminate and Stay Residen), its just a matter of which function of interrupt 21h you are using, pluss some fiddling with an interrupt I cannot remember atm used to hook your tsr to an interrupt. Try to google for "DOS TSR" and you should find some information on the topic.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by clapton
I suppose that I can think of interrupts as about 'global system procedures'. Assuming it's correct, how big an interrupt can be (what is a size of code I can put there)?

Thanx :)


:) An interrupt is just a pointer to your TSR.
In DOS, when you normally terminats the program through function 0x4, the the control is given back to the OS and the memory allocated for your program are freed. When, on the other hand, you terminate trough int 21h function 0x0 ( <-- do not remember the actual function anymore ) the memory de OS allocated for your program at startup, so it is still available in memory AFTER the program is terminated. So when you hook up your program with an interrupt, terminates the program and then calls the interrupt in another program. the CS:IP is set to the CS:IP of which you told the interrupt to start at, which again is your code :)

I hope all this make any sense, because I fell of at the middle ;)

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I hope all this make any sense, because I fell of at the middle ;)


Now everything makes sense! After that it became clear to me what you were trying to tell me. Sorry but I simply had to have a really 'dummy' explenation. ;P Indeed, your advice is very good. I'll google for this particular 'termination' interrupt-function.

Once again, thanks! You are very helpful! :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this