Programatically Uninstall a Software using LabVIEW ( NI and 3rd party )

[Muthukarthik]

Hi Folks,

Today I will add a vi that will programatically uninstalls a software. The only limitation is the Time it takes to generate the list of installed software's and its corresponding windows msi files. In my PC it took nearly 4 mins (I7 6th gen). Try the code and suggestions are welcomed!

Need to reduce the timing though!

ALL FOR LABVIEW ; LABVIEW FOR ALL

[pincpanter]

Since the delay is generated by the wmic program, you can do nothing - at the LabVIEW code level.

FYI, on my computer it takes 70 seconds (Xeon processor, SSD storage).

[Muthukarthik]

Hi Paolo,

                Thanks for your prompt reply, I have a doubt regarding reading a file properties in LabVIEW. Just right click any file and go to details tab. there you can see many properties and its values (like reading ini files ).can we programatically read all of its properties? if we can do, then I can programatically read the msi file properties which will drastically reduce the timing!

*This is an example, the msi files have a property called "subject" which has its corresponding software name.

[pincpanter]

I did not find a straghtforward way to do this. Sure it's possible writing C++/C# code.

You may try dig further into, starting, for example, from here.

[rolfk]

That Property dialog makes it appear as if this information is all conviniently accessible from a single place in Windows. Nothing is further from the truth.

The basic properties under the File section and always shown in the Details Tab for any file type are simply File API attributes such as creation time, modification time etc. retrieved with GetFileTime(). Then you have file size that is retrieved with GetFileSizeEx() and file attributes that you can retrieve with GetFileAttributes(). To make it more interesting the first two require a file handle while the latter requires a file path.

Retrieving the owner is quite different. You need to use GetFileSecurity() to retrieve the security descriptor for that file and from that you retrieve the Access Control List (ACL) for the file from which you can retrieve the owner and access Rights.

The file type is something stored in the registry for the according file ending. This and much more about file properties is not part of the Windows kernel itself but located in the Windows shell component. You can retrieve this particular information with SHGetFileInfo() and the SHGFI_TYPENAME flag.

And now the most interesting part. Anything in other sections in this list than File, is provided by so called property handlers that are registered in the Windows shell for a particular file type. This property handler is implemented as COM Object (not quite an ActiveX component but COM is the invocation mechanisme used in ActiveX). See here for documentation about this system. As it is COM you can only call it from C++ (and sometimes C with some extra effort). Normally you have to create COM objects with CoCreateInstance() for a particular class such as here a shell file enumerator, then initialize its persistent file and retrieve the according shell item and from that retrieve its property handler (if it has any) from it. But the Windows shell already provides this function premade as SHGetPropertyStoreFromParsingName(). But eventhough they are Windows APIs that theoretically could be called from LabVIEW with the Call Library Node directly there are several complications. The first is that most COM APIs only work with Unicode strings which would be possible to workaround. The real trouble is the returned object pointer however. Invocation of its object methods is NOT possible through the Call Library Node. And since COM isn't quite ActiveX you can't call it with the ActiveX functionality of LabVIEW either.

Possibly there are .Net methods that go through this interface rather than using WMI for it. But I wouldn't know and don't really care.

[pincpanter]

As always an interesting explanation from Rolf about Windows internals.

This page explains as an example how to read extended details info (ID3 Tags, in this case).

Of course, not only the code should be written in C#, but it should also be packed into a .NET (or standard) DLL that could be read by LabVIEW.

What I caught in short is this subject is a too complicated one, compared to my interest in it.

However, I guess wmic's search is not as simple as reading properties from a list of files in a single directory, otherwise it would not take so long to get it done.

[rolfk]

The problem with that example is that it references the different properties with "magic" indices. The entire property system in the Windows shell is really dynamic with different property handlers for different file types , and each of them can provide a random number of properties with an arbitrary name. The typical MP3 Properties are already build into the shell and take up the initial 40 or so colums after the standard File Properties. In newer Windows versions there are more standard entries that already come preinstalled with Windows.

The desired MSI properties are most likely not under these properties but somewhere else so it could be quite a search to find the right "magic" index and that could also change between systems and Windows versions. The index based access is really only useful for display purposes like in Explorer but not a good way to access those properties for specific use.

WMI is a monster really. It is basically a data management engine with an SQL like querying interface. It can be extended with data provider modules that funnel everything through this SQL query format. If you know the right magic words you can pretty much query everything about a machine with WMI as Windows provides many interfaces to even very low level hardware components but also about installed software and what else. And the MSI system is in itself a fully relational database engine and that is one of the reasons that it is pretty slow. Add a monster query interface like WMI on top of an overcomplicated database that maintains information just about every single file installed on your computer and you get a sluggish experience for sure.