Microsoft releases command-line package manager for Windows (there are snags) Microsoft has released Windows Package Manager 1.0, better known as winget, a command line tool for adding, removing and updating what is installed on the system. The Windows Package Manager has a number of arguments through which users can inspect what is installed as well as adding, removing or updating applications. The …
Quote: The restart thing is a problem too: not restarting is great, but it's frustrating when the application is not fully installed.
This has always annoyed me with Windows, why do so many user applications, such as Libre Office and many others, need a restart after an update in the first place?
I've been able to install and update things like GFX drivers (such as for nVidia cards) in Windows without needing a reboot for many years now, and that's replacing hardware drivers for something that is actively in use by the system.
So why can't updating a user application, also be done without a restart? Surely it should be much easier to update software that isn't actively in use at the time, than it is to update something that is actively in use, such as drivers for a GFX card?
A lot of these restarts seem to be unnecessary and - from what I can tell - are probably just a hangover from old versions of Windows or caution on the behalf of the person writing the installer. Many/most apps calling for a restart will work fine without, albeit they may use that restart to tidy up some of their logs etc. Per the article, there seems to be little standardisation in Windows to ensure things are all done in a similar manner.
Propably the largest deviation between Windows and Unix lies within its virtual memory implementation, the executable file format used, and how the file systems behave. If a COFF file is executed on Windows, the executable file is locked in such a way, that it can't be modified anymore on disk. Under Unix this is handled a little bit differently. If an ELF file is executed, the executable is also locked in a similar way as on Windows, but it is nevertheless possible to unlink the file (delete it) from file systems. Afterwards, the file can be created freshly, i.e. updated with a newer version. This "zombie" state of files--it is unlinked but still in use and therefore kept intact--is realised with tricks inside the file cache of the system. If you are interested how this is handled, read about "negative dentries".
In summary, if on Windows a program or any part of it in form of a shared library is executed, it is not possible to change or update the program files. Hence, such changes are deferred until the next reboot of the system is initiated. On Unix this is only necessary if the kernel itself is updated. If Microsoft want to change this, they must rewrite an important part of the operating system.
This is precisely the issue and it is (slightly) worse than suggested. Because of this historicalbehaviour, there are apps that rely on this locking. They "know" that if they are running then theycan'thavetheir dependencies upgraded under their feet, so things like config data formats and protocols are stable.
I doubt whether anyone knows how widespread this actually is, but MS have considered changing it in the past andbacked away. I think oldnewthing had an article on it a few years back. Don't expect it ever to change.
How does that work with regards to swap files then?
On Windows executables and shared libraries are never copied into the swap file if memory space is needed because the OS knows they already exist on disk - they're just unloaded and reloaded as required. But that happens outside of the file cache which doesn't need to know or care about such specifics. (To me that sounds like an unnecessary complication to what should be a small, streamline system.)
All major OS have flags for opening a file in an "private" way, meaning that no other process is allowed to change their view of the file.
On Windows, this locks the file completely, no other process may write to or delete the file at all. You can rename or move it though, a fact used by some installers. That works because files are objects in their own right, not just their name.
On Linux and BSD (inc. macOS), this is implemented by giving each process a "private view" onto the file as it existed when the file was opened. IIRC this is done by taking a snapshot of the inode chain that represents the file contents at the time.
If the file is deleted, the filesystem simply hides the file. It's not actually placed into the "free space" list until all open file handles are closed.
If the file is modified by some other process, the changed blocks don't appear for processes that have asked for a private view.
It's been best part of a decade since I looked at this & I've not tried this on Linux but I presume it is the same. But when a file is privately memory mapped then once a page is read it is mapped into the processes address space and its backing store can become the swap area if need be. It wasn't at open time that the file became "fixed" but at first access to a page.
That sounds like a recipe for disaster: I can end up seeing pages from two different versions of a file.
For example, suppose the start of a file contains a "directory" that gets locked immediately I map it. If somebody modifiers the file and changes where something is then when I go to get the data my directory says exists, it's no longer there, even though I'm supposed to have a private copy of the file that no one can modify.
you're right to think that it would cause a disaster
that's why it doesn't work like this
if a file is opened in exclusive mode, then nothing else can open it, but executing an application doesn't do that
The difference between Linux and Windows is that you can delete (unlink) an opened file on Linux, you can't on Windows. Such an unlinked file behaves normally for the application that has it opened (it will sync to disk, can be freely read and written to, and data is sent to disk, so you're not limited to RAM), but it doesn't have a name associated with it. As such, no other application can open it.
If two applications do manage to open same file at the same time, then they will see the same contents, so writes by the one application will be visible by the other, and vice versa. There is no way to "fork" a file and have two applications see different contents of the same file, that's a copy, even on ref-linked file systems like btrfs or zfs, so the new file needs to have a different file name.
@Brewster's Angle Grinder, you're right this is an accurate description.
It can vary from implementation to implementation. Some of it is beneath the vnode layer in the Unix kernel and so could potentially vary between different filesystems. Not all implantations even managed to be coherent between nmap MAP_SHARED and the traditional read/write system call interface to files.
To get a guaranteed consistent view of a file with MAP_PRIVATE you need to open the file, lock the whole thing, or at least the part you're interested in, then touch all the pages so your processes address space sets up all the data structures down to the page level and then unlock it. But that's really no difference to the behaviour of the read/write interface. If you open a file and start to read it while someone else is writing to the file you can get some old and some new new data. It is only the individual systems calls which are guaranteed to be atomic.
Things like libraries are normally only open read only so you don't need to worry about this sort of issue.
Also, not all systems allow you to unlink an open executable and you can get a text busy error, however you can rename an open executable so that an updated version can be inserted in its place.
NFS used to add "interesting" layers of behaviour too as it was never fully SVID compliant.
Sure, all this makes sense, but it doesn't when no files need modification yet a restart is required anyways. There's some cracker tricks that intentionally disable anything restart related to negate any further modifications after installing... yet everything runs smoothly anyhow. At the dawn of PCIe you could even bypass certain checks by pulling a card of interest and simply reinserting it. Again, everything ran fine and no further file modifications where made.
To me, it is a borked design, but Microsoft has never made any attempts at trying to make these checks more visible to the API to make things more helpful to the client. Basically, they just assume darkness is ALWAYS way.
No, it's whoever wrote the installer.
Windows simply believes the installer when it says "I need the OS to restart to work properly".
This is probably primarily because several commercial Windows installer systems assume every application will need a restart. Looking at you, Installshield.
Most applications don't, but whoever wrote the installer didn't find the opt-out.
@Richard 12 “No, it's whoever wrote the installer.” Exactly I have written many installers, and none require a reboot and yes in InstallShield you do have to set the flag for /norestart.
The only time a restart might happen (not often) is if we must update an external component like a Microsoft one which requires a reinstall. But it is done at the beginning before our install has started choosing to install those components will run those components installers which may trigger a reboot choosing not to install them will cancel the install.
We decided that to check and if not present offer to install those components more convenient for customers than when finding they are not present telling the customer to get them themselves but they still have that option.
Linux / BSD package managers work pretty well because the software is simple in terms of filesystem structure (though have IMO too many dependencies these days. Gtk, Gdk, Pango, Cairo, etc should potentially be a single package)
This is one thing that the (early) Mac OS X got right. Single folders that you just drag into a folder on your HD to "install". They went with the approach of all the dependencies bundled in (I like this approach (though despise the rest of macOS), but I understand it does have some limitations).
Solaris 10 had an interesting approach of handling many dependencies of different versions by using entire installation prefixes (/usr/sfw, /opt/sfw, /opt/csw, etc). This was confusing in many ways but was quite a good middle ground between the above.
Whereas Windows software includes all of these updater services, admin registry entries and other weirdness that I think Windows should simply block these days. No, don't cripple Windows by making silly AppStore-like packages, but just make it so distribution via a zip becomes the norm and as soon as an .exe attempts to write into system32 or the registry, then emulate it, or deny it.
People have been working on Windows for decades... why is it still so impossibly bad?
The registry is required to register application icons, file open commands and other integrations with the system and the user.
I understand those kind of advanced features are unheard in obsolete OSes with limited features, but the last thing Windows has to do is to lose features to become like an OS designed 50 years ago and never improved much from there.
Luckily Dave Cutler designed an OS without trying to copy Unix.
I really am. I know how entrenched Windows is in enterprise, but, well, wow.....
Whilst we are on the subject of BUILDING packages for installation.... I recently had to put some documentation together for windows and mac customers for building their own packages.
macOS: All the tools you need are right there with pkgbuild and productsign. If you wish to use an app to do it, there's some great ones
Windows: What an abysmal merdemess. Had to use NSIS, and it's own quirky scripting language (and it's 25 year old interface). I tried really hard to find a simple solution but....
If you're a windows admin, I sincerely pity you
WiX.
It's what Microsoft use and recommend. If your application is trivial enough that the built-in macOS tools are usable then WiX is literally a one-liner.
It produces an MSI which will install and uninstall as a single transaction.
Or there's the MSI creator that comes with Visual Studio, just like pkgbuild and productsign come with xcode. Though TBH I've never used it as wix is nicer.
These also mean windows admins can preinstall and remotely install/update whatever they need across thousands of managed desktops. I pity macOS admins, they rely on the end user for so much.
Oh no, I'd managed to block the absolute horror that was NSIS from my memory. Just... quite how whoever vomited up that thing considered any way that it worked to be useful I'll never know. It felt like the creator of it had heard of scripting and even basic logic structures and methods and had intentionally gone sideways instead.
The product is called WAPT. It's made in France by a team 3000 times smaller than the MS team.
It is agent and pull based so that it works well with NATs, firewalls and proxies, users don't need to be local admins, you have command line and console based management capabilities. Actions and packages are signed using certificates and all communications are https. You can catch return codes and even configure the user environment for their immediate productive use of the software package.
Repositories are self hosted so you can customize your packages.
It is designed to be flexible, secure and simple to set up and use.
Cherry on the cake, it even has a security certification from the French Cyberdefense agency.
Winget is what WAPT was in 2014.
https://www.wapt.fr/en/doc/
https://wapt.tranquil.it/
> How about Chocolatey? Is it any good?
It's OK. I use it here. Sometimes a package fails to upgrade for weird reasons, but in the main it works well. The closest I have come to having a convenient installer.
One good aspect is having choco update all installed software. So I have many of the classics like notepad++ and every now and then I just run a blanket update to get the most recent versions.
I can recommend giving it a try.
back when I were a wee lad, WIMP was the Future. Command lines were so old-fashioned. Yes, the 1980s. So MS are rediscovering the power of command lines. Meanwhile I will continue to enjoy the speed, power, flexibility of ksh93. Scripts that run 40 times faster than bash. No, I dont do much in graphics. Data munging, yes, a little
Really?
Can't say it's ever occurred to me that I might want or need to have a third party act as a gatekeeper for the software I might want to install.
It also doesn't appear that winget handles the installation process - that's just your regular .exe/.msi/.msix installer.
There might arguably be some value if it solved the problem of every package installing its own updater, but since you're getting the same installer package by this route as you would by any other, I'm struggling to see the advantage.
My go-to solution on Windows (my primary development platform) is MSYS2, with the Pacman package manager (same as Arch). This, together with a Manjaro (friendly Arch distro) VM, gives me a very coherent way to develop both for Windows and Linux, without having to resort to hacks like WSL(2).
On Windows I prefer to get an EXE or MSI installer package for large software packages (like LibreOffice), but I like using MSYS2's pacman to get libraries and tools I use during development, also because of the Linux-style filesystem layout this gives me in addition to a Bash shell.
//The question was whether to drop support for applications with legacy installers that are not transactional and have unpredictable behaviour.
Drop such support, and Winget would be less useful. Maintain it, and Windows trundles on, seemingly never escaping its disorganized past.//
Well put. I wish Microsoft brings the container technology from 10X so that all this mess can be hidden away inside individual container for every application.
A well written installer will run without issues with a silent install - it will use the default settings. If you need to change them you need the UI or a response file.
You need to test that as well.
Anyway usually Linux packages don't ask anything to users - but maybe some confirmations - they are not designed for a complex UI and interaction with the user. They leave an an exercise to the user hunting down configuration files and modify them after the package has been installed. A Windows installer lets the use to enter all required parameters - if designed to do so - and then write the required configuration.
It's no surprise many commercial application for Linux don't use standard packages but come with their own installers too - be it some Java multiplatform installer or some custom one.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
