Blind Not Dumb (Posts about windows)

Windows Papercuts for *NIX Developers

Chris Patti — Tue, 04 Jul 2023 17:42:31 GMT

Introduction

If you're used to developing on *NIX systems, coming to Windows can be a bit of a shock.

My goal in writing this article is to point out some of the pain points and, where I know they exist, some work-arounds.

Note that I'm talking about native Windows here. If WSL meets your needs and your environment allows it (not everyone's does. Many IT orgs turn it off) then bully for you but this article isn't about that :) I think WSL is both an incredible tool for developers and an awesome feat of engineering. I wish more Linux folks appreciated this. Anyway :)

So let's get started!

The Paper Cuts

The C Compiler

For most of us, having a standard raft of development tools on hand is par for the course. We just expect gcc and make to be there at our beck and call, and the fact that they're not can cause some tools to fail spectacularly.

For instance, whenever I start my editor of choice (Neovim) I'm greeted with:

Having spoken to some experts, apparently it's considered really bad form to leave your C compiler on the PATH on Windows. I suspect this is because malware on Windows is such an incredibly pervasive problem.

I get that, but then we should probably either modify our tool-chains to not expect that as a default or maybe create documentation to help people understand the happy path.

As near as I can tell, the 'standard' set of c/c++ tools on Windows is Microsoft Visual Studio. The free "Community" version works just fine though the installer is a bit of a jank-fest.

That thing provides a prompt shortcut called "Powershell for VS XXXX" and you can use that to get a shell that has the usual build tools available.

Not a great solution though, since the experts say not to run that way as a default, but having your editor blow up on start just-up isn't a great feel.

The Shell

While you certainly can run tools like bash or zsh on Windows, unless you really know what you're doing, this is not the happy path. You're in Rome. Do what the Romans do and you won't regret it :)

The good news here is that the native tools are now really quite good. Gone are the days when CMD.EXE was your only choice. You now have Powershell and it's really quite awesome.

Here are a couple of tips to make your Powershell experience awesome and help you appreciate what this environment has to offer.

Oh My Posh

This one's gotten a lot of press and let me tell you it's incredibly well deserved. It's like the oh my zsh of Windows shell prompts :)

Mine shows me git status and whether my last command's exit code indicates success or failure, as well as what Git branch I'm on. Here's what it looks like:

I wrote some about Oh My Posh in my previous article on Windows for Python Developers.

PSFzf

One of the biggest productivity boost for me in recent memory was when I integrated fzf the fuzzy finder into my workflow.

With a single keystroke I can find any file or directory on my system. Navigation becomes effortless and the endless sequence of cd and pwd commands melt away in a burst of productivity goodness :)

Thankfully, Powershell offers all these benefits as well via PSFzf.

Here's what it looks like. In this case I wanted to edit my Neovim main configuration file init.lua:

The Console / Terminal

For long time *NIX users, one of the biggest bones of contention for a long time was the Windows console. To put it kindly, it was god awful, mostly because it maintained compatibility with the Antideluvian DOS console.

Happily, we now have a fairly decent solution Windows Terminal. I say fairly decent because it's still not quite up to par with your favorite NIX terminal, but the fine folks behind this open source project are working really* hard to change that, and the progress they've made here has been nothing short of miraculous. Mad props to these folks for fixing by far the biggest deal breaker for many around working in Windows!

They've even recently added an easier UI for editing settings, but you can also still go edit the JSON yourself if that's your jam :)

It's not perfect, but this is an incredibly flexible tool with a ton of depth and it's been exciting to watch it evolve.

The Windows Desktop/GUI

I'm sure there will be folks who aren't happy with this one but my take? Just ignore it.

Windows is pretty good about making EVERYTHING accessible from the keyboard, and many things are also accessible from the command line. If you just avoid graphical interfaces wherever possible, and if you're anything like me, you'll see your productivity levels soar and your frustration levels plummet.

Packaging

One of the big pain points coming from *NIX is the lack of a 'real' package manager.

I use the winget tool that comes bundled with Windows 11. It's officially supported by Microsoft and lets me install most if not all of the commercial apps I use.

It has the further advantage that it will write a JSON blob with all the packages you have installed, so you can get your software up to snuff with a single Powershell invocation.

But there are other popular options as well, namely Scoop and Chocolatey.

To be honest I wish MSFT had worked a bit harder to maintain compatibility with these other projects so we don't have multiple separate package namespaces. Can't have everything I guess.

Where Do I Put?

One of the things I continue to struggle with is the simple expedient of "Where do I PUT things?". On UNIX based systems, pretty much everything user or configuration related lives in $HOME. Not so on Windows.

As just an example, my Neovim configuration lives in something like $HOME\AppData\Local\nvim.

In some respects, I get it. Keeping application configuration separate is a good thing, but navigating where to put what can feel like a bit of a morass for the uninitiated.

Maybe once I get a better understanding of the lay of the land, I can create a cheat sheet for UNIX users.

Fin

That's all I have for now, but I may update this post as time permits or if various situations I detail here improve. Thanks for reading!

Getting Started With Python On Windows 2021 Edition: Push The Easy Button!

Chris Patti — Sat, 06 Nov 2021 05:45:00 GMT

Don't Despair! This Is Gonna Be Easy! :)

Over the last few months I've seen a ton of confusion swirling around social media about how to help people who are new to Python development and software development in general get up and running on Windows quickly.

GOOD NEWS! You can ignore all that. Many of these suggestions are well meaning but come from people who don't actually do Python development on Windows regularly.

Note that I'm not going to tell you the 5 different ways to do a thing, I'm going to tell you the ONE easy way :)

So let's get started!

Side Note: Everyone Will Tell You To Use WSL - You Probably Don't Want That!

I hear a lot of incredibly talented and experienced well meaning UNIX/Mac enthusiasts tell newcomers looking to get going on Windows "Oh well you just use WSL! It's easy! Then you install python with apt get yada yada, and then you install pyenv, and then you configure your shell's environment to use the right shims... and..."

The truth is that if you want to learn Linux - you SHOULD! It's an incredible platform and a virtually bottomless font of power waiting for you to tap.

But if there's one thing I've learned in 30 years in the tech trenches, it's that trying to learn a million things all at once is the surest way to learn nothing. Why not focus on teaching yourself Python programming first and then exploring Linux as a separate effort?

Install Python

If you're on Windows 11 (And I recommend it if your hardware is new enough!) this is as simple as bringing up a Powershell in your swank Windows Terminal. If you want a look at my setup please go read my article on that.

Anyway, all you have to do is type:

winget install python

That's it! This will install the latest stable version of Python from The official Python website. If you're not lucky enough to be running Windows 11, just download the latest stable version from the website's Downloads page and double click on the executable file in your Downloads folder. If you're not sure just keep clicking Next on the dialogs and in a few minutes you'll have Python installed!

Embracing The Power of Py! (Psst. This Is The Easy Button!)

The 'py' Python launcher used to be a super power that only Windows versions of Python shipped with, but now thanks to Brett Cannon, an amazingly prolific Python core developer's hard work our UNIX friends can enjoy the easy button as well!

So let's get this party started and see how easy it is these days to get into the Python prompt:

Pretty easy, right?

Note that py has other superpowers as well. It can list all the python versions you have installed, and also let you choose which version to run with the arguments you choose. Run:

py --help

to see an exhaustive description of all the magic tricks py can do :)

Set The Stage

Again, from your Powershell, create a project directory for yourself. Programmers often create a 'src' directory wherever it's convenient (Maybe in your home directory?) and then put their projects underneath.

So let's go ahead and do that:

CD $HOME
mkdir src\starwars_characters

# Yes i'm a big nerd. Our project will pull down a list of characters in the movies from the Star Wars API :)

cd src\starwars_characters

Building A Sandbox

Now let's create a safe space for our project so we don't unintentionally install libraries or other experiments in public. This can lead to situations where you go to create another project but a library you installed previously either causes undesirable behavior or perhaps is even in a broken state, getting in the way of you getting your work done.

We're going to create a thing called 'virtual environment'. Don't worry too much about the details, just think about this as a nice tidy sandbox for us to play in where we don't have to worry about breaking anything outside.

Again from our Powershell prompt:

# Actually create our virtual environment. Put the bits in a folder called 'venv'.
# Most Pythonistas use this folder name, but you can use any name you want :)
py -m venv venv

# Actually activate our new virtual environment in our Powershell
.\venv\Scripts\Activate.ps1

Let's see what happens when we do that (Assuming you're running Oh My Posh, and you should be if you followed my setup article):

See what happens there? We create the virtual environment, and our shell notices which Python version it uses, and tells us that in our Powershell prompt!

Then, we activate our virtual environment, and now our prompt adds a (venv) at the beginning. With this visual indicator in plce, we know we're safely ensconced in our sandbox and can start playing with no worries!

Install Necessary Libraries

You'll need an editor or an IDE. I use Visual Studio Code. It's free, it runs on any modern computer, and it offers an incredibly rich set of tools to help you with your development. Bonus points? It's also free, and even largely open source.

Let's get started, and tell Python which libraries we'll need for our project:

code requirements.txt

In this file, add a single line:

requests

If you want to add a truly superlative interactive Python environment with which to prototype and explore, you could also add IPython:

IPython

(Note IPython here is case sensitive so be careful!)

Now, still in our Powershell prompt, type this command to actually install these required libraries into our virtual environment:

py -m pip install -r requirements.txt

You should see some messages about libraries being installed. Note that you invoke IPython this exact same way:

py -m IPython

Write The Code

Create a file in your project directory called starwars_characters.py with your editor that includes the following code:

import requests

STARWARS_API_URL_BASE = "https://swapi.dev/api"
GET_CHARACTERS_URL = f"{STARWARS_API_URL_BASE}/people"

response = requests.get(GET_CHARACTERS_URL)

response_json = response.json()

characters = response_json['results']

for character in characters:
    print(f"Character Name: {character['name']}")

Here's what my Visual Studio Code session looks like with this code loaded and the output shown in the run window:

Notice that bit at the bottom that says 3.10? That shows us that Visual Studio Code automatically detected the Python we have installed in our virtualenv. You can click on that to see a list of installed Python interpreters to choose from.

We can run our new project either by using the Run menu inside Visual Studio Code or on the command line with that very same py syntax we used before:

py starwars_characters.py

The End Is Just The Beginning

Well there we have it! You have Python installed and running, and you've built a small but interesting Python project right here on your Windows machine!

The truth is, a large number of people have put in innumerable hours making Python drive smooth like a Cadillac on Windows, so if you find yourself using and enjoying it, the next time someone tells you to abandon all hope and install Linux/WSL, be sure to point them at this article! Maybe if we change some minds we can help bring more Pythonistas into the incredibly awesome Python community!

Please feel free to leave comments with any questions, or hit me up on Mastodon or Twitter.

I'd love to hear from you!

Windows Scripting - a VBScript Survival Guide

cpatti — Wed, 31 Mar 2010 19:18:00 GMT

1. Introduction

If you're new to the world of Windows scripting as I am, the array of acronyms, technologies and access methodologies that you need to traverse in order to get anything done can range from bewildering on a good day to utterly derangement inducing on a bad one.

I've been doing installer and deployment development at a Windows enterprise software company for the last year or so, and after decades spent comfortably swaddled in the familiarity of the UNIX and Java world, I definitely found myself feeling shell shocked, disoriented, and frustrated at the lack of any sort of cohesive resources to aid me in my quest.

Microsoft has been doing its best to pretend VBScript doesn't exist - touting Windows PowerShell as the way and the light. PowerShell is indeed an awesome tool, and I for one would happily consign VBScript to the briny deeps never to be thought of again were it not for one little problem - the vast majority of Windows systems running in the wild don't have PowerShell installed. Until a new day dawns and PowerShell is on *every single* Windows box our company wants to install its software on, VBScript remains the lowest common denominator for system scripting and thus the only real game in town for install time scripting.

The goal of this article is not to teach you VBScript, sadly, there are essentially no books and precious few online resources dedicated to this topic online. I will offer pointers to those that I have found most useful, and some collected wisdom on how to best make use of them, as well as some pitfalls I encountered which with any luck I can help you avoid.

That said, let's get started.

2. Learning VBScript

This will mostly be a collection of pointers to resources with a smidgen of commentary on each to get you moving in the right direction.

A. Books

Windows XP Annoyances - This book should really be titled "Windows For Geeks" :) it is the single most useful book I have ever encountered for someone trying to make the transition from another environment and isn't content to just grit their teeth and groan at all the annoying defaults Windows ships with. In addition to an incredible amount of depth around the Windows registry and how you can wield it to suit your needs, this book also has one of the best simple introductions to system scripting with VBScript I've seen. Two thumbs up. Note that this is the 1997 edition, and this book now comes in Windows Vista and Windows 7 flavors which I haven't read, but can only assume are equally awesome.
visualbasicscript.com - This is far and away the single best VBScript resources on the intertubes. The folks in these forums are experts, and will help you solve your problem virtually every time. I can't say enough about the incredible community here. Nine out of ten times, if I go looking somewhere else first I end up coming back here and wishing I hadn't wasted my time elsewhere first :)
Microsoft Script Center / The Scripting Guys - The second most useful scripting site on the web. The Scripts Repository and "Scripting Guys" MSDN blog are an incredible resource for system scripters. While the emphasis has definitely shifted towards PowerShell these days (and rightfully so) most of the techniques discussed can be leveraged in VBScript once you get cozy with the syntactic differences between the two (very different) languages.
MSDN Windows Scripting Technologies - This page covers things like the Windows Scripting Host, the core technology that actually allows you to perform useful work in VBScript. While somewhat more complete than the VBScript reference itself, it's no great shakes. You'll find yourself learning much more from examples published elsewhere, but for the occasional API lookup or clarification it can be useful.
MSDN VBscript Reference - You'll note this site's position well down the list. It's there for a reason. The documentation provided here is very sketchy and frankly incredibly misleading in places. The authors seem to have weaseled out of writing a more complete documentation set by making a vacuous assertion along the lines of "Well, it's just like regular Visual Basic, with a few minor differences". This leaves people like myself who have never had the need to touch a fully fledged VB implementation out in the cold, feeling like second class citizens. While these pages can be useful for occasional clarification on some obscure language feature, those seeking to understand how the language works in the large should definitely look elsewhere.
Windows Script Debugging Microsoft KB Article - This article will get you started interactively debugging your scripts using Visual Studio. Don't bother with the Windows Script Debugger, Visual Studio Express is free and much better :)
W3Schools VBScript Tutorial/Reference - This page is definitely rather Web-centric, focusing on VBScript in classic ASP programming, however, the core language and some of the techniques are the same. In many cases this is a better reference than the MSDN one, and the tutorial lets you work through the examples online in a web browser which is cool.

3. Debugging

Who turned the lights out?

If you find that some script you've inherited is not working, but you get exactly zero output or errors, look for the telltale On Error Goto 0 or On Error Resume Next statements. These basically disable VBScript's inherent error handling functionality and cause your script to silently ignore errors. Helpful, eh?

That's all!

Hopefully this post will prove useful to some poor soul, manacled in place, suffering through their own personal Windows induced hell. Even if it isn't, these tidbits have been rattling around in my head since I escaped (I now work for Blue State Digital, we're a LAMPs shop (Linux, Apache, MySQL, PHP) and I hope to never be trapped in Windows enterprise limbo again!

3 Things Microsoft Should Do for Release Engineers

cpatti — Thu, 28 Jan 2010 18:39:00 GMT

For the last year or so I've been working at a 100% Windows based enterprise development shop. They ship a fairly large and complex application for health insurance providers, which draws on many of the core technologies in the Microsoft enterprise stable.

This post highlights a few things that make working in this environment a whole lot more onerous than it needs to be in my opinion, so let's get started.

1. Installers

The Windows installation landscape has been a bleak one indeed for a very long time. Tools like Installshield with their own proprietary languages like InstallScript make installer development unnecessarily painful and baroque. Is there really any reason I should be programming in a language with no real data structures to speak of in 2010? Even flow of control is handled in a way I can only describe as baroque. There are methods/functions, but the main body of your installer's code has to jump around everywhere using goto. What a mess.

There is hope on this front, in the form of WiX, the Windows Installer XML toolkit, which allows developers to iteratively build and design their installer along with the regular development process. Right now however the learning curve seems incredibly steep. Perhaps Visual Studio could generate a template WiX project to get people started?

I'd also love to see some thought given to simplifying the deployment model for things like COM+ - which feels to me like a magic black box with myriad buttons and levers, all of which are a bear to get right at install time.

2. Builds/SCM

MSBuild needs to have dramatically better documentation, and to a lesser extent so does TFS - they get the broad bits right - everything you could want to do through the UI is covered, but process automation using scripting / command line tools gets substantially murkier.

In the 'credit where credit is due' department, the TFS team has been incredibly responsive on their forums, and that's what's helped us get by so far, but there's no substitute for first rate docs.

3. Infrastructure Scripting

As of right now, there are a thousand different interfaces to accomplish the same thing, and for complex configuration tasks like configuring IIS at install time, the possibilities can be dizzying. I would like to see Microsoft choose one mechanism for run-time system/software configuration and document the heck out of it.

Kudos to the PowerShell team and The Scripting Guys for making great strides in this area. PowerShell is a really nice environment for all kinds of scripting, and I look forward to the day when we can eliminate VBScript from our installers entirely in its favor, but we're not there yet sadly. The object pipeline is one of the more powerful concepts in the modern scripting milieu, and I think Apple and the UNIX world could take a page from PowerShell's book in this regard.

Being a release engineer in a Windows world presents some very interesting and different challenges for someone coming from a UNIX background like myself, and with a little bit of emphasis and effort on Microsoft's part, surmounting them could be a whole lot less painful.

Something for nothing when you don't WANT IT is still damn annoying.

cpatti — Thu, 02 Oct 2008 15:02:00 GMT

Dear Sun;

When you tell me I hava Java (TM) updates available on my work Windows machine, I gleefully say sure why not and click through the installer, because generally Sun provided updates to my installed JDK don't do anything evil, and with security and all it's a good idea to stay up to date.

HOWEVER - trying to shoehorn OpenOffice into the mix is downright annoying, and I resent it.

I don't have anything at all against OpenOffice. In fact, it's a Class A piece of open source software and is damn impressive for what it is, what it does, and how much it costs ($0).

However, I and many other users have exactly zero use for OpenOffice because we have the arguably more powerful Microsoft Office suite already installed on our machines.

I take no issue with having a little checkbox that says "Hey, want to get OpenOffice along with Java?" because at least I can check that off if I want, or not. But having your Java update installer constantly display ads for OpenOffice, and having it give me no choice in the matter as to whether or not I want the ferschlugging OpenOffice installer is just wrong.

The software sells itself, Sun, there's no reason to try to sneak it under the radar of unsuspecting users just because you want to be able to claim more seats. Last time you tried this with Netbeans, and look at how well that turned out!

So, get a clue people, really. Truth in advertising, let me do what I mean and don't try to install software that I need whether I realize it or not, it just pisses me off.

Grumph, enough ranting for now :)