Batty is our logo/icon. She is supposed to represent the Hawaiian Hoary Bat and is dressed in a grass-skirted Hula dancer's outfit. The orange backdrop is intended to represent the oh so incredible colors of Hawaii's sunsets, and, also, Halloween, which is our favourite time of year to be out snorkeling on the Big Island. So, with Batty in the spotlight, let the show begin ...
Recognized expert, Ben Okimoto, DVM, Zoo Veterinarian at the Honolulu Zoo in Oahu, has been quoted as saying, "Historically, the Hoary bat was the only land mammal here when the Hawaiians came". Here is a pix we found at "http://www.smithfarms.com/Family%20Page.htm" (also, the source of the above quote) of a real Hoary bat ...
HulaBats is a collection of UNIX®/Linux®-like tools
that we have hacked together over the past twenty or so years,
some from our early UNIX®/MS-DOS days, and others, more recently,
were created while porting Solaris® based software over to
Microsoft® Windows® 2000/XP platforms during the last six years.
Most recently, we have been working with
Windows® Vista and 2003 Server R2, as well.
Our goal has been to pull together all our utils into a package/book
and, ultimately, we settled on the name HulaBats, since that
describes what most of the commands are - .bat, .cmd batch files -
also, known as "dot bats". The .bat extension was solely in use back
in the legacy MS-DOS days, the .cmd extension came about with the
introduction of the CMD shell under Windows® NT®, either one works.
These days we almost exclusively use the .cmd extension, and reserve
use of the .bat extension for "build.bat" wrappers around "build.xml"
Ant scripts that are doing wildcard installs of *.cmd scripts where you
do not want the build.bat itself included during the copying to the
target location.
HulaBats could be installed in: C:\progra~1\HulaBats
(or C:\Program Files\HulaBats). Maybe with an override option
to go into places like: C:\HulaBats (or C:\batch)
We could include instructions on how to use the 'ln.cmd' to make
a link (JUNCTION) to the default location. But, we will probably
just release it in two .zip file(s) (HulaCore.zip, HulaSupp.zip)
with relative pathnames like .\HulaBats so you can extract it
wherever you so desire to put it, and then you can add
the absolute path to it on your search PATH as you see fit.
Java's jar.exe can be used to extract the .zip files easily, too,
or, the wzunzip.exe tool from WinZip, or Info-Zip's unzip.exe, or
PK's pkzip25.exe.
The core base utils will be standalone .bat/.cmd scripts that do not need
anything other than the basic Windows® 2k/XP/Vista system to work ok.
We will lean towards Windows XP and 2k3srv but we have started to port
to Vista, too. Maybe a later edition can provide enhancements to the
Windows PowerShell (aka msh, Monad), someday.
Additional utils will either have dependencies on other's .exe's
or our own, or will just be our own or freely distributable (e.g.,
under the BSD UN*X license or something like it) .exe's. See copyright.rem
used for .cmd files, and copyright.cpp used for C/C++/Java files. Perl
is very useful and the user may be pointed to ActiveState or Cygwin®
for it, or we may be able to provide our own build that includes LibWin32
as a backup along with the source for our Perl version and 'dmake' on request.
-----------------------------------------------------
A contest for the best package title?
-----------------------------------------------------
HulaBats is a continuation of our original ideas for a developer book:
"Windows Shell Script Programming (for UN*X Geeks and Wannabees)". We had
a lot of various titles for the book though along the way. Such as:
"Windows Shell Script Programming (for the UN*X Literati)". Or, maybe
one of these:
"HulaCmds: UN*X/Linux Tools for Cmd Shell Users"
"HulaCmds: UN*X/Linux Toolkit for the Cmd Shell"
"HulaCmds: A Toolkit for Cmd Shell Users (like UN*X/Linux Geeks and Wannabees)"
"HulaCmds: Yet Another Toolkit of UN*X/Linux Commands for Cmd Shell Users"
"HulaCmds: A Toolkit for Cmd Shell Users"
"HulaCmds: A Toolkit for Command Shell Users"
"HulaCmds: A Toolkit for Command-Line Shell Users"
"HulaCmds: A Toolkit for Command-Line Users"
"HulaCmds: A Toolkit for Cmd-Line Users"
"HulaCmds: Harstine UN*X/Linux Advocates Commands"
"HulaCmds: Harstine UN*X/Linux Applied Commands"
"HulaCmds: Harstine UN*X/Linux Associated Commands"
"HulaCmds: Harstine UN*X/Linux Associates Commands"
"HulaCmds: Harstine UN*X/Linux Applications Commands"
"HulaCmds: Harstine UN*X/Linux Applicable Commands"
"HulaCmds: Helpful UN*X/Linux Applications for Command-Line Users"
"HulaCmds: A UN*X/Linux Toolkit for Cmd Shell Users"
"HulaCmds: A UN*X/Linux Toolkit for Cmd-Line Users"
"HulaCmds: A CMD-Line User's Toolkit (for UN*X/Linux Geeks and Wannabees)"
"HulaCmds: A Command-Line User's Toolkit (for UN*X/Linux Geeks and Wannabees)"
"HulaCmds: CMD Shell Command-Line Toolkit (for UN*X/Linux Geeks and Wannabees)"
"HulaCmds: A Software Porter's Toolkit (of Cultivated Anachronisms)"
"HulaCmds: A Software Porter's Toolbox (of Cultivated Anachronisms)"
"HulaCode: A Glue Coder's Garden (of Cultivated Anachronisms)"
"HulaGlue: A Glue Coder's Tropical Garden (of Cultivated Anachronisms)"
"HulaGlue: A Glue Coder's Garden (of Cultivated Anachronisms)"
variously, alternating Bats for Cmds after Hula works, as well.
-----------------------------------------------------
A contest for the best acronym?
-----------------------------------------------------
While "Hula" of course refers to the native Hawaiian dance
that was once banned by the conservative Christian colonialists,
its Hawaii connotations for us are not to be discounted because
we love Hawaii and want to move there someday to be nearer to our
sister, Sunny. However, currently, we reside on Harstine Island
in Puget Sound, so the winner of the acronym contest that most
closely aligns to our own interests is ...
Hula = Harstine UN*X/Linux Advocates
This has a .org ring to it don't you think?
However, if/when we finally make it to Hawaii we can change
"Harstine" to "Hawaii" without changing too many references to it.
And, in the long run, the web site will, hopefully, be:
www.HulaBats.com or www.HulaBats.net
but web hosting is so pricey and well, who has the extra time?
The runner-up was ...
HULA = Harstine UN*X/Linux Associates
But then there is only me, so that one makes little sense.
The contesting suffixes were ...
Bats = Batch files (dot bats, .bat's) (HulaBats)
BATS = Business And Technology Software (HulaBats)
RATS = Research And Technology Software (HulaRats)
However, we found out someone in China has already claimed
hularats.cn as their domain - even though they have no web site
that we can find. So, we threw out the rats and stuck with bats
which led us to Batty, of course, and the Hawaiian Hoary Bat,
and the hula skirt.
Other prefix contest contenders were ...
HULA = Harstine UN*X/Linux Applications
HULA = Harstine UN*X/Linux Associated
HULA = Harstine UN*X/Linux Associates
HULA = Harstine UN*X/Linux Applied
HULA = Hawaii UN*X/Linux Advocates
HULA = Hawaii UN*X/Linux Associates
HULA = Hawaii UN*X/Linux Associated
HULA = Hawaii UN*X/Linux Applications
HULA = Hawaiian UN*X/Linux Advocates
HULA = Hawaiian UN*X/Linux Associates
HULA = Hawaii-lover's UN*X/Linux Advocates
HULA = Hawaii-lover's UN*X/Linux Associates
HULA = Heritage UN*X/Linux Apps
HULA = Helpful UN*X/Linux Apps
HULA = Helpful UN*X Lover's Apps
HULA = Have UN*X command-Line Apps (will travel)
HULA = Have UN*X Lover's Apps (will travel)
HULA = Have UN*X/Linux Apps (will travel)
HULA = Has UN*X Lover's Attention
HULA = Has UN*X-Like Applications
HULA = Has UN*X Logical Applications
HULA = Has UN*X/Linux Applicability
HULA = Has UN*X/Linux Aspirations (wannabe?)
HULA = Hot UN*X command-Line Apps
HULA = Hot UN*X Lover's Apps
HULA = Hot UN*X/Linux Apps
And two of our special favourites (as in "glue code") were:
Glue = God Loves UN*X Environs
Glue = God Loves UN*X Engineers
but we couldn't seem to fit the glue word in very well, and
HulaGlue sounds a bit sticky, don't you think?
-----------------------------------------------------
Enough of that nonsense. What about the toolkit? It's mission in life...
-----------------------------------------------------
The toolkit needs to be small enough to fit on a developer's USB flash drive
so they can carry it around in their pocket. It must be as standalone as
possible. It is designed to not require a big product installation (like
SFU/SUA, Cygwin, &c) and get the developer up-and-running faster, working
with familiar command-line tools, like on quick-and-dirty jobs such as fixing
your sister's or a neighbor's computer. It needs to be easily customizable
for programmers, so they don't have to recompile things IOW. That's
where shell scripts excel! There are no dependencies on some big
fat DLL (like Cygwin has). There is no need for a POSIX sub-system,
either (like SFU/SUA has). It should be inexpensive (or "free" even).
It is designed for the Windows 2kpro/2ksrv/XPpro/2k3srv/Vista platforms.
But, there are associated components for WindowsCE/PocketPC, as well.
Security can be an issue when working short-term on other's systems.
They may not want you installing a big package like Cygwin or SFU/SUA.
It can also be an issue if you are part of a team and you tell the
other members that you need to add, say Cygwin, to the baseline. Oh my.
There may be licensing issues, extra cost $$$. Managers may not approve.
There may be reluctance to add software that may have come from one of
your enemies (USA, Russia, China, India, Iran, Palestine, Israel, ...).
It may leave a bad taste in their mouth if you try including GNU copyleft code.
The nice thing about what we are hoping to do here is that you have the
source code - heck, most of it is in CMD script. You can pretty easily
read it to determine if it has been hacked. The other tools? Well, we will
make sure that you have the source code for them, and show you how to compile
them all yourself so you know where the .exe's came from. There will be
no licensing issues that keep you from using HulaBats in whatever products
you choose (as long as you abide by our little quirks in the copyright
notice), or from leaving it hanging around on your mother-in-law's PC because
you forgot to remove it after you were done fixing up her system.
There is some precedence in UN*X systems, too, in having many commands
coded as shell scripts (or batch files in this case). If you have ever
bothered to run the 'file' command on executables in /bin (or /usr/bin)
you might see that many of them are shell ('sh', 'csh') scripts. So,
following in that tradition, our challenge has been: see how many UN*X
like scripts (or Windows batch files) you can code that emulate actual
UN*X commands.
Another part of the HulaBats mission, by implementing the 80:20 rule,
is to provide the most common options and capabilities that we normally
use all in a days work. If you look at all the options that have
evolved over the years in most if not all the common UN*X commands
you will be astounded. But, at the beginning, back to V7 UN*X and
before, life was somewhat simpler. A few switches here and a few
options there, and you could get by and still do good things. That
is the way these .cmd scripts have been implemented. First come one
or two basic capabilities that are those most commonly used (80% of
the time) given about 20% of the effort (to "make it so" as Capt.
Jean Luc Picard used to stay in Star Trek Next Generation). Then
over time, as time allows, add a few more here and there to make
them more complete (if Windows will let you find a way to implement
them that is).
Oh, and one thing more, there are to me many major annoyances about
Windows, that I have been searching for solutions or work-arounds
for over the years, and, whenever possible, another goal of HulaBats
is to alleviate some of these aches and pains. A prime example of
this type of thing comes in the capability of these two commands:
pgrep -v cmd.exe
tty -v
I normally work on a desktop with 4, 5 or 6 shell windows mixed
in equal parts Windows cmd.exe and Cygwin bash shells. I resort
to Cygwin for powerful features like a full 'find' implementation.
But as one of my goals is to improve on the HulaBats collection
I also try to work with cmd windows using the .cmd scripts to
stress them and tweak them a little each day. Well, when you
do a 'ps' (or 'tasklist' or 'tlist' or 'pulist' (except for 'ptree'
which has disappeared since the Windows 2000 Server Resource Kit!))
you get lists of "cmd.exe", "cmd.exe", "cmd.exe",... with no way to
actually map them to any of your cmd shell windows. IOW who is
this one's parent? If I lock one up, like I sometimes do, I want to
just 'kill' it and move on. But, I don't have a clue which is which!
Now I do!! Run 'tty -v' in each cmd shell terminal window to get the
pid of each one. Then when you do 'ps', or better, 'pgrep -v cmd.exe'
you can discern which is yours from the list. This kind of mapping
makes life a lot easier for command-line programmers. UN*X does
this by its very nature. Windows lives in a GUI world that hides
the underlying reality from non-programmer users. But that very
fact makes it so difficult for programmer types, especially old
command-line hands like me, to get along because oft-times the
abstraction gets in the way.
-----------------------------------------------------
What other stuff should the package/book contain?
-----------------------------------------------------
The package/book should contain meaningful commonly used examples.
Here are some examples of what we mean ...
cpdir . c: (copy directory tree)
grep -v "^@rem" script.cmd | wc -l (count comment lines)
grep -v "^#" script.ksh | wc -l (count comment lines)
grep -n "^.$" cat.cmd (squeeze out blank lines)
rm -rf foodir (remove directory tree)
tr -s [:space:] foobar.txt (squeeze out spaces)
tr -d [\r] messydos.txt (delete carriage returns)
pgrep -v cmd.exe (list PIDs of all CMDs)
tty -v (list PID of this CMD)
Our biggest gripe about other computer How-To books is that what
they show as examples are rarely useful to us in the real world.
And, often they depend on some quirky toolkit or another .dll or
environment or GUI that make it difficult to separate out just what
component we might use. We want to particularly focus on providing
real world examples of how these tools are useful.
The package/book should discuss, hopefully, some of the many things
UN*X geeks really, really, really don't like about Windows ...
1) spaces in filename paths break 'find | xargs' (called: "space challenged")
2) carat instead of backslash as the Escape char on the CMD command line
3) backward slashes instead of forward slashes as the file.separator
4) semi-colons instead of colons as the path.separator
5) \r\n (crlf) as the Text file type default EOLN translation
6) a wussy shell (CMD) with lottsa quirks, weirdnesses, and annoyances like
7) only %1 - %9 amount of argv[9] options to pass into .cmd, .bat scripts
8) drive letters A-Z: limit to mount points instead of a real mount command
9) the lack of an easy to use 'ln' command with hard and soft symbolic links
10) no discussion of the atomicity of commands like move, ren(ame), &c.
11) WindowsCE/PocketPC mounts flash memory on mount points with spaces in them!
12) PocketCMD cannot pass filenamepaths with spaces in them down in argv %1 %2
13) executability based on filename .ext(ensions) (with MIME-type mappings)
14) case insensitivity, copy a lowercase filename from a flashdrive UPCASES it
15) re-uses process Ids (or pids) as soon as they are freed up - we HATE this!!
16) process table dumps do not show the whole command (ps -eaf) just "java.exe"
Installation and Configuration
Soapbox Tirade
--------------
Speaking of what we don't like about Windows, here are some issues we don't
like that pertain to Installation and Configuration, just to set the stage
for discussing both of these important initial items ...
(1) Blanks or spaces in pathnames! "C:\Program Files\", huh?
Why not just "c:\programs", or even shorter yet "c:\prog"?
Or, my favourite "c:\proggies" (it rhymes with "froggies"!)?
(2) Microsoft or Microsoft Press or whomever (marketing?) keeps changing
the default installation locations for the Resource Kit tools. Why
can't they just pick one pathname and stick with it, huh?
(3) Long pathnames "Windows Resource Kit", huh? Why?
(4) No easy and consistent way to find out where the Resource Kit and
Support Tools packages are installed. Registry pointers if used are
probably changed just as often as the actual default disc locations.
(5) Security through obfuscation does not work - so why be so obtuse?
(6) Folks who still know how to "type" and like to use command-lines
really hate long pathnames!
When we encountered the Windows 2003 Server Resource Kit Tools installation
and found that the old default installation location
"C:\Program Files\Resource Kit\"
which usually resolved 99 out of 100 times to
"C:\progra~1\resour~1\"
was now changed to
"C:\Program Files\Windows Resource Kit\Tools\"
which since there are umpteen packages that begin with "Windows"
leaves one with no clue as to exactly what the short ('dir /x') name will
resolve to, we threw up our hands and said "enough is enough already"!
So, here's the deal. The onus is now on you the user to tell
us where the heck you decided to install the Resource Kit and
the Support Tools (assuming that you want to be able to use
our commands that need to use some of their commands as back-ends
that is). We are going to be nice enough to give you some advice,
prejudiced though it may be from our perspective, still, we are
going to give it to you never-the-less. We will give you some
other options in case you already have them installed, too.
Before we deal with the installation of HulaBats, we need to
to deal with the installation of the Resource Kit and the Support
Tools packages. Then we will look at HulaBats, itself.
You might ask: "Why do they care as long as they are on the PATH?"
Well, good question. Here is our answer: There are a couple of
problems with that: (1) there might be other commands in other
folders on your PATH with the same names that are resolved to first
but which may not take input parameters or output results in the
same formats which would mess up what HulaBats commands expect,
and (2) it makes it harder to test for existence (if exist) and
to control error messages (we can write them instead of whatever
randomly happens if the needed lower level command is not found
or arguments are not in the same order as expected, &c) to make
things cleaner all around. That being said, there may be one
or two HulaBats commands that do actually just blindly call out
for the back-end hoping that it is on the PATH as a last resort
or fallback position, but, in general, we try to avoid doing so.
Resource Kit Installation and Configuration for HulaBats Use
------------------------------------------------------------
Unfortunately, you may have to purchase the Resource Kit from
Microsoft Press to get it. Although, we have seen links on
the web for downloading the old Windows 2000 Resource Kit for
free. You can usually run these older executables on the newer
platforms just fine (e.g., linkd.exe) if you cannot afford to
get the newer one for your platform. Some of the commands we
use from it may be found in Microsoft Visual Studio .NET 2003
if you own that particular compiler suite. See the section
below which describes what files to grab from this package
to copy to your c:\msreskit directory to fake a partial Resource
Kit installation.
If you have a choice where to install it, then please choose
c:\msreskit
and be done with it.
If you have the Resource Kit installed already, you have two options
* make a symbolic directory link (what uSoft calls a JUNCTION)
using the 'linkd.exe' command to
c:\msreskit
The HulaBats script 'ln.cmd' has a '-d' option that does this
but there is a chicken-or-the-egg problem in that it needs to find
the Resource Kit linkd.exe to perform the feat. So, it is just
easier, initially, to use 'linkd.exe' directly until 'ln.cmd' can
find its location.
* set a global environment variable to point to the directory
where it is currently installed. E.g.,
MSRESKIT=c:\progra~1\resour~1
Three ways come to mind on how to do this depending on your
preference
- use the GUI under System Properties->Environment Variables
(again, they keep changing where the GUIs are so you figure it out!).
You will probably want to reboot after you set this.
- use the 'setx.exe' command that usually comes with either
the Resource Kit or with Windows itself as a native command
(and you can figure out the syntax for using it yourself).
This command 'setx.exe' is a perfect example of one that
has been moved over the years. Under Windows 2000 Server
it came with the Resource Kit and was usually found at
c:\progra~1\resour~1\setx.exe
but under Windows 2003 Server R2 it has become a native
command that lives at
%SystemRoot%\system32\setx.exe
You will probably want to reboot after you set this.
- edit the login.cmd script under the HulaBats bin directory and
source it in or run it IOW from your cmd.exe command line before
you execute any other HulaBats commands under that shell terminal.
An example would be
set MSRESKIT=c:\progra~1\resour~1
but your mileage may vary depending on where it is actually
installed (use 'dir /x' to figure out the short names to use).
This last one is our usual modus operandi BTW.
Support Tools Installation and Configuration for HulaBats Use
-------------------------------------------------------------
The Support Tools come on the media for the operating system
under the "SUPPORT\TOOLS" directory. It can be installed by
running its setup.exe or .msi file either in the file explorer
or on a cmd.exe command line.
Here you have choices similar to those above for the Resource Kit,
except that the installation location and environ variable name is
different.
If you have a choice where to install it, then please choose
c:\suptools
and be done with it.
If you have the Support Tools installed already, you have two options
* make a symbolic directory link (what uSoft calls a JUNCTION)
using the 'linkd.exe' command to
c:\suptools
The HulaBats script 'ln.cmd' has a '-d' option that does this
but there is a chicken-or-the-egg problem in that it needs to find
the Resource Kit 'linkd.exe' to perform the feat. So, it may just
be easier, initially, to use 'linkd.exe' directly until 'ln.cmd' can
find its location. If you already have MSRESKIT set in the environ
or have the Resource Kit installed under c:\msreskit or have a
JUNCTION made pointing to it as described above then you can use
the HulaBats 'ln.cmd' command to perform this deed. E.g.,
ln -d c:\progra~1\suppor~1 c:\suptools
* set a global environment variable to point to the directory
where it is currently installed. E.g.,
SUPTOOLS=c:\progra~1\suppor~1
Three ways come to mind on how to do this depending on your
preference
- use the GUI under System Properties->Environment Variables
(again, they keep changing where the GUIs are so you figure it out!).
You will probably want to reboot after you set this.
- use the 'setx.exe' command that usually comes with either
the Resource Kit or with Windows itself as a native command
(and you can figure out the syntax for using it yourself).
Again, you will probably want to reboot after you set this.
- edit the login.cmd script under the HulaBats bin directory and
source it in or run it IOW from your cmd.exe command line before
you execute any other HulaBats commands under that shell terminal.
An example would be
set SUPTOOLS=c:\progra~1\suppor~1
but your mileage may vary depending on where it is actually
installed (use 'dir /x' to figure out the short names to use).
This last one is our usual modus operandi BTW.
Back-ends Used From The Resource Kit or Support Tools
-----------------------------------------------------
Here is a (probably partial) listing of back-end programs used
by HulaBats commands that historically were found in either the
Resource Kit or the Support Tools (but which may be found under
%SystemRoot\system32 in newer platforms or may have been renamed
to something else or may even be OBE today).
depends.exe - ldd.cmd uses this
diruse.exe - du.cmd uses this
linkd.exe - ln.cmd uses this
oh.exe - fuser.cmd uses this (on Vista => openfile.exe)
ptree.exe - ps.cmd may use this (but prefers tasklist.exe)
pmon.exe - top.cmd uses this
robocopy.exe - cpdir.cmd uses this
sleep.exe - sleep.cmd may use this
uptime.exe - w.cmd uses this
windiff.exe - diff.cmd uses this for the -g option
where.exe - find.cmd uses this
whoami.exe - w.cmd uses this
Here are other tools of special interest that may be used in
the future...
setx.exe - env.cmd may use this someday to set global environ vars
timeit.exe - possible time.cmd may use this someday
xcacls.exe - possible set/getfacl.cmds (like in Cygwin) may use this
Alternate Locations Of Useful Programs
--------------------------------------
Some of the back-ends used by HulaBats commands that usually
come with the Resource Kit may also be found in Microsoft Visual
Studio .NET 2003 if you own that compiler suite. This section
describes what files to grab from this compiler suite that you
can copy to your "c:\msreskit" directory to fake a partial
Resource Kit installation.
First, here is the location of the files in the compiler package
C:\progra~1\"Microsoft Visual Studio .NET 2003"\Common7\Tools\Bin\
and here are the files you need to grab (assuming that you have
done a 'cd' command to go to the above location)
mkdir c:\msreskit
copy Depends.* c:\msreskit
copy Where.Exe c:\msreskit
copy WinDiff.* c:\msreskit
Another, useful tool (from DCE which we have our own version of, too)
can also be found there
copy Uuidgen.Exe c:\msreskit
and it can be used to generate unique GUID keys and file names.
How HulaBats Scripts Find The Resource Kit and Support Tools
--------------------------------------------------------------
First, they check if "c:\msreskit" and "c:\suptools" exist,
and look for the program they need under those locations.
Second, they see if MSRESKIT and SUPTOOLS are defined,
and look for the program they need under those locations.
Third, they look for them under "%SystemRoot%\system32".
In most cases an error will occur if none of the above work
out. In some cases though, as we described above,
the script might just act like it is on the PATH and run
it blindly not giving a damn about the input parameters or
output format compatibility, leaving the error to just
happen if the command being called is not found on the PATH.
How HulaBats Scripts Find Their Brother and Sister Commands
-----------------------------------------------------------
Recently, we have begun to use code (like this code snippet
lifted from ascii.cmd) in many of the HulaBats .cmd scripts
set HULABIN=%~dps0
^^^^^^
if defined HULADBUG @echo HULABIN=%HULABIN%
set ASCIITXT=%HULABIN%ascii.txt
^^^^^^^^^^^^^^^^^^
when they need to find data files or other scripts in the collection.
What the "%~dps0" does is expand to the full shortname path to
the currently running script itself (the full path to argv[0] IOW).
(And they used to always complain about how cryptic C and UN*X were!)
Note that HULABIN ends up with a terminating '\' (backslash) so no
extra backslash is needed between the %HULABIN% macro expansion and
the rest of the file path value.
We haven't yet fully decided how to point the manual scripts (like
man.cmd, apropos.cmd, whatis.cmd, mkwhatis.cmd) to the man pages.
We are leaning towards using HULAHOME with a HULAMANS override but
we may fallback to the trick above and base the man pages relative
to where the .cmds themselves are located.
Here are some scratch notes we made earlier on about this subject...
# We may need to add our root tree or bin dir to the PATH
# PATH=%HULAHOME%\bin;%path%
# We may need to set some environ variables to find stuff
# Here are some possibilities...
# HULAHOME=HulaBats installation tree root>
# HULABATS=
# HULAMANS=
# MSRESKIT=
# SUPTOOLS=
# PERLHOME=
# JSDKHOME=
Here are two scripts that we use to configure our working environ:
login.cmd - set up HulaBats working environ In this script is
where any or all of the above environ variables can
be set.
mslogin.cmd - set up supplemental cl.exe compiler environ (like for
building getppid.exe,...)
Or, like some of our recent scripts that depend on Perl
we could insist that the user add the directories where
things we need reside to the global, system, machine
environment PATH and be done with it. Then if they do
not work - it is their fault to correct. We still may
need HULAHOME to be able to find our data files relative
to our scripts and executables (ie. man pages). But, that
too can be added to the global, system, machine environs.
Futuristically Speaking
----------------------
We may be able to use "assoc" and "ftype" to find out
where things are installed? See the contents of the "file.cmd".
This is a MIME-type style mapping which Windows XP uses to
know how to "run" files (ie., .pl maps to a perl.exe
somewhere). Use them like this to find where a Perl is ...
F:\home\cal\bin>assoc .pl
.pl=pl_auto_file
F:\home\cal\bin>ftype pl_auto_file
pl_auto_file=C:\h\coe\comp\perl\bin\perl.exe "%1" %*
Core .cmd commands with no depends other than native Windows apps
These are the core HulaBats commands that have no real dependencies
on external applications other than those that come native with
Windows itself...
#-----------------------------------------------------------
apropos.cmd - See Also: man.cmd, whatis.cmd, mkwhatis.cmd
ascii.cmd - uses own location to find its ascii.txt data file
basename.cmd - similar to UN*X 'basename' command
cat.cmd - takes /dev/null, '-' filter option, 9 max file args
clear.cmd - simple wrapper around 'cls'
cp.cmd - wrapper around 'copy'
cpdir.cmd - wrapper around 'xcopy.exe'
diff.cmd - abbreviatable, line-numberable wrapper around 'fc.exe'
dirname.cmd - similar to UN*X 'dirname' command
du2.cmd - does not calculate sizes just lists dirs (See lsd, du)
env.cmd - simple wrapper around 'set' with no args
expand.cmd - expands tabs to spaces, nice filter tool (I hate tabs!)
expr.cmd - basic calc subset, no parens or nested expressions yet
false.cmd - similar to UN*X 'false' command
file.cmd - 'assoc', 'ftype' provide MIME-type style mappings
free.cmd - works on Windows XP/2k3srv/Vista (needs 'fsutil')
fsize.cmd - displays the size of the specified file in bytes
grep.cmd - simple subset works, uses 'findstr' and 'find'
ifconfig.cmd - in ok shape read-only-wise, does not configure yet!
kill.cmd - works on Windows XP/2k3srv/Vista (needs 'taskkill')
l1.cmd - an 'ls -1' single column alias
la.cmd - an 'ls -a' list all alias
lc.cmd - an 'ls -c' list columnar alias
less.cmd - simple (like 'more' and 'pg' does not go backwards)
ll.cmd - an 'ls -l' long list alias
logname.cmd - BSD UN*X, Cygwin equivalent: just echoes %USERNAME%
ls_.cmd - basic 'ls' command if no better 'ls.exe' is available
ltR.cmd - an 'ls -ltR' alias (newest files last)
man.cmd - See: apropos.cmd, whatis.cmd, mkwhatis.cmd
mkwhatis.cmd - See: man.cmd, apropos.cmd, whatis.cmd
mv.cmd - simple wrapper around 'move'
pg.cmd - simple wrapper around 'more'
printenv.cmd - in great shape, can specify a particular environ var
ps.cmd - uses 'tasklist' which is native on XP/2k3srv/Vista
pwd.cmd - simple wrapper around 'cd'
rand.cmd - simple one-liner, just 'echo %RANDOM%'
rm.cmd - in ok shape, -i and -rf supported
setfilec.{cmd,reg} - turns on CMD filename completion in the registry
su.cmd - 'runas' wrapper (hack it if you change Administrator)
tail.cmd - needs 'wc.cmd', does "-n #" and "-#" now, but no -f!
touch.cmd - similar to UN*X 'touch' command
true.cmd - similar to UN*X 'true' command
uname.cmd - several options work ok fine now w/o MsResKit
wall.cmd - works only if 'net' command works, needs more testing
wc.cmd - line and byte/char counts work, word count doesn't
what.cmd - needs some work, has leading @rem crapola in output
whatis.cmd - See: man.cmd, apropos.cmd, mkwhatis.cmd
which.cmd - in good shape (must specify .ext(ension) though)
yes.cmd - in good shape (needs a '-t 5' delay-timer option)
#-----------------------------------------------------------
.cmd commands with depends on HulaBats' own .exe's or scripts
One measure of how useful a particular piece of software
is - is if it can build on itself, use pieces of itself,
to create new and ever more useful components. Well, in
that regard, this section lists tools that use other parts
of the package to do meaningful work...
#-----------------------------------------------------------
cmp.cmd - wc.cmd
head.cmd - ed.exe + mktmpnam.exe
ln.cmd - link.exe + unlink.exe (+ linkd.exe from MsResKit)
prnt.cmd - unix2dos.exe + mktmpname.exe + basename.exe + tolower.exe + fold.exe
tail.cmd - wc.cmd
tty.cmd - calls 'getppid.exe' (sort of similar to BSD UN*X, Cygwin 'tty')
#-----------------------------------------------------------
.cmd commands with depends such as MsResKit, SupTools, Java, or Perl
Somehow those with depends need to detect whether they
are present or not and if not just echo something about
the user needing to install and/or configure for them
to be able to work correctly.
#-----------------------------------------------------------
cmp.cmd - needs native 'comp.exe' and our 'wc.cmd'
diff.cmd - -g GUI mode needs Support Tools 'windiff.exe'
domainname.cmd + domainname.pl- needs Perl with LibWin32 (see domainname.exe)
dos2unx.cmd - needs Perl on your PATH
du.cmd - needs 'diruse.exe' (See Also: du2.cmd, lsd.cmd)
find.cmd - 'find' subset that uses the MsResKit where.exe
fuser.cmd - uses oh.exe from MsResKit (SysInternals handle)
(oh.exe is now openfile.exe on Windows Vista
which broke this script - so it needs fixing!)
head.cmd - filter, needs our 'ed.exe' and 'mktmpnam.exe'
hostname.cmd + hostname.pl - needs Perl with LibWin32
ldd.cmd - needs 'depends' from MsResKit or Support Tools
ln.cmd + link.exe + unlink.exe + linkd.exe - needs 'linkd.exe' from MsResKit
lsd.cmd - list directories (See Also: du.cmd, du2.cmd)
modinfo.cmd - needs 'drivers.exe' on 2k or 'fsutil' on XP
mount.cmd + voltab.cmd + strrtrim.exe + printf.exe + findstr.exe
+ linkd.exe + subst.exe - virtual mount capabilities, needs linkd.exe
nospace.cmd + nospace.pl - removes spaces from path file names, uses Perl
pgrep.cmd - prefers 'tasklist' over the MsResKit 'ptree'
ps.cmd - prefers 'tasklist' over 'pulist' or 'tlist.exe'
pwd_pl.bat + pwd.pl - needs Perl with LibWin32
reboot.cmd + shutdown.exe - needs 'shutdown.exe' from MsResKit
sed.cmd - needs Perl on your PATH, more work/testing!
shutdown.cmd + shutdown.exe - needs 'shutdown.exe' from MsResKit or Vista
sleep.cmd + sleep.pl - needs Perl with LibWin32
tlist.cmd - needs 'tasklist' (use when tlist.exe fails)
top.cmd - uses 'pmon.exe' from MsResKit or Support Tools
tr.cmd - very nice but uses Perl "tr/ / /cds" commands
umount.cmd + findstr.exe + linkd.exe + subst.exe - unmount, needs linkd.exe
unx2dos.cmd - needs Perl on your PATH
unzip.cmd - needs Java 'jar.exe' or 'pkzip25.exe'
voltab.cmd + shuffle.exe + findstr.exe + mountvol.exe - falls back to perl.exe
w.cmd - needs MsResKit 'uptime.exe/whois.exe'
where.cmd - needs MsResKit (or Vista native) 'where.exe'
whoami.cmd + whoami.pl - needs Perl with LibWin32
whois.cmd + whois.pl - needs Perl with LibWin32
zip.cmd - needs Java 'jar.exe' or 'pkzip25.exe'
#-----------------------------------------------------------
.cmd commands that can act like true UN*X filters
Somewhere along the way it hit us that the Windows native
'more.com' command could be used as a silent filter to input
data from stdin. If the data stream can be analyzed, and
processed without an intermediate temporary file stage that
is preferred because it is much faster and much more elegant.
Otherwise, once the inbound data is redirected to a temporary
file it can be post-processed and then the final product
written on stdout. But then the temporary file must be
removed during a final cleanup operation which is a time waster.
Other Windows native commands that act like the 'more' filter
although in some cases not as cleanly are: findstr.exe, find.exe
Accordingly, we have been making an effort to add true filter
capabilities to our scripts.
Filters can take their standard input in one of two ways.
The first way is what is called a pipe or pipeline as indicated
by the pipe '|' symbol immediately before the filter command
as in this example:
cat foo.txt | head.cmd
The second way is what is called a redirection of stdin as
indicated by the '<' standard input redirector symbol immediately
following the filter command (and its optional switches) as in
this example:
tail.cmd -n 5 < foo.txt
The key here is that the data is coming in as an input stream
without a known filename instead of by specifying a known
filename that then must be opened and read for input. Sometimes
it is a disadvantage to not know the filename that is the source
of the incoming data. But, at other times it does not really
matter at all.
Pipelines are part of what UN*X programmers and power users
know to be at the core of its power. You can string several
commands and filters together to do many amazing things.
What follows then is a list of those commands which have this
filter capability to date. As we add filter mode to other
.cmd scripts they will be added to this list ...
#-----------------------------------------------------------
cat.cmd - uses more.com to read stdin
expand.cmd - uses more.com to read stdin
head.cmd - uses more.com to read stdin
grep.cmd - uses findstr.exe or find.exe to read stdin
tail.cmd - uses more.com to read stdin
what.cmd - uses more.com to read stdin in a for loop
#-----------------------------------------------------------
CMD Scripting Gems
In this chapter we will attempt to expose some kewl things
that you can do in CMD scripts - some are vaguely similar to
UN*X script coding. Also, covered will be some strangeoid
annoyances that we have figured out work-arounds for along the
way. The format is a Q/A format here.
Q: Can we make a .cmd script act like a real UN*X filter?
A: Yes. Here is what seems to work for me...
First, for some background, read the section in this document titled:
".cmd commands that can act like true UN*X filters"
if you have not done so already for more details on programming filters.
If you are reading this document top down you should have already read it.
Here is a code snippet from the HulaBats 'tail.cmd' script that
shows how to setup the read from stdin that is being fed from
a pipe ...
:PipeTail
@rem If no args at all are specified we are reading from a pipeline like:
@rem grep char foo.c | tail
@rem To make it work we have to write stdin to a tmp file using more>TEMPNAME
for /F "usebackq tokens=1" %%I in (`mktmpnam tail`) do set TEMPNAME=%%I
%SystemRoot%\system32\more.com /S>%TEMPNAME%
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here then is the magic - use a command like 'more.com' that is a filter
already setup to read from its stdin. You can pipe it to a tmp file
like we had to do here in 'tail.cmd'. Or you can post-process it in
an internal pipeline or as we show below you can even pipe data into
a CMD 'for' loop that is reading from 'more.com'. There are other
Windows native applications that are also filters like 'findstr.exe'
and 'find.exe' which can be used instead of 'more.com' should you
need or want to.
Q: Can we pipe things inside a CMD loop construct?
A: Yes. I finally discovered how to do it one day by looking at someone
elses code. The trick is to use '^' (carat or hat) symbol(s) just before
the '|' pipe symbol(s) to escape them like this...
for /F "usebackq tokens=1* delims=" %%I in (`type foo ^| grep bar`) ...
Q: Can we pipe things into a CMD loop construct?
A: Yes. Here is what seems to work for me...
Note: in the following code snippets we use a back-slash ('\')
at the end of each line where we split up code that actually
belongs all on one line. This is similar to the way
you break up long #include macros in C and C++ code.
We also indent the continuation code to make it sort
of understandable what block it corresponds to. If you
copy & paste or type in the code examples by hand be sure
to remove the back-slashes and rejoin all the code together
on a single long, long line.
Simple example first, a two-stage pipeline:
@echo off
@rem "@(#)forloop.cmd - can we read stdin in a for loop in a cmd script?"
echo bar | for /F "usebackq tokens=1* delims=" %%I in (`more`) \
do @echo off& echo %%I food
Here is a more complicated code snippet from the HulaBats
"what.cmd" script, a three-stage pipeline:
%SystemRoot%\system32\findstr.exe /I /R /C:"^@rem" %1 \
| %SystemRoot%\system32\findstr.exe /R /C:"@(#)" \
| for /F "usebackq tokens=1* delims= " %%I in (`more`) \
do @echo off& echo %%J
^^^^^^^^^^^^^
The main gotcha seems to be to use "@echo off&" as the first
thing that happens after the "do" in the "for" loop when you
are running it in a pipeline just as you would make it the
first line in your .cmd scripts. I took that to mean it was,
basically, forking a new shell to run that part of the code.
Please correct me if I am wrong here, somebody.
The trick is to use the Windows native "more.com" command as
a filter to read from stdin. What I really wanted to do was
use the "for" loop "file-set" syntax in a simpler loop like
this to read from the stdin stream:
echo foo | for %%I in (stdin) do echo %%I bar
or better yet just be able to use a minus symbol to specify
stdin like the UN*X 'tar' command does amongst others:
echo foo | for %%I in (-) do echo %%I bar
Unfortunately, Windows CMD is just not that sophisticated.
So, "more.com" suffices because it goes into filter mode
and ingests stdin when there are no args and writes the
results on stdout just like what we want to happen. In our
"for" loop above stdout from "more" is being processed by the
"for" statement and the fields are chopped up as you specify
in the "tokens=..." value and finally output in the "do"
section of the "for" statement using "echo".
Note that the above use of the "for" loop is similar to how a
UN*X script writer would use "cut -d' ' -f2" or "awk '{print $2}'"
to print out a particular field at the end of a pipeline
following a couple of "grep" calls. The ugly "for" loop syntax
is not nearly as clean and as easy to remember off the top of
your head as the "cut" syntax or even the "awk" overkill,
but that is just a way to pick out particular fields with CMD.
Q: How can we get rid of that annoying extra blank output line
that appears after we echo the results to stdout in a .cmd script?
A: This one I stumbled upon purely by coincidence.
Here is what works for me ...
@echo off
setlocal
@rem Do anything you want between "setlocal" and the ":EOFrame" label
@rem and have all your goto statements jump to ":EOFrame" not ":EOF".
echo Hello World& goto EOFrame
@rem Now the last three lines of the .cmd script file...
:EOFrame
endlocal
:EOF
.exe commands from our own, or BSD UN*X, or other "free" sources
One of our goals was to have as few .exe commands as possible.
However, now and again we need to create a customized utility.
The main idea was to have minimalistic .cmd scripts
that can get the user up and running without compilers,
or wrappers around freely available toolkits like
the Java SDK or the MsResKit. These just flesh things
out a bit. Grep and the link stuff are real nice,
same with tail and head and sed ... Sed is probably the
most important one of all of these! Some things you
just cannot do with Windows commands or add-ons such as our
'getppid.exe', 'mktmpnam.exe', and 'strrtrim.exe' executables!!
.exe commands require a ("free"?) compiler to build the .exe files.
Many of us won't find that a big limitation. But, others, will.
Here is our current list of .exe programs we find useful...
#-----------------------------------------------------------
arc.exe + arc src codes - arc521
banner.exe + banner.c - large bold banners stand out (like for motd)
beep.exe + beep.cs - one of the few .NET compiled commands so far
becho.exe + echo.c - a BSD UN*X style 'echo' command
cal.exe + cal.c - your basic calendar command
cat.exe + cat.c - type file to stdout or redirect elsewhere
comm.exe + comm.c - compare and contrast two files
cp.exe + cpbourn.c - original simple Bourne 'cp' command
cut.exe + cut.cpp - needs to become a filter!
date.exe + getctime.cpp - READONLY equiv of UN*X style 'date' command
domainname.exe + domainname.cs - one of the few .NET compiled commands so far
ed.exe + ed.c - the old ed editor, very useful, see head.cmd
fold.exe + fold.cpp - BSD UN*X version (prnt.cmd uses this)
getppid.exe + getppid.c - provides _getpid(), _getppid() via Win32
getlogin.exe + getlogin.c - getlogin(), does logname.cmd equivalent
grep.exe + grep.cpp - better than grep.cmd based on findstr & find
hd.exe + hd.cpp - hex dump is better than an octal dump (od)
head.exe + head.cpp - BSD UN*X style 'head', cleaner than head.cmd
hostname.exe + hostname.cpp - don't really need this since Windows has it
hostname.exe + hostname.cs - one of the few .NET compiled commands so far
link.exe + link.cpp - hard link files
mktmpnam.exe + mktmpnam.cpp - makes a uniq TMPDIR filename (see prnt.cmd)
paste2.exe + paste2.c - paste together side by side
pg.exe + pg.c - another basic PAGER
printf.exe + printf.c - C printf() in CMD scripts or on cmd-line
readline.exe + readline.cpp - read a line of input (use set /P if you can)
rev.exe + rev.c - reverses its input
rm.exe + rm.cpp - remove file(s)
sed.exe + sed.cpp - an old GNU sed hacked by me (GPL so bury it ASAP?)
shuffle.exe + shuffle.c - shuffle text files like a deck of cards
sleep.exe + sleep.c - take a nap
strings.exe + strings.cpp - see strings.cmd Borland tdump wrapper, too
strrtrim.exe + strrtrim.c - trims RHE of string arg, returns strlen
tail.exe + tail.c - need the .exe to do 'tail -f' and +1 offsets
techo.exe + techo.cpp - "tee echo" outputs to two places at once
tee.exe + tee.cpp - pipe output through tee to two places at once
test.exe + test.cpp - BSD UN*X style 'test' command
tolower.exe + tolower.cpp - downcases its argv1 argument (see prnt.cmd)
toupper.exe + toupper.cpp - upcases its argv1 argument
tr.exe + tr.c - we use tolower or toupper in CMD 'for' loops
uniq.exe + uniq.c - useful for 'sort | uniq' pipelines
unix2dos.exe + unix2dos.c - need dos2unix to go the other way (see prnt.cmd)
unlink.exe + unlink.c - unlink files
unshar.exe + unshar.c - unravel a UN*X 'sh' shar archive
vi(m).exe + help/conf files - some "free" version of the 'vi' editor
what.exe + what.c - from SCCS, displays "what" strings
which.exe + which.c - our old MS-DOS version (see which.cmd)
xxd.exe + xxd.c - (Bill Joy's?) Tahoe BSD UN*X tool
xstr.exe + xstr.c - (Bill Joy's?) Tahoe BSD UN*X tool
yes.exe + yes.c - port from BSD UN*X (see yes.cmd)
#-----------------------------------------------------------
Perforce (p4) RCS work-alike wrappers and tools
We like RCS. We are familiar with its simple commands.
CVS is ok, too. But, when we were forced to use Perforce
at work - well, needless to say, we weren't very happy for
a while until we figured out how to do RCS-style command
line equivalents. Here is our collection that gets us
by today ...
#-----------------------------------------------------------
ci.exe + ci.cpp - checks code into the repository
co.cmd - checks code out of the repository
rcs.cmd - initially registers a new file into the repository
rlock.cmd - checks if a file is currently locked
#-----------------------------------------------------------
Note: if you need a basic MS-DOS port of RCS I have done it.
Probably can round up the source code somewhere for it to.
Huhm, I might be interested in that myself for use here, too,
come to think of it!
Miscellaneous Tools
A list of some miscellaneous tools worth mentioning...
#-----------------------------------------------------------
aliases.cmd - uses 'doskey' to setup command line aliases
cc.cmd - Compile C (UN*X cc style) using the SDK compiler
ccs.cmd - Compile C Sharp (cc style) using .NET Framework
cjs.cmd - Compile J Sharp (cc style) using .NET Framework
downcase.exe + downcase.cpp - chcase equiv? needs an upcase? use tr.cmd?
This downcases all files in a directory?
See Also: tolower.exe, toupper.exe
they just change cases of their string args.
bindump.exe + bindump.c - a binary dumper (like 'hd'?)
deltree.cmd - missing MS-DOS 6.22 command (rm -rf equiv)
older.exe + older.c - from K&R C book or the K&P book or the web?
Found it on SysAdmin cdrom, provides the missing
find -older option (the opposite of find -newer).
prnt.cmd - wrapper around 'notepad', v2.0+ depends on:
'unix2dos', 'mktmpname', 'basename', 'tolower'
and 'fold'. Used instead of 'lp/lpr' commands.
uuidgen.exe + uuidgen.cpp - hacked out of "free" DCE code, generates GUIDs.
I recently found one like this in Visual Studio.
#-----------------------------------------------------------
Utilities that work with the "free" Borland C++ compiler utilities
Recently upgraded, the following .cmd scripts now depend on
our BSD 'tail' port as well as the tdump.exe from the Borland
"free" 5.5 C++ compiler suite. Actually, we just found out that
the Windows 2003 Resource Kit includes a tail.exe that has the -f
option equivalent so we can reimplement this for that platform
w/o providing our own tail.exe if need be.
#-----------------------------------------------------------
nm.cmd - dumps details about .exe's, .obj's and .dll's
nmgrep.cmd - 'nm ... | grep ...' equivalent in one simple command
strgrep.cmd - 'strings | grep ...' equivalent in one simple command
strings.cmd - a UN*X 'strings' command emulation
#-----------------------------------------------------------
ccbsdlib - C/C++ library that builds with "free" compilers
This is our (cc=Cal Crowley's) BSD compatible library for compiling
C/C++ code on Windows that contains BSD UN*X style code. This stuff
is kewl if you are a C/C++ programmer, otherwise, you will no
doubt want to skip it.
#-----------------------------------------------------------
flock() (& friends) - file locking stuff
getppid() - get parent process id
strcasecmp(), strncasecmp(),... - string stuff like these
opendir(), readdir() (& friends)- directory reading routines
#-----------------------------------------------------------
So what is Window's missing natively (besides a brain, hah!)?
Other Misc UN*X commands
#-----------------------------------------------------------
dirs - CMD has pushd and popd but no dirs, weird!
chgrp - see our chmod_.xxx script (xxx=w32,cyg)
chmod - see our chgrp_.xxx script (xxx=w32,cyg)
chown - see our chown_.xxx script (xxx=w32,cyg)
chsh - change your default login shell
logger - a Solaris /usr/ucb/logger or BSD UN*X equivalent
nice - run a command at a lower priority level
sane - we used to be able to use the mode command for this
stty - we used to be able to use the mode command for this
sync - you can get this one from www.sysinternals.com though
#-----------------------------------------------------------
Editors
#-----------------------------------------------------------
emacs - Richard Stallman's GNU Emacs editing environment
microemacs - Dave Conroy's public domain MicroEmacs text editor
with source and executables for DOS16, DOS32, Win32
and even Linux. (ftp://ftp.digitalmars.com/me.zip)
jove - Jonathan (Paine)'s Own Version of Emacs
vi(m) - our favourite editor, get vim at "http://www.vim.org"
#-----------------------------------------------------------
Shells (beyond CMD's limits) (vs. GUI shells like Explorer)
#-----------------------------------------------------------
ash - ash is in Cygwin, SFU/SUA, and other UN*X-like environs
csh - tcsh is in Cygwin, SFU/SUA, and other UN*X-like environs
bash - bash is in Cygwin, SFU/SUA, and other UN*X-like environs
ksh - the real Dave Korn ksh is in UWIN
pdksh - pdksh is in Cygwin, SFU/SUA(?), and other UN*X-like environs
perl - perl is in Cygwin, and downloadable from ActiveState
python - python is in Cygwin, and downloadable from ActiveState
ruby - ruby can be found at "http://www.ruby-lang.org/"
sh - sh is in Cygwin, SFU/SUA, and other UN*X-like environs
tcsh - tcsh is in Cygwin, SFU/SUA, and other UN*X-like environs
zsh - zsh is in Cygwin, SFU/SUA, and other UN*X-like environs
#-----------------------------------------------------------
Mailers (missing common UN*X SMTP MUAs and MTAs such as...)
#-----------------------------------------------------------
elm - SMTP MUA
exim - SMTP MTA
fetchmail - POP3 mbox downloader
mail(x) - SMTP MUA
mutt - SMTP MUA
postfix - Wietse Venema's mailer (alt.sendmail)
pine - SMTP MUA
sendmail - Eric Allman's SMTP MTA
#-----------------------------------------------------------
UN*X-like commands Windows and CMD already have natively
CMD builtins
#-----------------------------------------------------------
cd
mkdir
popd
pushd
rmdir
#-----------------------------------------------------------
UN*X-like general utilities
#-----------------------------------------------------------
more
pax (might be able to do a tar.cmd wrapper around this, and/or cpio.cmd?)
sort
#-----------------------------------------------------------
TCP/IP utilities and services
#-----------------------------------------------------------
arp
finger
ftp
hostname
ipconfig (we wrap this with our i'f'config.cmd)
lpq
lpr
nbtstat (is this a UN*X command though?)
netstat
nslookup
ping
rcp
rexec
route
rsh
telnet
tftp
tracert (we could wrap this with a traceroute.cmd)
#-----------------------------------------------------------
Optional UN*X-like "Features"
-----------------------------
Under Windows Vista this is a list of the
"Windows Features" that you can optionally install
via "Control Panel"->
"Programs" ...
"Installed Programs" ->
"Turn on or off Windows features"
Similar "features" should be available under earlier
versions of Windows based on NT (2k/2ksrv/XP/2k3srv).
[-] Internet Information Services (IIS)
[-] FTP Publishing Service
[ ] FTP Management Console
[ ] FTP Server
[+] Web Management Tools
[+] World Wide Web Services
Note: SMTP Services seems to be missing under the IIS pkg!?!?
Which way did it go?
[-] Print Services
[x] LPD Print Service
[x] LPR Port Monitor
[ ] Ras IpRip (YTBD: this might be the RIP protocol (e.g., gated)?)
[-] Services for NFS
[ ] Administrative Tools
[ ] Client for NFS
[x] Simple TCPIP services (i.e. echo, daytime etc)
[ ] SNMP feature
[x] Telnet Client
[x] Telnet Server
[ ] TFTP Client
Note: I added the Telnet Client and Telnet Server and it did not
prompt me for the installation dvd. YMMV with the other features.
When using Windows Vista Telnet Client to login to another
Windows box running Cygwin's telnetd you may need to use the
"-a" option or the login/password handshake may fail:
C:\> telnet -a squally
Password:
This attempts to log you in on the target (squally) as the user
you are currently on the source side (zephyr), but it does not
allow you to specify a different user login.
Configuring the Telnet Server on Windows Vista was a pain...
Next I had to figure out how to launch the Service Control
Manager GUI and set the Telnet Server to "autostart" and reboot.
Then I still could not get past the Firewall so I had to open
port 23 for telnet to have inbound access to the box. Finally,
you have to add all your users (or at least yourself) to the
TelnetClient group, which was not an intuitive thing to do BTW.
I finally found that the easiest way to figure out how to do it
was to go to Help and search for "TelnetClient group"
followed by "Add TelnetClient group". I was amazed when
I finally got it to work, and it worked as if I had a ~/.rhosts
file with ogin/sword pairs in it and were using rlogin instead!
If I was already the user 'winadmin' on hostA and telneted into
hostB it put me right into a CMD shell prompt w/o prompting
for the ogin/sword pair. But, what if I wanted to login as
a different user to hostB, huh? Behind the scenes authentication
must be taking place because I was already logged in on hostA
as _that_ user and once that user is added to the TelnetClient
group on hostB you are just good to go, it does save sending
clear text passwords over the wire, but still, it makes me
nervous to not be prompted for the usual ogin/sword pair, and
like I just said above: what if I want to login as a different
user? And, I know, I know, I should be using ssh instead but...
this was with the new OS - Windows Vista - and there are
no ssh's working yet because there is no Cygwin et.al. UN*X
environs working yet on that platform - so going back to ftp
and telnet was my only option. It just doesn't work/feel like
UN*X during the setup phase, nor even at the ogin/sword hand-
shake phase, and well, nor is CMD, bash either, for that matter.
Still for an old UN*X hand, a CMD shell via Window's weird telnet
is better than nothing to get you started using our HulaBats.
Oh, and there was also some "best practices" advice about adding
the 'chcp 1252' command to the "systemroot\system\login.cmd" file
but that file I found was actually, %SystemRoot%\System32\login.cmd
under Windows Vista. You might need to add this to support
"English and Western European UN*X" for computers "running an
internationalized version of UN*X". I have not yet determined
if this includes Cygwin or not.
To get an FTP Server running is even uglier than getting a Telnet
Server up and running. You have to install/configure IIS first,
and ???, then FTP Server. Because of the IIS wrapper there is a
lot more work involved. To learn about all this search Help for
"FTP services" which should lead you to topics like "Setting up
FTP sites" (at least it did on Windows Vista). You may need
to install all of IIS but only configure the subset you need to
get the FTP Server up and running. I am kind of vague on this
stuff because the Windows FTP and Telnet Server installation and
configuration is such a nightmare that once I have Cygwin installed
I usually just configure Cygwin and its inetd (e.g., inetd.conf) to
launch and run its versions of these two servers instead of the
Windows versions. However, since Cygwin is not released yet for
Vista - you/I may have no choice in the matter depending on what
you are up to.
Miscellaneous Topics
Color Terminals
---------------
GUI:
Upper left corner menu->Properties->Color tab->
(*) Screen Text
R: 255
G: 255
B: 0
This is "light yellow" (or gold).
Use this for all CMD shell foregrounds (fg) for fonts.
Gold was the font or foreground color of the old HP command-line
terminals. Studies have shown that this is the best combination
(gold on black) for tired, old eyes.
(*) Screen Text
R: 0
G: 255
B: 0
This is "light green".
Use this for all Cygwin bash (and rxvt) shell foregrounds (fg).
Green was the font or foreground color of the old Wyse command-line
terminals. Studies have shown that this is the 2nd best combination
(green on black) for tired, old eyes. The "light green" color blends
nicely with the ANSI default Cygwin prompt that uses plain "green" -
which is a bit darker.
(*) Screen Background
R: 0
G: 0
B: 0
This is "black".
Use this for all shell backgrounds (bg) with gold or green fonts (fg).
Command-line:
color /xy - sets bg and fg colors in CMD shell terminal windows:
color /0e = "black" bg, "light yellow" (or gold) fg
color /0a = "black" bg, "light green" fg
UN*X-like Alternatives You Can Get For Windows
We are reluctant to include this section because things
change so fast. You can google the Internet for current
information about these types of packages. We only add
them so it gives us a soapbox to stand on so that we can
relay our experiences and prejudices about some of them.
No book about UN*X/Linux on Windows is complete without
mentioning them. These are the biggies as we see them.
This may be a gross over-simplification but it appears that
in terms of full-blown UN*X work-alike systems for Windows
there seem to be, currently, mainly four: Cygwin, UWin,
SFU now SUA, and the various "MKS Toolkit for ..." (aka
NuTCRACKER) products. The Hamilton C Shell and the various
GnuWin32 products seem to be more specialized.
#-----------------------------------------------------
Cygwin - from RedHat, Inc.
http://www.cygwin.com
pros: Can access Win32 cuz it's built on top of it
which allows you to get to things like
gamer timers for faking nanosleep() while not
interrupting the BSD UN*X setitimer() callbacks.
Many things work in CMD shells if you
add C:\cygwin\bin to PATH
(ls!) although some things work only for one-liners.
Includes X11R6 server (new: Xorg; old: XFree86).
Has gcc or can use MinGW compiler for .exe's.
Will work even if your security police remove
the POSIX sub-system from Windows.
Provides Redhat Linux compatibility for developers.
cons: Loads a big DLL.
GNU copyleft style license(s).
Slower than SFU/SUA cuz its built on top of Win32.
Cannot have more than one version active, IOW
only one copy of the .dll can be loaded at a
time - this causes integration headaches like
when two different products have to go onto the
same machine but each needs a different version
of Cygwin to operate and may have a subset of
Cygwin already included in their product.
Had problems and did not work on Windows Vista,
but I believe that new versions have fixes for it.
Hamilton Csh - Hamilton C shell
http://www.hamiltonlabs.com/
(Located in the Bellevue-Redmond-Kirkland triangle.)
Does this work on Windows Vista?
Got email out of the blue from the author, Nicole Hamilton,
who has assured us it does work -- for both the Vista
32-bit and 64-bit versions -- and that it has been recently
updated (as of my writing this 2009.08.06). Hopefully, it will
work on Windows 7, as well? Ah, the times move on...
MKS - Mortis Kern Systems, Inc.
http://www.mks.com
Did this used to be called MKS Trilogy?
See Also: NutCracker 4 below
NuTCRACKER - from DataFocus
http://www.datafocus.com
See Also: NutCracker 4 below
NuTCRACKER 4 - now known as MKS Toolkit for Enterprise Developers
http://www.mkssoftware.com/
Dunno much about these alternative products, anyone?
From this site: http://www.scl.com/products/mks
it appears that there are several product offerings
with different forms of the name "MKS Toolkit for ...".
The above two products perhaps evolved into these?
They support both 32-bit and 64-bit architectures.
Do these products work on Windows Vista? Windows 7?
pros: both MKS and the NuTCRACKER products
have been around the block for quite some time.
They have an X11R6 server product, too.
cons: Costs you $$$.
SFU/SUA - Interix (from Softway Systems), Interop, Microsoft
http://www.interix.com
pros: Add C:\SFU\common tools to PATH for CMD shells.
v3.5.x is now free.
You can use X11R6 server in Cygwin for free.
Has gcc or can map cc to uSoft compilers.
Faster than Cygwin cuz its built on top of HAL.
It has its own POSIX sub-system.
cons: Extra tools from Interop cost $$$.
Hummingbird or other X11R6 Server cost $$$, but
you can use the "free" Cygwin X server with it.
Cannot or not easy to access Win32 like in Cygwin.
Have had trouble using C:\SFU\common\ls.exe on
Win2k3Srvr under JUNCTIONS from CMD shells.
For ksh to be usable you have to disable beep.sys.
Dunno if this works if POSIX is locked down
because of DoD Security policies, but doubt it,
so may not work if your security police remove
or lock you out of all POSIX runtime executables.
SFU 3.5.x does not work on Windows Vista.
Keeps getting renamed so it is hard to track it
and be loyal to the product (like you can with
Cygwin or UWIN which haven't been renamed along
the way) -- this also indicates some screwy
Marketing department has too much "say" in it --
renaming also may cause future integration
headaches if you have products with pathnames
pointing to the locations of its files and
directories and expect them to remain there.
notes: SFU is renamed SUA and supposedly will be native
on Windows Vista/Longhorn Server editions but
not on the Ultimate or less functional versions.
Actually, it turns out that only the core comes
with them natively, but you have to use Add/
Remove Programs to add it as an extra Component.
Then you still have to download/install the rest
of it to get a usable, more complete installation.
UWin - Dave Korn, AT&T Research, and WiPro from India
http://www.research.att.com/sw/tools/uwin/
pros: Has the very best ksh (thanx to Dave)!
Has gcc or you can map cc to many other compilers.
May have the purest AT&T UN*X IPC emulation?
Site says most "of the UNIX API is implemented by
the POSIX.DLL", but that programs "linked with
POSIX.DLL run under the WIN32 subsystem instead
of the POSIX subsystem, so programs can freely
intermix UNIX and WIN32 library calls".
cons: Costs you $$$.
Loads a big POSIX.DLL dynamically.
Dunno if this works if POSIX.DLL is locked down
because of DoD Security policies, but doubt it,
so may not work if your security police remove
or lock you out of all POSIX runtime executables.
Does this work on Windows Vista? Windows 7?
GnuWin32 - GNU and the Open Source community
http://unxutils.sourceforge.net/
http://gnuwin32.sourceforge.net/
http://mingwrep.sourceforge.net/
pros: Works from CMD terminal shell command lines.
Gnu's Not UN*X (does that mean it's better?).
Free but with GNU copyleft style license(s).
Very useful for providing UN*X tools that can be
used during hands-off customized Windows installs.
cons: GNU copyleft style license(s).
Last time I checked it did not fit in with Vista.
Have the Vista kinks been worked out yet?
To me project(s?) is too scattered, unlike say
Cygwin which is all in one location, a busy
person has to read so many different things
for clues as how best to proceed for an install
and what exactly is needed.
#-----------------------------------------------------
Free C/C++/C#/Java/J# Compilers you can get for Windows
Again, the big CAVEAT about anything based on the web.
Things may not be found at the same place they were
when we edited this section. So, YMMV, and Google
and Yahoo are your friends...
#-----------------------------------------------------
A good starting point for searches for Free C/C++ Compilers is here:
http://www.thefreecountry.com/compilers/cpp.shtml
Borland's BCC55
OLD: http://www.borland.com/products/downloads/download_cbuilder.html
LAST KNOWN LOCATION: http://cc.embarcadero.com/Free.aspx?id=24778
- get the Version 5.5 Compiler and Turbo Debugger
for the Windows Platform.
- not the fastest, bestest resultant .exe's but we do find
this to be the easiest to use to build source code that
was originally written for different UN*X platforms.
Also, you can build 'dmake' (needed to build 'Perl') with it,
and you can build 'Perl' itself with it.
- this works on Windows Vista BTW.
gcc + MinGW in Cygwin
http://www.cygwin.com/
- this did not work on Windows Vista last time I checked.
- does this work on Windows 7?
gcc in SFU/SUA
http://www.interix.com/
- this may not work on Windows Vista, does it?
- does this work on Windows 7?
gcc in UWin
http://www.research.att.com/sw/tools/uwin
- this may not work on Windows Vista, does it?
- does this work on Windows 7?
jdk1.[4,5,6].x_xx - from Sun Microsystem's JavaSoft division.
http://java.sun.com
- needed the 1.6.x.x early release or later for Windows Vista.
- heard the 1.5.x.x series was eventually patched for Windows Vista.
Microsoft's .NET Framework (C/C++/C#/J#)
http://msdn.microsoft.com/netframework/downloads/updates/default.aspx
but, the last time we went there it redirected us to:
http://msdn2.microsoft.com/en-us/netframework/aa731542.aspx
You will also need the PlatformSDK which is freely downloadable
for the include files like "windows.h".
Microsoft's C/C++ Compilers in one of the free packages (C/C++)
http://msdn.microsoft.com/vstudio/express/visualC/default.aspx
You may also need the PlatformSDK which is freely downloadable
for the include files like "windows.h".
MinGW standalone gcc
http://www.mingw.org
- Has installation issues - kind of
difficult to install.
- Is this still being updated? -- cuz it
did not work on Windows Vista the last time I checked.
- We wonder if this works under Windows 7?
Walter Bright's C/C++ Compiler (comes with D, too?)
http://www.digitalmars.com
- Used to be Zortech C/C++, Symantec C++, &c &c &c
- Does this work under Windows Vista? Windows 7?
- Look at their DMDScript for a faster ECMA 262 v3 implementation
(aka JavaScript, JScript).
Watcom
http://www.openwatcom.org
- We wonder if this works under Windows Vista? Windows 7?
#-----------------------------------------------------
Free C/C++/Java Compilers for WindowsCE/PocketPC
Programming for the PocketPC is another world entirely.
This section discusses some of the "free" or nearly so
compilers/interpreters to assist you in that endeavor.
#-----------------------------------------------------
PocketGCC - this is the gcc that we use now - from Vitaliy Pronkin
for the ARM/XScale processor (pgcc v1.5, gcc 3.2.2).
Pros: nice cuz you can compile right on the PDA itself.
Cons: a gcc.bat wrapper does not come with it.
a newer gcc - also, from russia with love???
Pros: it has a gcc.bat wrapper, supposedly, but, ...
Cons: dunno where to get it, cannot find it via Google.
PersonalJava - but Sun no longer supports this, unfortunately
Pros: free - if you can find it on the web somewhere.
Cons: you have to compile .class files on a Solaris,
Linux or Windows box and copy them to your PDA to
build an app. Pre 1.2 Java (I use 1.1.8 on Solaris 8
to build our apps for it). No Swing support, only AWT.
Sun dropped it, no longer supported.
gcc cross-compiler for ARM from Debian Linux ???
Pros: you can compile on a pc instead of the pda.
Cons: you have to compile on a pc instead of the pda.
Microsoft eMbedded C/C++ compiler (some say this is free but we could
not get the "free" one to work)
Pros: has a studio type of IDE you may be familiar with.
has emulators for different PDA platforms to test on.
supports chipsets other than the ARM/Xscale
Cons: have to install a lot of u$oft baggage for it to work.
See Also: our manual build script tree and
crt0 main() pre-processor workarounds.
#-----------------------------------------------------
.bat commands and PocketCMD under WindowsCE/PocketPC
Another separate section in the book should be
devoted to scripting .bat files and other useful
tools for UN*X geeks hacking with PocketCMD.
Like what PocketCMDs are out there anyway and where?
What are their pros/cons? How do they compare to CMD?
#-----------------------------------------------------
cat.bat
clear.bat
cp.bat
ls.bat
mv.bat
rm.bat
pg.bat + pg.exe
edit.bat + edit.class
view.bat + view.class
#-----------------------------------------------------
NOTE: I finally gave up on PocketPC -- it is just too braindead.
The fatal flaw is the limited battery life and its propensity
for wiping out everything that you have installed when it reloads
the base operating system from backup ROM when the battery dies
and you forget to recharge it in time. That and the way HP
mounts the SD and CF drives with embedded spaces in the mount
point pathname. And, that CMD does not come installed natively.
And, that the CMDs you can get and load do not grok spaces in
the SD and CF drive pathnames and parse them correctly into the
%1, %2, ... %9 position parameters. And, that PocketWord will
not let you put your own filename .ext(ensions) such as .bat on
whatever it is you are editing when you save it. And, that
there is no easy free way to get an updated version of Java
so you can have an alternate workaround for u$oft's idiodicies.
Basically, just too many imbecilic things to try to workaround
and to monitor to be worth it. I did like its alarm clock when
we were out camping, and my wife used the calculator sometimes.
I simplified my life -- bought an alumimum macbook pro and an iPhone.
Now I can dual boot Leopard (my preferred UN*X platform these days),
and Vista for maintaining HulaBats and doing genealogy with FTM,
with BootCamp. I am as happy as the proverbial UN*X clam in sea
water. Additionally, iNavX and AyeTides is awesome on the iPhone
when Location Services are turned on for a portable backup to
our old sailboat's aging Garman chart plotter. Now if I could
just figure out how to set it up as an anchor alarm...
Redistributables (stuff it is legal to redistribute)
Since it is not advisable that we redistribute these things
instead we will try to include URLs to where they might be
found on the Internet. Otherwise, as always, Google
and Yahoo are your best friends.
Python
#-----------------------------------------------------
Python for Microsoft Windows
See "ActiveState Python" just below.
ActiveState Python
Location of ActiveState Python products ...
* http://ftp.activestate.com/ActivePython/
which redirects you to ...
* http://downloads.activestate.com/ActivePython/
Then drill down to the "windows" folder from there.
#-----------------------------------------------------
Perl
#-----------------------------------------------------
Perl with LibWin32
See "ActiveState Perl with LibWin32" just below.
ActiveState Perl with LibWin32
Location of ActiveState Perl products ...
* http://ftp.activestate.com/ActivePerl/
* http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl
There are some scripts in Micrsoft's Support Tools that require specific
version(s) of ActiveState Perl.
Perl in Cygwin
Location of Cygwin products ...
http://www.cygwin.com/
Perl in SFU/SUA
#-----------------------------------------------------
Java
#-----------------------------------------------------
Sun's Java JRE GoTo URL: http://java.sun.com/
Sun's Java SDK (for jar.exe especially) GoTo URL: http://java.sun.com/
Sun's PersonalJava for PocketPC - it is not legal to redistribute this.
See J# section below.
#-----------------------------------------------------
C/C++
#-----------------------------------------------------
Borland dll library in the free Borland C++ Compiler
#----------------------------------------------------- C#, J# .NET Framework #----------------------------------------------------- Microsoft .NET Framework and SDK Microsoft J# redistributable #-----------------------------------------------------
ToDo List
Here is a working to do list, todo... #----------------------------------------------------- cksum/sum - we need a crc getter like Josh's sum.java, look at l5/l6, Perl cksum. env.cmd - enhance to use 'setx.exe' to set global environ variables and, also, launch applications with a modified environ. find.cmd - enhance the UN*X find subset emulation using the MsResKit where.exe and options like isdir, fsize. fdata, ftime in forfiles.exe, too. E.g., -size +99999 for a hogs implementaion, and a -newer option, and maybe even a -older option. fuser.cmd - see if we can use findstr instead of grep.exe for this? This is broken under Windows Vista BTW! get/setfacl.cmd - try to emulate these Cygwin commands with (x)cacls.exe NOTE: xcacls.exe is unreliable on w2k3r2 -- DO NOT USE IT! NOTE: Vista has a new cacls.exe called icacls.exe -- MUCH MO BETTA. Also, icacls is available on w2k3r2. head.cmd - the -# option does not check if # is a number and blindly passes the # value off to 'ed' - look at how the newer tail.cmd does it using 'set' environ variable expansion where it first checks if the first digit of # is a number betwee 1-9 before actually grabbing the whole # to use. The way head.cmd does it may be faster than the way it is done in tail.cmd - a time test would be nice to do as well. At any rate, you can at least do some validation if you use the tail.cmd way instead of the head.cmd way. This code is needed for man.cmd for its -# option, too. Look at getargv.cmd as well - it is a command line parser test script we played around with for tail.cmd testing. ifconfig.cmd - in ok shape read-only-wise, but it does not configure yet! We might be able to call into some .js (or .vbs) script to also configure network stuff? How? Using DMTF's WBEM/CIM? Could be an entrance into a section on .js programming to challenge the .vbs hackers? man.cmd - see -# parsing discussion in head.cmd, tail.cmd and getargv.cmd tail.cmd - the -f option does not work yet, now it execs tail.exe to do it tar.cmd - might be able to do a tar.cmd wrapper around 'pax'? and/or cpio.cmd? E:\home\cal\bin>which pax c:\winnt\system32\pax.exe E:\home\cal\bin>pax /? The system cannot find the file C:\WINNT\System32\pax.exe. Optionally, use the Java tar code example to build a nice tar command in Java instead. Personally, we use jar.exe and pkzip25.exe and .zip files instead of .tar.gz bundles these days cuz jar.exe is everywhere we go, practically. time.cmd - look at using 'timeit.exe' to evaluate how long a command runs w.cmd - enhance to possibly include some data from 'tty.cmd' &c. wc.cmd - the -w word count option does not work yet, speed up -c (see fsize.cmd) yes.cmd - add a timer-delay-to-start option for use with: pause < yes -t 5 ftruncate/truncate - NOTE: cat.cmd now takes "/dev/null" as an arg to zero out existing files. tline - There is a MsResKit tool that works like this though (choice.exe?) and you can use 'set /P "Enter a command:" for one line prompts. chown.cmd - Vista has the new icacls.exe which may facilitate this? matchacl.cmd - I have a Cygwin bash script that uses get/setfacl to do this, but I would like a native .cmd script to be able to match the ACLs of a newly created directory to another extant directory sort of like how you can specify a touchfile with the UN*X "touch" command to match the date-time-stamp(s) to; must work recursively. #-----------------------------------------------------
This section is specific to Windows Vista issues and anomalies...
Some commands we use in the MsResKit are now native in Vista. Examples are: where.exe, shutdown.exe,... #----------------------------------------------------- fuser.cmd - oh.exe is now openfile.exe which broke our fuser script ls.cmd - ls.cmd had some Vista issues (see also: ls_vista_fix.cmd) reboot.cmd - this had some Vista issues (see also: reboot_vista_fix.cmd) shutdown.cmd - this had some Vista issues (see also: shutdown_vista_fix.cmd) #-----------------------------------------------------
NEW: a new special section for Windows 7 issues and anomalies...
Unfortunately, we have been too busy learning Python and starting a Python version of HulaBats, and working on other things like our genealogy research and family history web pages to actually load Windows 7 Beta and try out our code on it. Will do so as soon as time allows.
Disclaimer: on the street talk terminology...
References to Microsoft products are not written out in the formal way with all the registered trademark ® or copyright © marks after them and their full names are rarely used. Many products have "handles" such as "MsResKit", "SupTools" and are used instead of their full product names (e.g., Microsoft Resource Kit, Support Tools). Programmers, the intended audience for this stuff, will usually know what is meant. But, here are some translations for the abnormally braindead among you... uSoft = refers to the company: Microsoft® (stock ticker: MSFT) u$oft = refers to the monopoly: Microsoft® (stock ticker: MSFT) Windows = refers to Microsoft® Windows® (not the X11 Window (singular) system) Windoze = refers to Microsoft® Windows® (yawn) 2k = refers to Microsoft® Windows® 2000 Professional w2k = refers to Microsoft® Windows® 2000 Professional w2kpro = refers to Microsoft® Windows® 2000 Professional w2ksrv = refers to Microsoft® Windows® 2000 Server w32 = refers to Microsoft® Windows® Win32 API library XP = refers to Microsoft® Windows® XP Professional XPpro = refers to Microsoft® Windows® XP Professional 2k3srv = refers to Microsoft® Windows® Server® 2003 sp1 Win2k3Srvr = refers to Microsoft® Windows® Server® 2003 sp1 w2k3r2 = refers to Microsoft® Windows® Server® 2003 R2 Vista = refers to Microsoft® Windows® Vista Longhorn = refers to Microsoft® Windows® Server 2008 w7 = refers to Microsoft® Windows® version 7 (the Vista follow-on) Windows 7 = refers to Microsoft® Windows® version 7 (the Vista follow-on) WindowsCE = Windows® Compact Edition for PDAs. PocketPC = Windows CE Pocket PC v4.2 and above for PDAs. We still probably did _not_ get all the "®" strings in the correct places! Similarly, you can tell we have been around a while, because UNIX® is such a pain to write that programmers like us usually just use this instead: UN*X = which refers to UNIX® systems in general, both the license encumbered versions and the "free" ones. Linux® is either a trademark or a registered trademark of Linus Torvalds in the U.S and other countries. So, when you see "Linux" please translate that to "Linux®" in your head, ok? Linux = refers to the Linux® operating system (in all of its incantations) You know, the one with the the Penguin "Tux" icon? Solaris® is a registered trademark of Sun Microsystems, Inc., although the operating system itself has recently been "open sourced"... OpenSolaris - GoTo URL: http://www.opensolaris.org/ Solaris = refers to the Sun Solaris® operating system Solaris - GoTo URL: http://www.sun.com/ Java = refers to Sun's Java Software Development Kit (JDK or SDK) Java - GoTo URL: http://java.sun.com/ BSD = refers to the University of California Berkeley's Berkeley UN*X Software Distribution, aka all BSD UN*X operating systems in general. Three examples of BSD systems for Intel and AMD devices are: FreeBSD - GoTo URL: http://www.freebsd.org/ NetBSD - GoTo URL: http://www.netbsd.org/ OpenBSD - GoTo URL: http://www.openbsd.org/ Cygwin = refers to the RedHat® Cygwin® project (GNU + Cygnus + Windows) and its releases of software. Cygwin - GoTo URL: http://www.cygwin.com/ Anyway, if you are a lawyer representing one of these august institutions in our industry and you are miffed about our terminology just send us email and we will be happy to fix whatever verbiage is bugging you. We surely don't intend on slighting anyone by the street talk, and we cannot afford a lawyer to deal with your idiosyncracies.
Solaris®,Sun®, and SunOS® are either trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
Linux® is either a trademark or a registered trademark of Linus Torvalds in the U.S. and other countries.
Windows® is either a trademark or a registered trademark of Microsoft in the U.S. and other countries.
Google® is either a trademark or a registered trademark of Google in the U.S. and other countries.
Yahoo® is either a trademark or a registered trademark of Yahoo in the U.S. and other countries.