Batch files (remember your old DOS days?) were originally designed to enable us to run a series of DOS commands to perform a task. Windows 95 came along and the functionality of batch files as we knew them pretty much went away because (1) they were generally used for file management and (2) file management is now done with Windows Explorer or something similar. It's not that batch files no longer work - they do - but long filenames and paths can make things a bit unwieldy.

What I'm presenting here is a method to easily launch multiple applications by running a single batch file. Sounds like pretty standard stuff, but there's a twist that you might not be expecting. I'm not launching the applications, but their associated documents.

I track my mileage and travel expenses using an Excel spreadsheet. I calculate the miles using a template in MS Streets & Trips. My schedule resides in the Palm Desktop. All of these items have shortcuts. The Excel sheet has a shortcut to the sheet, the Streets shortcut points to a template, and the Palm shortcut points to PALM.EXE. There are two things to consider here; all these items are shortcuts with the .LNK extension and .LNK files are executable.

As you've surmised, I created a batch file that launches the shortcuts. Works great and is a good click saver. There are some caveats to keep in mind if you try this.

• Because we are usually dealing with long paths and long filenames, the commandline must be enclosed with double quotes.
  
• Because it's a batch file, there is a max commandline length of 127 characters, so be careful here.
  
• Because we are dealing with a file system that understands mixed case, it's a good idea to match the case of your commandline to that in your file system. You can easily copy & paste much of your commandlines from Windows Explorer using the address bar. I have not tested incorrect case to see if I can break the batch file, but the possibility exists because the double quotes allow us to specify mixed case and long filenames in a character mode environment.

Here's a copy of the mileage tracking batch file I described above:

=================================================

@echo off
"C:\Documents and Settings\Ken\Desktop\Palm Desktop.lnk"
"C:\Documents and Settings\Ken\Desktop\Documents\Streets.lnk"
"C:\Documents and Settings\Ken\Desktop\Documents\Current Mileage.lnk"
exit

=================================================

You can drop the batch file pretty much anywhere on the local system (your machine - not a network drive) where you have full access. Then create a shortcut to this batch file and have the shortcut run it minimized and close on exit.

This launches all three tools that I use to calculate and track my mileage. All I do is cool-key (Alt-Tab) from one to another as needed.

Pretty simple stuff, and handy as well. Create your own little beastie in any text editor and give it a go.

And from the Secure Computing Department, AKA you don't know what you don't know, comes this.

I recently had the opportunity to build my first Microsoft Windows 2003 Server, and it turned into a bit of an education.  A rather surprising and time consuming one at that.

When a share is created with Windows NT4 and Windows 2000 servers, permissions on the share (as opposed to file or directory permissions) are such that the share simply works.  The defaults are Full Control, Change, and Read set to on.  Not particularly secure with the Full Control thing set, but quite workable for a small business.  Turning Full Contol off is okay if need be.  Along comes 2003 Server, and in the name of greater security for the file system, Microsoft defaults to only Read being on.  Sounds great on the surface.  Until you try to manipulate any files or folders under that share.

Details:  The server in question was destined to replace a venerable (and aging) NetWare 3.12 server, which was out of room, out of gas, and out of usability for modern applications.  I transferred all the user data without a hitch, set appropriate file/folder permissions, had all the scripting nailed down, and started to bring the workstations into the domain.  Everything was going swimmingly until we tried to do anything with the data.  Screech!  "Access Denied" messages all over the place anytime we tried to manipulate data.  Even when logged onto the machine as the domain administrator!

I verified (many times over) that the permissions were set correctly at both the file and folder level.  No help here.  I searched the MS Knowledge Base, and got no helpful hits.  Google turned up zero.  So I cringed, got out the VISA, and called in a support incident.  After a rather chilly woman took my credit card info, I got shuffled to a few friendly folks and found that there was no clear category for my issue.  So they threw me off to Active Directory Support.  When Ted in Charlotte picked up, I went through the gruesome details and he asked if the share permissions were still at the defaults.  When I said that they were, he directed me to turn Change on.  It works!  Yea!  2 hours later!

Ted said that this change to the defaults was made to make the server more secure, and it's hard to argue this.  If you can't do anything to your data, it's a whole lot more secure than if you have the ability to thoroughly trash it.  Sigh...  Ted was almost apologetic, probably because he could sense my frustration at having thrown $245 at a mouse click for which I could find no documentation.  Ted, however, was a genuinely stand-up guy and refunded the charge, for which I am grateful.

Thanks, Ted!  You done good!  I think I'm gonna remember this one...

KBC
Home

Who is this
Ken guy?!

Services
Offered

Contact
Information