DOS Database Program - Named Pipes (?) Access

[eagletg]

Hi everyone.

I'm attempting to get a database application programmed in (or using the architecture of) Advanced Revelation to launch properly via vDOS. I have this working under NTVDM, but can't seem to get it to work under any of the emulation platforms including vDOS. Personally, I would love to use vDOS ongoing for this application, and intend to purchase a network license.

I am mapping the network drive that houses the application in vDOS via:
use F: \\192.168.x.x\f
(naturally substituting the actual IP Address and path to the network drive)

I am able to launch the application, but it fails in accessing a network share/service called Linear Hash (LHSRVC). As I mentioned, this transition to accessing the Linear Hash files works from NTVDM on a 32-bit machine.

I am tracing the launch of the application using things like SysInternals Process Monitor and Process Explorer, comparing successful vs unsuccessful launches. The place where it seems to fail is in attempting to access the following network location:
\\192.168.x.x\PIPE\RCL\LHSRVC

As far as I can tell, this is a named pipe that it is attempting to access via IPC or "Inter Process Communication". I imagine that this needs to be mapped somehow in vDOS, but haven't found the magical incantation to make it work thus far.

Some additional testing (specifically monitoring the network traffic via tools like WireShark) has yielded the following path that it is attempting to access:
\device\lanmanredirector\192.168.x.x\IPC$\RCL\LHSRVC

This last path was where I found the Inter Process Communication aspect of Named Pipes (which I was not familiar with previously). But I still can't seem to make it work with vDOS.

I have Googled nearly every aspect of this, and can't seem to make any headway, so any assistance would be greatly appreciated!!
Happy New Year!!
-Todd

[Jos]

Also the best wishes to you and yours!

I’m unfamiliar with using named pipes. I recall one once had the same problem, perhaps also Advanced Revelation. He modified the (old) vDos code so it would accept those pipe references.

The underlying problem is that at calling the Windows API, DOS paths are translated to Windows paths.
So DOS F:\folder\file will become \\192.168.x.x\f\folder\file.

As off version 2022.05.01 UNC paths are also excepted, \\192.168.x.x\f\folder\file is then internally first translated to DOS F:\folder\file.
This only works if the leading path (\\192.168.x.x\f) resolves to DOS path, made available by USE.

I thought to do some testing at the command prompt, but noticed the translation of UNC paths isn’t enabled for its commands. Doesn’t apply to your problem, but have to fix that of course.

Could you try if for instance USE P: \\192.168.x.x\pipe is accepted? If so, that would then hopefully also make \\192.168.x.x\PIPE\RCL\LHSRVC accessible.

Jos

[eagletg]

Hi Jos,

Thanks for getting back to me so quickly.

I attempted a few iterations of the use command, all of which failed.
use p: \\192.168.x.x\pipe
use p: \\192.168.x.x\pipe\rcl
use p: \\192.168.x.x\pipe\rcl\lhsrvc
use p: \\192.168.x.x\ipc$
use p: \\192.168.x.x\ipc$\rcl
use p: \\192.168.x.x\pipe\rcl\lhsrvc

For each, I receive a response of 'Invalid path: \\192.168.x.x' followed by the relevant path from the command I entered.

I also tried these in capital letters on the chance that things were case-sensitive.

I found that I can connect from one of my test Windows XP machines to the IPC$ and PIPE paths via the following commands:
net use \\192.168.x.x\ipc$
net use \\192.168.x.x\pipe
(Note, no drive letter/mapping in the commands.)

Each replied with:
The command completed successfully.

I also tried logging via vdos.exe /log just to see what it reports. Comparing the log to my Process Monitor results for a successful launch, I see it failing to find some of the same files (that are legitimately missing). Eventually, the Windows XP machine redirects to the \\192.168.x.x\PIPE\RCL\LHSRVC file, but the vDOS side doesn't seem to try that.

Here's that log (slightly modified here and there to redact info):

26.16 LOADEXEC: arev.EXE username dbname /x /m4096
         Redirect INT 24 ignored, won't be further logged
         OPENFILE  failed: APP\RDRIVER(2) => \\192.168.x.x\f\APP\RDRIVER(2)
         Illegal FPU ESC 3
         INT 1B => 00BE:E953
         INT 16 => 00BE:E998
   26.17 FPU forced rounding ON
   26.19 OPENFILE  failed: APP\LH2.LOG(2) => \\192.168.x.x\f\APP\LH2.LOG(2)
         OPENFILE  failed: LH2.LOG(2) => C:\vDos\LH2.LOG(2)
         INT 2F unhandled call 1683
   26.22 INT 1B =>  original
         INT 16 =>  original
   27.02 Delayed logging, set w/o DOS call:
         INT 23 =>  original
   46.00 vDos ended by EXIT (0)

Let me know if there is anything else you'd like me to try.

Thanks again for the assistance!!
-Todd

[Jos]

Too bad use p: \\192.168.x.x\pipe didn’t work.

I’ll setup a MySQL or MS SQL server and do some testing later this week.

Jos

[Jos]

I did some first tests and pondering how to support named pipes.

use p: \\192.168.x.x\pipe doesn’t work because vDos verifies it’s an actual (existing) directory, Windows API just reports an error at querying that.

Accepting that USE nonetheless would be an option, but I don’t like this awkward workaround. The requirement general UNC paths resolve to DOS paths (by USE) was primary a safeguard to limit a DOS program access to assigned directories.

The idea is to implement a new config.txt directive: PIPE=pipe path.

If used, vDos will only verify the pipe path could be valid:
\\text\pipe\text

As a file is opened by DOS API (and only for this function), the file name path is compared to that set by PIPE=. If they match exactly (not considering case), vDos will try to open that pipe.
If successful, DOS read and write operations should then work for that connected pipe.

Jos

[eagletg]

That would be awesome. I'd be happy to test in any way you see fit.

Thanks again Jos!

[Jos]

You read my PM?

Jos

[caseyse]

I have also been interested in using named pipes with VDOS but could not get it working two years ago when I last tried.   I would like to use Microsoft's TSR application dbnmpipe.exe, which provides named pipe access to SQL Server.   I use named pipes with Paradox 4.5 for DOS and Paradox SQL Link to access SQL Server.   

- Sean

[Jos]

The object so far was to let vDos accept a “\\text\pipe\text” string in a File Open operation. Pipe communication supposed to be handled by standard File Write and Read operations.

dbnmpipe.exe provides for more functionality by extending DOS API Int 5Fh and 62h. Documentation on both interfaces is however virtually non-existent.

Jos

[caseyse]

Hi Jos,

Thank you for the explanation.   It looks like I'll be going to my grave with real DOS.

- Sean

[eagletg]

Hi again Jos,

Thanks for the PM. I noticed that the default ProBoard notification settings are very conservative (likely as not to cause too much spam), so I've modified them and should be much more responsive as a result. :-)