Why does WinBatch get installed in "C:\program files\(x86) program files" now?

[snowsnowsnow]

The question is as stated in the Subject: line, with a subquestion of "Would anything bad happen if I install t in regular old C:\program files\Winbatch ?

The underlying is this:  I have a program (written in C) that spawns WinBatch.exe and it is hard-coded to run C:\progra~1\WinBatch\system\winbatch.exe.  Yes, I know there are more elegant ways to do this than hard-coding it, but changing it is not an option at this point.

Anyway, this program has worked fine for years, until today when I tried it out on a Win 7 machine, which has the newfangled "(x86)" thingie.  It failed.  I fixed things by opening up a Administrator Command Prompt and creating the C:\progra~1\WinBatch\system directory and copying WinBatch.exe and the required DLL there.  Now it all works.

But, as always, when hacks like this prove necessary, one wonders why it was necessary and if there is a cleaner/better way to get there.

[td]

The WinBatch installer installs WinBatch 32-bit executables and dlls into "C:\Program Files (X86)\WinBatch\System" and  64-bit executables and dlls in "C:\Program Files\WinBatch\System" assuming both Windows and installer defaults.  Of course the "C:\" part is dependent on the system drive.  You are using an old version of WinBatch so your results may vary.  However, MSFT wants everyone to  use 'Program Files (X86)' for 32-bit applications and   ''Program Files' for 64-bit applications.  One key feature of these directories is that they are consider protected directories because only admins can write to them.  This can be important because of Windows 7 UAC. Depending on UAC related group policy settings, some WIL UI manipulation functions may not work properly when WinBatch is not started from a protected directory.  Other than UAC and few possible issues with environment variable, you shouldn't run into to many problems starting your WinBatch exe from a directory of your own choosing. 

[snowsnowsnow]

So, a couple of questions, raised by your (td's) response:

1) What you're basically saying is that WB gets installed in the "(x86)" directory by default (i.e., if you don't change anything when you do the install) because that's the new standard, as dictated by MSFT.  But this naturally raises the question of "Why?".  Why segregate them?  Would anything bad happen if I had installed it in the regular "Program Files" hierarchy?

2) I don't follow what you wrote about "protected directories".  Why should that matter?  Why would it matter to WinBatch if the directory into which it had been installed was not "protected"?  That seems an odd requirement...

[td]

So, a couple of questions, raised by your (td's) response:

1) What you're basically saying is that WB gets installed in the "(x86)" directory by default (i.e., if you don't change anything when you do the install) because that's the new standard, as dictated by MSFT.  But this naturally raises the question of "Why?".  Why segregate them?  Would anything bad happen if I had installed it in the regular "Program Files" hierarchy?

There are several good reasons for following MSFT on this issue but basically, MSFT setup the OS and file system architecture in such a way as to avoid name collisions between 64-bit and 32-bit.    It is just another of the many consequences of having a 32-bit and 64-bit version of the same OS commingled  on the same same hardware.  To give MSFT credit they have done reasonably good job of supporting 32-bit Windows applications, drivers, etc. on native 64-bit Windows.  Although, most of the credit probably goes to AMD and to a lesser extent Intel.  You do know that WinBatch has both a 32-bit and 64-bit version?

2) I don't follow what you wrote about "protected directories".  Why should that matter?  Why would it matter to WinBatch if the directory into which it had been installed was not "protected"?  That seems an odd requirement...

UAC has been around since 2007 and protected directories are just one of the many security 'features' of that part of the operating system.  After much whining and gnashing of teeth most have grudgingly adapted and adjusted to UAC.   If you are working in a UAC environment, it is strongly recommended that you get up to speed on the subject. 

[ChuckC]

There is an additional caveat to consider regarding what your C program is hard coded to use for a path to the WinBatch.exe file:

As of Win2K12, Win2K12R2, Windows 8, Windows 8.1 and Windows 10, it is now possible to disable the creation of short DOS 8.3 names on NTFS and ReFS volumes.  In a nutshell, not using the long names can result in complete breakage of any program that's dependent upon short names.


The Win32 API function SHGetKnownFolderPath() can be used to find out what the appropriate architecture-specific "program files" path is [long name], which includes having the O.S. installed on a drive other than C:, to which you can then append the a proper relative path information to find WinBatch.exe.

[td]

If I understand snow++'s post, he simply created a directory called 'C:\progra~1\WinBatch\system" which would actually create the a directory under the "Program Files" , if short  names are enabled.  I  believe it would create that literal path, if they are not.  So in this specific case he has both cases covered assuming he copied the WinBath file to the correct directory and UAC didn't keep his script from working correctly because of user write permission in the no short names case .  Of course, if he has other short names hard coded into the program, things could turn sideways quickly.


The "PROGRAMFILES" environment variable is also set to the program file path based on the bitness of the process.  The "PROGRAMFILES(X86)" variable will always return the 32-bit path  on 64-bit systems and "PROGRAMW6432" will return the 64-bit path on 64-bit systems.

[snowsnowsnow]

FWIW, what I actually did was:

1) Opened a Command Prompt running as Administrator
2) cd /D C:\program files
3) md winbatch\system

Then copied the WinBatch.exe and the needed DLL into that directory.

And, as I said in the OP, it now all works fine.

And, as I also said, I'm well aware that this is all kinda hacky, but it does work and that's the important thing.

Going a bit O/T, but I have heard that there is the possibility of the short names hack not working, and that later versions of Windows may omit it (as Chuck mentioned).  I'm not worried about this because the chances of my ever using (in any serious capacity) any version of Windows beyond 7 is zero.  Clearly Windows jumped the shark (*) at XP, and totally lost it after 7.  There's a reason they are giving it away for free now.

(*) In the technically correct meaning of JTS - that is, to have reached the pinnacle, from which the only way forward is down.

[td]

FWIW, what I actually did was:

1) Opened a Command Prompt running as Administrator
2) cd /D C:\program files
3) md winbatch\system

Then copied the WinBatch.exe and the needed DLL into that directory.

The is exactly what I thought you did.  My point was that in theory you should still be able to get your C program to work even if short file names were disabled. 

And, as I said in the OP, it now all works fine.

And, as I also said, I'm well aware that this is all kinda hacky, but it does work and that's the important thing.

Quite.

Going a bit O/T, but I have heard that there is the possibility of the short names hack not working, and that later versions of Windows may omit it (as Chuck mentioned).  I'm not worried about this because the chances of my ever using (in any serious capacity) any version of Windows beyond 7 is zero.  Clearly Windows jumped the shark (*) at XP, and totally lost it after 7.  There's a reason they are giving it away for free now.

(*) In the technically correct meaning of JTS - that is, to have reached the pinnacle, from which the only way forward is down.

You can add, remove, enable and disable short file names on Windows 7.  Check out the fsutil.exe command shell utility.

[snowsnowsnow]

The is exactly what I thought you did.  My point was that in theory you should still be able to get your C program to work even if short file names were disabled. 

I was confused at first, but I think I've figured out your meaning here.

You're saying that even if I was working on a system with short names disabled, there's nothing to stop me from creating a directory called "C:\progra~1" and then putting my stuff under that.  It just wouldn't be an alias for "C:\Program Files" as it currently is (with short names working).

[td]

Correct but I freely admit my communication skills are mostly a lack thereof.