How to pass short filename in context menu?

[Guest]

In earlier versions of Windows, using %1 would pass the short filename, and %L
would pass the long filename in a context menu shell command.

In WinXP, all parameters seem to pass the long filename. Is there any way to
get the short filename?

I can do something like pass the long filename to a CMD file which then uses
%~s1 to pass the short filename on to the actual desired command, but this is
a bit of a kludge job.

 

[Wesley Vogel]

Check this setting...

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Value Name: NtfsDisable8dot3NameCreation
Value Type: REG_DWORD
Value Data: 0 or 1
0 = 8.3 names
1 = No 8.3 names

 

[Guest]

No, that controls whether the NTFS filesystem creates 8.3 type filenames as
well as the long filenames. If you set it to disable 8.3 names, then they are
not saved in the filesystem. I want to pass 8.3 filenames inside of a context
menu command (under HKEY_CLASSES_ROOT), instead of the long filename. This
used to be done via %0 or %1 in earlier versions of Windows, but XP passes the
long filename.

|
|HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
|Value Name: NtfsDisable8dot3NameCreation
|Value Type: REG_DWORD
|Value Data: 0 or 1
|0 = 8.3 names
|1 = No 8.3 names
|

 

[Wesley Vogel]

[[The posted tweak uses %1 as a parameter which passes short filenames to
cmd.exe. Changing the %1 to %l (lowercase L) passes the long filename
instead. ]]

Command prompt here with long filename (WXP-Pro)
http://tinyurl.com/3qazt

 

[David Candy]

You are wrong

%1 passes long file names to 32 bit programs and Win 95 aware 16 bit programs. It passes shortfile names to 16 bit non win95 aware programs AND also to programs it can't find.

So in the command field in the registry change the path to cmd to something explorer can't find. Normally this occurs if the program's name is not enclosed in quotes (and there's spaces in the path).

Note Explorer builds a command line then gives it to CreateProcess to execute. Just because Explorer can't find a file doesn't mean CreateProcess can't. Try removing the path or something. MS refuse to say what Explorer's search alogarthm is (I suspect it just looks one place). CreatProcess' is well known and detailed below. I just add that it tries all ambigious paths as well..

This behaviour won't be chaged as some programs rely on this behaviour. MS did fix it but had to unfix it after application testing.

So in short there is no official way to force a shortname to be passed.

If the file name does not contain a directory path, the system searches for the executable file in the following sequence:
1.. The directory from which the application loaded.
2.. The current directory for the parent process.
3.. Windows 95/98/Me: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
Windows NT/2000/XP: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.

4.. Windows NT/2000/XP: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
5.. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6.. The directories that are listed in the PATH environment variable.

 

[Torgeir Bakken \(MVP\)]

You are wrong

%1 passes long file names to 32 bit programs and Win 95 aware 16 bit programs. It passes shortfile names to 16 bit non win95 aware programs AND also to programs it can't find.

So in the command field in the registry change the path to cmd to something explorer can't find. Normally this occurs if the program's name is not enclosed in quotes (and there's spaces in the path).

Note Explorer builds a command line then gives it to CreateProcess to execute. Just because Explorer can't find a file doesn't mean CreateProcess can't. Try removing the path or something. MS refuse to say what Explorer's search alogarthm is (I suspect it just looks one place). CreatProcess' is well known and detailed below. I just add that it tries all ambigious paths as well..

This behaviour won't be chaged as some programs rely on this behaviour. MS did fix it but had to unfix it after application testing.

So in short there is no official way to force a shortname to be passed.

If the file name does not contain a directory path, the system searches for the executable file in the following sequence:
1.. The directory from which the application loaded.
2.. The current directory for the parent process.
3.. Windows 95/98/Me: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
Windows NT/2000/XP: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.

4.. Windows NT/2000/XP: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
5.. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6.. The directories that are listed in the PATH environment variable.

Hi

In addition to the places in the list above, this one is used for
program location detection as well (Windows NT/2000/XP):

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\

 

[David Candy]

CreateProcess doesn't use AppPaths. Explorer does to build the command line it passes to CreateProcess . Also in shell verbs AppPaths is ignored. AppPaths is only a Start Run or ShellExecute.

What I don't know is if the KnownDll key affects loading. For dlls listed they will only be loaded from system32 and take precedence over all standard searches. Dunno what happens if one adds a exe to the key. Also compatability options can specify a program to run if the user tries to start a particulr non existent program.

 

[Guest]

Now I see a reason why some don't like top posting (I don't care myself):
the "-- " at the beginning of one's sig makes all the stuff below that from
earlier posts disappear. Oh well, on with the top post:


I looked at the suggestion below, and the idea that some had of putting in a
command that could not be found by explorer - to trick it into thinking that
it may be a non-longfilename aware command, and so pass the short filename.
It turned out to be hard to find an easy way to specify a command that
explorer could not find, but CreateProcess could. And then, it didn't help
anyway, as the long filename got passed in any case.

I did find that if I used a command that was an old DOS .COM file, it did pass
the short filename. So, by renaming the .EXE that I was trying to run to
COM, I got Explorer to pass the short filename. When the .COM file is
executed, it is found to have an EXE header inside, so it still runs
correctly.


In the suggestion below, it says that %1 passes short filenames - my problem
is that it does not. If I put in anything like the following shell command:
cmd.exe /k echo %1
I get the long filename under WinXP, and the short filename in other Windows
versions.

|[[The posted tweak uses %1 as a parameter which passes short filenames to
|cmd.exe. Changing the %1 to %l (lowercase L) passes the long filename
|instead. ]]
|
|Command prompt here with long filename (WXP-Pro)
|http://tinyurl.com/3qazt
|
|

 

[Wesley Vogel]

Second time I've heard this about my sig. I think the other guy was using
News Xpress 2.01 also. I'm not 100% certain. Doesn't disappear with
Outlook Express 6.00.2800.1437.

I'm not quite sure what you're trying to do.

command.com cannot interpret LFN (Long File Names). Maybe try using
command.com. Using command.com will open cmd.exe.

[[When a command is entered for execution by this shell {command.com}, it
does not actually execute it. Instead, it packages the command text and
sends it to a 32-bit CMD.EXE command shell for execution.]]

command.com is in C:\WINDOWS\system32

With David and Torgeir in on this, I'm bowing out. They know more than I
do.

 

[Torgeir Bakken \(MVP\)]

Second time I've heard this about my sig. I think the other guy was using
News Xpress 2.01 also. I'm not 100% certain. Doesn't disappear with
Outlook Express 6.00.2800.1437.

Hi

I'm using Mozilla newsreader, and all quoted text under the signature
marker "-- " is automatically removed when replying.

The "correct" place for a signature is at the bottom of the post, below
all other text, also quoted text.

 

[David Candy]

Look at reg files. Explorer always gives reg files as shortfile names. This is because for merging the command is
regedit "%1"

but uses the long name if you want to edit it (or print). Also note notepad assumes long file names and doesn't need "" around the file name - but this is a rare program, most do require..
%SystemRoot%\system32\NOTEPAD.EXE %1

So explorer can't find regedit but can find notepad. Create Process finds both of course.

MS has changed their policy over the years.Only several weeks ago one MS programmer said he didn't know if MS were in a specifing absulate paths or just let the system find it as they kept changing the policy faster than he could keep up.

Also when one reads several thousands posts a day top posting is important. Else it forces many thousands of turns if the mouse wheel EVERY DAY. This is an OH&S issue. I reckon MS can be sued for not providing safe guidelines for use.

 

[David Candy]

I suppose we can chat about the theory of this for a long time. But what is your actual problem.

 

[Wesley Vogel]

Hi,

Top posting and signature placement had nothing to do with it.

I use OE with OE-QuoteFix. I must've accidentally set Strip quoted
signature. [[Strip quoted signature, will strip the signature (if any) of
the message you reply to.]] OE-QuoteFix was removing everything after
the --.

It's fixed now.

And I'll place *my* signature where ever I feel like it.

 

[Torgeir Bakken \(MVP\)]

Hi,

Top posting and signature placement had nothing to do with it.

"it" referring to what exactly? (for me as a Mozilla user,
signature placement has everything to do with what is removed
automatically)

I use OE with OE-QuoteFix. I must've accidentally set Strip quoted
signature. [[Strip quoted signature, will strip the signature (if any) of
the message you reply to.]] OE-QuoteFix was removing everything after
the --.

That is what Mozilla do as well (removes everything after "-- "),
but there is no option to stop it from doing it (not that I have
found at least).

It's fixed now.

And I'll place *my* signature where ever I feel like it.

Of course you can, that is why I used quotes around the word "correct"
in this statement:

<quote>
The "correct" place for a signature is at the bottom of the post,
below all other text, also quoted text.
</quote>

Why I state this is because it is the "standard" (again, note the
double quotes) for Usenet, a standard most people in the
microsoft.public.* hierarchy does not follow.

Mozilla also indicates that this is the "correct" place for the
signature, in the configuration panel for the signature, this is
what it recommends, as this is the text in one of the choices:

"place my signature below the quote (recommended)"

 

[Wesley Vogel]

[["it" referring to what exactly? ]] My problem of OE-QuoteFix removing
everything after the signature.

To fix your problem, apparently you'll have to use a different newsreader.

Actually, I'll place my signature wherever OE-QuoteFix places it.

With OE-QuoteFix, top posting automatically places the signature at the end
of the new material, not at the bottom.

All of the following is purely opinion.

I like top posting and dislike bottom posting. Why should I have to scroll
through everything I've already read to see something new? Interspersed
posting is OK.

I also like to see the signature without having to scroll way to the bottom.
Quite often folks will sign with their real name, whereas the From column
has some goofy handle.

OE-QuoteFix used with OE allows for all three posting types.

As far as which posting type is appropriate, I won't even touch that.

--
Hope this helps. Let us know.
Wes

In

Hi,

Top posting and signature placement had nothing to do with it.

"it" referring to what exactly? (for me as a Mozilla user,
signature placement has everything to do with what is removed
automatically)

I use OE with OE-QuoteFix. I must've accidentally set Strip quoted
signature. [[Strip quoted signature, will strip the signature (if
any) of the message you reply to.]] OE-QuoteFix was removing
everything after the --.

That is what Mozilla do as well (removes everything after "-- "),
but there is no option to stop it from doing it (not that I have
found at least).

It's fixed now.

And I'll place *my* signature where ever I feel like it.

Of course you can, that is why I used quotes around the word "correct"
in this statement:

<quote>
The "correct" place for a signature is at the bottom of the post,
below all other text, also quoted text.
</quote>

Why I state this is because it is the "standard" (again, note the
double quotes) for Usenet, a standard most people in the
microsoft.public.* hierarchy does not follow.

Mozilla also indicates that this is the "correct" place for the
signature, in the configuration panel for the signature, this is
what it recommends, as this is the text in one of the choices:

"place my signature below the quote (recommended)"


--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.mspx

 

[Guest]

I guess that the original "actual problem" was in the part that got clipped
below the sig indicator line.
I didn't get the answer that I originally looked for, but some replies gave me
a few hints, and I did find a solution that worked for me in most cases.

Sorry about mentioning the "top posting" stuff at all (please ignore this
mention, too).

I could perhaps start another flurry by mentioning the sheer stupidity of
allowing filenames to contain spaces in the first place (which is the root
cause of my "original problem"). At least they could have not allowed spaces
to be both in filenames and used as delimiters, too!
Why not have allowed people to type in spaces when creating a filename, but
then replace them all with something like an underscore - it would have looked
about the same, but not have caused such grief. Most of the time people who
put spaces in names never type them again, anyway - they just click on them in
some GUI.

|I suppose we can chat about the theory of this for a long time. But what =
|is your actual problem.
|
|--=20
|----------------------------------------------------------
|http://www.uscricket.com
||> Now I see a reason why some don't like top posting (I don't care =
|myself):
|> the "-- " at the beginning of one's sig makes all the stuff below that =
|from=20
|> earlier posts disappear. Oh well, on with the top post:
|>=20
|>=20
|> I looked at the suggestion below, and the idea that some had of =
|putting in a=20
|> command that could not be found by explorer - to trick it into =
|thinking that=20
|> it may be a non-longfilename aware command, and so pass the short =
|filename.
|> It turned out to be hard to find an easy way to specify a command that =
|
|> explorer could not find, but CreateProcess could. And then, it didn't =
|help=20
|> anyway, as the long filename got passed in any case.
|>=20
|> I did find that if I used a command that was an old DOS .COM file, it =
|did pass=20
|> the short filename. So, by renaming the .EXE that I was trying to run =
|to=20
|> COM, I got Explorer to pass the short filename. When the .COM file is =
|
|> executed, it is found to have an EXE header inside, so it still runs=20
|> correctly.
|>=20
|>=20
|> In the suggestion below, it says that %1 passes short filenames - my =
|problem=20
|> is that it does not. If I put in anything like the following shell =
|command:
|> cmd.exe /k echo %1
|> I get the long filename under WinXP, and the short filename in other =
|Windows=20
|> versions.
|>=20
|> In article <[email protected]>, "Wesley Vogel"=20
|> |[[The posted tweak uses %1 as a parameter which passes short =
|filenames to
|> |cmd.exe. Changing the %1 to %l (lowercase L) passes the long filename
|> |instead. ]]
|> |
|> |Command prompt here with long filename (WXP-Pro)
|> |http://tinyurl.com/3qazt
|> |
|> |

 

[David Candy]

You have to specify exactly what the specific problem is. Like c:\something\some.exe

--
----------------------------------------------------------
http://www.uscricket.com

I guess that the original "actual problem" was in the part that got clipped
below the sig indicator line.
I didn't get the answer that I originally looked for, but some replies gave me
a few hints, and I did find a solution that worked for me in most cases.

Sorry about mentioning the "top posting" stuff at all (please ignore this
mention, too).

I could perhaps start another flurry by mentioning the sheer stupidity of
allowing filenames to contain spaces in the first place (which is the root
cause of my "original problem"). At least they could have not allowed spaces
to be both in filenames and used as delimiters, too!
Why not have allowed people to type in spaces when creating a filename, but
then replace them all with something like an underscore - it would have looked
about the same, but not have caused such grief. Most of the time people who
put spaces in names never type them again, anyway - they just click on them in
some GUI.

|I suppose we can chat about the theory of this for a long time. But what =
|is your actual problem.
|
|--=20
|----------------------------------------------------------
|http://www.uscricket.com
||> Now I see a reason why some don't like top posting (I don't care =
|myself):
|> the "-- " at the beginning of one's sig makes all the stuff below that =
|from=20
|> earlier posts disappear. Oh well, on with the top post:
|>=20
|>=20
|> I looked at the suggestion below, and the idea that some had of =
|putting in a=20
|> command that could not be found by explorer - to trick it into =
|thinking that=20
|> it may be a non-longfilename aware command, and so pass the short =
|filename.
|> It turned out to be hard to find an easy way to specify a command that =
|
|> explorer could not find, but CreateProcess could. And then, it didn't =
|help=20
|> anyway, as the long filename got passed in any case.
|>=20
|> I did find that if I used a command that was an old DOS .COM file, it =
|did pass=20
|> the short filename. So, by renaming the .EXE that I was trying to run =
|to=20
|> COM, I got Explorer to pass the short filename. When the .COM file is =
|
|> executed, it is found to have an EXE header inside, so it still runs=20
|> correctly.
|>=20
|>=20
|> In the suggestion below, it says that %1 passes short filenames - my =
|problem=20
|> is that it does not. If I put in anything like the following shell =
|command:
|> cmd.exe /k echo %1
|> I get the long filename under WinXP, and the short filename in other =
|Windows=20
|> versions.
|>=20
|> In article <[email protected]>, "Wesley Vogel"=20
|> |[[The posted tweak uses %1 as a parameter which passes short =
|filenames to
|> |cmd.exe. Changing the %1 to %l (lowercase L) passes the long filename
|> |instead. ]]
|> |
|> |Command prompt here with long filename (WXP-Pro)
|> |http://tinyurl.com/3qazt
|> |
|> |