Microsoft did something good in Windows 11

I know that I dislike Microsoft because they cheat. But if I’m going to have at least a little bit of integrity, I need to admit it when Microsoft does something good. Yes, they did something good in Windows 11, even if it took them 30+ years to copy the idea.

In Windows 11, you can select a file and right-click on it, and the popup menu lets you copy the path of the file to the clipboard.

If you didn’t know about this, and you start using it, you may be surprised at just how useful this is. I’m not, because I’ve had that functionality all along these last 30 years in WinBatch. For 30 years, I’ve had an easier time of it than you, because I’ve always had right-click clipboard tricks at my fingertips.

And I do have some sympathy for Microsoft taking so long to implement this feature. Microsoft had been caught stealing ideas from software vendors who sold (or wanted to sell) Windows utilities. Wilson WindowWare, the publisher of WinBatch, made Windows better by providing a macro recorder for Windows. It was kind of a sham though, because playing back the same mouse and keystrokes – without the ability to edit the macro – was more teaser to buy a product than helpful.

But if you bought the product, it was magical.

And Microsoft decided (this time) to not stab their partner in the back by implementing the partner’s idea themselves.

I did buy WinBatch. I bought it for my personal use. And in fact, I conviced my employer to buy the compiler, at $500 per year. What that gave me was an unlimited site license to run as many WinBatch scripts as I wanted on every machine in my environment. The compiler embedded the scripts inside a .exe much like the Perl PAR modules do, so you get a Windows .exe that runs your Perl script. The interpreter is embedded, the DLLs are embedded, and the script is embedded, and it all launches from the .exe

At work, I put the runtime DLLs on the public folder of every NetWare server where users log in. I compiled scripts to the small .exe option, and then copied the .exe to the file servers. Well, I didn’t copy them, I had a WinBatch copy them for me. Then I edited the Novell login script to launch the WinBatch exes.

Did I need to take an inventory of every drive letter mapping on a machine? Yes. Could I do that for 2,500 machines and write the results to a shared drive? Yes. Oh, and by the way, how about listing which printers were installed too? This was reasonably competent tech for 2005. WinBatch had a set of Windows Registry search-and-replace calls, so I could launch from a login script a utility that changed registry keys on your machine after we migrated you to a new server.

Anyway, I loved WinBatch, and used it daily. And it came with clipboard tricks: any file, any folder, mulitple files and folders: you could right-click and copy either the name(s) or the full path (including file names) to the Windows clipboard.

So when I saw that Windows 11 added right-click copy path to clipboard I was impressed. Microsoft finally did something good.

Now technically, this feature has been in Windows for a decade or more, but you needed to know to shift+right-click to get the menu option. With Windows 11, they finally just made it available without any weird key combinations. Good job, Microsoft.

Web browsers and automation, oh my!

At work, one of my job tasks is e-discovery, which means logging in to an email archive web application, doing searches, and tagging the items that meet the search criteria. The web application was originally written by one guy (I think) and although the back-end stuff is amazing, the actual web pages I interact with are twitchy. There are more than 110 million emails in this archive; and the search and indexing features are great. But the results pages? Sometimes I have to deal with a lot of them, and the smart way to go is automation.

(As I write this, the one automation script is working it’s way through 88 pages of results, and the script tells me it will likely be done in about 15 minutes)

When I say the results pages are twitchy, what I mean is that the buttons on the page move, after they have been clicked. Usually, but not always – and that is dependent on the web browser.

I’m using WinBatch to automate driving the web page. Specifically, there is a start cycle process, where I go through the motions of which buttons to press; but, I don’t press them, WinBatch does. To signal WinBatch that the mouse co-ordinates are correct, I tap the Shift key. There is a super tight loop in the WinBatch script which is recording where the mouse pointer is (it’s a 1000 * 1000 virtual x-y coordinate system). It reads the x-y coordinates, checks to see if the Shift key has been depressed, and if so, it records the coordinates for that button, and then moves through to the location of the next button that needs to be defined.

This works fine if the buttons do not move. But under some browsers, clicking a button moves elements on the web page. I’m sure this is a CSS / Javascript thing that happens because the initial development was all about how to wrangle millions of emails, and not about web page design.

So, under Google Chrome, the web page is the least twitchy. But Google with their Chrome browser are a bunch of rat-bastard bullies, so I can’t really use it. We have an internal (private) domain name, which means our SSL certificates are self-signed. Yeah, Google Chrome hates on that. Most recently, the problem is that the server is old. We ran into a problem trying to upgrade, so we didn’t. But that means the SSL on the web page is TLS 1.2 – to which Google helpfully tells me to go kick rocks.

Okay, what about my favorite browser, Firefox? It is the most friendly when it comes time to just get things done; but, it is the most twitchy. Sometimes the email archive server gets in a state where the web page dialog boxes pop up off screen; this only happens with Firefox. I had actually opened up a technical support ticket with the email archive vendor for this, and they told me to stop Tomcat, Apache, MySQL, empty a cache directory, and start everything back up. That worked, so the vendor never actually tried to figure out what was going wrong. Recently, I’m having to share the server with people doing email exports, so I can’t just willy-nilly bounce the services. If the services have been bounced recently, Firefox works fine. But if it’s been a few days, then I can’t. I don’t want to re-write a portion of my WinBatch script to try to find the top of the web page, then the bottom of the web page, just to support this twitchy behavior by Firefox.

Okay, what about Microsoft’s Edge browser? It’s based on Google Chrome, so it might have better HMTL element layout like Chrome has. Alas, during the loop to track where the mouse pointer is, Edge just really doesn’t like refreshing the screen / sharing anything with any other program (WinBatch). So I could not actually get the location of the buttons on the web pages to play the mouse clicks back later.

Finally, I have tried the Brave web browser. I’m not terribly fond of it. It looks to me rather like a front by Google to try to get people who are suspicious of Google’s privacy violating lifeblood to use the Chrome browser anyway. But, it has the advantage of being based on the Chromium engine (which creates the least amount of twitch).

Nicely enough, it isn’t trying to be the bully that gives me the finger for trying to access a self-signed cert web site over TLS 1.2. I can actually get work done now.

Weirdly, it’s the only browser that causes the “Next” button (to advance to the next page of search results) to twitch horizontally. I need to position the mouse pointer over the “t” in Next, let go of the mouse, and tap the Shift key to set the position. Sometimes the Next button shifts to the right, and sometimes it does not. But if it does, then when the mouse pointer gets played back to the same position, is still over the “N” in Next, and the button press does work.

Wow Perl PAR::Packer sucks

I presented a problem to my boss, where I need to let about 30 desktop technicians run some code I’ve written. My boss said when he is in that position, he writes it in PowerShell, and uses PS2EXE. This is good idea. I found that in the Perl world, the same idea is in PAR::Packer.

A super simple script, running on my Linux box, takes less than one second to run. Open up an SQLite database, fetch all 20 records, sort them, print them. Simple. Less than one second.

The Windows .exe version takes 19 seconds.

Every. single. run.

There is no way that the on-call technicians who have to run the scripts I’m writing are going to be happy with that. And it would make me feel bad, inflicting that sort of this-is-time-of-my-life-that-I-am-not-getting-back on some poor soul who got a call at two in the morning, to deal with whomever for whatever.

Normally, on Windows, I used WinBatch. Did so for 20 years. But alas, WinBatch was always a for-pay product, and eventually hobbyists wrote AutoHotKey (or was it Auto-It?) (for free) to do everything WinBatch does. Also, the real goal was to take my Perl scripts that use REST to get and put JSON or XML at a web service. WinBatch has lots of old extenders, but rarely any new ones. I don’t know of a REST extender for WinBatch. I don’t know of anything in WinBatch that does what DBI does in the Perl world. The WinBatch answer is to install MS Access (or whatever) and use COM to drive the actual database client. Avoiding installing software is part of the goal here. I need something That Just Works.

And preferably works in a second or two; not twenty.

I’ve got REST modules written in Perl. I’ve gotten far enough in my Perl skills to put standardized code in modules, and then use those modules. But that meant putting modifying the search environment for finding modules. Guess what doesn’t work with PAR::Packer?

Okay, crap, I can move all my modules into the root directory where my scripts are. This is stupid, but I’ll do it.

And then I find that the execution speed of even a simple script is terrible.

Searching for a solution, of course the answer is “You’re doing Perl wrong, if you don’t want to install an entire development environment on every workstation”.

Well, thanks for nothing. Apparently I need to give up Perl and start learning PowerShell. PowerShell does rather look like Perl, so maybe it won’t be too terrible of a transition.