ftp.wwiv.com/ftp.wwiv.com.zip/ftp.wwiv.com/pub/HATCH/WWIVNEWS.ZIP/9407_4.NWS

Text File | 1994-07-24 | 21KB | 501 lines

     WARNINGS:

     This option should not be used if:

        - the disk was partitioned using Storage Dimensions'
          SpeedStor utility with its /Bootall option
        - more than 4 partitions exist
        - certain dual-boot programs are in use

Storage Dimensions' SpeedStor utility using the /Bootall option redefines the
drive's physical parameters (cylinder, head, sector). /BOOTALL stores
information on how the drive has been changed in an area of the master boot
record that MS-DOS does not use. FDISK /MBR will erase that information,
making the disk unusable.

Some older OEM versions of MS-DOS and some third-party partitioning utilities
can create more than 4 partitions. Additional partition information is
commonly stored information on partitions in an area that FDISK /MBR will
overwrite.

Some dual-boot programs have a special MBR that asks the user which operating
system they want on bootup. FDISK /MBR erases this program. Dual-boot
systems that boot whichever partition is marked Active are not affected by
FDISK /MBR.

If you have a Boot Sector Virus, just boot from a known "clean" floppy disk
that's write protected and which has FDISK on it, and run FDISK /MBR.

─────────────────────────────────────────────────────────────────────────────

FOR %%V IN (/SOMETHING)
───────────────────────

How can a batch file (without 4DOS) determine from which drive it has been
started?

      Example:  C:\>A:TEST.BAT

Now my batch should be able to find out that it is located on drive A: (not
the path, only the drive!).

In a batch file, the variable %0 contains the name of the batch file as it was
typed at the command line. If you run the batch file as A:TEST.BAT, %0 will
be "A:TEST.BAT". If you have the directory on your path, and simply type
TEST, then %0 will be "TEST". The drive, path, and extension will only appear
in %0 if you enter them in the command used to call the batch file (either
typed at the command line, or called from another batch file). So, you must
specify the drive as part of the batch filename for this to work.

To extract the drive only from %0, use the undocumented FOR %%V in /SOMETHING
command:

     set drive=
     for %%v in (/%0) do call test2 %%v
     echo Calling drive is %drive%

...where TEST2.BAT is:

     if not '%drive%'=='' set drive=%1:

FOR %%V IN (/SOMETHING) DO WHATEVER will do WHATEVER twice -- the first time
with %%V set to the first character in SOMETHING ("S"), the second time with
all the remaining characters in SOMETHING ("OMETHING"). If SOMETHING is only
a single character, WHATEVER will only be called once, with that character in
%%V. If the single character is a wildcard (? or *) that wild card will not
be expanded to a set of filenames. (The main purpose of this feature is
apparently to allow inclusion of the literal characters "?" and "*" without
them being expanded.)

This works in DOS 3.30 and later.

─────────────────────────────────────────────────────────────────────────────

FORMAT /AUTOTEST
────────────────

The autotest parameter will allow FORMAT to proceed, checking the existing
format of the disk (unless the /U parameter with DOS 5 or 6 is also present),
and proceeding with the format.

All this will take place with no delay and no waiting for user input. It will
also end without pausing. It will not ask for a volume label or whether to
format another diskette.

WARNING!  This procedure will also work on hard drives!  Be very cautious if
you plan to use this feature!


FORMAT /BACKUP
──────────────

This works exactly like /AUTOTEST, but it does ask for a volume label.


FORMAT /SELECT
──────────────

This is like the DOS MIRROR command... For safety-fanatics only.


FORMAT /SELECT /U
─────────────────

Just makes a disk unreadable. Guess it could be handy?


FORMAT /H
─────────

In DOS 3.30 (not tested with other versions), FORMAT /H will cause the format
to begin immediately after pressing Y in response to "Format another", rather
than displaying "Place disk to be formatted in drive x: and press Enter" on a
second and subsequent disks.

In DOS 5.0, FORMAT reports "invalid switch".

─────────────────────────────────────────────────────────────────────────────

IF EXIST <dirname>\NUL <command> and IF EXIST EMMXXXX0 <command>
────────────────────────────────────────────────────────────────
This is a handy quirk of DOS. Installable drivers are seen as files in all
directories. You can use the if exist test to either test for the existence
of a directory, with "if exist <dirname>\nul", which fails if the directory
does not exist because the nul device is not found; or to test whether any
driver is loaded, such as the DOS 5 or 6 EMM386 memory manager.

Caveats:  For testing NUL, you need to know the name of the directory or the
driver whose existence you are testing, and this is MS-DOS specific -- it
doesn't work on network drives, and may not work under DR-DOS.

Where did you learn the "EMMXXXX0" name from?  Instead of typing MEM /C, type
MEM /D for the "debug" listing.

The only trouble is EXISTS returns true for COM3/4 and LPT2/3 even if the
hardware does not exist.

─────────────────────────────────────────────────────────────────────────────

INSTALLHIGH
───────────

In DOS 6.0, there is an undocumented CONFIG.SYS command called INSTALLHIGH=
which works just like INSTALL= but loads the TSR high (into upper memory).

The only drawback to this is that MemMaker will not touch INSTALLHIGH lines
during the optimizing process. It just takes it as it is currently. But then
again, INSTALL= is ignored too. All in all, INSTALL and INSTALLHIGH really
are commands to set up manually by the user, and are not really recommended
for normal use. Load TSRs at the beginning of AUTOEXEC.BAT (and using
LOADHIGH if desired).

       Example:

       DOS=HIGH,UMB
       DEVICE=C:\DOS\HIMEM.SYS
       DEVICE=C:\DOS\EMM386.EXE NOEMS
       INSTALLHIGH=C:\DOS\SHARE.EXE

─────────────────────────────────────────────────────────────────────────────

SWITCHES=/W
───────────

Enables you to have the Windows 3.0 WINA20.386 file anywhere on your boot
drive. Without this you have to have it in the root directory.

This should not be used with Windows 3.1, since it appears to waste around
120 to 130K of UMBs, depending on your system configuration.

─────────────────────────────────────────────────────────────────────────────

TRUENAME
────────

Internal DOS 5.0 command. Canonicalize a filename or path (using DOS
interrupt 21h, function 60) prints the actual directory.

     Syntax:

     TRUENAME filename   - Prints the complete path to file.
     TRUENAME directory  - Prints the complete path to directory.

Note:  If the path is in a network, it starts with a \\machine-name.

TRUENAME is analogous to the UNIX "whence" command. It returns the real
fully-qualified path name for a command.

TRUENAME is useful in networks, where a physical drive may be mapped to a
logical volume, and the user needs to know the physical location of the file.
It ignores the DOS SUBST and JOIN commands, or network MAPped drives.

TRUENAME is an undocumented MS-DOS feature, but it is documented in JP
Software's 4DOS software (COMMAND.COM replacement) as follows:
     Syntax:

     TRUENAME [d:][path]filename

     Purpose:

     Returns a fully qualified filename.

     Comments:

     TRUENAME will see "through" JOIN and SUBST commands, and
     requires MS-DOS 3.0 or above.

     Example:

     The following command uses TRUENAME to get the true pathname
     for a file:

     c:\>subst d: c:\util\test
     c:\>truename d:\test.exe

     c:\util\test\test.exe

TRUENAME : will reveal the full name drive and path of the filename. If you
specify a wildcard (*) in the filename, it will expand the filename to use
question marks instead. If the path includes the ..\ sequence, TRUENAME will
examine the directory structure and calculate the path.

Stranger still, the line:

     TRUENAME \CRONK\FLIBBET\..\ART

produces the response:

     C:\CRONK\ART
even if the directories \CRONK\FLIBBET and the file ART don't exist! Don't
expect this command to work well across networks. After all, this is still
undocumented in MS-DOS for a reason!

─────────────────────────────────────────────────────────────────────────────

VER /R
──────

Yields extended information about the DOS version:

     MS-DOS Version 5.00
     Revision A
     DOS is in HMA

Doesn't work with DOS 3.30. VER /R is a documented feature of JP Software's
4DOS.

─────────────────────────────────────────────────────────────────────────────

Using : for batch file comments
───────────────────────────────

DOS uses a leading : to indicate a label in a batch file. If the next
character following the : is a space or other non-alphanumeric character, then
DOS will decide it's an invalid label and skip to the next line, performing no
further action. Faster batch file processing is achieved using this method
for comments instead of REM commands.

─────────────────────────────────────────────────────────────────────────────

REM in lines with pipes or redirection
──────────────────────────────────────

For example:  REM echo y | del *.*

Problems are encountered when trying to REM out an "echo y | del *.*" line in
a batch file. The problem appears to only occur if there is a pipe or
redirection in the REMed out line, which shows that DOS first reads the entire
line and processes pipes and redirections first, and then goes back to find
out what to do with them in the line. It's actually doing what it thinks
you've told it:  Piping the output of REM to DEL. Since REM has no output,
DEL hangs, waiting for the answer to its question.

─────────────────────────────────────────────────────────────────────────────

Delimiter character
───────────────────

Prior to DOS 5.0, there was an undocumented DOS function that would allow you
to set the DOS option delimiter character to something else, like a dash (-).
Once you did this, you could use either \ or / in PATH specifications.

DOS 5.0 removed the function to set the option delimiter, but retained the
function to query what it currently is.

(Unfortunately, no further details were provided in this file, so not sure if
the delimiter character can still be changed somehow.)

─────────────────────────────────────────────────────────────────────────────

Once again, there's probably a few commands I've missed. If you've got any
to add, please pass them on to me, and I'll reprint the additions in an
future issue of WWIVNews!

───────────────┬─────────────────────────────────────────────┬───────────────
               │    Tips For Running WWIV Under OS/2 2.1     │
               │             By Martin (1@6251)              │
               │                     And                     │
               │            Lord Sigma2 (1@5498)             │
               └─────────────────────────────────────────────┘

[Editor's note: In response to repeated requests by sysops in configuring
OS/2 2.1 to properly run WWIV, both Martin and Lord Sigma2 contributed to
several discussions regarding this topic. The end result is this article,
which is a compilation of the tips revealed in those discussions, and also
includes the contents of an article on the topic that appeared in _IceNEWS_,
our sister publication on IceNET.]

─────────────────────────────────────────────────────────────────────────────

MARTIN: FIRST THINGS FIRST
──────────────────────────

Getting WWIV 4.23 was something that I, like everyone else it seems, had been
looking forward to for a long time. I was lucky enough to have been able to
get it from Amber the night it was released so I was able to take a look at it
right away. I had planned to wait to install 4.23 on my BBS for at least a
week so I'd have time to really look it over but when I saw what it had to
offer I decided not to wait.

I had been running OS/2 on my second computer for almost 4 months. When I
first installed it I realized that I was faced with almost the same magnitude
of confusion as I had worked through each time I had bought a new, unfamiliar,
computer system. I say this only to say that when I set up WWIV 4.23 under
OS/2 I was far from being an expert (and still am not) on the operating system.
I was a beginner as far as the use and understanding of OS/2 was concerned, and
I was also using a new version of the BBS software. I had a lot of confusion
to overcome!

Regardless, to the best of my memory, and for whatever help this is worth,
here is the breath-taking saga of Amiga Blues' encounter with running multi-
instance under OS/2.


HPFS or FAT?
────────────

I had set up OS/2 on my "personal" (as opposed to the BBS) computer with the
HPFS and dual boot. I didn't realize at that time that a person could switch
back and forth booting either OS/2 or DOS without installing the dual boot
feature under the HPFS. It is possible, though, to install OS/2 on an existing
partition by installing it in a subdirectory using the FAT system. You can
still reboot into DOS by using the "boot /dos" command, and back to OS/2 by
typing "c:\os2\boot /os2" (assuming you have used the default directories).
When it came time to install OS/2 on my BBS computer I decided to use the FAT
system and give it a try. I didn't want to have to repartition my hard drive
to use HPFS. You will have to weigh the advantages and disadvantages of the
FAT vs the HPFS and decide which way seems best for you.

Once I had installed the operating system, I booted it up, made an icon (see
below) for instance number one and ran it. It worked!

Well, it worked to the extent that the board came up and ran. There was still
a lot of work to do before I was ready to actually open the board back up to
callers while running under OS/2.


ICONS AND .BAT FILES
────────────────────

In order to get icons for my "instances" of WWIV, I had to go into the System
Setup folder and select "Migrate Applications". Your OS/2 manual will explain
the process involved with doing this. After running Migrate Applications, you
will need to select the "Add Programs" option and "Add" your BBS.COM to the
Selected Programs list. You will do this so that you'll have an icon, but you
will only do this as a first step; you won't actually run the board off it.
You should make a copy of this icon for each instance you will want to run so
that you have one icon for each instance.


ICON SETTINGS
─────────────

Once you have created your icons, go into the Settings for each one and under
"Path and file name:" have them call a .BAT file for each instance rather than
calling BBS.COM. Under "Path and file name:" you will want C:\WWIV\WWIV1.BAT,
C:\WWIV\WWIV2.BAT, and so on rather than C:\WWIV\BBS.COM. This will allow you
to set the instance correctly. See my example .BAT files (following) if you
don't know what I mean by this.

One of the other very important things to do is replace the standard COM
drivers that come with OS/2 with Ray Gwinn's SIO drivers. I won't go into the
way to do this; it's well covered in the documentation files that come with the
drivers. But one thing that's not immediately clear is that you should go into
the BBS's icons and make some changes under the new options the SIO drivers
give you. For one thing, you'll need to disable access to every COM port but
the one used by that instance. For example, let's assume you're running your
setup as follows:

2 remote and one local instance (3 icons total).
Instance 1 (WWIV1.BAT) uses COM2
Instance 2 (WWIV2.BAT) uses COM3
Instance 3 (WWIV3.BAT) is local.

You would want to go into your BBS icons and change your DOS settings so that
the icon for instance 1 (WWIV1.BAT) has access to COM2 only, the icon for
instance 2 (WWIV2.BAT) has access to COM3 only, and the icon for instance 3
(WWIV3.BAT) does not access any of the COM ports. Once you've installed the
SIO drivers, you'll see that the icons will allow for the new options the SIO
drivers provide. Restricting each instance's access to only the COM port it
needs will prevent problems such as online programs causing a System Error
message telling you that your application tried to access a communications port
which is in use by another application.

I don't have any experience with running WWIV under OS/2's drivers and I would
highly recommend getting Mr. Gwinn's drivers. I ran the OS/2 drivers for a
while under Procomm Plus, and the difference between the SIO drivers and the
standard OS/2 drivers was amazing. I went from approximately 600 CPS and many
crashes during transfers to 1600-1700 CPS and no more crashes.

Anyway, back to the issue of setting up your icons... You will also want to
set the IDLE_SECONDS and IDLE_SENSITIVITY to provide the best performance on
your particular system. As I've said, I'm no OS/2 expert, but I do believe
that these settings will work differently from one system to another. Your
settings will probably be different from mine. What I did to get them tweaked
the best I could was to set the IDLE_SECONDS just high enough so I didn't get
the famous "pause after message header" problem, and set the IDLE_SENSITIVITY
so that the processing time would be divided up between instances as evenly as
possible.

What I believe causes the problem with messages pausing right after the header
is displayed is OS/2 mistakenly thinking that the session is inactive and
pausing it until it thinks it's active again. Apparently this is a problem
with OS/2 and communication software. The software (in this case your BBS) is
processing data but there is no mouse movement or keyboard action while you are
reading the message. OS/2 doesn't think anything is happening and idles the
session until you do something. On my system I experienced the problem with
the session pausing after the message header until I set the IDLE_SECONDS up to
4. Setting the IDLE_SECONDS to 4 took care of the problem.

In order to get IDLE_SENSITIVITY set so that it seems to work the best, I tried
setting it as low as possible, and then ran the session. I checked the setting
by doing a new message scan and watching to see if the text was "jerky". If it
was jerky at the IDLE_SENSITIVITY I had, I exited the BBS, quit the session,
opened the icon's DOS settings and bumped the setting up by 10 at a time until
the text displayed smoothly. I then adjusted it by an increment of 5. What I
mean is this:

With IDLE_SENSITIVITY set at 30 if the text scrolled jerkily, I went out and
set the sensitivity to 40. If it was still jerky I set it to 50. If it was
then okay, I set it to 45. If it was okay, I left it alone, and if it was
jerky again I set it back to 50.

I have left INT_DURING_IO off. I have heard that having it on can mess up
network packet handling, and I don't want to risk that.
Another thing I did was to aim the DOS_DEVICE to C:\OS2\MDOS\ANSI.SYS so that
my system would be able to handle ANSI displays.

One last thing that I have just tried is setting the HW_TIMER to on. This is
due to a recommendation in "Your OS/2 Consultant" written by Herb Tyson and
published by Sams Publishing. Having the HW_TIMER on allows WWIV to have
direct access to the timer ports and stops OS/2 from emulating a timer.
Apparently, it's been documented that some fax programs and high speed data
transfer utilities don't run well unless HW_TIMER is set to on.


.BAT FILES
──────────

The .BAT files are fairly simple. Here are mine:

(WWIV1.BAT)

set WWIV_INSTANCE=1
c:
cd \wwiv
bbs.com /i1

(WWIV2.BAT)

set WWIV_INSTANCE=2
c:
cd \wwiv
bbs.com /i2

(WWIV3.BAT)

set WWIV_INSTANCE=3
c:
cd \wwiv
bbs.com /m /i3

You can see that I've got instance 3 set up for local only use and have used
the /m parameter to disable the BBS from trying to find a modem.


CD-ROM DRIVES
─────────────

I had a little difficulty setting up my CD-ROM drives to work under OS/2 in the
same way they had been working under DOS. The problem was not the fault of
OS/2; it runs CD-ROM drives just as well as it runs anything else. It was just
a matter of finding drivers that worked with my drives (I have Mitsumis). If
you have a Mitsumi CD-ROM drive and haven't been able to find a driver for it,
you can call the OS/2 BBS at 919-517-0001 and get the driver there. The file
name is MITFIX.ZIP and the driver name is MITFIX001.ADD. This driver supports
the new FX series of Mitsumi drives as well as the CRMC-FX001, the CRMC-FX001D
and the older CRMC-LU005 drives. Once I found and installed the drivers (see
your OS/2 manual for more information on this; it's covered very well), I set
up a small RAM drive so that the CD-ROM drive letters would be the same as they
had been under DOS. I did this because I had used a RAM drive under DOS. This