Subj : Another filearea question To : Mark Lewis From : Mvan Le Date : Sat Jun 09 2007 12:41 pm 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 * Origin: Top Hat 2 BBS (1:343/41) .