Subj : Another filearea question
To : Mvan Le
From : Shawn Highfield
Date : Tue Jun 05 2007 10:56 am
Hello Mvan,
On 05/Jun/07 at 05:07 you wrote:
ML> I reached the website, but couldn't download the file. Internet
ML> Explorer timedout for some reason.
SH> Hrmmm.
I fixed that. Took me a while to figure out it was the FTP / NAT badness.
Just changed it to use HTTP to send files now.
SH> file_id.diz from MFM? I can't find the button to do
SH> that one. :)
ML> Did MFM ever import file_id.diz's ? ... I forgot ...
Okay then I'm not out to lunch. :) I just mis-read what you said. I've
almost got an updated MFM with file_id.diz importing working, just being held
up by time removing the fossil / door code to MFM which is causing a giant
headache in the OS/2, Win32 port.
Besides does anyone run it as a door anymore?
ML> compliant door.sys or the AB source code for retrieving node number
ML> from a standard door.sys dropfile is wrong.
I'm going to blame the Ab source code because I have around 30 other doors
using door.sys without a problem. :)
ML> Probably because it's looking for dorinfo2.def for node 2 etc.
ML> Atleast that's how AB-I works ie. dorinfo<node>.def. I'm assuming
ML> AB-II works similarly.
Exactly.
ML> copy %max%\dorinfo1.def .\dorinfo%1.def
I never thought of doing it that way, I changed the dorinfo.mec file with a
bunch of [if task] lines. :) Your way is much easier.
ML> Apparently people adopted the numeral in dorinfo#.def to be a node
ML> designator when it was never meant to be. It's probably a "dorinfo"
ML> dropfile specification version number.
