Creating Shortcuts for 32 and 64 bit computers

[witch]

Can anyone give me an idiot's guide on how to get shortcuts to work on both 32 and 64 bit computers?

We have some 64 bit teacher's laptops that I refuse to wipe and put a 32 bit image on as it seems a bit backward to me.

These are shortcuts deployed by user.

If I create two shortcuts for each bit of software then I end up with a blank icon which looks bad and the computers seem to hang for a long time.

All the 64 bit computers (apart from my own desktop) are teachers laptops.

 

Grateful for any simple ideas!

[computer_expert]

Group policy preferences and item level targeting?

 

See the post by Mike1879 here: Deploying desktop shortcuts via GP for 32-bit programs on 64-bit O/S - Spiceworks

[witch]

Group policy preferences and item level targeting?

 

See the post by Mike1879 here: Deploying desktop shortcuts via GP for 32-bit programs on 64-bit O/S - Spiceworks

 

I did see this - not sure I understand it really. Is it really the best way?

[sted]

i redirect the start menus to \\server\startmenu$\win7\x86 (or x64) and use a wmi filter on a start menu group policy to decide which one a pc gets

[siuko]

I did see this - not sure I understand it really. Is it really the best way?

 

We do our shortcuts using GPP

 

It is extremely flexible and will only add shortcuts to programs that are actually on the computer / mapped drive etc - which makes the start bars tidier than having shortcuts to something not accessible.

 

The only big downside is the amount of shortcuts you need to create!! Can take some time to setup but once it is done it works very nicely.

[FN-GM]

@witch do you use redirected start menus?

[witch]

Yes, we do redirected everything @FN-GM

so, @siuko, are you saying that if I create a shortcut in GPP pointing at program files and one pointing at program files (x86) it will only show the one that is installed on that computer?

[siuko]

Yes, we do redirected everything @FN-GM

so, @siuko, are you saying that if I create a shortcut in GPP pointing at program files and one pointing at program files (x86) it will only show the one that is installed on that computer?

 

Sort of

 

Once you have put in all the info to create it - you then need to go to the common tab and tick item level targeting - then click the targeting tab - click new item - file match - then put in which exe or other file you want it to watch for.

 

These files will be different depend on if you are running 32bit or 64bit

 

The downside to these types of links - is you will also need to add a corresponding delete which checks if the file doesnt exist and deletes if it isnt there - that cleans up your start bar

[Michael]

In my opinion I think Microsoft got things the wrong way around.

 

They should have maintained C:\Program Files for all 32Bit processes (on both platforms) and created C:\Program Files (x64) for all 64Bit processes. We then wouldn't need to 'faff' with WMI filters as much.

[sparkeh]

I too use GPPs for this. However, I currently send out both 32bit and 64bit shortcuts and the correct one work and the incorrect ones (silently) fail. Though reading @computer_expert post I can make it more elegant by checking the OS version (bit of a moment there!).

[sparkeh]

In my opinion I think Microsoft got things the wrong way around.

 

They should have maintained C:\Program Files for all 32Bit processes (on both platforms) and created C:\Program Files (x64) for all 64Bit processes. We then wouldn't need to 'faff' with WMI filters as much.

Possibly but everyone should be thinking of 64bit as the norm and 32bit as legacy really, the current naming reflects this.

[Michael]

At some point though, 128Bit or more will start becoming the norm, so you'll then have:

 

C:\Program Files

C:\Program Files (x86)

C:\Program Files (x64)

 

Program Files would be renamed again for 64Bit processes.

 

If they did what I suggested, it would be consistent across all versions of Windows concerned. Program Files wouldn't need to be renamed either!

 

C:\Program Files

C:\Program Files (x64)

C:\Program Files (x128)

C:\Program Files (x256) etc..

[witch]

Not sure when 64 bit will be seen as the norm in the far reaches of junior school education, I have over 120 computers at one of my schools and currently I have 5 64 bit laptops and one 64 bit desktop.

[Michael]

Not sure when 64 bit will be seen as the norm in the far reaches of junior school education, I have over 120 computers at one of my schools and currently I have 5 64 bit laptops and one 64 bit desktop.

 

I agree with you there - 'normally' most of my images are 32Bit, offering legacy support. A lot of software is becoming more cloud based, so slowly it's becoming less of an issue.

 

These days all new PCs I've seen with Windows 8 or 8.1 are the x64 version from all the big OEMs. Come to think of it, I don't think I've seen any OEM hardware pre-installed with x86 for the past few years.

[sted]

In my opinion I think Microsoft got things the wrong way around.

 

They should have maintained C:\Program Files for all 32Bit processes (on both platforms) and created C:\Program Files (x64) for all 64Bit processes. We then wouldn't need to 'faff' with WMI filters as much.

 

I agree but would go one stage further. Why split it at all what actual good is splitting up your programs into 2 folders based on architecture the disk itself dosent care the os dosent as you can force install them in the wrong folders if you like so what actual purpose does it serve? I cant say ive ever been really bothered about if an installed program is x86/x64 and that's what the help about box is for surely?

[sparkeh]

Not sure when 64 bit will be seen as the norm in the far reaches of junior school education, I have over 120 computers at one of my schools and currently I have 5 64 bit laptops and one 64 bit desktop.

Oh? Primary here with same number of machines here and all but a couple are 64 bit. What's the issue with moving to 64 bit?

[sted]

Oh? Primary here with same number of machines here and all but a couple are 64 bit. What's the issue with moving to 64 bit?

 

same here unless the hardware wont take it as far as im concerned windows 7 is a 64 bit os unly x86 pcs are old ones that cant run x64 again primary schools

[Mr.Ben]

Can you create Junction points in a script and push them out to all of the x64 machines?

[free780]

Be aware the 64bit item level targeting doesnt work on win 7 x64 without a hotfix.

 

Group Policy preference item-level targeting does not work for 64-bit versions of Windows 7

 

We have a redirect start menu for each room so we know where the 32bit pcs are.

[Duke5A]

Call me old, but I still prefer to use VB for this stuff.

 

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set WshShell = CreateObject("WScript.Shell")

strAllDesktopPath = WshShell.SpecialFolders("AllUsersDesktop")
strUserDesktopPath = WshShell.SpecialFolders("Desktop")

If GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").AddressWidth = 64 Then
strProgramFilesPath = "C:\Program Files (x86)"
Else
strProgramFilesPath = "C:\Program Files"
End If

On Error Resume Next

If objFSO.FileExists(strUserDesktopPath & "\My Shortcut.lnk") Then
Else
Set objShortcutUrl = WshShell.CreateShortcut(strUserDesktopPath & "\My Shortcut.lnk")
objShortcutUrl.TargetPath = strProgramFilesPath & "\" & "My Program" & "\" & "Program.exe"
objShortcutUrl.WorkingDirectory = strProgramFilesPath & "\" & "My Program"
objShortcutUrl.IconLocation = strProgramFilesPath & "\" & "My Program" & "\" & "Program.exe,0"
objShortcutUrl.Save
End If

 

I just tossed this together, so it needs to be tested.

[FN-GM]

We had 2 redirected start menus when we had a mix. One for x86 and the other for x64. You can separate the group policy that enforces them with a WMI filter.

[Arthur]

At some point though, 128-bit or more will start becoming the norm, so you'll then have

I doubt we will need 128-bit OSs and processors in our lifetimes. If someone requires more than 4 Pebibytes of RAM in a single computer, it would be far easier to buy another computer and network them together.

 

In my opinion I think Microsoft got things the wrong way around.

Not at all. The "Program Files" folder is reserved for native programs only. Non-native programs go in a different folder because at some point in the future, Microsoft will remove support for them (as they did with 16-bit apps on 64-bits OSs).

 

64-bit versions of Windows have two folders for application files; 'Program Files' folder serves as the default installation target for native (in this case 64-bit) programs, while the 'Program Files (x86)' folder is the default installation target for non-native (in this case x86-32) programs. While 64-bit Windows versions also have a %ProgramFiles(x86)% environment variable, the dirids/CSIDLs are not different for 32-bit/64-bit; the setup/shell APIs merely return different results, depending on whether the calling process is native or not.

 

To be backwards compatible with the 8.3 limitations of the old File Allocation Table file names, the names 'Program Files', 'Program Files (x86)' and 'Common Program Files' are shortened by the system to progra~N and common~N, where N is a digit, a sequence number that on a clean install will be 1 (or 1 and 2 when both 'Program Files' and 'Program Files (x86)' are present). (Source)

 

We then wouldn't need to 'faff' with WMI filters as much.

My school is 100% 64-bit. No faffing required!

[Arthur]

Call me old, but I still prefer to use VB for this stuff.

You're old!

 

I use a modified* version of @jklight's PowerShell script to do our Start Menu. Copying shortcuts into a folder is far easier than having to modify a script each time you want to add another program. Since the script automatically deletes shortcuts that do not exist, you could put both 32-bit and 64-bit shortcuts in the same folder (although obviously they can't have the same name).

 

Btw, wouldn't your script set "strProgramFilesPath" to the wrong location if it was run on a PC with a 64-bit processor and a 32-bit OS? Surely you should be checking the OS architecture rather than the processor architecture?

 

If GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").AddressWidth = 64 Then
strProgramFilesPath = "C:\Program Files (x86)"
Else
strProgramFilesPath = "C:\Program Files"
End If

 

* The script I am using is different from the one posted in the linked thread. It has several improvements like removing empty folders that do not contain any shortcuts and uses the existing Start Menu folder rather than create a new one.

[DrCheese]

I cheated and just made a symlink of "Program files (x86)" on our 32bit machines, gets around this easily

[Michael]

My school is 100% 64-bit. No faffing required!

 

This is why I try and standardise across 32Bit or 64Bit rather than mixing environments, but sometimes it's not always possible - hence the need for filtering.

 

Still - If Microsoft used Program Files for existing 32Bit processes and Program Files (x64) for new 64Bit processes, even in a mixed environment; because the 32Bit process would be in the same directory on both platforms, it would have made things considerably easier this way.

 

When (at some point) 128Bit OSes and processes come about, Microsoft would (in theory) rename Program Files again... it's just a bit messy doing it this way.