Dos -> Windows communication

[LorenPechtel]

I'm trying to send data from a Borland Pascal program to a Delphi program. The data is of variable size up to 4k. The problem is I want to do this fast--I'm hoping for 100ms.

What I've tried:

Writing to a file and reading it on the Delphi side. This works but the timing isn't what I'm looking for--I'm getting >500ms times.

IPX (since I had working IPX code on the dos side already). So far I haven't gotten a single packet received despite every field looking fine on the Delphi side. The callback function *DOES* get called when the listen is cancelled so things are at least reasonably correct. There's something seriously wrong, though, in that upon cancelling the fourth buffer I get a read of address $FFFFFFFF occuring inside the NWSIPX.DLL module (supplied by Novell, I have no debug info to see what it's up to at that point.)

I have basically complete control over the machines in question--their main job by far is running my program. I have tried to figure out some way to get a block of memory that both programs can see but I have not figured out any way to accomplish this.

Note: This solution only needs to work on win9x. The dos program is very problematic on 2k and won't even complete it's initialization on xp. (As far as I can tell file locks are fubar in an xp dos box.)

 

[Bertv100]

I don't think such a thing is possible in a direct way(accessing memory). TP DOS programs work in real mode, whereas Delphi applications work in protected mode under Windows (processes are protected from each other i.e. they can't "see" each other).

Maybe you could use some free IO ports (in both TP and Delphi you can access them using the port[] or portw[] arrays). Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com

http://student.vub.ac.be/~bvingerh/

Don't worry what people think about you. They're too busy wondering what you think about them.

 

[LorenPechtel]

That has been my experience also--no way to get the memory manager to let me have such an address. It's physically possible but that doesn't say there's a way to get the system to do it.

 

[dilettante]

I'm not trying to teach my granny how to suck eggs here, but have you considered a RAM drive?

Win 9x has RAMDRIVE.SYS, and there is a quicky runthrough at

http://www.speedcorp.net/dos/dos/v-ramdrive-sys.html

on using it.

This drive will bump your CD and misc. drive letters up (it grabs the letter just above your HD partition letters as I recall) but it is free, easy, and somewht configurable. Plus both DOS and Win 9x can see it.

One caveat: though Win Me is a 9x family OS, something has changed with Protected Mode so that RAMDRIVE.SYS can only be used from bootable floppies such as an emergency repair disk on Me. So even though they've included the driver, dont get too frustrated if it won't work for you under Me.

Then of course you may find a number of 3rd party RAM drives out there too with fewer limitations or greater advantages. Seems to me RAMDRIVE.SYS only configures down to a 4KB drive as a minumum, and defaults to 64KB.


And after all of that, you still need a plan as to how you can best use ramdrive files as a communication area. Random files?

Ahh, shades of the '80s... RAM drives. ;-) Reminds me of my DOS and Amiga days.

 

[LorenPechtel]

Since "writing" it to the HD doesn't seem to result in disk activity (Windows caching the file) I don't think it would make a difference, but it's worth considering. I can't get ramdrive to run on my machine but I'll try it on a different one.

 

[dilettante]

Don't use the /A or /E parameter unless you have a memory manager (EMM386, etc.) installed too.

The MS ram disk driver will crap out instead of loading.

 

[4Hmermaid]

Hi LorenPechtel ,

we have the same problem with a datalogger task in a DOS-box under 9x AND Win-NT/2000.

Delphi is very slow because the multitasking of Delphi/Windows and a (multitasking) DOS program is not optimized.

Under 9x You can use the clipboard, there a some very easy units for Pascal (Real AND DPMI) and Delphi. You have to use the Win.API, still with BP.
This will NOT work under NT/2000/XP, because the DOS-box have a totaly own memory space.

We decided to use a RAM-Drive and write/read/delete files with commands instead of clipboard - or - network (IPX) messages.
Because everythink is doing in the drives cashe it is so fast as a direct memory access.

Greetings.

 

[lionelhill]

Am I right in assuming you want to get only 4K (4096 bytes) in less than 100ms, i.e. 0.1sec?? By rights that oughtn't to be impossible. This is 2 programmes sharing one machine, one DOS/pascal, the othe protected/Delphi. Is it a problem that one of the progs isn't getting much processor time, or is waiting for something, or whatever, and therefore isn't responding?

Really dense suggestion: if you want to pass over in memory, and can't find any common memory, how about (ouch this really hurts to say it) video memory. So far as I know there are plenty of workarrounds for direct use of screen memory even in protected mode, and it's got to be available to all programmes, and in a fixed, findable place.
Obviously you'd have to use a bit that isn't going to mess up the display.

Please ignore this posting if too too stupid

 

[LorenPechtel]

My first reaction is that I'm already using the screen but thinking about it there's more memory on the video card than is actually being used (no user likes modes above 640x480).

I suspect that part of the problem is getting control given to the Delphi program quickly enough. Hmmmm...

 

[lionelhill]

Thanks for kind reply. I was thinking about it while out shopping and came to conclusion I was utterly wrong: video ram is notoriously slow, and I don't actually know what happens to the DOS screen when windows is doing its stuff anyway. If you can't get the transfer to work via cached disk or a ramdrive, then there must be something more fundamental amiss with passing control fast enough between the two programs, and nothing is going to bypass that.

Incidentally, DOS progs going horribly wrong in windows: We had one machine that ran DOS boxes hideously slowly, and when I got rid of the DOS protected extender it was back to full speed. Since most DOS progs are written to run in under 500K anyway, who needs DOS/protected mode interface as standard? Other common one is dos prog uses mouse, but no one bothered installing dos mouse driver. Another common problem: TP often demands read AND WRITE access over its bits and pieces, like the bgi files if you're using them. In a system where file access is limited according to user, that plays havoc...

good luck, and sorry to clutter message board with amateurish replies!
Li

 

[LorenPechtel]

This .EXE is something over 2mb and users getting careless have been known to run out the entire 64mb dos box. I have seen legitimate uses that approached 60mb.

It should have been ported to Windows at least 5 years ago but I couldn't convince management of this. They have finally seen the light but it's overe 200,000 lines to port.

I suspect the problem lies in the control transfer (unfortunately, the program is crippled under 2k impossible under XP so I can't try a multiprocessor setup.) but I don't consider your idea amateurish at all--sure, video ram is slow but it's not slow enough to drag down the whole machine flipping 4k through it.