ml>  MvanL> Man I just use the Hurl menu option.

 ml> what has that to do with removing fossil and door 
 ml> library code from the package in question? hurl is used 
 ml> to move a file from one location to another along with 
 ml> its description... that has nothing to do with the 
 ml> original question and discussion about MFM importing file_id.diz files...

Hurl has everything to do with not removing fossil, library code and
importing file_id.diz's with the package in the original question and
discussion.

 ml>  MLvan>> copy %max%\dorinfo1.def .\dorinfo%1.def

 ml> that is exactly how one does it with a system that 
 ml> doesn't create dorinfo2-9 files... now, what does one 
 ml> do when they are running 10 or more nodes? the 

Pass the node as an argument to the door. If the door doesn't support such
execution then use an alternate dropfile.

 ml> dorinfox.def standard wasn't thought thru very well... 

People assuming that "x" is a node designator would be
uncomfortable with their understanding of dorinfo1.def.

 ml> i've seen implementation that use hex and as such can 
 ml> support up to 16 nodes... i've also seen 
 ml> implementations that support base36 which is also 
 ml> limiting on a large multinode system... then, there're 
 ml> those that start dropping letters to make room for numbers...

 ml>   ie: dorinfo1.def
 ml>       dorinf22.def
 ml>       dorin134.def

Which is all pointless unless the door is programmed to read the most
recent created *.def file or accept a node number as a command line option.

A "/node=65535" sounds pretty limitless to me.

 ml> like i say, not very well thought out... but it is way 
 ml> way way too late to do anything about it now, too... i 
 ml> tried some 15 years back but all anyone wanted to do 
 ml> then was spout the existing standard and do nothing 
 ml> about fixing or enhancing it...

... assuming it needed fixing or enhancing. That's what alternate dropfiles
were for eg. door.sys. 

Did you ever think dorinfo1.def was made for Maximus/QBBS/RBBS, and that
doors written for these systems were meant to follow a standard method of
execution ie. support a /n# or /node= et al. ? and/or interface with their
respective BBS's in a certain way ... The same way(s) exitinfo works for RA
and forces all RA util authors to adhere to its ideologies, and prevents
other BBS's from using exitinfo-specific doors ?

 ml> [trim]

 ml>  MvanL>> Apparently people adopted the numeral in dorinfo#.def to
 ml>  MvanL>> be a node designator when it was never meant to be. It's
 ml>  MLvan>> probably a "dorinfo" dropfile
specification version number.

 ml> hunh? you can provide documentation to this? i'd like 
 ml> to read it because nothing like it was ever presented 
 ml> or found in all my research years ago... everything i 
 ml> found showed that the number _was_ the node number... 

Because that became the most popular train of thought.

It is documented somewhere - some BBS/door author(s) made a complaint.

 ml> some bbs systems got around the 9 node limitation by 
 ml> creating dorinfo1.def for all nodes, though... and 
 ml> that's no real problem if the door can look in a 
 ml> directory other than its own for the drop file...

 ml>   ie: somedoor c:\bbs\n1

 ml> where c:\bbs\n1 is where the dropfile, whatever is 
 ml> being used, is located... c:\bbs\n42 for node 42... no 
 ml> copying or overwritting and no possibility of things 
 ml> going wonky if two users enter the door at the same time...

My argument would be people started writing and using TCP/IP and
multithreaded daemons and computer clusters and invented the
I-n-t-e-r-n-e-t.

And that's why those large multinode BBS's are extinct and any
node/dropfile conflict issues are nowadays virtually impossible.

--- Maximus/2 3.01