Subj : Another filearea question
To : Mvan Le
From : mark lewis
Date : Fri Jun 08 2007 12:41 pm
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.
MvanL> Man I just use the Hurl menu option.
what has that to do with removing fossil and door library code from the package
in question? hurl is used to move a file from one location to another along
with its description... that has nothing to do with the original question and
discussion about MFM importing file_id.diz files...
[Arrowbridge I]
MvanL>> Probably because it's looking for dorinfo2.def for node 2 etc.
MvanL>> Atleast that's how AB-I works ie. dorinfo<node>.def. I'm assuming
MLvan>> AB-II works similarly.
SH>> Exactly.
MLvan>> copy %max%\dorinfo1.def .\dorinfo%1.def
that is exactly how one does it with a system that doesn't create dorinfo2-9
files... now, what does one do when they are running 10 or more nodes? the
dorinfox.def standard wasn't thought thru very well... i've seen implementation
that use hex and as such can support up to 16 nodes... i've also seen
implementations that support base36 which is also limiting on a large multinode
system... then, there're those that start dropping letters to make room for
numbers...
ie: dorinfo1.def
dorinf22.def
dorin134.def
like i say, not very well thought out... but it is way way way too late to do
anything about it now, too... i tried some 15 years back but all anyone wanted
to do then was spout the existing standard and do nothing about fixing or
enhancing it...
[trim]
MvanL>> Apparently people adopted the numeral in dorinfo#.def to
MvanL>> be a node designator when it was never meant to be. It's
MLvan>> probably a "dorinfo" dropfile specification version number.
hunh? you can provide documentation to this? i'd like to read it because
nothing like it was ever presented or found in all my research years ago...
everything i found showed that the number _was_ the node number... some bbs
systems got around the 9 node limitation by creating dorinfo1.def for all
nodes, though... and that's no real problem if the door can look in a directory
other than its own for the drop file...
ie: somedoor c:\bbs\n1
where c:\bbs\n1 is where the dropfile, whatever is being used, is located...
c:\bbs\n42 for node 42... no copying or overwritting and no possibility of
things going wonky if two users enter the door at the same time...
