Dos -> Windows communication
Dos -> Windows communication
(OP)
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.)
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.)
RE: Dos -> Windows communication
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.
RE: Dos -> Windows communication
RE: Dos -> Windows communication
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.
RE: Dos -> Windows communication
RE: Dos -> Windows communication
The MS ram disk driver will crap out instead of loading.
RE: Dos -> Windows communication
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.
RE: Dos -> Windows communication
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
RE: Dos -> Windows communication
I suspect that part of the problem is getting control given to the Delphi program quickly enough. Hmmmm...
RE: Dos -> Windows communication
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
RE: Dos -> Windows communication
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.