x64, Dynamic Link Libraries and confusion.

Still ranting about AppV.  So all three readers plus the mysterious bot from russia that reads this, get ready for more.

Everybody knows what a dynamic link library is don't they?  They were originally designed in the good old day when memory was expensive and mutlitasking was cool.  Now Multitasking is old hat and memory is cheap, dlls are kept around because their content is useful.  They are a useful container to pile in libraries of compiled code and a whole bunch of resources your program might use.

This works great provided there is no incompatibilities between this dll and that one.  And of course, for a variety of good reasons (and some really bad ones)  this doesn't happen.  This means that although you may have a library of the same name, with the same public hooks, and a later version, you may end up with different results.  Bad.  So how do we sort this out?

In comes the .local file.  Create an empty file called blah.exe.local in a given directory and it will use the dlls it finds in the same directory as the executable first.  Then it will hunt through the system.

Other cool things you can do is create a directory called blah.exe.local and pile the dlls in there.  This has the benefit of differentiating two executables in the same directory.

So, wasn't AppV going to deliver us from dll hell by sandboxing everything?  It tried.  But fortunately this trick works inside an AppV sandbox as well.  Hooray.

And what are other solutions?

Unix as a general rule includes the version number in the file name for libraries.  This means the executable will only associate with an appropriate version.  You can have as many versions as you like in a shared directory and everyone gets what they need.

Problem solved.  The problem is solved.  We solved the problem so everything is awesome.  Problem solved...

But wait.  There's more.

Along comes x64 libraries designed to run x 64 code on x 64 chips which is back compatible with x86 (or 32 bit) code.  This might mean that there are now 4 locations that the dll might be.

• The current working directory
• C:\windows\System
• C:\windows\System32
• C:\windows\SysWOW64

Where should they go?  Just to be confusing, x86 legacy code can try to look for dlls in System32 despite the fact that this is the directory for x64 dlls.  They should use SysWOW64 as their first location to look.  They don't.  

So use your .local files wisely people as this will make life happier.  Otherwise, inside your AppV sandbox, scatter your dlls everywhere.  It is messy, but it works.  And odds are nobody will look inside to complain about it.

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.

Tablets, and why you shouldn't be cheap.

This  is a long story that takes me back.  When I was first riding to work I discovered that the 15" laptop was no longer a good thing.  So I checked the market for small laptops that would fit on the back of the bike and do everything I needed them to do.  During my research, I chanced upon the Asus Transformer 300.  A great little tablet with fantastic battery life, and a Keyboard.

Do not ever underestimate the power of a keyboard.  They transform a tablet from being a content consuming device, to being a content creation device.

Yes there were a whole bunch of compromises.  I found myself using simple word processors rather than Microsoft Office.  And found for my requirements, they worked just fine.  Browsing was a doddle, and games were small, not as immersive but fun.

The decision to move to a smaller laptop was a good one for me.  

Anyways.  A couple of years later, and the tablet supplier decided that they would end support for new software.  This left me with the choice of running stock software or playing around with flashing it myself to cyanogenmod.

I chose the latter being the good geek I am and had some mixed success.  But one lesson I will give you for free.

The GApps module that says nano really means, You will have to uninstall all the Google Apps and reinstall them to make them work.  Save time and panic.  Get the larger one and then just do the upgrade.

Look out for more scripting nonsense later today.

Leadership skills you actually need.

I was reading my linkdin feed today and noticed a plethora of articles reading like this

• 6 Things a leader never does.
• 5 Habits all leaders have
• One thing all Leaders have in common.
• Etc. Etc.

The issue I have with these articles is they assume that leadership in and of itself is the end goal.  And for a manager stuck in middle management dreaming of the CEO's car parking space, it sounds very enticing.  I check off the habits that leaders have and I become a leader.  

Here is the one thing that all these articles forget.  A leader is a leader because something is following them.  Yes there are a bunch of techniques that will improve the chances of people following you, but the thing to remember is to go somewhere.

Do something awesome.  The person that creates something new is a greater leader than the person who herds people round in circles.

Go.  Be Awesome.

Asking for .hlp

The package I am currently working on has a .hlp file that needs opening so people can, well, get help.  Now because the .hlp standard is flawed with some insecurities that would allow people to redirect around security to get at stuff, Microsoft decided to only include the executable to read these as an optional extra.

In a .msu file

That only runs when the Windows Update service is running

That service you switch off so you can get a vanilla box to package on

Great...

You can switch it on and off. at will, and it seems to work for sliding it into the App-V bubble.  Hooray.

Turn's out this doesn't work.  Will keep this post updated as I look for answers.

Update:
I figured it out.  It's a bit of a pa-lava but it's definitely possible to bubble this bad boy.

Grab the .msu from the link. then pop it open using the cmd command

expand F:* windows6.1-KB917607-x86.msu C:\Temp\winhlp32

Now you fire up AppV sequencer and follow the steps below in your bubble

This will grab you a whole directory of joy.   Now you are going to have to do some ownership grabbing of the following files.  If you need help, click here.

• C:\Windows\winhlp32.exe
• C:\Windows\System32\ftsrch.dll
• C:\Windows\EN-US\winhlp32.exe.mui
• C:\Windows\EN-US\ftsrch.dll.mui

Copy the files below over their counterparts above.

• C:\Temp\winhlp32\x86_microsoft-windows-winhstb.resources_31bf3856ad364e35_50.1.7600.16386_none_da3d517bf9765116\winhlp32.exe
• C:\Temp\winhlp32\x86_microsoft-windows-winhstb.resources_31bf3856ad364e35_50.1.7600.16386_none_da3d517bf9765116\ftsrch.dll
• C:\Temp\winhlp32\x86_microsoft-windows-winhstb.resources_31bf3856ad364e35_50.1.7600.16386_en-us_83921ac31ded8ee9\winhlp32.exe.mui

• C:\Temp\winhlp32\x86_microsoft-windows-winhstb.resources_31bf3856ad364e35_50.1.7600.16386_en-us_83921ac31ded8ee9\ftsrch.dll.mui

And... now you have help in a bubble.  Standard cleanups apply.

App-V and permissions

App-V Version 5 now respects permissions.  Hooray.  When dealing with legacy apps that write stuff wherever the hell they want to, keep this in mind.

Also works with setting rights on virtual services.  When capturing, use subinacl.  (Available here)

It works a treat. :-)

App-V stole my shortcuts!

Being quite new to the App-V packaging world, I ran into an issue that I figured I'd share so others can

1. Laugh at how silly I am, and
2. Help out others in the same predicament

I was packaging up an application using Microsoft Application Virtualization Sequencer and all was good.  All the pieces from the MSI I was using were dropping into the correct place.  "Happy" thought I.  "I shall have this package ready for testing by luncheon today"

I install it onto a clean machine, and all is right with the world.  So I publish via the publisher.

I get the advertised icons on my start menu.  But do they do anything?  Nooooooo.  Badness.

I spend a while Google problem, try random fix, hope.

Anyways what I had not done was edited the package in the sequencer, gone into the Advanced Tab and ticked the boxes

• Allow all named objects to interact with the local system
• Allow all COM objects to interact with the local system
• Allow virtual applications full write permissions to the virtual file system

Save, Publish and Happiness.