It’d be much more impactful if critical OS configuration was done either via text files (ala *nix) or cli. Either would need to be feature complete and discoverable/documented very well.
I used to use wmi in my software to manage printer ports. In the end I had to remove it because wmi was broken on a significant number of my customers machines.
You can, it’s just that going the PInvoke route can be quite complicated. It can certainly be done but typically finding a good community module that has already done so makes things a lot easier.
Some settings changes happen are effected via undocumented registry changes that you have to make directly, and can be a pain to track down.
Sometimes you can do something via PowerShell, but only by using PowerShell to directly call some 'raw' .NET API.
Sometimes there's a native CLI utility that'll do what you want, but it's one of the DOS-like, pre-PowerShell commands, and the PowerShell equivalent is missing or unsuitable.
Even when a native PowerShell API exists, it can be difficult to find the documentation for it because Windows culture is to document GUI solutions first (and often GUI solutions only).
Try as one might, Windows remains a platform inherently hostile to automation. Doing automation and/or configuration management on Windows sucks.
What do you mean by "critical"? Do you mean stuff that everyone will have to do, like changing mouse speed? Installing programs? The more obscure stuff, like Event Viewer? The really obscure changes that currently need registry hacks (the "I know my setup is weird but it works for me" stuff)?
Different demographics will probably need different solutions. The important thing isn't what solutions they come up with, it's that they choose a system and stick with it. To me it's understandable that Event Viewer isn't part of the main Settings app (plenty of IT folks would be upset if anything about Event Viewer changed). But Mouse Acceleration options really should be.
Try setting Group Policy objects through CLI without some serious workarounds and without using that one Microsoft local GPO binary that I don't remember the name of but isn't supported.
Show me how to set an arbitrary, already existing, GPO's value without having to manually toggle it first, back that up, and use that backup to import the change.
Windows is not UNIX, we ought to keep it that way. Its object-oriented model is in many ways better than UNIX's everything-is-text-or-a-bunch-of-bytes model.
> if critical OS configuration was done either via text files
Ah, please, no. On Linux today we have a terrible jumble of configuration files in .conf, .ini, .yaml, .toml, even .json and .xml...
IMO the Windows Registry was a fantastic way to store settings, and Microsoft should return its usage. It's not like Linux distro don't have something similar in systemd...
I'd be happy to see Edit come back, but honestly I think MS wants people doing as little commandline as possible.
In fact, there newest tactic is to hide configuration changes they don't want users to mess with in commandline only powershell options that are typically poorly documented, and have odd syntax.
More than scripts, an hybrid web/scripting approach. You set up the settings in a web panel, and then you should be able to export the cfg/scripts to a zip file to be scripted/applied afterwards.
I personally have little interest in Windows servers these days. I'm more interested in automating painful settings and actions on my remaining Windows VMs that I use for some desktop applications or maintain just in case I need one in a pinch.
One task I wanted to do was have my Windows VM boot in the night and install all updates before shutting down and creating a snapshot. Windows has a pretty jank update system but I was kind of shocked there is no command line way built into windows to trigger "run all the updates now". Despite their obsession with preventing people turning updates off and rebooting against user wishes they didn't build in a way to actually just run them on a controlled schedule.
I ended up needing to install a 3rd party powershell package some one made to get this functionality which is ridiculous and arguably somewhat of a security risk.
I think it feels like the inverse. It seems like MS wants people to use more CLI and has been retrofitting PowerShell as a full-fledged Windows administration layer. But the problem with it being retrofitted is it feels very clunky and difficult to explore.
There's also Windows Terminal which seems like a genuine attempt at making interacting with shells in Windows less painful in general.
> Why would they need to be recreated? Windows ports of vim and emacs exist
I think you are missing the point here. It's not about litterally rewriting them, but about copying their design. It'd be nice to see a new advanced text editor written using what we've learned over the last 40 years and about usability, discoverability, etc.
No, the point is to select one or more existing text editors to add to Windows:
"The goal would be to install the selected editor(s) by default such that their commands work out-of-the-box. Example editors include but are not limited to:
• Edit
• Pico
• Nano
• Vim
• Emacs
• etc.
Installing one or more of these editors by default will offer immediate CLI text editor capabilities on all Windows machines, preventing the need for additional installs or workarounds when operating on local machines, remote connections, or Windows containers."
Microsoft is not trying to create a new text editor.
If anyone wants to write their own new advanced text editor or whatever, they can, but that is not what the GitHub issue is about.
I agree, I would love to see something modern that works for devs today and isn’t just a port of something that was put together in the past.
Helix feels like a cli VSCode to me, in the sense it has TreeSitter and LSP built-in and support for most languages out the box. It’s doesn’t require loads of plugins to be useful.
"There are plenty of offline scenarios where this would be incredibly useful. For disconnected environments, etc. There are some environments that will never connect to winget."
The author is confused about what CLI means. None of the programs listed are command-line editors. Ed and sed are examples of command-line editors. These are not. (Vim and Emacs have command lines within them, but so does VSCode, for that matter.)
Vast majority of users (especially on Windows) don't understand the difference between console, terminal, shell, and command line. So this thread treats CLI as TUI.
> What is the difference between these on Windows?
A command line interface (CLI), as the name implies, is a user interface pattern consisting of an application that you pass arguments to it through the command line to form a request/command to be executed by the application.
This type of user interface also covers features such as exit code and text input/output through standard streams as to allow programs to be compostable through pipes.
For example, '$ cp origin rest', '$ grep -Ri foo /opt | sort', etc.
A terminal user interface (TUI) is a type of user interface which uses a terminal's limited features to provide a windowed user interface that supports interactivity.
that discussion is wild... just install a few of the most popular editors and be done with it. default to whatever the smallest, simplest one is—nano or similar? support setting $EDITOR or whatever the fuck the Windows equivalent should be and you're done.
51 comments
[ 3.1 ms ] story [ 74.8 ms ] threadSometimes you can do something via PowerShell, but only by using PowerShell to directly call some 'raw' .NET API.
Sometimes there's a native CLI utility that'll do what you want, but it's one of the DOS-like, pre-PowerShell commands, and the PowerShell equivalent is missing or unsuitable.
Even when a native PowerShell API exists, it can be difficult to find the documentation for it because Windows culture is to document GUI solutions first (and often GUI solutions only).
Try as one might, Windows remains a platform inherently hostile to automation. Doing automation and/or configuration management on Windows sucks.
Different demographics will probably need different solutions. The important thing isn't what solutions they come up with, it's that they choose a system and stick with it. To me it's understandable that Event Viewer isn't part of the main Settings app (plenty of IT folks would be upset if anything about Event Viewer changed). But Mouse Acceleration options really should be.
VBScript, JScript and nowadays Poweshell.
Windows is not UNIX, we ought to keep it that way. Its object-oriented model is in many ways better than UNIX's everything-is-text-or-a-bunch-of-bytes model.
> if critical OS configuration was done either via text files
Ah, please, no. On Linux today we have a terrible jumble of configuration files in .conf, .ini, .yaml, .toml, even .json and .xml...
IMO the Windows Registry was a fantastic way to store settings, and Microsoft should return its usage. It's not like Linux distro don't have something similar in systemd...
You mean dconf? What part of systemd is like the registry?
In fact, there newest tactic is to hide configuration changes they don't want users to mess with in commandline only powershell options that are typically poorly documented, and have odd syntax.
maybe isn't malicious, but it feels like it.
Hence Windows Nano Server, and everything configuration setting being available via scripting.
I thought HN would appreciate that.
Nowadays the new Windows Admin Center,
https://learn.microsoft.com/en-us/windows-server/manage/wind...
One task I wanted to do was have my Windows VM boot in the night and install all updates before shutting down and creating a snapshot. Windows has a pretty jank update system but I was kind of shocked there is no command line way built into windows to trigger "run all the updates now". Despite their obsession with preventing people turning updates off and rebooting against user wishes they didn't build in a way to actually just run them on a controlled schedule.
I ended up needing to install a 3rd party powershell package some one made to get this functionality which is ridiculous and arguably somewhat of a security risk.
There's also Windows Terminal which seems like a genuine attempt at making interacting with shells in Windows less painful in general.
Why would they need to be recreated?
Windows ports of vim and emacs exist and they would be excellent choices along with a simple editor like nano.
I agree with those in the thread that they should just include vim, emacs, and nano.
They are mature, have excellent features and would target all the major groups of users who use text editors.
Creating an entirely new text editor seems silly when there are so many good choices with full ecosystems and user communities.
I think you are missing the point here. It's not about litterally rewriting them, but about copying their design. It'd be nice to see a new advanced text editor written using what we've learned over the last 40 years and about usability, discoverability, etc.
No, the point is to select one or more existing text editors to add to Windows:
"The goal would be to install the selected editor(s) by default such that their commands work out-of-the-box. Example editors include but are not limited to:
• Edit
• Pico
• Nano
• Vim
• Emacs
• etc.
Installing one or more of these editors by default will offer immediate CLI text editor capabilities on all Windows machines, preventing the need for additional installs or workarounds when operating on local machines, remote connections, or Windows containers."
Microsoft is not trying to create a new text editor.
If anyone wants to write their own new advanced text editor or whatever, they can, but that is not what the GitHub issue is about.
Helix feels like a cli VSCode to me, in the sense it has TreeSitter and LSP built-in and support for most languages out the box. It’s doesn’t require loads of plugins to be useful.
Source: https://github.com/microsoft/terminal/discussions/16440#disc...
What is the difference between these on Windows?
Tangential, tty is also a term that can and should be left in the past.
>> these two can be used interchangeably, even in Linux.
> No, they cannot. Your tty4 or xterm underestand different commands than your shell.
I think you're replying to an imaginary comment? The question was about console vs. terminal, not terminal vs. shell.
A command line interface (CLI), as the name implies, is a user interface pattern consisting of an application that you pass arguments to it through the command line to form a request/command to be executed by the application.
This type of user interface also covers features such as exit code and text input/output through standard streams as to allow programs to be compostable through pipes.
For example, '$ cp origin rest', '$ grep -Ri foo /opt | sort', etc.
A terminal user interface (TUI) is a type of user interface which uses a terminal's limited features to provide a windowed user interface that supports interactivity.
For example, see apps like vim, fdisk, etc.