bird@kksys.UUCP (Mike Bird) (10/17/88)
BEWARE: When you change the command line switch on COMMAND.COM, there are quite a few products that no longer will work. Let me (try) to explain what I'm talking about: A friend gave me the executable of switchar. This will take any character specified on the command line and change the command line switch to that character. Since MeSsy-DOS can handle paths specified with either a '/' or an '\', and it is COMMAND.COM itself which specified that '/' is a command line switch, I am now able to use paths with a '/' an stop getting confused between UNIX and MS-DOS. However, I discovered several problems. This led me to believe that something was being screwed up by the switchar program. Another friend of mine used to work for a company (now defunct) who was a licensed MicroSoft OEM. He still had the OEM book from MS. In it, there is documented a MSDOS function x'37' subfunction 01. I created a TP4.0 program to use this function, and it worked identically to the switchar program. Identically in every respect. Same problems. So, I conclude that the problems are in the products I'm using, and not in the programs which switch. Here are some examples of the problems I'm having: I have a LOGITECH 3-button serial mouse (great mouse!). It came with software to simulate keystrokes. This allows me to use the mouse with programs which do not communicate with the mouse directly. You have to "program" the mouse for each emulation. It also included a program (called CLICK) to automatically load the emulator with the proper program based upon the command line or batch file entry. This makes the re-programming of the mouse transparent to the user and is a wonderful help. However, CLICK refuses to work when the command line character is switched off of '/'. Switching it back lets it work again. I called LogiTech's technical support line, and was informed that function x'37' is a reserved function, so they won't support their programs if I'm playing with reserved functions. Apparently, the DOS technical reference manual doesn't document function x'37' while the OEM manual does. Another program I have problems with is one I got from PC magazine. It's called SWEEP, and it will duplicate a command on your current directory and all sub-directories of your current directory. It's a great way to get rid of .BAK files just before doing a full-disk backup. Anyway, when it tries to do it's thing (I think it EXECs the command). I get the DOS prompt and I'm in an environment where NO environment variables were copied from the parent. The prompt is the default, no path exists, etc. When I EXIT back, I get this repeated for all sub-directories as well. Changing the command line switch character back to '/' clears the problem up. So, as I say, be careful when you switch the command line switch character. Some of your most cherished utilities may refuse to work. -- ================================================================================ Mike Bird (These opinions are mine, dammit!) Mail paths: bird@kksys.kksys.mn.org You can't call ME books! -or- claudius@kksys.kksys.mn.org!bird Void where prohibited by law. -or- ...rutgers!bungia!kksys!bird
bell@ocsmd.OCS.COM (John T. Bell) (10/17/88)
In article <824@kksys.UUCP> bird@kksys.UUCP (Mike Bird) writes: > >BEWARE: When you change the command line switch on COMMAND.COM, there are >quite a few products that no longer will work. I have found that any aplication linked with the Phoenix Linker (plink) has problems if switchar is changed. This includes all clipper compiled dbase programs. Also WordStar, and PibTerm have problems whenever a new shell is invoked. I suspect that the PibTerm problem may indicate that any thing compiled with T*rboPascal may break. John T. Bell My word's only, etc...
tittle@alexandre-dumas.ics.uci.edu (Cindy Tittle) (10/18/88)
In article <824@kksys.UUCP> bird@kksys.UUCP (Mike Bird) writes:
*
*BEWARE: When you change the command line switch on COMMAND.COM, there are
*quite a few products that no longer will work. Let me (try) to explain what
*I'm talking about:
I believe the documentation for switchar warns about this possibility.
Like you said, it has to do with the lack of documentation about
the switch character -- there are programs which hardwire the '/' character
in, rather than taking it from the environment set up.
When I installed it, I found that I had to install pctools first (as a tsr),
*then* I could switch the character. Otherwise I haven't run into any
problems. (But then I don't use many different programs.)
Cheers,
--Cindy
--
Sooner or later, the worst | ARPA: tittle@ics.uci.edu
possible set of circumstances | Cindy UUCP: {sdcsvax|ucbvax}!ucivax!tittle
is bound to occur... | Tittle BITNET: cltittle@uci.bitnetwsd@whuts.UUCP (DINSMORE) (10/18/88)
In article <170@ocsmd.OCS.COM> bell@ocsmd.OCS.COM (John T. Bell) writes: >In article <824@kksys.UUCP> bird@kksys.UUCP (Mike Bird) writes: >> >>BEWARE: When you change the command line switch on COMMAND.COM, there are >>quite a few products that no longer will work. > I have found that using a menu system with the MKS toolkit works very well. I currently use setup 4 which invokes login. When I need to run programs that use hard-coded info I invoke a DOS shell via login with the command to run the menu(ie: command -c menu). This allows for all the individual setups required for a particular application. For example, I use the Galaxy word processor with the Turbo Lightning spell checker. By way of the menu the spell checker is installed, then Galaxy is invoked, and then I do my work. When I exit though, the spell checker is uninstalled and I am back in the menu, ready for another application. When I finally exit the menu system, I go directly to login again. This menuing scheme also worked quite well under DOS only shells as well (ie: no MKS toolkit). The menu system I currently use is AUTOMENU. The moral here is: If you have to do something special to get an application to work, let the menu handle it so you don't have to remember complicated sequences. By the way, the MKS toolkit will allow the use of either '\' or '/' in a path. I always use '\' because DOS shells can now be properly initialized. Good luck on customizing your PC! -- | Wayne S. Dinsmore Make it in Massachusetts, | AT&T Bell Labs (att,moss)!whuts!wsd Spend it in New Hampshire. | 20 Shattuck Road Room 4A-118 | Andover,Mass 01810
toma@tekgvs.GVS.TEK.COM (Tom Almy) (10/19/88)
In article <824@kksys.UUCP> bird@kksys.UUCP (Mike Bird) writes: > >BEWARE: When you change the command line switch on COMMAND.COM, there are >quite a few products that no longer will work. Some more non-working programs when switch char is changed: Windows 386 WordPerfect 5.0 (n4.2 understands switch char) system() in Microsoft "C" (possibly others as well) About 50% of the programs I have with shell escape commands do not work with switch char changed because they have wired in to exec "command /c". In fact there seems to be an increasing number of programs that don't support switch char any more. I have ended up dropping the changed switch character. Maybe what is needed is to make UN*X more MSDOS like rather than the other way around. Why can't I change the file name delimiter character from '/' to '\' in UN*X? Tom Almy toma@tekgvs.TEK.COM Standard Disclaimers Apply
markd@proxftl.UUCP (Mark Davidson) (10/20/88)
In article <824@kksys.UUCP> bird@kksys.UUCP (Mike Bird) writes: > >BEWARE: When you change the command line switch on COMMAND.COM, there are >quite a few products that no longer will work. Alas, this is too true. If you purchase the MKS Toolkit (highly recommended for Unix(R) fans), and you use the Korn shell supplied with it, you find out exactly what programs don't handle this correctly. The documentation supplied with the toolkit is kind enough to point some of these out. For example, since the Korn shell sets your path separator to / and uses - as an option switch, Microsoft C has problems because you would naturally use /'s in your environment variables (PATH, LIB, INCLUDE), right? You have to change this back in your shell setup scripts, as Microsoft C can't handle forward slashes in these variables. Fortunately, the shell itself has no problem with this, so you can just set these variables up in a special manner and use - to specify compiler options. It's a bit of a pain though, because the compiler doesn't tell you this is the problem; it just fails in the middle of the compile process (I believe with either an internal or an unknown error). Sigh. -- In real life: Mark E. Davidson uflorida!novavax!proxftl!markd Proximity Technology Inc., 3511 NE 22nd Ave, Ft. Lauderdale FL, 33308 #define STANDARD_DISCLAIMER <Quote construction site>
jackm@jpl-devvax.JPL.NASA.GOV (Jack Morrison) (10/20/88)
>BEWARE: When you change the command line switch on COMMAND.COM, there are >quite a few products that no longer will work. As this point gets mentioned over and over, I'd like to humbly point out an alternative that seems to work well: modify the command line editor to translate / to \ and vice-versa (see -x option of UNCLE on simtel20). -- Jack C. Morrison, Jet Propulsion Laboratory "How am I typing? Call 1-818-354-1431, or mail jackm@jpl-devvax.jpl.nasa.gov"
hartung@amos.ling.ucsd.edu (Jeff Hartung) (10/21/88)
>In article <824@kksys.UUCP> bird@kksys.UUCP (Mike Bird) writes: >> >>BEWARE: When you change the command line switch on COMMAND.COM, there are >>quite a few products that no longer will work. > In article <930@proxftl.UUCP> markd@proxftl.UUCP (Mark Davidson) writes: > >Alas, this is too true. If you purchase the MKS Toolkit (highly recommended >for Unix(R) fans), and you use the Korn shell supplied with it, you find out >exactly what programs don't handle this correctly. The documentation supplied >with the toolkit is kind enough to point some of these out. After finding out which programs don't like using "/" as a path separator and "-" as an option character, I make a batch file for those programs that uses the MKS Toolkit command "switch" (which is what changes the option character in the first place in the AUTOEXEC.BAT file) to change the option character back to "/" before executing the command, then again to change it back after execution is completed. Clumsy, but it works. I usually give the batch file a different name and then alias it using MKS Toolkit's alias command in AUTOEXEC.BAT to the actual .EXE file it is to represent. AS for the Korn shell, I'm not really all that impressed with it. Yes, it does resemble a Bourne shell, but I don't find the occasion to use it all that often and the Korn shell itself seems to have problems with some programs that work fine with COMMAND.COM as the command interpreter. However, I may be prejudiced as I tried this early in my experimenting with the MKS Toolkit and may have learned how to deal with those problems by now. The most disappointing feature was the login shell which I really wanted to work like a U*IX login shell, but which offered no file protection for individual users at all and seemed to be mostly a pain in the a**. Sure, it might limit access somewhat, but it didn't seem to be worth the effort just to give different users a home directory and option of using "sh" vs COMMAND.COM. When I want to use the Korn shell, I run it from COMMAND.COM as a subshell. --Jeff Hartung-- Disclaimer: "Nobody here really cares what I think anyhow." ARPA - hartung@amos.ling.ucsd.edu UUCP - !ucsd!ling!amos!hartung (I think! Just got this account recently.)
simon@ms.uky.edu (Simon Gales) (10/26/88)
The reason programs have problems with altered switch characters is not
really complicated. When an internal DOS command is invoked from within
the program (like 'dir'), the program spawns off a copy of command.com
and makes it perform the command ('dir').
In MS C:
system("command.com /c dir");
This is supposed to run a command.com and make it do a dir.
The normal switchar is '/' so the programmer naturally used '/'
to access the '/c' option of command.com.
When the above 'system(" ... ")' is done with the switch char
changed, command.com does not understand the '/c' anymore, so
it returns an error instead of performing the command.
The same happens in many other languages, since the string passed to
DOS ("command.com /c dir") is usually just typed in directly; rather
than going to the trouble of finding out the current switch character
and building the string correctly.
It may be possible to edit the .exe/.com file, find these strings and
change the '/' to a '-' or whatever. I've never tried this, but Norton
utilities would probably make it easy.
--
<-------------------------------------------------------------------------->
<--- Simon Gales@University of Ky 254-9387/257-3597 --->
<--- [ simon@ms.uky.edu ] | [ simon@UKMA.BITNET ] --->
<-------------------------------------------------------------------------->simon@ms.uky.edu (Simon Gales) (11/29/88)
In article <826@kksys.UUCP> bird@kksys.UUCP (Mike Bird) writes: >In article <170@ocsmd.OCS.COM>, bell@ocsmd.OCS.COM (John T. Bell) writes: >> ... Also WordStar, and PibTerm have problems >> whenever a new shell is invoked. I suspect that the PibTerm problem >> may indicate that any thing compiled with T*rboPascal may break. >> John T. Bell > >I have used TP 4.0 under the switched character, and it works fine and >dandy. Also, applications I've written parses the command line just fine. > >I don't know (yet) about TP 5.0, TC 2.0 or TASM 1.0, but they're on >order... The problem is not inherent to the language, but to how the program is coded. One technique of running a sub-process is by calling command.com and letting it find the program (using the PATH) and run it. In MS C, this can be done by: system("command.com /c progname"); Note that a '/c' is used, without checking to see if '/' is actually the switch character. This can be changed to '-c' if you have access to the application's source (I have pibterm's if you want it). This is done slightly differently in TP, but I believe that it's similar. <--------------------------------------------------------------------------> <--- Simon Gales@University of Ky 263-2285/257-3597 ---> <--- [ simon@ms.uky.edu ] | [ simon@UKMA.BITNET ] ---> <--------------------------------------------------------------------------> -- <--------------------------------------------------------------------------> <--- Simon Gales@University of Ky 263-2285/257-3597 ---> <--- [ simon@ms.uky.edu ] | [ simon@UKMA.BITNET ] ---> <-------------------------------------------------------------------------->
jls@killer.DALLAS.TX.US (Jerome Schneider) (11/29/88)
In article <10629@s.ms.uky.edu>, simon@ms.uky.edu (Simon Gales) writes: > In article <826@kksys.UUCP> bird@kksys.UUCP (Mike Bird) writes: > >In article <170@ocsmd.OCS.COM>, bell@ocsmd.OCS.COM (John T. Bell) writes: > ....... > > In MS C, this can be done by: > system("command.com /c progname"); > > Note that a '/c' is used, without checking to see if '/' is actually the > switch character. This can be changed to '-c' if you have access to the > application's source (I have pibterm's if you want it). This is done > slightly differently in TP, but I believe that it's similar. > I posted a message with a patch to command.com for permanently setting either the / or - as valid switch chars within command.com. Thus, when any program uses the system() call, the /c works even if switchar is -. The patch was in a message detailing several MKS ppatches (but was very long - 400 lines). I could post a quick summary or email you the patch if you wish. The "Specified COMMAND search path bad" error results because command.com doesn't see the -c as an option flag, and thus treats it like a new path to cofigure the COMSPEC variable. Because a file /c is not found, the COMSPEC is not altered, but the error is posted and an empty environment is generated. This probably was an error in design, since the path should only be examined by a login (or root) command.com (using the /p, for example, but has been a bug since the begining. Heck, don't use them undocumented bugs, anyway! :-).