Tuesday, November 17, 2015

Batch me up a shortcut.

Today's frustration comes in two parts.  Expect my thoughts on x64 implementations shortly.  But first, over the last week, I have been trying to shoehorn a legacy app into an AppV package.  This thing is so ancient, it's trying to install, not to some handy directory like "C:\Program Files\BLAH" but directly to C:\

No directory.  No.  Just going to scatter my own directories directly to the root.  So it comes as no surprise that this application does log management and launching via batch files.

Don't get me wrong.  A batch file can be a beautiful thing.  When the task is simple and within the scope of a batch file, which is considerably limited.  But these days, there are many choices for scripting.  JavaScript, vbScript, Powershell script, or if you want to go old school, there is always bash (ask your father)  All of these scripting languages have hooks into all sorts of handy functions in the OS.  You can (not that you should) build just about anything with them.

So the good  old .bat gets thrown on the temporal scrap heap.  Until I have to get this thing running on WindowsRecentx64.

This is where I learned that when using AppV, you have to explicitly name what program the .bat file should run under in a shortcut.  This means changing the target from

C:\BLAH\go.bat -fconfig /appvve:AGUID-WITH-A-BUNCHOFHEX_ANOTHER-GUID-WITH-MOREHEX

to

cmd.exe /C"C:\BLAH\go.bat -fconfig" /appvve:AGUID-WITH-A-BUNCHOFHEX_ANOTHER-GUID-WITH-MOREHEX

The same goes with .vbs and .js scripts, exept the engine changes to cscript or wscript if you like an abundance of pop ups.

Expect more ranting once I've finished documenting this legacy BLAH.

No comments: