Cannot DIR with netware vlm client about fdpp

[andrewbird]

Hi there,
I think you'll need to rerun your test with the logging for MFS turned on i.e. -DD9d otherwise we won't be able to see if the filesystem calls are being handled by Netware or our redirector.
Also

• what is the output of the lredir command?
• what is the output of the Netware command to list mapped drives?

[bpranoto]

Output of lredir:

The netware command MAP.EXE resides in netware SYS:PUBLIC directory, so it can't be executed because DOSEMU is unable to see it.

Attached is the log file with -DD9d
boot.log

[andrewbird]

The netware command MAP.EXE resides in netware SYS:PUBLIC directory, so it can't be executed because DOSEMU is unable to see it.

Is SYS:PUBLIC mapped itself? Can you execute it by full path e.g. F:\map.exe? I'm aiming to see whether just findfile/next is broken or the whole interaction between Netware and our redirector.

[bpranoto]

When I was logged in, the mapping commands in the login script is executed

But, as you can see in the screenshot, I cannot execute the map.exe by its full path.

[andrewbird]

I think I'm going to have to try to recreate your setup here. What versions of Netware server and client are you running?

[andrewbird]

BTW I think I set up Netware only once 30 years ago, so it might be a challenge!

[bpranoto]

Netware server version 6.5 sp8 (latest version before discontinuation)
vlm v1,21

Other problem is current linux kernel drops ipx and ncpfs support, we have to install the kernel modules by ourself.

I think it will be easier if I give you ssh access to my computer? I just install the computer because it is an unused old computer. Please give me your email address.

[bpranoto]

you can contact me at [email protected]

[andrewbird]

I forgot to ask, is this a regression or has it never worked?

[bpranoto]

It is the first time I try in dosemu2/fdpp.

[bpranoto]

it works in opendos

[stsp]

Try freecom instead of comcom32.
If that fails too, try freedos.
And in case of fdpp please add
the f letter to the log flags.

[andrewbird]

it works in opendos

Interesting, that's unexpected to me.

@stsp , he's provided me with ssh now and I can confirm it's the same with freecom. I noticed from one of the logs he posted that something obtained LOL and SDA, so there might be some direct poking of those structures going on.
I just tried Freedos 1.2 kernel + freecom and that works okay to dir c: (mfs) and dir z: (netware).

[stsp]

Cool, thanks for info.
If it goes for lol, try $_dos_up=(off)
to see if maybe it doesnt like lol in umb.

[andrewbird]

If it goes for lol, try $_dos_up=(off)

No, unfortunately it didn't help.

Here are the logs with -f from the previous run (with default dos_up)
t1.zip

[andrewbird]

This FDPP debugging is probably beyond me, I was expecting an MFS problem. @bpranoto if @stsp wants to take over, will you extend the login details to him please?

[bpranoto]

no problem... You can forward my email to him.

[stsp]

Works fine with freedos.
So the interesting thing is
that vlm changes int2f/111ch
call (findnext) with 110ch
call under fdpp...

[stsp]

Should now be fixed.

[stsp]

Andrew, would you like to add
test about SS=DOS_DS (and
maybe some other things you
can think of) on the appropriate
redirector calls?

[stsp]

I wonder if other things, like
SFT pointers, should also be
relative to DOS_DS? Although
I haven't seen this ever documented
that way.

[andrewbird]

Andrew, would you like to add
test about SS=DOS_DS (and
maybe some other things you
can think of) on the appropriate
redirector calls?

Do you have an idea on how to implement such a test? My only idea is that maybe I could sample dosemu's log file, but I think I'll have difficulty associating the section of log with the test call.

[stsp]

Do you have an idea on how to implement such a test?

Same as vlm does.
You hook int2f and wait till
DOS calls you.
Or?