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.

App-V versus error 142

For the last month or so I have been working with App-V and have had a series of issues that no one on the web seems to want to talk about. First of all,

Error 0x00000142 

Conventional wisdom says

• Check that 8.3 naming is turned on
• Check that all DLL's are registered
• If you're using App-V version 5 then make sure you are not dragging DLL's across the net

But I have found at least one case where the above error is caused by Empty directories.  Fortunately this is easy to fix by placing a dummy file in the empty directory in the bubble.  Remind me to report this to the good people at Microsoft for some cool merch.

Update:

I have been randomly deleting files from the Package\Root\VFS directory since this seems to be the main culprit.  Basically, if it's empty, it can go.  Also, anything with the extension .msi can be deleted on principal.

Anything else in the Package\Root directory should probably use dummy folders.

As I learn more I'll keep all 3 of you posted.

Powershell

In the last two weeks I have had to learn powershell and was handed a big old project to do in that. So this will act as my heading block for all I learn.

Direct access to the. Net libraries is a good thing.  Four versions of the language... Bad thing.  More to come.

The point of riding in the rain.

Last night I took the ZZR out for a quick ride to Ashley's house. Yay. All good. Spent some time there and then had to leave. It's raining. Bother. It was then that I learned the whole point of riding in the rain on a motorcycle is to make the rider look like he has wet his pants. All the water that hit my chest ran straight down my jacket and into my crotch. I could feel it pooling there. A sensation like no other I can assure you.

Made it home in one piece which was good. But I can see why riding in the rain is not considered a good motoring experience.

Keeping yourself nice on Facebook.

So you've been hooked onto the social media thingy. Now all you need to do is to learn how to use it properly. This can be a problem because not only do you need to work out what button does what, but you also need to work out how to use the format in a socially acceptable way.

Think to the way you use a telephone. It rings. You pick up. If you know the caller from caller ID, you acknowledge the caller by stating their name and inquiring after their health. If not the conversation runs as below.

"Hello, John Matthews speaking."
"Hello John, this is Fred Nerk calling."
"Ah Fred. Good to hear from you. How are you?"

A few social pleasantries are exchanged and then the purpose of the call is raised.

The above example is the protocol for telephone conversation. Each party introducing themselves and discussing some light conversation before getting into the meat of the conversation.

Facebook users are still working out the rules. Here are some that need stating.

Rule 1.

Keep your Game Achievements sparse.

You are most welcome to play any of the many facebook games you like, but please keep the number of updates you share with your friends to a minimum. Game makers want you to share your progress lots, so will pop up any number of dialog boxes to encourage you to tell your friends how well you are doing on SuperMafiaNinjaTreasureFarmVille. This is so the game maker can get your friends to play the game and therefore generate more income for themselves through advertising banners on the page and the purchase of special items. Resist the temptation to publish every little achievement as this turns your news sheet into a running log of "Bob levelLed up AGAIN." "Bob earned his 87th chicken" "Bob found an attractive stone with a hole through it" "Bob has lost his life outside this sad game and can only post about playing flash games".

A few posts from the game are acceptable, My rule is no more than three updates concerning games in any 24 hour period. If the game gives you a chance to comment on the achievement, please do, as it adds to the social nature of the communication, making it more like small talk and less like spam from game makers.

Rule 2.

Major news should never be announced via facebook to close family.

An issue came up recently when a friend of mine found out he was to become an uncle via Facebook. This is bad form. Just because it is an easier way to communicate does not make it the best way to communicate the message.

As a rule of thumb, I would call all people who need telephone calls about the topic. Hang the expense. It's important news. To people who don't rate a phone call, try an SMS or MMS. It's a little more personal. Then afterwards, compose a Facebook message for all your distant friends to rejoice at.

Rule 3.

Death needs 24 hours before it is posted to Facebook.

Death has always had a list of taboos surrounding it in all cultures. Ours is no exception. Give people time to find out via the family before plastering it on Facebook. This allows the shock to wear off a bit before the person can grieve publicly. Otherwise some poor family member discovers that their relative is dead and may find their shock turning to anger because of the way they found out. It is better that family members have this space to grieve privately before doing it publicly.

Rule 4.

Do not use a logged on Facebook account as an opportunity to be funny.

If you find a computer with the browser open to someone else's Facebook account, quietly log out the other user and inform them that they left themselves logged in. Do not deface their news reel with statements about their sexuality, football team or other funny thing. I have yet to see a comment along these lines that has made me LOL, let alone LMAO or even do a coffee spit. It is sad and petty. You are bigger than that. Act so.

And I'm out of rules for the time being. So shall ask people for more now. Feel free to comment below or email me with more.

The joy of .nets

Too long since last post... So here is another one. The job has changed and I find myself a .net developer.

Task one was to take a whole bunch of .vbs files and turn them into neat executables. The easy way would have been to add the wscript dll and go from there. This was what I did first up. But I soon went native because of a little thing called System.IO. All of a sudden file level operations do not need to be wrapped in an On error resume next and then checking if the file you just copied actually exists.

ReDim

I have to admit that the way vbScript handles arrays is abysmal at best and hideous at worst. First of all, what is an array? It is a list. Pure and simple. vbScript expose things like multidimensional arrays, but that is just a list of lists. (or if there are three dimensions, a list of lists of lists).

OK let's declare an array


Dim arrFred(2)


So far so good. now some entries for the array.


arrFred(0) = 1
arrFred(1) = 54


OK so arrays use zero counting. That is the first element of an array is designated 0 and the last is length - 1. This is something to keep in mind as vbScript spends a lot of time flicking between 0 based and 1 based counting for various functions.

Now let's look at what the rant is really about. Say you want to make the list longer by one. Frequently done by people with say, shopping lists. Whoops forgot the eggs. I'll just write it on the end of the list. Lucky for us, there is the command


ReDim arrFred(3)
arrFred(2) = 42


So far so painless. Let's get back to calling that first value now we are at the shops and looking for the flour.


Wscript.Echo CStr(arrFred(0)) 'Outputs ""


That's right my chickadees, nothing. No output. And why? because when we did the ReDim. When you ReDim, your shopping list is torn up and thrown out. All values are returned to Null. Not very useful. So what options do we have? We could make the list impossibly long to begin with,


Dim arrFred(1000)


But my experience is that even if we make this really big, some user puts in more things than can really be dealt with by a really big number. I had a problem with a script that was designed to deal with around 20 servers. Someone then adapted my script to deal with 150 servers. If I had have used the really big number thought, then there would have been a failure there, as "really big" would have been 100 due to other constraints. So where is the answer? vbScript gives us the command


ReDim Preserve arrFred(arrFred.Length + 1)


This grows the array and keeps it's contents intact. Although why Preserve is not presumed for all arrays is quite beyond me and one of the dumbest things I have found in vbScript. If I ruled the world the code would be along the lines of.


arrFred.ClearAll
ReDim arrFred(3)


But I'm not. So I'll just highlight the issue.

Chr(34)

Chr(34). What kind of drugs am I on with this rant? One of th emost frustrating things I have come across with vbScript is it's handling of odd characters. Say I want something that looks like

"Hello,
World."

In Perl this is a matter of typing in

print "\"Hello,\nWorld.\"";

The backslash works as an incoming special character next alert. Double quotes are special characters. It's almost self explanatory that way. The \n means new line. Let's write the same peice of text in vbScript.

Wscript.Echo Chr(34) & "Hello," & vbCRLF & "World." & Chr(34)

It's twice as long, contains an outside object call, two functions and a built in constant. People who say Perl is line noise should have a look at this first. And it isn't as if the scripty people at Microsoft didn't know about \n as a substitute for Carriage Return Line Feed. (new line for anybody who doesn't use dot matrix printers as their text out interface.) They use it for matching regular expressions.

So how does writing things to the screen get to be so messy? I think it's probably down to a battle of wills. For instance, in my job I get to code any way I like to. The decisions I make are my own. The style I use is used by one person on a team of 8. And the down side of this is that I have to know exactly what is going on and document it all to keep up our quality certification.

Because Microsoft has lots of coders and (probably more importantly) managers, we see a battle of wills with their flagship language. If a coder has a new method of making coding more consistent across a range of areas, he has to convince his manager, who has to convince his manager who has to care enough to inform two downstream managers that this should go ahead. That is a lot of convincing to make something go ahead. Not gonna happen.

Whereas Larry Wall when he designed perl started out making the decisions himself. A coder who wished to change the direction of perl needs only convince Larry (or whoever is pump king these days) that it is a good idea and the change will be made. And it doesn't even have to be that bad.

print '"Hello,
World."'


will also work. So we see the difference between the One True Way and TIMTOWTDI.

On a side note, I would suggest that making pop up dialog boxes with more than one line of information in them is probably a bad thing because most users don't read even that one line. The ones that do, probably won't bother with the second.

So what do we do with this horror? I suppose we could all give up and code in javascript or perl, but if you work in establishments such as mine, vbScript is mandated as "The" scripting language. The first problem is the double quote. vbScript refuses to handle it as anything besides the beginning or the end of a quote. Chr(34) is the only way to print this. It is built in. if you feel like it you could include a line such as

Const vbQuot = Chr(34)

which at least has the advantage of readability in the example.

Wscript.Echo vbQuot & "Hello," & vbCRLF & "World." & vbQuot

The other thing that bugs me is the vb prefix to internal constants. Yes it is nice to flag such things, but it puts me in mind of those applications that install under Windows that stick a shortcut in every conceivable place to give the application screen presence. Even when it is not needed. You get a desktop icon, a start menu icon, a quick launch icon, a toll tray icon that does nothing more than chew up memory and slow down start times. They then pin the icon onto your right click wherever possible.

The same thing can be said of the vb. I've paid for the product. Why are you trying to sell it to me over and over when I write a constant?

Enough rants. Must go to bed.

WhereFor art thou loop?

So there I was learning this vbScript thingy. I have a problem that requires a for loop. So I start applying logic rather than reading the manual.


For intFoo = 0 To intEndCount Step 1
Wscript.Echo CStr(intFoo) & ". Hello World"
Next
. . .


I fully expected never to greet the world. I am a cave dweller. Why would I? Logic dictates that any lazy parser would read the first line and say unto itself one of two things. Either "intFoo is already equal to intEndCount, therefore I can jump over this redundant code block and get on with my life." This would have been acceptable to me as I really only wanted the for loop to run if intEndCount was bigger than 0.

The other behaviour which would be less acceptable but at least logical would have been "Error 0xFOAD Dumb use of a for loop. Try RTFM and come back to me." (RTFM = Read that Fine Manual) I'd be quite happy to see such a message as this informs the user as to how clever the parser isn't and allows me to dumb down my code appropriately or pick another language.

What I wasn't expecting was this

0. Hello World

I sat there in wonderment. staring at my scratch pad for a full 30 seconds in disbelief. Why loop through once? Your condition has already been met. I tried some variations. Maybe upping the count to 1 would work

For intFoo = 1 To 1 Step 1

Almost the same result. Only the prefixing digit changes. So I go back to TFM. No mention of this strange behaviour. I asked 5 of my colleagues what they would expect. the range of answers went from zero loops, infinite loops, to error state. Nobody guessed that you get one loop out of it. I even went to the Microsoft Fanboi. The guy who likes Vista. He could not explain it. So rather than trying to bust my head on it, my code now features the following statement.

If intEndCount > 0 Then
For intFoo = 0 To intEndCount Step 1
. . .
Next
End If


The trouble is that all the looping functionality in vbScript WORKS THE SAME WAY. I would suggest that having multiple looping statements should give you subtley different functionality.

Option Implicit

To introduce myself, I'm a scripter for a reasonably large organisation. I came from a perl background doing php to interface with web pages. I now find myself writing in vbScript and missing a few things from the other side of the house.

Learning a new language you will find yourself scraping the net looking for any number of resources that will aid you in writing good code, but one of the frustrations I found was that Microsoft Scripting is not particularly consistent in their code management. There are any number of other forums that will give you band aid solitions for the "How do I..." code. However it gets very tempting to copy and paste from these sites without actually working out what you have done.

So todays lesson will be on two words. The first two words you should write in a vbScript without a comment in front of them.

Option Explicit

What does this do? It forces you to declare variables, it forces you to think about whether the routine you are writing is a Subroutine or a Function. In short, it forces you to stop writing spaghetticode and start thinking about what you are writing.

When faced with a new peice of code that needs to be written, my first step will be to write it out something like this

Option Explicit

' What do we want to do here?
' Open an ini file and check that it contains all the info we want
' grab the latest data from central server
' copy this data out using patching routines
' log all of the above

All of these steps break down quite nicely later on. I only have to fill in the blanks now with useful code. But now I can start using the limitations placed on me by Option Explicit to think about variable names.

At the moment I am coding a fancy "Copy Files" routine that should automate periodic data upgrades once out of testing. I found that this needed a tie in from four scripts to do the job. One to set up the "Golden Source", one to control how many servers to replicate to at a given time. (I'm lucky the system I work on tends to have more servers on it than a lot of organisations have workstations.). One to do the actual copying, and one to launch the product on a workstation at the end of it all. 4 scripts written by 4 people. Each with their own idea about how it should go.

My boss (Who incidentally wrote and maintained the scripts before me) told me that looking after this should be my job. Great. I open each one up and see the pain before me. Spaghetti code and undelcared variables everywhere. Job One to work out this mess? Our favorite friend, Option Explicit. Running the script now errors horribly, but starts to produce a list of undeclared variables and the scope they cover off on. I now have a list of variables and have tidied up some of the subroutines.

What I find is that accross all four scripts are variables that contain the same information, but are called three or four different names. So as part of the rewrite, all global variables are renamed the same thing so it is easy to flick from script to script and see where the information is going and what it is being used for.

The other thing that it does is allows me to reduce memory footprint. Not particularly important to me as I am working on servers and power workstations where any less than 4GB of memory is considered obsolete. But as I go hunting through the subroutines I meet up with some friends.

• objFSO
• objFS
• objFileSys
• filesys
• fs

All prefixing

= CreateObject("Scripting.FileSystemObject")

Hmm. So what would happen if we have one name right through one script called one thing. We would be able to borrow this File System Object any time we want to do file operations. It's a handy class by the way. Does cool stuff. Not nessecarily predictably, but more on that in another rant.

So, because of Option Explcit, accross my four scripts, I only have to open the class once. Less of a memory footprint, and therefore more space for servers to do important stuff, like cope with an SQL call to push out a report to an executive.

Next time? why not have a look at things For a While Until we are Done.