Subj : Another filearea question
To : Shawn Highfield
From : Mvan Le
Date : Fri Jun 08 2007 07:34 am
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 ...
SH> Okay then I'm not out to lunch. :) I just mis-read
SH> what you said. I've almost got an updated MFM with
SH> file_id.diz importing working, just being held up by
SH> time removing the fossil / door code to MFM which is
SH> causing a giant headache in the OS/2, Win32 port.
Man I just use the Hurl menu option.
SH> Besides does anyone run it as a door anymore?
Not me. I'll set it up one day for kicks, just to remember what it does. I
never really used it.
ML> compliant door.sys or the AB source code for retrieving node number
ML> from a standard door.sys dropfile is wrong.
SH> I'm going to blame the Ab source code because I have
SH> around 30 other doors using door.sys without a problem.
SH> :)
That's what I thought too :)
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.
SH> Exactly.
ML> copy %max%\dorinfo1.def .\dorinfo%1.def
SH> I never thought of doing it that way, I changed the
SH> dorinfo.mec file with a bunch of [if task] lines. :)
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.
SH> I wonder if that's what happened? Makes sense.
I dunno. I just adapt to whatever works. I stopped questioning it a long time
ago :)
--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)