On Wed, 7/29/2026 7:33 PM, Lawrence D?Oliveiro wrote:
Here?s an article to reassure Windows developers who feel their
platform is increasingly being overshadowed by Linux these days: how
to set up a nice Windows development environment <https://www.infoworld.com/article/4196853/how-to-make-windows-a-proper-development-environment.html>.
Step 1: Install Linux. Not even kidding: install WSL, so you get
access to a Linux system while still being able to pretend that you?re
using Windows.
Step 2: Admit that the native Windows filesystem, NTFS, doesn?t deal
well with lots of files and directories, like Linux filesystems can.
Install something called ?ReFS?, which Microsoft was pushing quite
heavily at one point, but now seems to have lost a lot of its
enthusiasm for. Don?t worry, I?m sure Microsoft?s layoffs haven?t
reached the team working on that -- yet.
Step 3: Try doing Windows software installs the Linux way, with
Microsoft?s Linux-wannabe package manager, WinGet. Only it doesn?t
quite work like a Linux package manager: it won?t install packages by
name, you have to use those arcane ID strings instead. Good luck
figuring those out.
Step 4: Enable PowerShell to run local scripts without proper checks.
What could possibly go wrong? Linux, being a multiuser system, has
built-in protection checks; but who needs that kind of stuff on
Windows?
Step 5: Install more and more tools from the Linux world. Isn?t it
reassuring when recommended package manager commands use options like ?--force? and ?--override? in them? I?m sure it?ll all work out fine
without those extra checks, you can trust Microsoft!
And there you have it: a proper, pukka Windows-native development
environment for creating Windows-native software, which can hold its
head up high next to any Linux machine!
by Serdar Yegulalp
Senior Writer
set-executionpolicy remotesigned # Now, this is perfectly safe <snicker>.
# It's the Unrestricted that's a bit daft, but... enjoy :-)
# Most people here would run Unrestricted,
# because I'd tell them to do that <more snickering>.
Install-Module -Name Microsoft.WinGet.Client # Takes a Repository name as well (some Repos "not safe")
Import-module -Name Microsoft.Winget.Client
(Get-Module microsoft.winget.client).ExportedCommands # Lists the catalog entries added
# Broken a bit, in that you have to know the syntax
# or it won't help you with the syntax. Not a problem, right?
# Commands are similar to winget.exe ones.
PS C:\program files\windowspowershell\modules\Microsoft.WinGet.Client\1.29.280> Find-WinGetPackage -Name Adobe -Source winget
Name Id Version Source ---- -- ------- ------ Adobe Acrobat Pro Adobe.Acrobat.Pro 26.001.21662 winget Adobe Acrobat 2020 Adobe.Acrobat.Pro.2020 20.001.30002 winget Adobe Acrobat Reader (32-bit) Adobe.Acrobat.Reader.32-bit 26.001.21662 winget Adobe Acrobat Reader (64-bit) Adobe.Acrobat.Reader.64-bit 26.001.21745 winget Adobe Connect Adobe.AdobeConnect 21.11.22 winget Adobe Connect Adobe.Connect 2026.3.125 winget Adobe Connect application MSI Adobe.Connect.MSI 26.3.125 winget Adobe Creative Cloud Adobe.CreativeCloud 6.10.0.252.3 winget Adobe DNG Converter Adobe.DNGConverter 18.4.1 winget Adobe AIR HARMAN.AdobeAIR 51.3.3.1 winget
Then, now that you know the identifiers, you can do the install (800MB download, don't do this, but syntax passes OK)
Install-WinGetPackage -ID Adobe.Acrobat.Reader.64-bit -Version 26.001.21745 -Source winget
Id Name Source InstallerErrorCode Status RebootRequired ExtendedErrorCode
-- ---- ------ ------------------ ------ -------------- -----------------
Adobe.Acrobat.Reader.64-bit Adobe Acrobat Reader (64-bit) winget 3221226356 InstallError False System.Exceptio...
0xC0000374
Even though the installer threw an error, the program starts, and being Adobe (and 800MB),
it's chock-full of garbage. I made a good choice for a demo. Using the old fashioned
"Programs and Features", the 800MB package can be removed.
For my next test, we'll do a wider scan, and autosize the fields.
I have included only two lines of output to show the columns fitting nicely.
Find-WinGetPackage -Name file -Source winget | ft -Autosize
Name Id Version Source
---- -- ------- ------
ADInstruments Playback File ADInstruments.LabChart.DeviceEnabler.PlaybackFile 1.2.2400 winget
FileLocator Pro/Lite Mythicsoft.FileLocator 9.3.3562.1 winget
And I don't think that's a development environment, any more than
Fink on my Apple Computer was a trusted source. If you are an idiot
with a computer, bad things will happen. The above tested in a throwaway VM, and not because it's particularly unsafe, I would not pollute a Daily Driver this way. There are really no benefits from "doing things this way".
Anyone with common sense knows to "go to the Source" first for things,
not walk uphill ten miles in the opposite direction to fetch a pail of water. There is undoubtedly an easier way to get "Adobe.Acrobat.Reader.64-bit",
which is actually on my Nope List. It's banned here. Autoupdating and
removing the rotate knobs, that was the last straw for Adobe. I see a
rotate knob is back, but who really cares, when the software auto-updates
and the GUI can be knackered at any time by goofballs.
"Force" and "Override" are "Are you sure?" options. You usually
have a functional failure when not using them, realize they are
protection against accidental activation, and you toss them in as
required.
Whereas "Clean" and "Clean All", don't prompt at all.
There are all sorts of random guardrails. They had set up one
of those, on my D: drive, it was driving me nuts, and after
some Windows Update, that one disappeared again. It was one
jolly fine experiment, for the twit who did that. Yes, yes,
I'm scared of EXE files now, I'm scared of my own shadow,
the experiment... worked.
Paul
--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)