home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
DP Tool Club 8
/
CDASC08.ISO
/
VRAC
/
CDMX2DOR.ZIP
/
CDMX2DOR.DOC
< prev
next >
Wrap
Text File
|
1993-09-06
|
122KB
|
2,505 lines
=============================================================================
"Whatsoever we ask, we receive of him, because we keep his commandments, and
do those things that are pleasing in his sight." 1 John 3:22
=============================================================================
CDMX2DOR
Release v1.10
The "Next Generation CDRom-Access BBS Door"
(c)1993 Robert E. Lee
(309)797-6027
U.S.A.
1:232/31 8:7002/3005
New Century BBS
See end of file for Revisions History
=============================================================================
A special "Thanks" to Chris Kuefler @1:3402/22@Fidonet for his suggestions
and assistance in beta-testing CDMX2DOR.
Thanks also go to Samson Luk 6:700/8 and to Dave DeGear 1:351/220 /300
for their help in testing and making suggestions to improve CDMX2DOR.
=============================================================================
[1.0] Introduction
So long, ROMBRAIN, Hello CDMX2DOR!!!
In the beginning there was CDMAXDOR, and it worked ok on some
boards but was not capable of doing some things that it should
and gave some folks fits. As a result of many suggestions from
CDMAXDOR users and other sysops, here is CDMX2DOR, a CDRom-BBS
interface door that, I believe, you'll find to be a superior
product. The latest version of CDMX2DOR is available for F'Req
at 1:232/31 as well as are a number of other doors we've written.
[1.1] WHAT WILL CDMX2DOR DO?
In a word.... EVERYTHING.
Some features:
o it will work with ANY BBS software (not just MAXIMUS) that
is capable of writing a long-style (52 line) DOOR.SYS
drop-file, e.g., WILDCAT, PCB, GAP, etc. If your system
can't write a long-style DOOR.SYS, then you may still
use this software via a door conversion program that
makes long-style DOOR.SYS files.
o it will allow you to control the number of KBytes that
a user may access from your CD's in a given day so as
to prevent file leaching regardless of BBS software type.
o it will allow viewing of textfiles and will unarchieve
zips for viewing as well.
o it will automatically update MAXIMUS BBS user's files
to reflect their CDRom downloads. Other boards' auto-
updating of user's download stats is not yet supported
but will be (for registered users).
If you are a Maximus BBS sysop, it will:
o end the need to re-SILT when you
change CD's
o end the need to FB your CD's
o end putting your CD's files.bbs's on your
HD and save you a lot of HD space
o automatically write its own door.sys
of the type necessary
o make using CD's on Max a piece of cake!
o Configuration is done by a standard ASCII text editor
of your choice, e.g., QEdit, so it is very easy to
set up. Extensively documented installation instructions.
o it will allow users to download files from your CD or
HD with ease, search for files or text, and allow your
users to unzip files on the CD for reading text files
and other docs in zipped files.
o it will add your BBS comment/advertisement on outgoing
files.
o it will also allow you to put your C: drive (HD) files
within its structure for use, so CDMX2DOR can even be
used as a complete drop-in files-transfer system working
with CDRom drives and Hard Drives. Tape drive interfacing
may be supported in future versions to registered users.
If you want to squeeze every possible drive for online
files for your users, you can even have CDMX2DOR access
files off your B:\ drive for an additional 1.44 meg of
files online.
o it has beautiful ansi graphics and also supports non-ansi
use.
o it will allow you to have as many as 34 CD's online, each
in its own drive, from which users may select
o it will support CD's with as many as 238 subdirectories
and you can break down a CD that has more than 238
subdirectories into 2 or more sub-sets (thereby making
CDMX2DOR capable of handling any CD regardless of its
number of subdirectories).
o it is fully configureable. It will work with:
o CD's with files.bbs in separate
subdirectories on the CD.
o CD's with dirx.lst in separate
subdirectories on the CD.
o You can even specify what file it should
look for to find subdirectory listings,
e.g., files.bbs, dirx.lst, files.lst,
DIR, or whatever you have.
o CD's that have their files.bbs's or
whatever, in a single subdirectory on
the CD instead of having them in each
subdirectory.
o It will even work with CD's that don't
even have a files.bbs or other subdirectory
listing at all -- you can create a list
on your HD and call it whatever you like
(but it must be in a files.bbs- or dirx.
lst-like structure). A utility for making
skeleton files.bbs-like structures is
included in this archieve.
o If you wish you can copy your CD's files.bbs-
like lists to the HD for fast file searches
or leave them on the CD to save HD space.
It is entirely up to you.
o you can even incorporate your HD files
into CDMX2DOR if you desire.
o Detects online/offline files automatically.
o Supports X, Y, 1K, and Z-modem downloads via DSZ.COM
o Supports file-tagging, instant downloading, global search
and a host of other features.
Not bad, eh? Well, it will do much more. It will keep track of
a user's downloads so that you can specify a "daily limit" of
download Kbytes off the CD(s). It will keep track of how much
time it will take to download files (based on baudrates) and not
allow a slow modem to download a huge file and eclipse their
time-allotted limit. It will even allow you to lock out certain
files from being downloaded if you don't want nasty gifs to be
available to your users. There's even more...
o Supports having certain files requiring a "key" that
a user must know in order to process these files.
o a whole lot more!
The following sysop functions are available while awaiting
keyboard input :
F5 - Shell to DOS.
F8 - Twit user and return to BBS.
F10 - Initiate chat with user.
<CTL>F10 - Answer user's page.
Home - Main user stats.
End - Displays sysop keys available.
PgDn - Secondary user stats.
Up Arrow - Increase user's time remaining.
Dn Arrow - Decrease user's time remaining.
o Utilities for making dirx.lst's for CD's that have no
files.display strutures and for making dirx.lsts from
your files.bbs files on your HD.
o Utilities for translating files.bbs files into dirx.lst-
like structure files.
o full control over IRQ's and HEXport addressing of COM
ports.
o Sysop paging, chat with user, etc.
Interested? <g> Let's look at how to install it.
[2.0] DEFINITIONS
A "DSP" is a file in which is contained the files list of a
paraticular subdirectory. Typical DSPs are "files.bbs" or
"dirx.lst" or some other type of list. Henceforth, reference
to "DSP" or "files display structure" is referring to a
file like this.
A "Files.bbs" DSP does not usually contain the file size and
file date for the files it describes; a "dirx.lst" usually
DOES contain that information. CDMX2DOR requires that your
DSP have the size/date information present. If you have a
files.bbs DSP that does, in fact, have the size/date information
in it, then your displays in CDMX2DOR will be just fine; if they
do not and there is no alternative DSP available on your CD then
you should make a "dirx.lst" DSP using utilities included herein.
More about all of this as we continue...
[3.0] INSTALLATION
Unzip CDMX2DOR.ZIP into a subdirectory of your choice. In your
subdirectory you should find these files:
FILE Function
FILES TXT A directory-listing of files in this package.
DOOR SYS A sample door.sys
BBSSTAT ASC ASCII/Non-Ansi display files
CDSONLIN ASC "
DIRECTS ASC "
DOWNSCR ASC "
FILEH ASC "
DOWNIT ASC "
FIN ASC "
HELPSCR ASC "
MAIN ASC "
MORE ASC "
STAG ASC "
TAGEDIT ASC "
OPSC ASC "
FORB ASC "
LOCKEY ASC "
CDSONLIN ANS Ansi display files
BBSSTAT ANS "
DIRECTS ANS "
DOWNIT ANS "
DOWNSCR ANS "
FILEH ANS "
FIN ANS "
HELPSCR ANS "
MAIN ANS "
MORE ANS "
STAG ANS "
TAGEDIT ANS "
OPSC ANS "
FORB ANS "
LOCKEY ANS "
CDTEMP LST CDMX2DOR-operation list file
NO8CBOB LST CDMX2DOR CD menu-control file for NightOwl 8 CD
PBCBOB LST " (for PowerBox v1.00 CD)
PPCBOB LST " (for PowerPak Gold '92 CD)
CDSONLIN LST CDMX2DOR-operation CD/Door/Menu interface file
LOCK LST CDMX2DOR-operation locked/keyed file interface file
AHELP TXT CDMX2DOR-operation text files for remote door users
CHELP TXT " (Note these are not "DOC" files
VHELP TXT " but are used by CDMX2DOR)
SHELP TXT "
YHELP TXT "
DHELP TXT "
HHELP TXT "
THELP TXT "
PHELP TXT "
ZHELP TXT "
TAGLIST DAT CDMX2DOR-operation data files
USERS DAT "
NGDL LOG CDMX2DOR-operation log files
BADSEND LST " (written if necessary)
NCB ADV Sample BBS advertisement file
CDMX2DOR MEC Maximus BBS-specific files
CDMX2DOR BBS "
FIXMAX EXE "
FLYDIRX.EXE A utility for creating dirx.lst-type structures for CD's
that have no files.bbs/dirx.lst or other file-display
structures. FlyDirx will work on any drive, A,B,C,D,E,
etc. You can do individual directories by running
FLYDIRX.EXE via a command line call or recursively
through an entire CDRom by using FLYENGIN.EXE. FLYDIRX.EXE
can handle subdirectories with up to 300 files. FLYDIRX
will also import files' descriptions from existing files.
bbs files (if it finds them in the directory your are
trying to convert to a dirx.lst AND if they are normal
files.bbs files).
FLYDIRX.CFG Works with FLYDIRX.EXE and FLYENGIN.EXE to do massive
creations of skeleton dirx.lst files (in the case of
working with CD's that have no files-display structures,
e.g., files.bbs's or anything else
FLYENGIN.EXE Mass-driver for FLYDIRX.EXE.
KUEFLER.EXE For converting odd files.bbs files to dirx.lsts
DIRXMAKE.EXE A utility for translating your files.bbs structures
into dirx.lsts so you can display your C: drive (HD) files
on CDMX2DOR. (Particularly useful for Maximus sysops in
incorporating Max's files into CDMX2DOR services.
DIRXMAKE.CFG Configuration file for DIRXMAKE.EXE
FASTFREQ.BAT A batfile to drive INSTFREQ.EXE in copying files and
driving FLYDIRX.EXE to make "innies"
INSTFREQ.EXE A utility to copy any file(s) from any drive to any other
drive while being in a third drive. INSTFREQ will
use wildcards, e.g., *.zip, fa*.arj, cat*.*, or *.*
CDMX2DOR CNF CDMX2DOR-operation CNF file
CDMX2DOR CFG CDMX2DOR-operation CFG file
CDMX2GO BAT CDMX2DOR-operation BAT file
CDMX2DOR ERR CDMX2DOR-operation Error report file
CDMX2DOR EXE CDMX2DOR
Ok, now that you have identified these files and they are unzipped
in a subdirectory of your choice, then you must:
=============================================================================
[3.1] Fix CDMX2DOR.CNF file. In it you will find the following:
--------- Line #
c:\cdbob <----- your door's subdirectory 1
New Century BBS <----- your board's name 2
0 <----- leave this as a zero so to read door.sys 3
3 <----- your IRQ number 4
02F8 <----- your Comport's HEX address 5
3 <----- your IRQ number again 6
cdmx2dor.cfg <----- the name of your *.CFG file 7
---------
Fixes: Change line (1) to that of the subdirectory in which you
have unzipped CDMX2DOR.ZIP. Be sure to have the DRIVE
and a colon and a backslash and the subdirectory name.
Change line (2) to the name of your BBS
Leave line (3) as a 0.
Change line (4) to reflect your IRQ # (Com2 is 02F8, and
IRQ 3. See a list in this doc file (below)
for other IRQ numbers based on ports, etc.)
Change line (5) to your HEXport address. Default is at
COM2. See below for other HEXport addresses for other
ports besides COM2.
Change line (6) to the same value as that in line (4).
For line (7), please specify the *.CFG file that you
are using for your particular node. If you are running
just one node, you can call your file by the name I
have included here and just edit the cdmx2dor.CFG file
to reflect your particular situation. If you are
multinoded, you'll likely need additional *.CFG files
(particularly if you are running Maximus): there is more
on this below.
You will eventually use this *.CFG file in a command-line argument
to start the door up via a bat file, e.g.,
/--- see here... a command-line argument.
/ to start the door up is found
C:\cd2>cdmx2dor cdmx2dor.cnf in your startup BAT, e.g.,
CDMX2DOGO.BAT
Leave no blank lines at the end of this file after editing.
=============================================================================
[3.2] Fix CDMX2DOR.CFG file. (Note: you can have multiple copies of
this file (with changed names) for multinode; or you can rename
this file to whatever you please if you like (as long as you
reflect the changed name in your *.CNF file).
This file is highly commented so you can follow instructions there.
Do not remove the ";" commentline markers on the left margins.
Leave no blank lines at the end of this file after editing.
Note that this file can be renamed to whatever you like it to be
called or your can have multiple *.CFG files to support multinode
situations. You will place tha name of this file in your
CDMX2DOR.CNF file (see above).
=============================================================================
[3.3a] IF you are NOT using MAXIMUS BBS software, then you should
set your system up so that it will write a 52-line door.sys which
CDMX2DOR can use. If your particular BBS software won't write a
52-line door.sys, then you can use a conversion program, e.g.,
QKDOOR2B.ZIP, to make a 52-line door.sys from your BBS's own
unique dropfile (e.g., dorinfo1.def, callinfo.bbs, or whatever your
BBS might write). Door.sys MUST eventually be copied to or written
directly in the subdirectory in which CDMX2DOR files reside. That
copying may be accomplished in a *.bat file, e.g.,
--sample.bat--
@echo off
C:
cd \bbs
cd \<cdmx2dor subdirectory>
copy c:\bbs\door.sys
cdmx2dor cdmx2dor.cnf
cd \bbs
---------------
You note that the above *.bat copies door.sys to CDMX2DOR's sub-
directory and starts up CDMX2DOR. If there is not a door.sys
in CDMX2DOR's subdirectory, then the door will not work.
[3.3b] IF you ARE using MAXIMUS.BBS software, then you should make an
edit to your MENUS.CTL file in the FILES section thusly:
Display_File \cdbob\cdmx2dor Normal "2CDRoms"
Now note that you should change the "\cdbob\cdmx2dor" so that
the "\cdbob\" part states the subdirectory in which CDMX2DOR
is actually residing. You can also change the part after the
"Normal," i.e., the "2Cdroms" to be whatever you'd like. You
must however, have this in your FILE section of your MENUS.CTL
somehow else your users won't be able to access your CD's.
Make sure you now re-SILT Maximus so that the change you made
is incorporated into your FILES area. You will not have to
SILT Max ever again for this door.
This change will allow users to activate the cdmx2dor.bbs that
is in CDMX2DOR's subdirectory. Cdmx2dor.bbs will do 2 things:
(1) it will write the appropriate door.sys for you and it will
start the door up. You will need to make some edits to this
cdmx2dor.bbs, so included is the cdmx2dor.mec file that
you can change as needed. Particularly, you will find in the
cdmx2dor.mec file a need to change the door.sys directory
lines, e.g.,
-------- excerpt of cdmx2dor.mec -------
[comment %Z Translates to the user's full name, in caps.]
[comment install the door.sys in the right subdirectory]
[delete]c:\cdbob\door.sys <----- change this line
[open]c:\cdbob\door.sys <----- change this line
[write]COM%P:[comment Com Port ]
[write]%b[comment baud rate]
------- end of cdmx2dor.mec excerpt ----
Change the lines with the door.sys statements in them to reflect
the placement of your CDMX2DOR files. The objective is to have
a door.sys written in the subdirectory where CDMX2DOR is.
You should also make a change in the following section of this *.mec
file, i.e.,
-------- excerpt of cdmx2dor.mec -------
[comment quit comment And we're done! ]
[comment start up cdmx2dor.exe with an extern run to re-read the lastuser.bbs]
[xtern_dos]@c:\cdbob\cdmx2dgo.bat <------ change this line
-------- end of excerpt ----------------
The last line is where you should make the change. Change the
subdirectory line to reflect the subdirectory where you have placed
CDMX2DOR files. Make sure you have CDMX2DGO.BAT (or another similar
bat) in CDMX2DOR's subdirectory. Also make ABSOLUTELY SURE that
you do not forget to put the "@" character right after the
[xtern_dos] command else Maximus user.bbs will not be updated and
will not show users' downloads off your CDs.
After you have made your changes, you should go to your MAX sub-
directory and and MECCA your CDMX2DOR.MEC file so as to create
a CDMX2DOR.BBS file. If you don't then it won't work <g>. After
you have SILTed your changes into MAX, MECCA'ed your cdmx2dor.mec
and have the *.bat file in your CDMX2DOR subdirectory you're all
set to go.
The *.bat file should look like so:
--------- *.bat statup file example --------
@echo off
C:
cd \cdbob
cdmx2dor cdmx2dor.cnf
cd \max
--------------------------------------------
Make sure the last line switches back to MAX, i.e., "cd \max"
or whereever. Adjust as necessary, of course. MAXIMUS is
GREAT!!! software for BBS's BTW. If you aren't using
MAX, then you really should <g>. Thanks Scott Dudley!
=============================================================================
[4.0] CD PREPARATION
If you have the following CDs:
NightOwl 8
PowerBox v1.00
PowerPak '92
then you can use the following files in CDMX2DOR's sub-
directory with minimal edits:
NO8CBOB LST 1751 07-27-93 1:11p
PBCBOB LST 1163 07-14-93 2:02p
PPCBOB LST 1626 07-14-93 2:01a
These files are the control menus where CDMX2DOR interfaces with
these particular CD's. You can use these files as is without
changes (unless you are on running them on some other drives then
those specified - take a look at 'em).
Note: If you have done the above changes and have no other CD's
than the ones above, then the door is ready to go. Before you
run it however, you probably should read on...
=============================================================================
[5.0] PREPARING CONTROL MENU (*.LST) FILES
If you have CD's other than the one's above (as you probably do)
then you will have to make your *.LST file(s).
[5.1] HOW TO MAKE A CD MENU-CONTROL *.LST:
Your construction of your CD menu-control *.LST will be
governed by the type of setup your CD has (as regards its
subdirectories, files' list types, etc.). You'll have to
examine your CD to determine which of the below configurations
suits your particular CD and then build a CD menu-control
*.LST file for it.
You will build your *.LST file(s) with a standard text editor,
e.g., QEdit. Some sample lists are included in this archieve
for NightOwl 8 (no8cbob.lst), PowerBox v1.00 (pbcbob.lst), and
PowerPak Gold '92 (ppcbob.lst) that can serve as examples.
===============
Making "INnies"
===============
Here's an excerpt sample *.LST for your consideration:
-------------------------------------------
Fig. 1
----------- ppcbob.lst excerpt ------------ LINE #
PowerPak Gold '92:dirx.lst:in 1
ACCOUNT:Accounting-related files 2
ANIMAT:Animation, FLI, Autocad 3
ANTI_VIR:Antivirus-related files 4
ARCHIVE:Archievers, ARJ, ZIP, etc. 5
BACKUP:File/Disk Backup Utilities 6
-------------------------------------------
The rest of ppcbob.lst is like the last 5 lines above. The really
important line is the first line. In the above (Fig. 1), in the
first line, we see 3 data items:
(1) the name of the CD, (2) the file structure, and (3) where the
file lives (either "in" its own subdirectory with the rest of its
files or "out" in some other subdirectory. So, in creating a *.LST
for your CDrom you must know the name, the file structure of the
files display (DSP), and where the file display structure (DSP)
lives.
On the PowerPak Gold CD, the DSP is a dirx.lst and it lives IN the
subdirectories where its files are.
Graphically: (showing another CD for example)
/--- CD's name
/ /--- DSP file name
/ / /--- DSP residence is IN the subdirec-
/ / / tories it is describing
PowerBox V1.00:files.bbs:in
The next lines after the first line contain 2 data items, (1) the
actual name of the subdirectory on the CD itself, and (2) the
description of the files in that subdirectory.
Graphically:
/--- actual subdirectory name on the CD that the DSP
/ is describing.
/
/ /--- user description for the subdirectory
/ / (What the user will see
ACCOUNT:Accounting-related files as a description)
You may have up to 328 subdirectories per *.LST. If your CD has
more than that just make another *.LST and include the rest in
the second *.LST (the 2nd LST must also have a config line #1 with
a second name, e.g., *.LST #1 may have SUPERSHARE Pt.I, and the
2nd .LST may have SUPERSHARE Pt. II or whatever your please.
For example:
PowerZing Part 1:dirx.lst:in <- first line of *.LST #1
ACCOUNT:Accounting-related files
(etc. up to 238 subdirectories)
PowerZing Part 2:dirx.lst:in <- first line of *.LST #2
MARKET:Farming-related files
(etc. to end of CD's subs)
So, you see, you can accomodate any CD regardless of number of
subdirectories.
Now, what if it is not a dirx.lst for the file display structure?
Here ya go:
-------------------------------------
Fig. 2
---------- pbcbob.lst excerpt ------- Line #
PowerBox V1.00:files.bbs:in 1
001:ASP Software 2
002:BBS Related - CDROM 3
003:BBS Related - General 4
004:BBS Related - PCBoard 5
005:BBS Related - Other 6
---------- end of excerpt -----------
The 2nd through the end line in the excerpt above is just like
the first example (Fig. 1) we saw immediately above. The difference
in this example (Fig. 2) is in the very first line. It is not a
"dirx.lst" but is a "files.bbs." Note that it still lives "IN" the
subdirectory of files which it displays.
So, we now can accomodate either a dirx.lst or files.bbs that
live "in" the subdirectories they report on.
/--- files.bbs and not a dirx.lst
/
PowerBox V1.00:files.bbs:in
This particular CD's "files.bbs" DSP DOES have the size and date
information in it so I can use it just fine and CDMX2dOR will
display it just fine. If it were a normal files.bbs that did not
have the size/date information in it, then I would need to either
find an alternative DSP (e.g., a dirx.lst) on the CD or make
a dirx.lst DSP using utilities included and put the DSP for that
CD on my HD.
What if it is not a dirx.lst OR a files.bbs but it still lives
"in." Easy. Just call it it's name, whatever it may be, e.g.,
if it is a files.lst file IN the subdirectory describing the
files in that subdirectory, then just have the following:
/--- a files.lst and not a files.bbs or
/ a dirx.lst.
/
BizarreGifs:files.lst:in <- first line of the *.lst for this CD.
As long as this "files.lst" DSP has the size/date information and
conforms to normal DSP style then CDMX2DOR will handle it just
fine.
The rest of the structure (lines 2 to X) of the menu command *.LST
would be just like the first one shown above. So, you see, CDMX2DOR
can work with ANY display file structure that has any name (provided
that it approximates the typical files.bbs/dirx.lst structure.
---------------------------------------------------------
Leave no blank lines at the end of your CD menu-control
*.LST files else you will get an "Illegal function" error.
----------------------------------------------------------
================
Making "OUTties"
================
BUT I HAVE A CD WHERE THE DIRX.LST is NOT a live "in." Now what?
Easy <g>. If it's not an "innie" it's an "outtie," e.g.,
--------------------------------------------
Fig. 3
-------- excerpt from NightOwl 8 ----------- Line #
NightOwl 8:dirx.lst:out:text 1
DIR1:001A:Apogee Games 2
DIR2:002A:Software Creations 3
DIR3:003A:Gamer's Edge 4
DIR4:004A:Epic MegaGames 5
--------------------------------------------
Notice that we have now, not three, but 4 (FOUR) pieces of data
on the first line in the menu-command LST file. (1) the CD name,
e.g., NightOwl 8, (2) the display file structure, e.g., dirx.lst,
(3) that it is OUT (meaning that dirx.lst is not living in the
subdirectories that it describes, and (4), the subdirectory where
the all the dirx.lsts live :-).
Graphically:
/--- CDrom's name
/ /--- display file [DSP] format
/ / /--- where the DSP lives (not in the
/ / / subdirectories it describes)
/ / / /--- the subdirectory on the CD where
NightOwl 8:dirx.lst:out:text DSP does live.
Notice that the last 4 lines in the example above have 3 (three)
bits of information rather than just the 2 we've seen so far. The
3 data pieces are (1), the name of the out-living file-display
file, (2) the subdirectory that it is describing, and (3) a
description of the files in that subdirectory.
Graphically:
/--- The name of the DSP for subdirectory 1 on the CD
/ /--- the name of the subdirectory on the CD being described
/ / /--- a description of the subdirectory for users to
/ / / see
DIR1:001A:Apogee Games
----------------------------------------------------------
Leave no blank lines at the end of your CD menu-control
*.LST files else you will get an "Illegal function" error.
----------------------------------------------------------
Note that if your DSP is several subdirectories deep in this
current situation (an outtie) you can have the name of the
DSP prefaced by subdirectories which are under the head
subdirectory "\text". For example, let's assume
that DIR1 (in the above DSP) is in the subdirectory \text\lists
rather than in just \text. We would then have our 2nd through
Nth lines in our menu-command LST specifying this, i.e.,
LINE #
OddOwl 11:dirx.lst:out:text 1
lists\DIR1:001A:Apogee Games 2
twists\DIR2:002A:Mega Games 3
lists\boxes\DIR3:003A:Super Gams 4
etc. N
Note that in this situation, the DSP in line 2 is name DIR1 with
no extension; line 3's is DIR2. Some CD's have DSP's of that
name, e.g., the NightOwl CD's particularly.
Whereever the DSP is under the major subdirectory, you can
specify the path to it under the major subdirectory. So, in
the above case the path to the first DSP (in line 2) is:
\text\lists\DIR1 (note this is not the format to use to state this
in your control menu... this is just an inter-
pretation of what it means. Use the format to
state this as is indicated in line 2 above.)
For the 4th line it is:
\text\lists\boxes\DIR3 (also not the correct format; only an
interpretation of what it means)
------------------------------
Summary: A recap to this point
------------------------------
So, in the NightOwl 8 example (Fig. 3 above), we see for NightOwl 8
that it has:
out-living description files, located in a subdirectory
called "text" on the CDrom and that the display file for
the first subdirectory is living in subdirectory "text"
and is called "DIR1." In it is a description of the files
found in subdirectory "001A" (Apogee Games) on the CD.
The second description file is called "DIR2" and describes
files found in subdirectory "002A" (Software Creations)
on the CD, etc.
As long as you tell it OUT and where the display file structure
lists [the DSP's] live (a subdirectory) and what their names are
then all will be well. You could have:
a files.bbs living in
a files.bbs living out in \whatnot
a dirx.lst living in
a dirx.lst living out in \whatnot
a files.lst living in
a files.lst living out in \whatnot
a *.* living in
a *.* living out in \whatnot
======================
LIVING IN, LIVING OUT?
======================
LIVING IN (see more on innies further down):
If the files-description file lives "IN" then the first line of the
*.LST will have 3 data items:
(1) CD Name, (2) files-description file name, (3) IN
Graphically:
/--- CD's name
/ /--- DSP file name
/ / /--- DSP residence is IN the subdirec-
/ / / tories it is describing
PowerBox V1.00:files.bbs:in
The remaining lines will have two (2) data items:
(1) the subdirectory where it is, and (2) a description
of the subdirectory for the user.
Graphically:
/--- actual subdirectory name on the CD
/
/
/ /--- user description for the subdirectory
/ /
ACCOUNT:Accounting-related files
LIVING OUT (reprise):
If the files-description files live "OUT" then the first line of the
*.LST will have 4 data items:
(1) CD Name, (2) files-description file type, (3), OUT, and
(4) subdirectory where the files-descriptions all live.
Graphically:
/--- CD's name
/ /--- files-description file [the DSP] type
/ / /--- the DSP lives OUTside of the subs they
/ / / describe
/ / / /--- they all live in this subdirectory on
NightOwl 8:dirx.lst:out:text the NightOwl 8 CD.
The remaining lines will have three (3) data items:
(1) the name of the file-description file, (2) what
subdirectory it is describing, and (3) a description of
the subdirectory for the user.
Graphically:
/--- the DSP's name for the first subdirectory
/
/ /--- the subdirectory name on the CD the DSP describes
/ / /--- a description for the user of this subdirectory
/ / /
DIR1:001A:Apogee Games
You get the idea. As long as your first line is set up properly
and your remaining lines are correct then CDMX2DOR will work just
fine. Now as long as your CD's have these simple situations you
can handle building your menu-control *.lst file with the above
information. However, as there is no standardization with how
CD's are constructed (i.e., their subdirectory structure and their
DSP's) you may need additional configuration options. Here they
are:
=====================================================
SPECIAL CASE! CD's with no dirx.lst, files.bbs, etc.
=====================================================
==============================
Not "INnies" and not "OUTties"
==============================
HEY, MY CD doesn't even have a files list display at all... nothing.
No dirx.lst, no files.lst, no files.bbs... nothing. Now what?
Fairly easy. :-)
In this situation, you will have to make a files.bbs- or a
dirx.lst-type display file structure for your CD and put it on
your HD. You can use FLYDIRX.EXE to make your file display
structures [DSP's] that is included in this archieve. This
situation would be known as a "double-outtie" (the files.bbs/
dirx.lst's do not live IN the subdirectories on the CD that they
describe and do not even live on the CD at all (because there were
none and you had to construct them)). Use FLYENGIN.EXE
and FLYDIRX.CFG to make dirx.lsts for entire CD's automatically
(see FLYDIRX.CFG for more explanation). See caveat on FLYDIRX.EXE
later on in these docs.
The control menu *.LST first line in an example menu for this
case would looks as so: (note: this is a "double outtie")
------------------------------------------------------
Fig. 4
------ excerpt of a "no-nothing" CD *.LST setup ------ Line #
IBM Networking:dirx.lst:out:max\file\twerp:C: 1
001N.LST:001N:LANS 2
002N.LST:002N:Networks of fun 3
003N.LST:003N:Networking games 4
004N.LST:004N:Nets & OS/2 5
005N.LST:005N:Net Arcanum 6
------------------------------------------------------
In the above situation, you'll have to use FLYDIRX.EXE to make
your dirx.lsts for yourself. See info on FLYDIRX.EXE
below for contructing skeleton files.bbs/dirx.lsts.
Your CD's menu control *.LST structure now is slightly different
in the first line then previous menu *.LST structures, i.e., there
are not 3, not 4, but now FIVE (5) bits of data:
/--- Name of your CD
/ /--- display file structure (DSP) format
/ / /--- the DSP doesn't live in the
/ / / CD's subs it describes
/ / / /--- it lives in this subdirectory
/ / / / /--- and on C: drive
IBM Networking:dirx.lst:out:max\file\twerp:C:
(1) the CD name, (2) the displayfile structure type, (3) OUT,
(4) the path on your HD where these displayfile structures will
be found, and (5), the DRIVE on your HD where they are. So,
we see in the above example (where there are no files.bbs's or
other display file structures on the IBM Networking CD) that:
there are dirx.lst-type structures, living OUT, on C:
drive, in subdirectory "max\file\twerp" and that
the first dirx.lst-type structure for the first
subdirectory is called "DIR1" and that it is describing
files in subdirectory 001N (actual subdirectory on
the CD). Finally, we see this subdirectory of files
described for users as "LANS."
----------------------------------------------------------
Leave no blank lines at the end of your CD menu-control
*.LST files else you will get an "Illegal function" error.
----------------------------------------------------------
--------------------------------------------------------------
A Caveat on FlyDirx
--------------------------------------------------------------
Use FLYDIRX.EXE to make these dirx.lst-type structures for
yourself. FLYDIRX.EXE will automatically make a display-file
structure for each of your CD's subdirectories that is compatible
to the door's display structure requirement and these dirx.lsts
will have included in them the following:
Filename File Size File Date
You would now then have to edit these subdirectory list structures
to include descriptions if you want them, yech!@, in your
dirx.lst-formatted file display structure that FLYDIRX.EXE makes
for you.
FLYDIRX works on a commandline basis, e.g., to make a skeleton
dirx.lst for a CD that has no files.bbs's or to make dirx.lsts
for any other Drive\Subdirectory you desire. For spot fixes,
just use FLYDIRX.EXE itself. For longer jobs, use FLYENGIN.EXE
to complete a large number of subdirectories with ease. If the
subdirectory you desire to make a dirx.lst for already has a
files.bbs, then FLYDIRX.EXE will import the files' descriptions
from the files.bbs into the newly created dirx.lst. FLYDIRX.EXE
is started thusly (an example):
flydirx d:\001N IN <dlc#>
where d:\001N is the subdirectory for which I mean to make a
skeleton dirx.lst
where IN (or OUT) is the placement of this skeleton dirx.lst
upon its creation. Use OUT when working on CD's
where <dlc#> is the number of spaces to adjust to the right(+#)
or to the left(-#) to accomodate the importing of files
descriptions from previously existing files.bbs in the
d:\001N subdirectory. If FLYDIRX.EXE finds a files.bbs
in the subdirectory for which you are making a dirx.lst,
it will import the files.bbs descriptions automatically.
If no file.bbs is to be found, then you may just enter a
"0" on this parameter.
NOTE: IF your subdirectory DOES have files.bbs files from
which to import descriptions, you will need to adjust the
cut-line for the importing of files.bbs descriptions into
the newly created dirx.lsts depending on the layout of the
files.bbs. Use <dlc#> to adjust the cutline as needed. You
will likely need to play a bit to get it right so experiment
on a single directory before you start a large job employing
FLYENGIN.EXE. IF your files.bbs files are not the normal
structure for files.bbs files, then you will need to employ
KEUFLER.EXE rather than FLYDIRX.EXE.
You could then place all these newly-created dirx.lsts in their
own singular subdirectory on your HD (where you are running
FLYDIRX) in the case of a CD that has no files.bbs/dirx.lsts
(thereby making a "double outtie" out a a CD that couldn't otherwise
be displayed to your users for downloading). You could also place
these newly-created dirx.lsts within the subdirectory they are
describing in the event these subdirectories are on a writeable
drive (thereby making "innies" possible).
You may wish to employ INSTFREQ.EXE/FASTFREQ.BAT in combination with
FLYDIRX.EXE in certain situations (see below).
If FLYDIRX.EXE finds a normal files.bbs in the subdirectory you
are converting to a dirx.lst listing, it will automatically import
those files descriptions into the dirx.lst from the files.bbs it
finds. This is provided that the files.bbs is of this nature:
BUFFALO.GIF (320*200*256) A buffalo on the range
CATFISH.GIF (400*177*256)Your very own catfish!
DEER.JPG A nice deer
DOGNCAT.GIF (320*200*256) Bulldog and kitty
IF your file.bbs is an odd-type structure that looks like this:
MICKEY.ARJ MAC.pic of Mickey Mouse
MINK.GIF (320*200*256) A mink in a tree
RACCOON.GIF (320*200*256) A raccoon
SPUDS.ARJ MAC.pic of the party animal, Spuds.
then you must use Keufler.exe to achieve your goal of making a new
dirx.lst with imported files.bbs descriptions. KEUFLER.EXE is
just like FLYDIRX.EXE with the only difference being its handling
of files.bbs list structure. With KEUFLER.EXE, you will have to
manually do each subdirectory; FLYENGIN.EXE will not work with
KEUFLER.EXE. KEUFLER.EXE command line entry is exactly like
that of FLYDIRX.EXE, so it is possible to drive KEUFLER.EXE using
a bat file (that you would create) to do mass conversions.
=========================================
Special Case: The "Double Outtie"
=========================================
The appropriate format to access this type of "double outtie"
special case (as it would be displayed in your control menu *.LST
file) is as follows:
--------------------------------------------------------
Fig. 5
------ excerpt of a "no-files.bbs" CD *.LST setup ------ LINE #
IBM Networking:dirx.lst:out:max\file\twerp:C: 1
001N.LST:001N:LANS 2
002N.LST:002N:Networks of fun 3
003N.LST:003N:Networking games 4
004N.LST:004N:Nets & OS/2 5
005N.LST:005N:Net Arcanum 6
--------------------------------------------------------
The list files in lines 2-6 above (Fig. 5), e.g., in the 2nd line,
001N.LST, are those list files made by FLYDIRX.EXE for use in
double-outties.
/--- these *.LSTs are made using FLYDIRX.EXE
/ /--- actual subdirectory name on your CD
/ / /--- Description for users of subdirectory
/ / /
002N.LST:002N:Networks of fun
---------------------------------------------------------------
Make sure you leave no blank lines at the end of the control
menu *.LST files else you will get an "illegal function" error.
---------------------------------------------------------------
What is Fig. 5, line 1 telling us? Living OUT in drive C: in
subdirectory max\file\twerp are a collection of DSP's for our
CD that are all dirx.lst-like files.
From lines 2-6 in Fig. 5, we see these dirx.lst-like files are
called 001N.LST, 002N.LST, etc. Though they are all on
c:\max\file\twerp, they are each describing different subdirectories
on the CD. On line 2 of Fig. 5, we see that 001N.LST (though on
c:\max\file\twerp) is describing files on our CD's subdirectory
called \001N. (Note: the drive letter to our CD is set in a file
called CDSONLIN.LST discussed later -- don't worry about that just
yet).
Well, now you can do simple innies, simple outties, make a double-outtie
from a "nottie" CD. We can work with files.bbs's, dirx.lst's, and *.*
display file structures. That ought to handle your basic situations <g>.
There are, however, other "special cases" that we'll discuss here shortly.
As a caveat, however, check this out:
----------------------------------------------------------------
Playing with configs and making your own special cases
----------------------------------------------------------------
Leave no blank lines at the end of any of the configuration
files you create yourself or edit else it is likely that you
will get an "Illegal function" error.
The key to getting any CDrom to work on CDMX2DOR is having things
appropriately configured. If things are not working for you,
then you probably have not configured things rightly. Check to
make sure you have things configured appropriately.
For the expert user: you can play with configs as you please as
regards to where files.bbs-like structures live. For example,
I put CDMX2DOR on a Drive B: subdirectory, copied NightOwl 8's
DIR files to a Drive A: subdirectory, had NightOwl 8 CD in Drive
D:, and had a subdirectory in Drive C: as my scratch directory.
This worked quite nicely as a "Double Outtie" accessing all my
drives. You can do your innies, outties, notties, or whatever
wherever you please as long as you have things configured
appropriately. The advantage of a "double outtie" is just faster
file searches (i.e., the CD's directories are on the HD -- but
they take up about 1 Meg so it is a tradeoff between speed and
HD space). Of course if your CD has no file-display structures
you'll HAVE to use a double outtie configuration.
----------------------------------------
Special case: DRIVE B: use as an "innie"
----------------------------------------
Included in this archieve is a little control-menu for my Drive
B: called "tbcbob.lst" which I have configured as an "innie."
Drive B: was originally a "nottie," i.e., there was no file.bbs
or dirx.lst on B:\tiny nor any in B:\ or anywhere else.
I used FLYDIRX.EXE to set up its skeleton dirx.lst (which
FLYDIRX.EXE named as TINY.LST and put on Drive C:), used
QEdit to finish up the dirx.lst, renamed it "dirx.lst" and
copied to Drive B:\tiny. I then told CDSONLIN.LST that this
was an innie. So, you can squeeze an extra 1.44 bytes out of
your B: drive for users if you so desire. I could just as
easily configured my B: drive as an outtie or a double outtie
if I so chose... it depends on where you place the dirx.lst
and what you call the dirx.lst as to whether it is an innie,
outtie.
Now back to the special cases...
More on innies...
=============================================================
YET ANOTHER SPECIAL CASE: The "buried innie"
=============================================================
------------------
Weird-named Innies
------------------
Let's assume a situation in which your files directory lists
are "in" the subdirectories that they describe but that they
are not all named the same, e.g., for one directory the
files display structure is GAMESA-L.LST and for another
subdirectory the files display structure is GAMESM-Z.LST.
A simple innie using a common name, e.g., dirx.lst, won't
work. You will have a special case here known as a "buried
weird named-innie." Here is an example:
----------------------------------------------------------------------------
Fig. 6
----------------------------------------------------------------------------
/-- CD name
/ /-- display file structure type
/ / /-- location is "in" the subdirectories it
Line# / / / describes
1 SIMTEL 8:dirx.lst:IN
2 filesg\001A\games@DIR1:Games A-P
3 filesg\002A\arcane@DIR2:Games Q-Z<---- description for user of subdir
\ \ \ \ \--------------dirx.lst's real NAME whatever
\ \ \ \-- NOTE: see this "@" sign??? It is critical
\ \ \-- two subs deep in the config!
\ \-- one sub deep
\-- main root subdirectory of all files off of X: drive
----------------------------------------------------------------------------
To do a "buried innie" you must put the root subdirectory off the
X: drive (whatever it is as specified in your CDSONLIN.LST),
followed by the remaining subs, followed by a "@" to denote the
end of the complete path; next you place the name of the files
display structure (whatever it may be, e.g., DIR, GAMESA-P.LST,
whatever it may be. Follow that with a colon (:) and then the
description of the subdirectory that the user will see.
The first line (e.g. starting with SIMTEL, above) is exactly like
any other innie; the difference is in the remaining lines.
What is Fig. 6 telling us about our CD? Living IN buried subs
on our CD are some DSP's. In line 2 (Fig. 6) we see that
our DSP (called DIR1 on the CD) lives in the \filesg\001a\games
subdirectory. Line 3 (Fig. 6) states our DSP (called DIR2 on
the CD) lives in \filesg\002A\arcane subdirectory.
So, with this setup, we can go subdirectories deep into a
CD and find different named DSPs if we need to and still do an
"innie" situation.
-------------------
Normal-named Innies
-------------------
My DSP's are all called the same name (e.g., dirx.lst) but they
are buried subdirectories deep on my CD. Now what?
NOTE: You can have a "not-weird named-buried innie" simply by
having something like the following:
----------------------------------------
Fig. 7
----------------------------------------
Line#
1 The Back Door:dirx.lst:in
2 max\file\amiga:Fun stuff for you
3 max\file\apple:More fun stuff
4 max\file\bbsstuf:BBS stuff
-----------------------------------------
The only difference between this "normal" buried innie and the
weird-named innie is that there is no "@whatver.lst" in the
second thru the 4th lines. This means that, though buried, each
one is called "dirx.lst." The difference between this "not-
weird named-buried innie" and a simple "innie" (discussed way
up at the start of this section) is that this type handles buried
innies; the other's discussion (above) does not really detail this
special case as is detailed here.
=====================================================
SPECIAL CASE! Variable subdirectory-depth Innies
=====================================================
I have a case on my CD where sometimes the DSP's are only 1
subdirectory deep and sometimes 3 subs deep. Now what?
-------------------------------------------
(Variable stacked-deep normal-named Innies)
-------------------------------------------
You can have combinations of stacked-deep buried innies also, e.g.,
---------------------------------------------
Fig. 8
(Variable stacked-deep normal innies)
---------------------------------------------
Line#
1 The Side Door:dirx.lst:in
2 max\:Fun stuff for you
3 max\file\:More fun stuff
4 max\file\bbsstuf:BBS stuff
---------------------------------------------
See how I have different subdirectories-deep locations for my
dirx.lsts? Keep this in mind if you encounter a CD such as this.
Remember, though, they are all named "dirx.lst." What if they
are not??
--------------------------------------------------
Fig. 9
(Variable stacked-deep weird-named innies)
--------------------------------------------------
Line#
1 RAMTEL 10:dirx.lst:IN
2 backup\games@squid.lst:Apogee Games
3 backup\001\arcane@DIR1:Arcanum <---- description for user of subdir
--------------------------------------------------
Note that in line 2 (Fig. 9) I only have 2 subs deep to get to
my squid.lst (DSP) for that files display structure that is living
"in." For the 3rd line, I have 3 subs deep to get to the DIR1
display file list. Therefore, I can go differing subdirectories
deep on a CD to look for "innie" files-display structures (DSPs) and
their associated "in" files and identify the DSP's by name.
========================================
COMBINATIONS
========================================
Combo Innies
You have a CD that has some of the files display structures 2
levels deep, some only one deep, some 3 deep and some have
3 files descriptions (3 DSPs) in some single subdirectories each of
which only describe part of the files that are in the entire
subdirectory... eeeek! Now what? No problem!
-----------------------------------------------------------
Fig. 10
-----------------------------------------------------------
CATBOX CD:dirx.lst:IN
fleas\chiggers\gnats\flies@Stimpy.lst:CATS on the Roof
fleas@rin.LST:Chihuahua Dancing
fleas@hairball.lst:Hairballs for you
fleas@notnow.lst:The Great Escape
fleas\bees\bats\rats\mats\scats\fats@insect.lst:Zowee Bugs!
-----------------------------------------------------------
The above combo will allow us to look IN on different subs-deep
levels for different named DSP's. These above special cases
of subs-deep, normal vs weird named DSP, INnies ought to catch
about 99.5% of your CD cases.
-------------
Combo Outties
-------------
Yeah, but I want to put 'em on my Hard Drive and bury 'em in
subdirectories on my HD. Can you do that? Sure.
--------------------------------------------
Fig. 11
--------------------------------------------
IBM Lantastics:dirx.lst:out:car\file\0023:F:
001N.LST:001N:LANS
NETFUN.LST:002N\077A\BOX2:Networks of fun
003N.LST:003N\088A:Networking games
COWSOUP.LST:004N:Nets & OS/2
005N.LST:005N\099A:Net Arcanum
--------------------------------------------
Translating the above situation, Living OUT on F:\car\file is
a collection of DSP's that are different named, describing
subdirectories on the CD that are several subs deep off the
main drive letter. Some are only 1 sub deep; some are 3 subs
deep on the CD.
You get the picture. Don't you wish that CD makers would figure
a standard way of indexing their products?!? :*)
Let's recap before we move on to step 6 (so you don't get totally mind-
boggled :*). It really is much simpler to DO then to explain making menu
control LST files, so take heart! Most cases these days tend to be CD's
that are already set up for easy BBS display (if they are shareware).
So far you have:
o seen how to configure the *.CNF and *.CFG files
o seen how to get the *.BAT set up (and the *.BBS/*.MEC
if your Maximus)
o seen how to set up CD control menu *.LST files for all
kinds of circumstances, i.e., innies, outties, and notties.
o seen how to work with files.bbs, dirx.lst, or even *.*
display file lists.
o talked about "double outties" and advanced configurations
o talked about a utility (FLYDIRX.EXE) for making skeleton
files-display structures for CDs that have none.
o talked about incorporating your HD (Drive C:) and even your
B:\ drive for files use via CDMX2DOR.
o talked about normal- and weird-named innies.
o discussed variable-depth innies
o discussed combination innies and combination outties
=============================================================================
[6.0] Now you'll have to edit the file called CDSONLIN.LST to include
your *.LST menus of your CD's. This file looks so:
------------------------------------------
Fig. 12
-------- excerpt of CDSONLIN.LST --------- Line #
PowerPak '92,30,ppcbob.lst,OK,D:,* 1
NightOwl 8,50,no8cbob.lst,OK,E:,nite8ok.nam 2
PowerBox v1.00,30,pbcbob.lst,OK,G:,* 3
Pier 1,30,p1cbob.lst,-,F:,pier1ok.nam 4
NightOwl 7,30,no7cbob.lst,-,H:,* 5
NightOwl 6,10,no6cbob.lst,-,I:,* 6
SuperShare v1.00,50,sscbob.lst,-,M:,suprshok.nam 7
-------- end of excerpt ------------------
CDSONLIN.LST structure
NOTE: your CD's name cannot exceed 15 characters maximum else
the door will not work appropriately. Stick with something like
"PowerPak '92" rather than "PowerPak Online '92 SuperDuper CDROM."
Note that each line in Fig. 12 has 6 pieces of data: (1) the CD's
name, (2) the CD's security/privlege level, (3) the CD's *.LST file
(a directory structure - see below), (4), an OK if it is online
and a - if it is not online, (5), the DRIVE: where this CDRom
is located, and (6), the special privileger.
In the above, you can see I have 3 CD's online and 4 offline.
The first 3 are online in drives D:, E:, and G: and the last 4 are
offline. Users may select at will which of the 3 they wish to
work with on their own in either drives D:, E:, or G:. The online
drives (D:, E:, and G:) have a security level of 30, 50, and 30,
respectively. A user with a security level of 30 will only see
2 of the 3 drives as available to them. You can see that NightOwl8,
Pier1, and SuperShare have a ".nam" file in the special privileger
slot and the others just have a "*" in the special privileger slot.
-------------------------------------------
A Caveat on "special privileged CDs
-------------------------------------------
What is the special privileger anyway??
The *.NAM files in the special privileger slot above (data
item 6 on each line) contains a list of users' names that have
access to a disk IF their security level meets the requirement.
Others, who's security level meets the requirement for that CD
but who's names are NOT in this list will be told by the door that
this CD is "offline." They can't get to the CD even if their
security level is sufficient to do so because their name is not
in the *.NAM list for that CD. If you only care to have a CD's
access governed by the security level alone, then just have a
star (*) in the special privilege slot. If you want to keep
users out of a CD, though they are qualified by security level
to see it, then use the .NAM file to control that disk. ONLY
people with adequate security AND their name in the .NAM file
for that CD will be able to get into it. You can call these
*.NAM files whatever you please as long as you put that name in
the CDSONLIN.LST.
---------------------------------------------------------------
Let's look at Line #1 (Fig. 12) graphically:
Graphically:
/--- the CD's name
/ /--- a security level of 30
/ / /--- the CD's *.LST you made in step 5 above.
/ / /
/ / / /--- it is online and ready to be used
PowerPak '92,30,ppcbob.lst,OK,E:,*
+---------------------------/ \
| \
+-the drive where the CD lives \--- special privilege slot
Here's one that is offline:
/--- the CD's name
/ /--- security level 50
/ / /--- the CD's *.LST menu
/ / /
/ / / /--- it is offline
Pier 1,50,p1cbob.lst,-,G:,* <------------- accessible to anyone with
\ a security level of 50
\--- if it were online, it would be in
drive G:
Here's some changes so you can see what happens
/--- the CD's name
/ /--- I reduced the security level to 30
/ / /--- the CD's *.LST menu
/ / /
/ / / /--- it is now online
Pier 1,30,p1cbob.lst,OK,H:,pier1ok.nam <---- accessible ONLY to users
/ with a security level of
| 30 AND their name appears
| in pier1ok.nam.
\
\--- it is online in drive H:
The function of this list is to provide you and your users a
selection of CD's upon which to work. You may display some, all, or
none of your CD's to users based on their privelege level and whether
you put their names in a special privilege list or not. This
privilege/security level is that one which is written in the door.sys
file.
To initiate the special privilege controls, you have to have a file
with names in it; if not special privilege controls, then just have a
"*" in that slot. Note: it MUST be an asterisk/star there if no
special privilege controls are used for a CD.
------------------------------------------------------------
Leave no blank lines at the end of any of the configuration
files you create yourself or edit else it is likely that you
will get an "Illegal function" error.
------------------------------------------------------------
Maximus BBS-only sysop information:
If you are a Maximus BBS sysop, this privelege level is set in the
cdmx2dor.mec/.bbs files included herein. If you are not a Maximus
BBS software sysop then your door.sys will write a privelege level
for you based on your own particular software.
CDMX2DOR.MEC/BBS defaults for Maximus users
Maximus setup on privilege levels/security levels
Privilege Level Security Value
Sysop 100
AsstSysop 80
Clerk 70
Extra 60
Favored 50
Privileged 40
Worthy 35
Normal 30
Limited 25
Disgrace 20
Twit 5
You can change these security values if you wish, but, if so, then
you will need to change your CDMX2DOR.MEC and re-MECCA.
All BBS Systems sysop information:
You may have up to 34 CD's online with this door from which your users
may select. The following lines have a particular structure that you
must follow to make the door work appropriately. An explanation of
the structure follows by example:
/---- CD's name. Keep it at 12 or less characters, please.
/ /--- User's privelege level
/ / /---CD's control menu
/ / / /--- online status "OK" for online, "-"
/ / / / for not online.
PowerPak '92,40,ppcbob.lst,-,D:* <--- no special privilege controls
\
\--- CD's actual drive location
(put the : at the end, e.g.,
C:, X:, Q: or whatever)
Explanation: The CD is PowerPak '92 and users with a security level
of 40 or greater have access to it. The CD's control menu is
ppcbob.lst (see this one and others in this archieve), it is currently
offline, but would, if online, be in Drive D: There is no special
access required via a *.NAM file to get at this CD, you only need to
have the right security level.
Changing your door' actions on this list is as easy as using a text
editor to change this list. I can increase/decrease security for
a particular CD by just changing the security/privilege level value
that a user must have as a minimum to access it via using Qedit or
whatever text editor, OR, by initiating special privilege controls
an putting their name in a *.NAM list for that particular CD.
I can change the online/offline status by changing the "-" above to
an "OK" and, voila, it is now online. I can change the actual drive
that the CD lives in in similar fashion. In less than a minute I can
bring an offline, high-security-level CD on drive G: to online, low-
security-level CD on drive D: by just using a text editor and changing
a very few things.
Note that if you just have one (1) CD drive, you can only have one
CD list available online for users <g>. This door will unfortunately
not physically remove and replace your CD's in your drive :*) If you
have 34 CD Drives, then you can have 34 CD's online... one per drive.
You can also put your HD files on CDMX2DOR if you like so a user
would have full access to ALL your files everywhere via CDMX2DOR.
======================
Support up to 34 CD's
======================
You may have up to 34 CD's online if you want to <g>. Each CD
needs a line in the CDSONLIN.LST. Edit your CDSONLIN.LST
as necessary. Each CD requires a *.LST menu as described in
step 5 above (innies, outties, notties, etc.). You can call your
*.LSTs whatever you please but you must tell CDMX2DOR what they
are via CDSONLIN.LST. Just for novices: You have to have a
different drive for each list for each drive you have online.
You can't have 4 drives online with only one CD driver :*)
unless you're REAL QUICK in changing CD's (joke).
=============================================================================
[7.0] Well, now, after we've gotten this far, the rest is pretty
simple. CDMX2DOR needs to have access to the following
files to have it work rightly:
(a) PKZIP.EXE
(b) PKUNZIP.EXE
(c) DSZ.COM
Put these on your PATH for best results. You can get these
files off of almost any BBS if you don't already have them.
(I know for sure you've got pkunzip.exe :-)) Be sure to
use DSZ.COM and not DSZ.EXE. These files are for online
unzipping and viewing files, for putting your BBS Add in out-
going files, and for download, of course. BE SURE TO PUT
YOUR BBS ADVERTISEMENT IN YOUR SCRATCH/TEMPORARY SUBDIRECTORY
(you will specify this subdirectory in CDMX2DOR.CFG). I've
included NCB.ADV as an example BBS advertisement.
You will want to adjust your autoexec.bat with DSZ statements
so as to get it to write a DSZ.log for you. In my autoexec.bat
I have the following for DSZ:
set dszlog=c:\max\log\dsz.log
You will want to adjust this above line to suit your system.
Now copy your BBS advertisement file, e.g., NCB.ADV into your
scratch directory (as configured in CDMX2DOR.CFG) so this can
be appended to outgoing zips.
=============================================================================
[8.0] Well.... if you've done everything above appropriately then
it is now time to let the users have a go at it. You can try
it out on your own offline if you have the first line in your
DOOR.SYS set to COM0: , making sure your ANSI driver is loaded,
and then, at the prompt, type:
cdmx2dor cdmx2dor.cnf
When you are on locally, the door will not do the DSZ downloading
nor will it add BBS Advertisements to files. This only happens
when a user is on. However, you will see locally what the user
will see remotely when they are on it. When users are running
it, the display will appear to mess up when pkzip and dsz are
doing their thing but this is only on the local screen so don't
get worried - users don't see this stuff. Running it locally
will let you see what the users will see (i.e., no distortions
by pkzip and dsz).
You will note that if you are unregistered, there is a message
to that effect on starting the door and there will be a brief
delay for users on the main menu along with a message that
the door is not registered. You can fix that <g> if you register
the door and get your KEY which will turn off the delays and
the unregistered messages. See below for registration information.
=============================================================================
[9.0] OK, I got it setup and I saw it locally and it looks good. What's
all the files and stuff?
It is likely that you'll find a few extra *.lst, *.nam, or *.bats
in this archieve that are not listed above. They are just various
sample files that will help you in configuring/controlling CDMX2DOR.
If it is not listed above, take a peek at the file and see what it
is and how it might help you in setting things up.
(a) CDMX2DOR will write a NGDL.LOG recording user's downloading
activity. All files successfully transferred will have
a record of same made here. You'll know who downloaded
what, when, and with what protocol.
(b) BADSEND.LST is a record of all unsuccessful transfers.
You can find out who is screwing up.
(c) USERS.DAT is a record of who has been on the door lately
and keeps track of how many Kbytes a body downloaded
today. It will prevent a user from downloading more than
the daily Kbyte allotment in a given day. This record
also gives you info on who was in the door and when
they were last on the door.
(d) LOCK.LST is a file where you put the names of the
files you'd like to control users' access to particular
files. The format of lock.lst entries is as follows:
filename.ext, key$
/- file to lock
/
/ /-key for this file
example: cindy.gif, foxxy
If you choose to prevent users from ever downloading
a particular file, then just put the filename.ext and
leave out the "," and have no key for it. For example
a totally forebidden file entry in lock.lst would appear
as follows:
filename.exe
/- file forbidden to all users and
/ there is no key.
/
example: cindy.gif
Some good CD's have GIFS on them that are near-to-porn
and prevent family-oriented boards from using them. Any
file name you put in here without a key will be forbidden
and users won't be able to download it. If you don't want
to forbid anything, then don't enter any filenames or just
have an empty file. Note that any filename placed in
this list WITHOUT A KEY is inaccessible to all your users.
If you'd like some of your users to get access to a file
but prevent others from downloading that file, then put
the filename.ext in the list and have a key to it. You
would then share or not share this key with whomever you
choose. Those that have the key can process the file for
viewing/downloading -- those that don't can't. You can
change this key with a standard text-editor at will, so
you can re-lock to formerly un-locked users by simply
changing the key.
(e) CDTEMP.LST is a file that the user will employ to
access your CD's. Up to 34 CD's are supported via
CDMX2DOR. The file is volatile and changes based
on users activity.
(f) FIXMAX.EXE is a utility for MAXIMUS (TM) BBS sysops
that will automatically adjust Max's users.bbs files
for you. If you're not using Maximus then this file
does nothing. This file must be in CDMX2DOR's
subdirectory.
(g) FLYDIRX.EXE is a utility for making dirx.lst/files.bbs
type structures for your CD's that have no dirx.lst/
files.bbs's on them or for making dirx.lsts for your
writeable drives. With this utility you can take
virtually any CD and run it on CDMX2DOR after you've
got the display-file structures (dirx.lst/files.bbs)
made. FLYDIRX.EXE will make these structures for you
and name them by the name of the subdirectory they
came from, e.g., 001A.LST, or BOOKS.LST or whatever.
You can then use these *.LST file structures on your
HD so that a user can download anything from your
CDs. If you have a situation like this, just run
FLYDIRX.EXE and follow instructions. Use a text editor
to edit the resulting products of FLYDIRX.EXE to your
liking (e.g., adding file descriptions and cleaning
up the structure to suit your needs).
In this case, where your CD's have no files-display
structures, you would have a "Special Case" so see
that information above for assistance.
See FASTFREQ.BAT as an associate of flydirx.exe.
KEUFLER.EXE is a type of FLYDIRX.EXE that is for the
purpose of dealing with odd-structured files.bbs files'
description importation into newly created dirx.lsts.
(h) DIRXMAKE.EXE is a utility that will make dirx.lst structures
from your files.bbs files. You need to place the name of
the subdirectories where your files.bbs's live on your
c: drive in DIRXMAKE.CFG as well as the full path to the
subdirectory where all the subdirectories where the
files.bbs's live. See DIRXMAKE.CFG for more information
on running this utility. Please refer to the control-
menu *.LST file called SSCBOB.LST as an example of how
to set up your HD (C:\bbs\files drive) to run through
CDMX2DOR.
DIRXMAKE will make and place dirx.lsts in each of your
files.bbs's subdirectories on your HD, so your HD is
configured as an "dirx.lst innie." The reason for DIRXMAKE
exists in that oft times files.bbs files have no file
size/date stamp in them (e.g., Maximus is like this)
and therefore makes these type of files.bbs files
unusable to CDMX2DOR. DIRXMAKE, however, translates
these type of files.bbs's into dirx.lsts that can be
used by CDMX2DOR. DIRXMAKE will incorporate your
already-existing files descriptions (as found in
files.bbs files) into the new dirx.lst files.
(i) INSTFREQ.EXE and FASTFREQ.BAT
Instfreq.exe will quickly copy any files meeting a wild-
card parameter from any drive to any drive. FastFreq.BAT
is an example of employing INSTFREQ and FLYDIRX together
to quickly copy a set of files meeting a definition to
a particular drive/subdirectory and then quickly making
a dirx.lst of those files copied. This utility comes
in handy if a user requests certain files and you want
them to get at them immediately. For example, a user
requests QModem files... you just edit your FASTFREQ.BAT
appropriately and then run it and the user now has these
files in a preconfigured download area called "Requests."
They now have immediate access to those files via
CDMX2DOR. The "Request" area might have a special
privilege control file on it where ONLY this particular
user's name is. Only HIM and no one else can then get
these requested files.
(j) A Special Note on security:
CDMX2DOR could give you these levels of security on
your CDs/files:
Example of super-strict security
o a user has to have a security level of, say 40, to
even know that a particular CD exists on the system.
Assume he does have a security level of 40 and sees
that a particular CD exists. You set this one up
with a special privilege file. He must have his name
in the special privilege *.NAM list for that CD else it
will appear to him that it is offline. Assume he
has his name in the list and the CD is online for him.
He must now know the keyword for each different file
that he finally gets to see
In this above example, a user would need to pass 3
levels of security to access a given file.
Example of lowest-level security
o a CD has a security level of 5, no special privilege
file, and no keys. Virtually anyone gets access to
every file on that CD. Everyone knows it is there.
=============================================================================
[10.0] Still Problems???
If you've still not gotten it going correctly after double
checking, then drop me some e-mail at 1:232/31 or call my
board at (309) 797-6027. Here's a few tips just in case:
It shows garbage and no colors. Why?
Do you have ANSI running? Did you do a DVANSI if
you are running DV/QEMM?
It barfs and says "illegal function call." Why?
You have not got it configured correctly. Please
recheck your configs. The problem most likely
rests in your CD *.LST files not being set up
correctly. Check to be sure your configuration
files, cd-menu-control files, and other configuration
files do NOT have any blank lines at the end of
them. If they do, then the program will die
and say "Illegal function call." Remember, NO
empty lines at the end of any configuration file
(or for that matter, at the end of any file that
CDMX2DOR allows you to setup or edit).
I can't figure out how to configure my CD! What now?
Send me a copy of:
(a) your CD's directories
(b) your CDSONLIN.LST
(c) your menu-control *.LST file
I'll have a go at it and put the results in a
file that I will put on HOLD for you to pick up
via a F'Req. I HAVE to have a COMPLETE listing
of your CD's directories, you COMPLETE CDSONLIN.LST,
and your COMPLETE menu-control *.LST file to be
able to figure out what you are trying to do. ALSO
tell me if you are wanting it to be an "innie" or
and "outtie." After a few days, call my system
and pick up your configs; they will be in a file
named thusly:
Yourlastname.INF
so F'Req that particular file on your return call to
get your info.
I get a QEMM exception 13... what gives?
You probably don't have it configured correctly.
Again, the problem is likely in your CD Menu
control *.LST files. Maybe you don't have
enough memory in this DV window??
The door runs for a while and then gives me some really
weird looking hi-ansi/IBM characters and then seems to
die. What gives?
You have likely either (1) gotten your CD's name
in your CDSONLIN.LST too long (keep it around
15 characters maximum), or (2) gotten your
menu-control lists inappropriately configured.
I can't get it to run locally. How come?
Do you have a door.sys in CDMX2DOR's directory?
Is the first line set to COM0: ?? Gotta have
both to run locally. Got your ANSI driver
running?
User's see garbage when they get on and loose control of
the program. How come?
If you are using Maximus it is likely due to
the fact that you've not set the "-s" parameter
(lockedbaud rate) in your spawnbbs.bat file, e.g.,
Max Max -b%2 -p%3 -t%4 -s38400
If you are not using Maximus it is due to not
telling the door.sys that the port is locked.
Adjust as necessary.
Do you have your port locked at a fast baud
(if you are using a high speed modem)? If not,
then lock it.
Gotta have CDMX2DOR start up with COM2 if users
are using COM2. Don't expect a COM1 startup of
CDMX2DOR to handle callers on COM2. Check your
CDMX2DOR.CNF against your DOOR.SYS. Door.sys
first line should read COM2: for com2 and the
CDMX2DOR.CNF should have 02F8 in the Hexport
line. Adjust as necessary depending on your
port/IRQs. Got your IRQs set up correctly?
Gotta have that else it won't send out the
right comport (if you are using any port higher
than COM2).
It doesn't lock out users from downloading a file I had set it
up to have a key. How come?
Did you have the filename and key in your lock file?
A user is online and, bam!, the are sudden back in the BBS with
no apparent warning. What happened?
CDMX2DOR encountered some type of error that would
have crashed the program but rather than to do that,
it made note of the error in CDMX2DOR.ERR and then
kicked the user back to the BBS. It is likely that
you have misconfigured something. Check your CDSONLIN.LST
and your menu-control structures to be certain they are
correct. Look at CDMX2DOR.ERR: if it says something
about "write protection" it is likely that you told it
to find something that is not there, e.g., are your
CDSONLIN.LST entries REALLY there... you aren't sending
CDMX2DOR out to look at a wrong CD by accident are you?
It won't forbid my file I told it to. Why not?
Did you enter the filename.ext in lock.lst? Make
sure!
It won't download files to users. Why?
Is DSZ.COM on your PATH? IF not you need to
get it there. Is your port locked correctly? Does
the remote user have his act together? Is your
BBS Advertisement in your scratch subdirectory?
Is PKUNZIP on your PATH? Are you using a recent
version of DSZ.COM? Should have a DSZ.COM that
is at least a 1991 edition.
It quits and says there is a "Path not found" error. What's
up?
You have either not configured your CDSONLIN.LST correctly
or have not configured your control-menu *.LST files
correctly. Double check these to be sure you've specified
the right drives and paths. If the problem persists,
drop me some Email with the address location of the error
in module CDROMBOB (or perhaps in module CDBOMB).
It won't allow users to view zips online. Why?
PKZIP.EXE and PKUNZIP.EXE are likely
not on your PATH. Put them there. If you don't
have these on your PATH then don't expect things
to work appropriately. Do you have at least 750 Kbytes
available diskspace on your HD for unzipping files?
Users might want to view a big file and if there's no
room for unpacking it, there may be problems.
It won't add my BBS comments to outgoing BBS files. Why?
Gotta put your BBS.ADV file in your scratch/temporary
subdirectory. Gotta have PKZIP.EXE on your path.
It won't work right on multinode. Why?
Have you adjusted your HEX port address (line 5)
in your *.CNF files? Are you starting CDMX2DOR.EXE
with the right command line *.CNF in your *.BAT file?
Have you adjusted your IRQ # (line 4 and 6) in your *.CNF
files, e.g., in CDMX2DOR.CNF? You HAVE to make sure
your HEX port addresses and your IRQs are rightly
configured for proper operation in a multinode
environment.
I'm a MAXIMUS BBS sysop and it won't work. Why?
Did you SILT Maximus after making the changes in your
FILE section of your MENUS.CTL file? Did you edit
CDMX2DOR.MEC to have the door.sys written in CDMX2DOR's
subdirectory? Did you MECCA your CDMX2DOR.MEC after
making the changes? Did you leave the "@" character
after the [xtern_dos] in your CDMX2DOR.MEC file? Gotta
have it.
It won't update Maximus's USERS.BBS. Why?
Did you tell it where to find your LASTUSER.BBS correctly?
Gotta do it. Do ya have the "@" in your CDMX2DOR.MEC
file right after the [xtern_dos] to start the door?
It won't lock out certain files from user download. Why?
Do you have a LOCK.LST in CDMX2DOR's home directory? If
you want a lockout, you have to have LOCK.LST. If you
want some users to get access to this file, then you
HAVE to have a comma and a key$ after the filename.exe.
If you don't have a key, DON'T have a comma!
A last word on installation:
You have to fix cdmx2dor.cnf, cdmx2dor.cfg, cdsonlin.lst,
cdmx2dgo.bat, and make your cd menu-control *.lst files to get
the door working appropriately. Make sure you've done all these
changes.
Flow of files in running the door:
Your users activate a command off of your BBS to start
the door (a bat file if not Maximus or a BBS file if Maximus),
this procedure writes a door.sys file that must end up in the
subdirectory where CDMX2DOR exists and also starts the door.
CDMX2DOR reads its *.cnf file and starts up based on the parameters
contained in its *.cnf and *.cfg files. If it is not going out
the port as it should, check your HEXport addressing and IRQ's
as well as your lockport baud settings.
If you send your questions to me via netmail, I'll help ya! :-)
IF you have found a bug in the program, I will fix it for you
and send you a fixed copy on my dime. Just let me know via
NetMail @ 1:232/31 or call my BBS at (309)797-6027 (USA).
=============================================================================
[11.0] What about Multinode operation? Easy....
To run the door multinode, you will need to have a different
CDMX2DOR.CNF for each node and make these changes:
------------------------------------------
Fig. 13
-------------- *.CNF excerpt ------------- LINE #
c:\cdbob 1
New Century BBS 2
0 3
3 <--- this line (see below) 4
02F8 <--- this line (see below) 5
3 <--- this line (see below) 6
cdmx2dor.cfg <--- this line (see below) 7
--------------- end of file --------------
The "02F8" line (line 5) is the Hex address for COM2. The "3" line
(line 4 and 6) is the IRQ number for COM2. Here is a list of other
settings for other ports and IRQ's:
Here's a chart with the STANDARD IRQs
and addresses for the PS/2s and IBM PCs:
Non PS/2
Com port IRQ Address CDMX2DOR address
1 4 &H3F8 03F8
2 3 &H2F8 02F8
3 4 &H3E8 03E8
4 3 &H2E8 02E8
5-8 4 &H3F8 03F8
PS/2
Com port IRQ Address
1 4 &H3F8 03F8
2 3 &H2F8 02F8
3 3 &H3220 3220
4 3 &H3228 3228
5 3 &H4220 4220
6 3 &H4228 4228
7 3 &H5220 5220
8 3 &H5228 5228
Set your HEX address's and IRQ's for each different node
appropriately based on this information.
Line 4 of the configuration file is the IRQ for the port.
Line 5 of the configuration file is the Base Address for the port.
If the user is using COM 1 or COM 2, then you may enter
a zero (0) on both of these lines, as the default port
assignments are always used for COM 1 and COM 2.
The IRQ (line 4) must be in the range of 1 - 7.
The Base Address (line 5) must be a Hexadecimal number in the
format of:
02E8
03E8
etc.
Clear enough? :-)
Note that DSZ may use some odd HEXPort addresses and IRQ's
for Comports 5 and above... check the DSZ docs and adjust
your Hexport address and IRQ's as is appropriate in these
cases (COM 5-8 usually).
You can rename CDMX2DOR.CNF to whatever you please so you can
have multiple *.CNF files to start the door based on ports/
com settings/IRQs. For example, if you want to run CDMX2DOR
in shared mode (all nodes accessing one program), your
*.CNF's would be as follows:
CDMX2D1.CNF is for node 1
CDMX2D2.CNF is for node 2
CDMX2D3.CNF is for node 3, etc.
These files might look something like this:
CDMX2D1.CNF: (For Node 1 on Com2)
------------ sample *.cnf on multinode ---------------------
c:\cdbob
New Century BBS
0
3 <---------------- IRQ 3
02F8 <---------------- HEXport address 02F8
3 <---------------- IRQ 3 (again)
cdmx2do1.cfg <---------------- config data for this node
------------------------------------------------------------
CDMX2D2.CNF: (For Node 2 on Com4)
------------ sample *.cnf on multinode ---------------------
c:\cdbob
New Century BBS
0
3 <---------------- IRQ 3
02E8 <---------------- HEXport address 02E8
3 <---------------- IRQ 3 (again)
cdmx2do2.cfg <---------------- config data for this node
------------------------------------------------------------
CDMX2D3.CNF: (For Node 3 on Com3)
------------ sample *.cnf on multinode ---------------------
c:\cdbob
New Century BBS
0
4 <---------------- IRQ 4
03E8 <---------------- HEXport address 03E8
4 <---------------- IRQ 4 (again)
cdmx2do3.cfg <---------------- config data for this node
------------------------------------------------------------
Make sure to adjust your *.BAT files for each node so that
you've incorporated the command-line calling of the differing
.CNF files for each node.
You get the idea....
If your data is NOT different in your *.CFG files across nodes
then you may just continue to specify the same filename. If there
is a difference, particular for multinodal MAXIMUS users, then
you must make the changes required and have differently named
*.CFG files.
CDMX2DOR.EXE must be started with a command line which includes
the *.CNF filename so you will have to make adjustments as
necessary to your *.BAT files that start the door up to incorporate
these different *.CNF filenames. Be sure that SHARE is installed
to run all nodes off of one copy of CDMX2DOR.EXE.
CDMX2DOR is written such that all files are "shared" files, i.e.,
any node can access any file without problem. To set up CDMX2DOR
on multinode, however, I would do the following (just to be safe
and sure and, particularly, if I have HD space to spare):
(1) have a different subdirectory on my HD for
each node used
(2) have complete copies of CDMX2DOR files in
these different node-specific subdirectories
(3) edit the *.CNF file for each node to have the
correct Hex port address (see above) for that
node.
(4) have the *.bat run the right *.CNF for the
specific node.
(5) have the *.CNF for each node specifying the
correct *.CFG (if different info) for that node.
This takes a little more space on your HD, but will absolutely
prevent any file-sharing conflicts. If you're short on HD
space then you probably should do it all in one directory in
shared mode. This is entirely up to you, of course.
If you're a risk-taker, you might want to try running CDMX2DOR
in shared mode... all on one directory with different *.CNF's
starting it based on node... you're on your own here <g>. If
your short on HD space, you might want to do it this way. No
promises <g>. Do it my way (different copies for each node) and
all should be well. As CDMX2DOR only reads a "door.sys" drop
file, you'll likely have to have different copies of CDMX2dOR
in diffrent directories. Future versions will be able to
read node-aware dropfiles.
=============================================================================
[12.0] OTHER THINGS you can do with CDMX2DOR... possibilities plus!
o Meeting users' special file requests in an instant.
A user requests certain files and wants them online
right away. The files are offline. How to get them
online FAST? Check out INSTFREQ.EXE, FASTFREQ.BAT, and
FLYDIRX.EXE working in combination...
I edit FASTFREQ.BAT and then run it. FASTFREQ.BAT
tell INSTFREQ.EXE to:
copy these requested files to a subdirectory on
your harddrive. FASTFREQ.BAT then runs FLYDIRX.EXE
for that subdirectory that you have previously
configured as an "innie." You previously made
a control menu for that subdirectory and edited
CDSONLIN.LST with Qedit. (See the reqbob.lst and
its associated entry in CDSONLIN.LST for an example
of this preconfiguration)
Time required to put the user's file request
online using FASTFREQ.BAT is less than 1 minute.
For example. A user requests these files:
MAPBBS.CNF 1870 01-18-89
MAPDOS.DAT 127 01-18-89
MAPLBDR.BI 18288 10-12-92
MAPLBDR.LIB 69471 10-03-92
MAPLBDR.QLB 43513 10-03-92
MAPLBDR.TXT 122613 10-03-92
(1) I have a preconfigured FILES REquest control
menu set up (e.g., see reqbob.lst this
archieve). This file is in my CDMX2DOR
subdirectory. The file looks like this:
Requested Files:dirx.lst:in
backup:"Files" You Requested
(2) I have preconfigured my CDSONLIN.LST to
add this line:
Requested Files,30,reqbob.lst,OK,C:,reqst.lck
(3) I use FASTFREQ.BAT to copy the MAPL*.* files
from a given subdirectory to my "c:\backup"
drive. FASTFREQ.BAT calls FLYDIRX.EXE and
ultimately makes a dirx.lst for the MAPL*.*
files and puts it in c:\backup. Make sure
you edit FASTFREQ.BAT appropriately before
running it.
(4) I let the user know his files are ready.
Time required: Less than 1 minute. User
can now download his request.
(5) If the user left a message and isn't online
when he made the request, I fill his request
as above and put his name in reqst.lck (a
special privilege NAM file.lst) as
follows:
Matt Timion
and it is available ONLY to him. If I have
several requests, I add the files to my
c:\backup drive using FASTFREQ.BAT, add the
additional user's names to the reqst.lck file
so they can get into the drive, and also put a
special keyword (see LOCK.LST) on the files for
each particular user. I leave email for them
all telling them their files are ready and their
special access key for their files is XXXXX.
(If you do this procedure, make sure to edit
FASTFREQ.BAT so it does not delete the files
it finds in C:\backup from previous user's
requests).
o Having all my 1.44meg B: floppies formatted for instant
use on the BBS.
(1) copy my BBS's new upload directory's files.bbs
to my B:\subdirectory drive
(2) copy the selected files of my choice to my
B:\subdirectory drive from off the BBS's new
uploads directory
(3) run flydirx.exe as an innie, e.g.,
flydirx.exe b:\subdirectory IN <dlc#>
(4) delete the files.bbs off of B:\subdirectory
(5) make a control-display menu for a B:\subdirectory
innie and include it CDMX2DOR's directory, e.g.,
TINY B Drive:dirx.lst:in
TINY:Miscellaneous Stuff
(6) adjust CDMX2DOR's CDSONLIN.LST to include the
b:\tiny subdirectory, e.g.,
Tiny B,30,tbcbob.lst,OK,B:
(7) From now on, every B: drive that I copy files
to from off of the BBS will have a subdirectory
called the same, e.g., B:\TINY, and I repeat
steps 1-4 with that B: drive. Steps 5-6 only
need to be done once.
(8) To change the files available to users on the
tiny B: drive, I just change the disk. That's
it!
I can do all of the above or, alternately, run FASTFREQ.BAT
to do the copying/dirx.lsts for me. Try out FASTFREQ.BAT
and see what it does.
o Putting EVERY drive online for downloading. I can use
all my drives for files for user-downloads with CDMX2DOR
e.g., A:, B:, C:, D:...Z: everything! (and, of course,
all my CDRoms). Hard-drives, floppies, CD's... future
versions of CDMX2DOR will have Colorado tape supports.
=============================================================================
[13.0] Well... I think you've got enough info to get your door running.
You can run it right away locally for testing if you've got
the CD's I have. Explore!
If you like it and need further help or questions before
registration, drop me some netmail. We've been online since 1991
and will be here for the duration :-). I think you'll be very
happy with this door. Multinodal 34-CD's per node plus your
HD files... not bad, eh?
Be sure to have things configured rightly. There's a bit of
busy work with configuration, but it is pretty simple to do and
it's all done on a text editor like QEdit. If you've got the CD's
I've got then you'll be up and going in a very short time and
there won't be much configuration to do.
Make sure when you start the door up in local mode that you add
the commandline$, i.e., the *.cnf file name, e.g.,
C:\BBS\DR>cdmxdor2 cdmx2dor.cnf
else your door will not work.
If you've got any suggestions, pass'em along...
=============================================================================
[14.0] Legal stuff
The program is guaranteed to do nothing at all except to take up
space on your HD. Your first run of the program is your implied
consent to hold no torts, suits, or other legal action against
the author for any problems to your hardware or software. If you
do not agree with these terms then don't run the software.
=============================================================================
[15.0] Registration
CDMX2DOR has taken a lot of time and money to develop. Please
support the shareware concept and you will see this door continually
improved.
Thank you for your support!
Until you receive your registration "key," CDMX2DOR will show
"Please register" messages periodically and will pause occassionally
as a reminder to register. Upon receipt of a key, registered
user's versions will no longer have these reminder messages and
program pauses. Additionally, registered users will receive a
selection of a number of other doors I have written and will
have access to any updated versions of CDMX2DOR via New Century
BBS (309)797-6027. If you find CDMX2DOR useful, please consider
registration so as to support further enhancements. I will need
your first and last name and your BBS's name to send you a working
key.
Your registration now will entitle you to future updates as they
are made without cost. You registration fee is for all future
versions of CDMX2DOR which will be made available for download
or FReq at New Century BBS 1:232/31 (309)797-6027.
The registration fee is $20.00 [cheap!!! :-)] and is payable by
cash, check, or money order to:
New Century BBS
c/o Robert Lee
1812 36th Street
Moline, Illinois 61265
USA
Please include the below information in your registration
request:
Name: (First/Last)____________________________________________
Name you are using on your system as the Sysop:
Firstname:_____________________ Lastname:_____________________
Your key will be based on this firstname/lastname information
as it appears on your BBS so please check to be sure your names
here match your board names.
Street Address: ______________________________________________
______________________________________________
City: ________________________________________________________
State: ______________
Country: ___________________
Zip: ________________ (if applicable)
BBS Name: ____________________________________________________
Your key will be based on your board's name as it appears on
your BBS so please check to be sure your board name you specify
here matches your board's name.
BBS phone # where you can be reached: ________________________
FIDONET Address (Z:N/#) if appropriate: ______________________
Where did you get CDMX2DOR? __________________________________
Comments/Suggestions: ________________________________________
______________________________________________________________
______________________________________________________________
===========================================================================
[16.0] Revisions History
- V.099 First BETA Release; several minor revisions along the
way to fix buglets. Finally resulting in a version
worth putting out for inspection. Seems to be capable
of looking at all drives.
- V.100 Fixed bug in display of CD subdirectories, added several
suggestions from Chris Keufler (1:3402/22) for CD security
- V.101 Fixed bug when a HD was full and CDMX2DOR tried to copy
a file from a CD to a fullup HD. Now reports HD full
and instructs user to alert sysop. Fixed buglet in
finding location of an ansi file.
- V.102 Changed coding for CDMX2DOR's *.CFG file so as to allow
multiple *.CFG's to accomodate multinodal Maximus
situations. Maximus multinodes must still put separate
copies of CDMX2DOR files into separate directories pending
code changes associated with door.sys naming.
-V.103 CDMX2DOR would not handle deep-buried odd-named innies.
This is fixed in version 1.03. Tweaked the subdirectories
display to allow back/forward intelligence with just an
"ENTER" from the user. Version also fixed to handle
variable subdirectory-depth finding of "innie" files
display structures. Added error trapping so that in
the event a problem occurs, program will report error
in file called CDMX2DOR.ERR and then exit normally so
that it does not hang anymore awaiting a sysop "Press
any key." Updated doc file.
- V.104 Fixed the zipviewer to better format the fileschoice
list; cosmetic. Changed the "please register" display
to only occur at first logon and not after every command.
Will now pause 20 secs. for unregistered users and that's
all. Added a help section for the "Download files"
section to explain to users what a "protocol" is.
- V.105 Fixed the zipviewer to better format the fileschoice
list (again; v1.04 change disturbed numbering; v1.05
fixed this). Fixed a bug in the zipviewer when unzipping
multiple subdirectories-deep zips to only allow viewing
of first level deep subdirectory textfiles; preventing
viewing of zip -rp packed zips past the first subdirectory.
Serves as a security protect to prevent viewing nested
subdirectory zips. (Thanks, Samson Luk 6:700/8)
- V.106 Fixed a bug in searches and displaying file DSP when
configured on a double outtie with many subdirectories
deep on the HD and on the CD. (Thanks, again, Samson
Luk 6:700/8). Also fixed zipviewer so that in a zip
archieve that has been archieved via a zip -rp command
the subdirectories within the zip are not showed to
users at all. Only the first level files in the zip
are showed to users for possible extraction and viewing.
- V.107 Added KEUFLER.EXE utility to archieve. KEUFLER.EXE will
import the files' descriptions from odd-structured and
non-capitalized files.bbs files into newly made dirx.lsts.
(Thanks to: Chris Keufler 1:3402/22)
-V.108 Fixed code in the routines to display subdirectories
available on a particular CD. Did only display up to 99
subdirectories per control-menu. V1.08 displays up to
238 subdirectories per control-menu. Also fixed a bug
that prevented "intelligent" fowarding in the subdirectories-
available routines. Now will auto-advance through all
available directories with only an "ENTER" and when it
reaches end of list, will automatically go back to start
of list - supporting up to 238 subdirectories. (Thanks
to: Samson Luk, 6:700/8).
-V.109 "Previous page" was broken in the subdirectories selection
menu. Fixed via deletion of previous/next functions in
lieu of an ENTER looping routine. (Thanks, Samson Luk,
6:700/8).
-V1.10 Improved the Search performance by a speed factor of about
3 using an entirely different algorithm. (Thanks, Chris
Keufler, 1:3402/22).
Samson Luk (6:700/8) reported that when using Maximus and
a user logs on CDMX2DOR more than once in one session that
the user's time-spent-on-board variable is distorted in
Maximus BBS time accounting. CDMX2DOR does not change nor
even write to this variable during its operation. There
may be a bug in Maximus in interpretting re-read lastuser.
bbs files in multiple uses in a single session. I am at
a loss as to how to fix this as it is not CDMX2DOR's
changing that is distorting Maximus's time-spent-on-board
variable. All other Maximus variables work as they should.
Changed the naming of the 3 log files that CDMX2DOR keeps so
that their names can be configured by the user via
CDMX2DOR.CFG file. These files can each be named
differently or all named with the same name for logfile
simplicity. (Thanks Dave DeGear, 1:351/300)
===========================================================================
"For God so loved the world that He gave His Only Begotten Son that
whosoever believeth in Him shall not perish but shall have
everlasting life." John 3:16
===========================================================================