When writing automation scripts or modules, you might find that you frequently reference external binary data.
“Binary data? Well, that accounts for all data!” you might say.
Yes, that’s true. But I’m talking about binary data as opposed to files containing simple ASCII or UTF-8 data. Maybe there’s some better terminology to describe that, but hey it works for now. Binary data could include things such as:
- Word documents
- Executable (Portable Executable format)
- Code libraries (DLLs)
- Registry files
In the case of executables, oftentimes they provide useful functionality that would take many lines of PowerShell code to replicate. Some developers, for better or for worse, elect to use these utilities instead of going through the effort of writing the necessary code to handle the function natively in PowerShell. This creates an additional dependency when porting the PowerShell code, as the author must be sure to include the utility with their code, or otherwise ensure (via documentation, for example) that the target user will already have it available.
Wouldn’t it be nice if you didn’t have to depend on the user having some executable pre-installed, just to get your script to work, though? Unfortunately the little topic of “software licensing” can sometimes prevent redistribution of software that you are not given explicit permission to copy, however there are also many cases where this is allowed (eg. open-source projects). The work-around in cases where redistribution is not allowed, is to either direct the user where to download the software from, or automate it for them.