Dec 222017
X.COM allows you to archive seldom-used .COM and .EXE files into a COMLIB (command library) file, and then quickly execute them with the X program.
File X30.ZIP from The Programmer’s Corner in
Category Utilities for DOS and Windows Machines
X.COM allows you to archive seldom-used .COM and .EXE files into a COMLIB (command library) file, and then quickly execute them with the X program.
File Name File Size Zip Size Zip Type
X.COM 11040 10630 deflated
X.DOC 15240 5264 deflated

Download File X30.ZIP Here

Contents of the X.DOC file

X: the COMLIB Executioner

Copyright (c) 1988 - 1991 by Keith Ledbetter
and Orion Micro Systems

[>> Version 3.0 enhancements are at the end of this document <<]

Welcome to X.COM. When I did a catalog of my \DOS\ directory the other
day and saw 194 files, which were mostly little-used but hard-to-delete
.COM and .EXE files, I figured it was time to do something (yes, I'm a
pack rat).

X.COM was the solution. X.COM allows you to ARC those seldom-used .COM
and .EXE files into a COMLIB (command library) file, and then quickly
execute them with the X.COM program. There are many advantages to this;
mainly you free up all of the file slots occupied by those programs, which
makes directory searches much faster.

I started out writing my own "library" (or archiver) program, but then I
came to my senses and realized that ARC (not PKARC) already supports the
ability to "store" files into an ARC file without compressing them. So, to
use X.COM you *must* have ARC.EXE in one of your PATH subdirectories.
X.COM and ARC.EXE work hand-in-hand EXCEPT for the "extract and run"
function; X does the extraction itself and then spawns the process (at a
very high rate of speed, by the way).

At the heart of X is the environment variable named COMLIB. On my system,
the main PATH for my commands is \DOS\. So, in my AUTOEXEC.BAT file I have
the following entry:


Change your entry depending on where you want your COMLIB.ARC file to be.

There are two ways to invoke X.COM (which you should place in one of your
PATH directories). The two invocations are as follows:

X filename [arguments....]

X -switch [filemask]

If you invoke X with a '-switch' in the FIRST argument, then X will pass
that switch directly to ARC.EXE to process, supplying the name of your COMLIB
file. X will also add a "s" to the -switch, so that ARC will work with files
in "stored" mode instead of compressed mode.

If you invoke X without a '-switch' specified, then X will

(a) extract the .COM or .EXE file to a temporary file in the
root directory of drive C:

(b) execute the command passing any command line arguments
that you specified

(c) delete the temporary file when the command terminates.

Setting up your COMLIB file

OK, enough of that boring stuff! Let's set up your command library and
see X.COM in action. I will assume in the following examples that

(a) you want your command library to be in C:\DOS\
(b) C:\DOS\ is specified in your PATH environment variable

First, you need to set up your COMLIB variable with the following command:


Next, we need to add some files to your command library. Since everyone has
the CHKDSK.COM command, we'll add that file. At the DOS prompt, key in:

X -a \your_path\

When X.COM sees the '-a' switch, it will spawn ARC.EXE to ADD the member to
your COMLIB file. After ARC finishes execution, you can verify that it was
indeed added with the following command:

X -v

X.COM will again spawn ARC.EXE to do a "verbose listing" of the files in your
COMLIB file.

The final step is to execute CHKDSK.COM from your COMLIB arc file. Simply
key in:

X chkdsk

X will extract the file and then run it. That's all there is to it!

Don't forget; ANY switch that you can normally give to ARC.EXE you can also
give to X.COM. You can, for example, "freshen" all files in your COMLIB file
with the command: X -f. Also, invoking X.COM with no command line
arguments will give you a short "help screen".

On my system (which is an AT), my COMLIB file currently has 75 entries in
it, yet X.COM can still extract the LAST member in the file and have it
executing in about 3 seconds. So, you're not going to suffer waiting for
COMLIB'ed files to execute. I hope you enjoy it. If you have any questions
or suggestions for improvements, you can reach me at:


Keith Ledbetter


Version 1.2 Enhancements and Changes

The changes to version 1.2 of X.COM are relatively minor. The biggest
change is that you can now store and execute BATCH files from your COMLIB

This should come in very handy, since batch files are notorious for being
small files that eat up incredible amounts of hard disk space because of the
cluster size overhead.

You add batch files to your COMLIB file just like any other file. For
example, if you have a batch file named PROCOMM.BAT, just do:

X -a procomm.bat

(or, "-m" if you want to put it into your COMLIB file and then delete it).
Now, to execute PROCOMM.BAT, you'd just do the following at the DOS prompt:

X procomm

Can't be much simpler than that! When you execute a batch file, X.COM does
the following steps:

(a) it extracts the file to the root directory of drive C: under
a temporary .BAT name.

(b) it spawns another copy of COMMAND.COM, passing it the name
of the temporary batch file for execution. X.COM honors
(in fact, requires) the COMSPEC environment setting for

(c) after control returns from COMMAND.COM, it deletes the
temporary file from drive C:.

Other minor enhancements in this version:

o Unused free memory is released before running the extracted
command. Only around 30K of your memory will be eaten up
by using X.COM to execute another program. It is very easy
for me to bring this memory overhead down to around 18K or
so, but doing so would drastically slow down the time
required to extract the file out of the COMLIB file. If you
have a requirement for a special version like this, just let
me know.

o Extraction of members should now be a little bit faster than
earlier versions.


Version 2.0 Enhancements and Changes

The changes to version 2.0 of X.COM fall into the "major" category. The
most important change is that X.COM now uses the new PKZIP by Phil Katz, so
that the COMLIB members are actually shrunk down as opposed to just being
"stored as is" like they were with ARC.EXE.

The main reason that I went with PKZIP is that the program can extract
compressed members just about as fast as I could extract the older "stored
only" modules. There will be a slight speed loss (for example, 3 seconds to
get a program extracted and running instead of 2 seconds), but you will gain
a lot of disk space in return. PKZIP v1.02 routinely crunches down .EXE
files to around 30% to 50% of their original size. I think waiting an extra
second or so is worth that much disk savings.

There are two pathways to converting to version 2.0 of X.COM:

1. IF YOU CURRENTLY USE v1.2 (or less) OF X.COM ...

a. First, you must convert your COMLIB.ARC file manually
to a COMLIB.ZIP file. Simply create a temp directory,
extract all members from the ARC file, and then ZIP them
into your new COMLIB.ZIP file.

b. Change your AUTOEXEC.BAT file to reflect that your COMLIB
file is now a ZIP file (ie: SET COMLIB=D:\UTILS\COMLIB.ZIP).
Actually, SET COMLIB=D:\UTILS\COMLIB will work, too.

or 2. IF YOU DO NOT CURRENTLY USE v1.2 (or less) OF X.COM ...

a. Simply set things up as described in the above older
documentation, except for:

- PKZIP/PKUNZIP.EXE must be in your PATH instead
- name your COMLIB file to xxxx.ZIP instead of .ARC.

Operational changes

To the user, v2.0 of X.COM seems as though it processes things exactly
like v1.x did. In the overall scheme of things, it does; but, in reality,
there had to be a few differences since PKUNZIP is now doing the extracting.
Here is what happens now when you execute a COMLIB member:

for example: X WHEREIS *.bat

1. A temp directory is created in the root directory of C:\
2. X spawns off PKUNZIP.EXE to extract WHEREIS.*
3. If more than one WHEREIS.* file exists, give the user an
error message telling them that the names must be unique.
4. If the extracted file is a BATCH file
spawn a second copy of COMMAND.COM and execute it
spawn the program that was extracted.
5. Delete all files in the temporary directory.
6. Delete the temporary directory.

Passing switches

The switch to PKZIP/PKUNZIP is also complicated by the fact that there are
TWO programs instead of the singular ARC.EXE which did all ARC processing. So,
when you pass a "-switch" through X.COM, it treats things like this:

If the switch is -X (extract), -V (verbose list), -T (test),
or -C (print to screen) then
spawn off PKUNZIP.EXE
spawn off PKZIP.EXE

So, if you need to execute PKUNZIP with a switch other than -x, -v, -t,
or -c, you'll have to do it manually.


Version 2.1 Enhancements and Changes

Version 2.1 fixes a bug (well, actually an oversite) where X would not
pass all of the parameters that you specified to PKZIP/PKUNZIP. X.COM would
only pass the first filename that you specified. For example, if you did the
following command:

X -x edit.bat abc.bat test.bat e:\outdir\

which says "extract the files EDIT.BAT, ABC.BAT, and TEST.BAT from my system
COMLIB file, and place them into the directory named E:\OUTDIR\", X.COM would
only pass the following to PKUNZIP:

PKUNZIP -x \path\ edit.bat

which, of course, didn't quite end up with the expected results. X.COM will
now correctly pass all of the arguments you specify; using the above example,
X.COM would now correctly spawn PKUNZIP as follows:

PKUNZIP -x \path\ edit.bat abc.bat test.bat e:\outdir\

Thanks to Bruce Bordonaro of Ramsey, NJ for documenting this oversite and
contacting me about it (I can't get anything past you guys!).


Version 2.2 Enhancements and Changes

The only change made in version 2.2 is the ability for you to specify the
drive where you want X.COM to place the temporary extracted file. Earlier
versions of X.COM would always put this temporary file on drive C:.

Of course, this caused problems for those people who run "disk manager"
programs that only put a very small boot partition on drive C:, and then
allocate the entire rest of the hard drive as drive D:. What would happen
is that PKUNZIP would run out of disk space when trying to extract the file
to drive C:, which would in turn make X.COM respond with "That file doesn't
exist in your COMLIB file!".

By default, X.COM still uses drive C as the temporary drive. But, you
can over-ride this by simply defining an environment variable named X_DRIVE.
For example, if you'd like for X.COM to use drive D: as the holding area for
the temporary file, just put the following command in your AUTOEXEC.BAT file:

Set X_Drive=D

Version 3.0 Enhancements and Changes

The only change made in version 3.0 is that I went back to an earlier way
of creating temporary directories that now lets you "nest" execution of X'ed

For example, you could have a batch file in your COMLIB that calls another
program that's in your COMLIB; eg: consider the command "C:> testit":

(in COMLIB) echo Now loading MYPROG.EXE
x Myprog.exe

V2.3 of X.COM would not allow this to happen because I went to a "set in
stone" convention of naming the temporary subdirectory. v3.0 now generates
a unique temporary directory name on each new invocation, so this "nesting" is
now allowed.

In conclusion

If you use PKZIP/PKUNZIP regularly, please register your copy! We need
quality shareware, and the market will dwindle if there is no monetary support
for the authors. Remember, you vote with your wallet!

Last, but not least, concerning contributions on this and any other of my
"freeware" programs: My stand is simple - contributions are not required, but
they are HEARTILY accepted (note the accent on HEARTILY...grin). If you feel
that you'd like to make a contribution for X.COM, or if you'd like to drop me
a line with any suggestions, you can reach me at any of the following:

Keith Ledbetter
4240 Ketcham Drive
Chesterfield, VA 23832

CompuServe: 72240,1221

If you are not a member of GEnie or CompuServe, you can contact me on the
Blue Ridge Express BBS at (804) 790-1675, user name "Keith Ledbetter". This
board runs 24 hours a day at 300/1200/2400 baud (with 24 phone lines), and is
well worth the call.


Keith Ledbetter

 December 22, 2017  Add comments

Leave a Reply