blog.immatt

I'm Matt - You're here for my blog!

Category: Windows

Running Windows 11 on Apple M1 Silicone under MacOS

July 13, 2023 / / 0 Comments

Wait. What? Say huh?

Okay. Whatever. If you’re reading this, I have to assume you read the title of the post and so know why you’re here – so let’s dig in.

I recently purchased a new Apple MacBook Pro for things and stuff. Because I like to waste more time doing things that feel like work rather than doing rewarding actual work, I figured I should figure out how to most quickly violate the laws of nature – and what faster path to condemnation than to install Windows 11 on Apple silicone (specifically, the M1 Pro).

Note: This post is going to discuss how to get the ARM build of Windows 11 running on Apple silicone – a point worth noting, as there may be some limitations.

Up first, we need to install UTM – https://mac.getutm.app/

I won’t get into the specifics of installing UTM – if you’re here, on my tech blog, reading a super nerdy post about running an OS on a platform that god herself has forbidden, I assume you know how to drag the little app icon thingy into the application folders icon thingy… Cool – installed.

Up next, you’re going to need a Windows 11 image to run, right? Here, we’re going to use the Windows Insider Preview (which requires an Insiders account – so get to registering in the likely event that your Apple Fangirl/Fanboy butt doesn’t already have one) – https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewARM64

Now go get a tasty beverage while you wait for that Windows 11 download to complete – I averaged 2MBs on my ~300MBs connection…

Downloaded? Cool-cool-cool. Now we need to get it running…

Let’s open up UTM.

With UTM open, you’re going to want to click on ‘Create a New Virtual Machine’:

And then ‘Virtualize’:

And then ‘Linux’:

Wait… No.. Not ‘Linux’ – ‘Windows’, dummy… Gah….

Ensure you click ‘Import VHDX Image’ and then click ‘Browse…’ and browse to the Windows 11 VHDX that took one million years to download the last time you tried to complete this tutorial before ultimately walking away and forgetting that you were trying to get Windows running on your MBP M1/M2:

Special Note: Previously it would seem you needed to manually download the ‘SPICE’, similarly to VirtualBox Extensions, but this now seems to be handled automagically (assuming you’re not a dumb-dumb and accidentally deselect ‘Install drivers and SPICE tools’ like I may or may not have the first time I did this).

Click ‘Continue’ to proceed to configuring your memory and CPU allocation – I’m opting for defaults because I want Windows 11 to run like garbage and to be painfully slow:

Then optionally configure a share between your host (MacOS) and guest (Windows 11). I recommend this as how else are you going to easily screw up your line endings while working in Git repos?:

After clicking ‘Continue’, you should be presented with this totes helpful Summary screen – just click ‘Save’:

Watch the super cool spinny:

Now we’re ready to start the setup/install process – click that little ‘Play Button’ in the middle of the preview or up at the top at the toolbar (or just figure it out – maybe recite a little spell or say a little prayer, I dunno…):

Things seem to be happening:

“ARE YOU READY?!?!” -Jonathan Davis:

Ah.. A ‘moment’ – such a fun imaginary increment of time…but then again, isn’t all time imaginary? But for real – maybe go do something else…this is going to take a while…:

Some PLURAL moments later, you should be dumped out into the Windows setup – just proceed until you can’t anymore (e.g. see next step for network workaround):

After clicking Continue a couple times and Skip, you’ll likely find yourself stuck on the following screen:

Now what? Let’s just move on… Press ‘Shift+F10’ (so fn+shift+F10) to open a command prompt and then type ”OOBE\BYPASSNRO” and press [ENTER] (okay…okay… ‘return’):

The Windows 11 image should restart and the setup process should restart – once you progress to the Network screen, you should now see a new option – ‘I don’t have internet’ (anyone notice how poorly styled that is? It’s like MS doesn’t like this option or something…):

Click ‘I don’t have internet’ – and then click ‘Continue with limited setup’ on the following screen:

Accept the License Agreement and then setup your account on the following screens:

There are a handful of screens not captured in screenshots here – BECAUSE I’M LAZY!!!! Just ‘Next’, ‘Next’, ‘Next’ until you’re done – I opted out of all optional settings (which I simply mention in case you do something different and then have an error)…

After a few moments and a few friendly progress screens, the Windows setup should be complete – and you then should find yourself looking at your shiny new Windows 11 desktop!:

But we’re not quite done yet – if you try to do much, you’re likely to see what I mean:

We still need to get network ready…

First, you’ll want to click on the little CD/Disk icon to access the ‘Drive image options’:

Then select ‘Install Windows Guest Tools…’:

You may get a notification that the image is already mounted – in which case, sorry for wasting your time, you can carry on…

Next you will want to access the mounted disk, which is mounted as a virtual CD/DVD drive: – run ‘spice-guest-tools-…’ by double clicking it:

Yes:

Next and then ‘I agree’ should get you installing:

Reboot now:

After the reboot completes, you should find your Windows 11 install a bit more useful:

Up next in our series, we’ll look at setting up WSL2 under Windows 11 under MacOS 🤣

I hope that you’ve found this of value in angering your respective gods! Happy Dev’ing!

-Matt

Taking the New Windows Terminal for a Spin

June 12, 2019 / / 0 Comments

If you’re a techie, you’ve probably heard of the shiny new Windows Terminal. While not currently available via an official Microsoft build, I decided to give it a spin – which, due to Microsoft’s commitment to Open Source over the last handful of years, is now possible!

4 realz – they do!

Essentially, the new Windows Terminal is a wrapper application of sorts that allows for a tabbed CLI interface for all supported command line environments within Windows. Bash (via WSL)? Check! Powershell? Check! Old faithful CMD? Check, check and check!

Of course, unifying all CLIs isn’t sexy enough for Microsoft in 2019 – no sir! In addition to providing an all-in-one interface for the various CLIs now running under Windows, a slew of customization features have been added as well – with more currently in the pipeline for the coming releases.

This post isn’t intended to be an installation/build tutorial, but instead is more of a fluff piece detailing my personal experiences getting up and running, as well as a couple of tips and tricks picked up in my little bit of time spent tinkering.

I was able to get running relatively easily. I found the official readme instructions for the project pretty solid – getting me 99% of the way there. If you’ve not tried, I’d recommend visiting the Github link and checking out the Getting Started section: https://github.com/microsoft/terminal#getting-started

One of the first things you’re likely to notice is the requirement to be on Windows build 1903 ( >= 10.0.18362.0). Though by no means complicated, this was by far the longest part of the setup for me. Initially my efforts to manually download and install the build update proved fruitless, largely due to me having missed a required incremental update between what I was running when I started and 1903. Fortunately, a couple of quick Googles revealed that mere mortals, such as myself, could use the built in Windows Update to get to 1903 – once I got all of the required updates in place, I was eventually presented with the option to install 1903.

After getting Windows 10 up to 1903, I realized that I didn’t have Visual Studio proper on my newest dev machine – this proved to be the next longest part of the process. Having been using VSCode exclusively for the last year+ doing Angular dev (and in part due to no longer having a personal MSDN), I’d just not found a need for Visual Studio until now. Being a bit out of the loop on the IDE, I decided to go with the latest and greatest – installing 2019 Community.

There you have it – the bulk of the technical work. 1) upgrading Windows 2) installing Visual Studio. With these two time sinks out of the way, I was able to follow the rest of the instructions pretty much directly and get a working build (note: as mentioned in the readme, I was prompted to install some additional tooling as a result of opening in 2019, but this was seamless and handled automatically by VS).

The observant observer is probably thinking “Well… Okay… Lots of words to essentially say ‘I did it by reading the linked instructions’… Why am I reading your post?” Well, let me ask you a couple of questions, in turn, observant friend… Do you like running your app after building? Do you like animations in your CLI to breakup the mundane monotony of executing command after command? Well, then you’ve come to the right place! Keep going!

Running Windows Terminal

If you’re like me, you found yourself doing a victory lap after CTRL+Shift+B didn’t blow up your PC. If you’re like me, then you likely found yourself scratching your head about which one of the many build output artifacts you should be haphazardly clicking on in order to see your awesome new Windows Terminal. The answer: “None of them”. Something that wasn’t quite clear to me was that the application actually needs to be locally deployed in order to properly run. To deploy, simply right-click the ‘CascadiaPackage’ project and then click ‘Deploy’. Note: If you’re following the instructions, you’ve enabled Developer Mode, which is required – if you’re not following the instructions, then shame on you.

Deploy == Install

Once deployed, you should be able to locate “Windows Terminal (Dev Build)” in your Start menu.

There it is! Isn’t it beautiful?!

Okay, great! We have a terminal!!! But… we already had a terminal (or few)… So what?

Multiple CLIs – One Windows Terminal

Towards the top right of your terminal window, you should see a ‘+’ and down arrow. Fortunately for me, Windows Terminal picked up all of my currently installed CLIs – PowerShell, CMD and Ubuntu Bash via WSL. If I want to open up another instance of the default CLI (PowerShell for me), I can simply click the ‘+’ and it will open a new tab with a new CLI instance! Additionally, key bindings are likely similar to what you’re used to in other apps – CTRL+T to open a new tab, and CTRL+W to close the current tab.

You can also click the down arrow in order to get a drop-down list of all of the configured CLIs – selecting one to open an instance of that CLI in a new tab!

So many CLIs!

But what if Windows Terminal didn’t pick up all of my CLIs? Or what if I add additional CLIs (say via different Linux subsystems)? Enter ‘Settings’. When you click settings, you’re likely to be prompted for which viewer/editor you would like the profile config file to be opened with – in my case, I just went with the suggestion default of VS Code. Once open, you will see a JSON file containing the default configuration for Windows Terminal similar to the following:

profile.json / config

By scrolling down, you can find the individual CLI profiles – here are a couple of mine:

CLI configurations

While I’m not 100% of the various configuration properties, I’ve learned enough to be dangerous – I’ve learned enough to set things on fire… But we will talk about burning the house down shortly – for now, back to the topic at hand. If your desired CLI isn’t automatically found, you can easily configure it by copying/pasting one of the existing configurations as a new ‘profiles’ entry, and then modifying the commandline and other relevant properties to suit your needs! Easy peasy!

Animate All The Things!!!

Image result for Animate all the things

So back to setting things on fire… Odds are you found yourself going down this rabbit hole not out of your hate of having multiple windows open, but instead because you like shiny new things as much as I do. Odds are you probably saw a really cool demo showing fancy color schemes and backgrounds and thought “holyfugginshizbawls! I can haz animated CLIs too?!”. Well, as fate would have it, you can! While I again am not 100% on all of the configuration possibilities, I’ve fumbled around enough to figure out how to animate my various CLI instances – which I will share with you here.

To get started, we need a new property in our profile config – “backgroundImage”. This string value may point to a local image file, or (best I can tell) any network accessible image file that your little heart desires… But who really cares about regular old static images anyways? What is this? 1999? Fortunately, not only are static images supported but so are ANIMATED GIFS!!! By setting the value of this property to a path string to an animated gif, we are enabled to razzle-dazzle all inferior onlookers with our clearly superior terminal.

Behold and be amazed!

RAZZLE-FREAKING-DAZZLE!

Another setting of interest is ‘backgroundImageOpacity’, which (hold on to your seats!) allows you to set the opacity of the CLI instance’s background. Here’s my PowerShell configuration rocking the synthwave:

CLI Profile Example

Something that’s worth noting, and something I don’t yet fully understand – ‘useAcrylic’ in relation to using ‘backgroundImage’. In my experiences thus far, I must set useAcrylic to false in order to set a background image and have it actually load – when set to true, my CLI instance seems to fall back to simple color configurations (with Acrylic’s glassy transparency goodness, of course).

Here Be Dragons

So far, I am digging the new Windows Terminal. That said, it’s not been the most stable of experiences for me personally. As I’ve tinkered, I’ve found myself in a non-operational state multiple times with the Windows Terminal – at which time a full reboot has been my only discovered recourse. I’ve not quite nailed down what causes the ‘Abort’ crash – so far, it just seems to happen after the Windows Terminal has been up and running for some unknown period of time. Eventually, Windows Terminal will vanish, with an error dialog indicating a problem – with the process crashed, there’s no process to terminate, but subsequent attempts to relaunch will result in the same error message being displayed until reboot… more to come.

Anywhos. I hope that you’ve enjoyed reading about the Windows Terminal as much as I’ve enjoyed learning about it! Happy tinkering!
-Matt

Playing with Docker on Windows 10 with Live Reload (nodemon)

April 16, 2019 / / 0 Comments
Image result for what year is it

I know. I know. I’m a bit late to the game – and this was long overdue…

For a few years now, I’ve been fully submerged in the world of Enterprise Angular development – which has unfortunately led to me falling behind on some technologies, such as Docker. While I’ve been aware of LXCs for many, many years now, I’d not gotten past 101 setup tutorials for Docker to date – which changes today.

This post details my initial journey with running my first Docker container based Node.js application under Windows 10 – as well as the challenges encountered with live reload via nodemon during the journey, and how I got everything working well enough in the end.

As is often the case, I went looking for a recent basic getting started writeup, which led me to Dinushanka Ramawickrama’s “Let’s Dockerize a Nodejs Express API“. Being a huge fan of Node.js, often choosing it as my stack of preference, this seemed like a great place to start – taking a Node Express API and shoving it into a container using Docker.

All in all, I have to say that Dinushanka’s write up is pretty good – short, to the point, easy to follow, and accurate. It wasn’t until getting the last section, titled “Dynamically Change the Contents of the Running Container using Nodemon.”, that I ran into problems – for the life of me, I could not get live reload via nodemon to work as expected. Docker would output log messages seemingly indicating that all was well, but when I’d make changes to my server they weren’t syncing in my Docker container.

nodemon reporting for duty – but the duty never shows

As I often do in situations like this, I turned to the comments – assuming that someone else had already experienced my pain and provided me a nicely packaged solution. Nope – not this time. So I went searching, which led me to a relatively recent issue on nodemon’s github repo:
https://github.com/remy/nodemon/issues/1447 . As suggested by a commenter, I checked out “Application isn’t restarting” in the nodemon readme –
https://github.com/remy/nodemon#application-isnt-restarting . Going for the low hanging fruit approach, I updated my package.json’s dev script to include the Legacy Watch flag:


Now, all that was left was to rebuild my image and rerun it:

> docker-compose down
> docker-compose build
> docker-compose up

With the above in place, all was well in the world – containerized live reloading node development. AIN’T LIFE GRAND?!

Long story short, essentially the mechanisms leveraged on Linux systems to detect filesystem changes aren’t available in Windows – and so live reload doesn’t work out of the box. Fortunately, nodemon’s Legacy Watch uses a different (though more costly) polling mechanism to detect changes – which works fine for our purposes of ‘getting started’. Note: this is actually a known issue, as you can see in the Docker official docs:
https://docs.docker.com/docker-for-windows/troubleshoot/#inotify-on-shared-drives-does-not-work

It’s worth mentioning that some folks have reported this issue when developing on host Linux systems, which is believed to be related to inotify-tools not being present in the OS image used to create your container. In these cases, your nodemon woes may be solved by simply updating your Dockerfile with an additional run statement to install the package using the container OS’ package manager. See here:
https://stackoverflow.com/questions/42445288/enabling-webpack-hot-reload-in-a-docker-application/46804953#46804953

-Matt

© 2024 blog.immatt

Theme by Anders Noren — Up ↑