In the general case (not always,) yes, using one of the many "Windows Macro Recorders" with scripting features. (Also, the controlling side may be another GUI program, not command line)
I went down to the basement again ;) and found the following:
Disclaimer, I have not used any of those.
-- Roberto Waltman
[ Please reply to the group. Return address is invalid ]
Correct. Actually there are multiple tags: the archive itself has a tag that indicates what program version created it, and then each individual file has a tag which indicates how/if it was compressed.
The archive information structures are backward compatible ... using an program old version you just may forfeit some of the information fields found in a newer version. But an older program won't understand newer compression methods and so may not be able to extract the files.
And, as I said previously, if the archive might exceed 4GB, zip and Winzip won't work ... you need zip64.
NTFS always has permitted a 12 terabyte file, but 32-bit programs had to use the extended Win32 file API to access them ... programs using C library functions simply couldn't do it. Even Windows own (filesystem) Explorer didn't accurately report file lengths > 4GB until, IIRC, NTsp3.
George
No and yes. A program must be designed deliberately for command line use. WIndows programs normally do not use the command line or environment variables (other than PATH) for much of anything.
However Windows scripting (WSH) or Powershell can send menu and mouse clicks to any program - and also can directly drive programs that are designed for automation with OLE, COM, etc. - so it is technically possible to create a command line "driver" for any program.
NB: Powershell requires .NET. WSH requires a service be installed on some platforms.
George
Some programs do support an "automation" interface, allowing its functionality to be accessed from a script, but only if the author bothered to put effort into supporting automation interfaces.
Depends on the program. Since many windows users have never seen a command prompt in there life, few bother to add support a decent command line interface for their application.
Windows and their applications are mostly targeted at non-programmers (people with little or no interest in computers), as opposed to *NIX which are mostly intended for programmers/system administrators. Though Micrsoft has made some halfhearted attempts to build in some facilities into Windows to make it more scripting friendly (e.g. Windows Scripting Host, PowerShell), but its lack of consistent vision over the years has resulted in a inconsistent mess which severely limits what you can from a script.
OK. But, there is no common, preexisting mechanism by which one can drive any arbitrary program?
And, presumably, every program that is *designed* with "automation" in mind, defines its own interface? I.e., the verbs that it exports need not correspond with the actions available on the menus, accelerators, etc.?
Never a problem (on Wintel boxes) here. 1GB is the largest "currency" I tend to use (big enough to hold a lot, small enough that a "loss" doesn't hurt me badly!)
Note that this isn't the same issue. I.e., the 4+GB file, in this case, resides on another box (non-windows). But, IE gets the size information (as an FTP client), sees that it exceeds 4GB (i.e., we're not talking about a case where only the least significant portion of the size is being held) and displays it *as* "3.99G".
Windows (XP) correctly displays the sizes of 4+G files
*locally*. It's just IE that is brain damaged...
No, there is no common mechanism.
Things like Powershell or macro (mouse and keyboard) recorders can help a bit, but they are not reliable for most programs. If a program can be controlled well by a keyboard, then it's probably a good candidate for a macro recorder. But there are still all sorts of issues that get in the way. Pop-up windows can be a pain as they move around, and unexpected message boxes ("There's an update available!") will ruin your macro script.
Power-shell also likes-to use-hyphens every-where. It's nice to see that MS has finally realised that command-line control is an important tool for administrators, but they'd have been better off making a few useful windows-specific command line utilities and shipping MSys with Windows.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.