Closed brogers5 closed 7 months ago
Interesting.
IMHO: I'd allow installing on Win8x as the I'm sure the developer is going to fix the problem program (and I'm lazy and wouldn't want to have to change the script and/or dependencies of the Chocolatey package multiple times). It might even incentivize the developer to fix the problem faster if more people install it and have problems on Windows 8.x. :-)
RE: You're last paragraph - Yeah, chocolatey-fastanswers.extension is for drilling down compatibility in relation to the Windows SKU. Between the two I hope there is a solution. I haven't looked at chocolatey-fastanswers.extension for a long time. There maybe some updates it could use like checking for Desktop Experience. I'm welcome to suggestions; including some sort of evaluation based on multiple SKUs such as if Windows 10 and not Windows 11 or Windows Server but not Windows Server Core as an example. I have no idea how I'd implement it at the moment but with some feedback with clear goals I might make the effort. I saw "might" because if it's too "edgy" and not very "real world" it'd go to the bottom of the priority list.
Let me know if you've already found a solution to the issue; if not then please provide some clear guidance with examples of how I can improve either or both extensions to be more useful.
So I just ran ChocolateyPowerShell to do a quick look at the chocolatey-fastanswers.extension functions.
If I understood the original problem correctly, I think you'd want to use one or more of the Get-IsWin8 functions and then abort the install when true. That would be the way to exclude install specifically on Windows 8. I don't see a reason to use chocolatey-os-dependency.extension in this circumstance.
For additional context: this came up with localsend.portable
v1.10.0.
It historically took a dependency on chocolatey-os-dependency.extension
and called Confirm-WinMinimumBuild -ReqBuild 9600
to enforce a minimum requirement of Windows 8.1. Nowadays, the package creation guide encourages maintainers to codify OS compatibility restrictions, and Chocolatey CLI at the time supported installation from Windows 7+ and Server 2003+.
Unfortunately, a minimum OS requirement wasn't clearly documented, so I felt obliged to figure this out with some trial and error. During the initial package bringup effort (which technically happened under localsend
v1.8.0), I spun up a few VMs for each major client OS version and smoke tested the application in each. Admittedly, I didn't bother to dig too deeply into version-specific issues, so if I encountered a problem beyond missing a known dependency, it got written off as incompatible. Through this process, I landed on a minimum requirement of Windows 8.1 and ran with it until recently.
In reviewing v1.10.0's release notes, I noticed "restore Windows 7 support" being mentioned, which prompted me to review the OS compatibility situation. In so doing, I found the disqualifying issue with Windows 8 was still unresolved. I also found I missed that Windows Server had a feature dependency (currently in the review queue under wireless-lan-service
), and that Windows 8's issue could be worked around in Server 2012.
Getting into more specifics:
IMHO: I'd allow installing on Win8x as the I'm sure the developer is going to fix the problem program (and I'm lazy and wouldn't want to have to change the script and/or dependencies of the Chocolatey package multiple times). It might even incentivize the developer to fix the problem faster if more people install it and have problems on Windows 8.x. :-)
Unfortunately, I don't foresee this happening. I actually inquired about it on LocalSend's Discord server, and the primary maintainer agreed that continuing to block installation on Windows 8 would be for the best. As far as I'm aware, nobody has complained about the lack of support for Windows 8 specifically, and its continued absence from the project's Issues list suggests its compatibility is just not a priority. Can't say I'm surprised, considering it's been out of support for over 7 years now, and most 8 users made the jump to 8.1. Regardless, I'd rather not contribute to a poor user experience if it can be avoided.
I haven't looked at chocolatey-fastanswers.extension for a long time. There maybe some updates it could use like checking for Desktop Experience. I'm welcome to suggestions; including some sort of evaluation based on multiple SKUs such as if Windows 10 and not Windows 11 or Windows Server but not Windows Server Core as an example. I have no idea how I'd implement it at the moment but with some feedback with clear goals I might make the effort. I saw "might" because if it's too "edgy" and not very "real world" it'd go to the bottom of the priority list.
I guess my comments were more targeted at chocolatey-os-dependency.extension
's limitations in terms of what it could enforce on its own. My hope was it could be more of a "one-stop shop" for all things relating to the OS. If the intent was to limit its scope to version number comparsions specifically, it's not a big deal to me if I also need chocolatey-fastanswers.extension
to sort through some finer details. The examples I cited earlier just stuck out to me as potential areas to iterate with.
As one admittedly "edgy" example, Server Core installations only have a subset of Windows features available to it in comparison to Desktop Experience. I know this would be problematic for LocalSend in particular, since its feature dependency is among those impacted.
Let me know if you've already found a solution to the issue; if not then please provide some clear guidance with examples of how I can improve either or both extensions to be more useful.
Not a blocker by any means. For v1.10.0, I worked around it by taking a new dependency on chocolatey-fastanswers.extension
, rolled my own check for a Windows 8 client OS (($majorOsVersion -eq 6) -and ($minorOsVersion -ge 2) -and !(Get-IsWinServer)
), then conditionally called Confirm-Win81
or Confirm-WinMinimumBuild -ReqBuild 7601
depending on the result.
Not as simple as I'd like it to be, but it gets the job done.
If I understood the original problem correctly, I think you'd want to use one or more of the Get-IsWin8 functions and then abort the install when true. That would be the way to exclude install specifically on Windows 8. I don't see a reason to use chocolatey-os-dependency.extension in this circumstance.
Get-IsWin8
would've helped to simplify the Windows 8 check portion on paper, but I actually found a bug in its implementation that would've been a blocker in this context. I'll open a separate issue for this.
I liked how chocolatey-os-dependency.extension
rolls both a version check and throwing an exception upon failure into one function call. I'd have to reimplement the latter if I migrated to chocolatey-fastanswers.extension
's equivalent.
In keeping with the "minimum OS requirement" mindset, I also wanted to continue blocking installation for some older Server versions (i.e. 2003-2008). A minimum build check against Windows 7/Server 2008 R2's build number (7601) seemed like the simplest path forward for that requirement.
EDIT: In hindsight, Get-IsWin80
would've helped if I wanted to go down the "throw my own error" route.
I had a strange OS compatibility situation come up with one of the packages I maintain, where Windows 7 compatibility was recently restored, but its framework has an unfixed UI rendering issue in Windows 8, which effectively cripples the application's usability. It has historically worked without issues on Windows 8.1+. It doesn't seem like I can implement an exclusion for Windows 8 specifically without some additional code.
Windows 8 would pass a
Confirm-WinMinimumBuild
call with Windows 7's build number (7601), butConfirm-Win81
and the other numbered functions will perform an equivalency check against the current major-minor version, making them unsuitable for allowing multiple possible version combinations.A further complication is that I would also want to allow installation on Windows Server 2012, despite it sharing the same version number (since unlike Windows 8, it supports a workaround of installing .NET Framework 4.8). The extension currently keys only off of a version number and has no awareness of product lines (e.g. PC or Server), editions (e.g. Home or Pro), or server install configurations (e.g. Desktop Experience or Server Core), although I'm aware
chocolatey-fastanswers.extension
could help with some of these.