ooshutup10_recommended
Obegg opened this issue · comments
Why would you store the ooshutup10_recommended.cfg in a separate external file
https://github.com/ChrisTitusTech/winutil/blob/main/config/ooshutup10_recommended.cfg
When you can create it in script:
Invoke-WebRequest -Uri https://dl5.oo-software.com/files/ooshutup10/OOSU10.exe -OutFile $ENV:temp\OOSU10.exe
$OOSU10 = '############################################################################
# This file was created with O&O ShutUp10++ V1.9.1436
# and can be imported onto another computer.
#
# Download the application at https://www.oo-software.com/shutup10
# You can then import the file from within the program.
#
# Alternatively you can import it automatically over a command line.
# Simply use the following parameter:
# OOSU10.exe <path to file>
#
# Selecting the Option /quiet ends the app right after the import and the
# user does not get any feedback about the import.
#
# We are always happy to answer any questions you may have!
# © 2015-2023 O&O Software GmbH, Berlin. All rights reserved.
# https://www.oo-software.com/
############################################################################
P001 +
P002 +
P003 +
P004 +
P005 +
P006 +
P008 +
P026 +
P027 +
P028 +
P064 +
P065 +
P066 +
P067 +
P070 +
P069 +
P009 -
P010 -
P015 -
P068 -
P016 -
A001 +
A002 +
A003 +
A004 +
A006 +
A005 +
P007 +
P036 +
P025 +
P033 +
P023 +
P056 +
P057 -
P012 -
P034 -
P013 -
P035 -
P062 -
P063 -
P081 -
P047 -
P019 -
P048 -
P049 -
P020 -
P037 -
P011 -
P038 -
P050 -
P051 -
P018 -
P039 -
P021 -
P040 -
P022 -
P041 -
P014 -
P042 -
P052 -
P053 -
P054 -
P055 -
P029 -
P043 -
P030 -
P044 -
P031 -
P045 -
P032 -
P046 -
P058 -
P059 -
P060 -
P061 -
P024 -
S001 +
S002 +
S003 +
S008 -
E001 +
E002 +
E003 +
E008 +
E007 +
E010 +
E011 +
E012 +
E009 -
E004 -
E005 -
E013 -
E014 -
E006 -
Y001 +
Y002 +
Y003 +
Y004 +
Y005 +
Y006 +
Y007 +
C012 +
C002 +
C013 +
C007 +
C008 +
C009 +
C010 +
C011 +
C014 +
C015 +
L001 +
L003 +
L004 -
L005 -
U001 +
U004 +
U005 +
U006 +
U007 +
W001 +
W011 +
W004 -
W005 -
W010 -
W009 -
P017 -
W006 -
W008 -
M006 +
M011 -
M010 -
O003 -
O001 -
S012 -
S013 -
S014 -
K001 +
K002 +
K005 +
M003 -
M015 -
M016 -
M017 -
M018 -
M019 -
M020 -
M022 +
M001 +
M004 +
M005 +
M024 +
M012 -
M013 -
M014 -
M023 -
N001 -
'
New-Item -Path $ENV:temp\OOSU10.cfg -ItemType File -Value $OOSU10 -Force
Start-Process $ENV:temp\OOSU10.exe -ArgumentList "$ENV:temp\OOSU10.cfg /quiet" -Wait
Performance:
If you want to use Winutil but do not want to use the OO Tweaks, the config data is never downloaded to your PC and the compiled winutil script is a bit smaller which can reduce the time needed to download and start winutil on a slow network.
Maintainability
I thought it would be easier to export a new config from OO Shutup and replace the file the next time OO Shutup is updated than needing to copy-paste the content into the script which becomes a bit harder to read and easier to mess up if you include it in there. (Also the factory config would need to be incorporated the same...)
In the end, I don't see the upside of including the config in the script itself, because even the argument "what about running winutil offline" doesn't hold up, because the OOSU10.exe needs to be downloaded anyways...
Tangent: How could OOSU be implemented offline in winutil (not sensible)
If you wanted to make the functionality fully available in winutil in a single script without requiring internet connectivity, you would need to take extra steps like compressing the OOSU Executable, turning it into a string representation (eg. Base64), and including the blob of text in winutil so it can be turned into the executable offline.
Reasons why this is most likely not sensible for winutil
- Performance: In my POC the b64 representation of OOSU10 ended up with a length of ~1.33 Million characters. -> Powershell is an interpreted language. I would be quite impressed if Powershell could handle such large scripts but I haven't tested it.
- AV Detection: In my experience, AV Programs (and IT Security People) really don't like large obfuscated blocks of compressed, unreadable data included in scripts that unpack themselves, as this is not uncommon to see in malware samples.
- Trustworthiness: At the moment the executable file is downloaded directly from OO Software (and every user can check the script quite easily to validate this) If you start including blocks of compressed third-party software in the script, who would validate that the compressed executable hasn't been tampered with? (Yes I know hash values exist but those are also not really easily verifiable by a normal user)
If anyone has a different take, please let me know :)
You did a great job explaining in great detail your opinion and I respect and appreciate that.
First of let me say I guess it depends on the application and use case, so even if I have some points I disagree with - I can understand why you argue differently.
Second - I think this is a great piece of code, which does fit the (I assume) the desired intent of the winutil, which is to be fast and efficient and only execute what's needed.
Lines 4103 to 4145 in 2354645
But the main point of my case here (which could be just my opinion and you can disagree with) is that it is possible to insert the config file inside the script itself instead of using external file, which yes, will increase the size of winutil, but to that I can also argue 1. network speeds have improved recently, 2. I assume it will be a small size bump, nothing major.
I can also argue and say "hey, an extreme use case would be the apply recommended ooshutup, but then the user will restore to default, so what exactly you 'saved' in this implementation? the user downloaded both files"
But ultimately I think it's about trying to cram as much as possible into one file instead of having many small files, it's possible.
Maintainability - copy-paste (content of file) vs a different (file to file) copy-paste is kind of the same.
I actually think it's somewhat (yes, I said somewhat) efficient to store the config file inside the script itself.
Tangent: How could OOSU be implemented offline in winutil (not sensible)
Never crossed my mind about "offline" to be honest, it's just goes to show you considered something I failed to consider.
I actually prefer scripts (any) to be online, the amount of complexity in trying to offline them is too much (my opinion).
Updates to individual components that the script is depending on and so on...
Finally, as I stated before - I completely understand your opinion, I respect it, thank you.
Off-topic:
I stopped using winutil when I understood what exactly it was doing, no need for all that bloat if you ask me (this is just my perspective), default values being changed to default values on the services tweak (you already replied to that other issue), chocolately is being installed (which I never asked for) and users kept opening issues about it without a single reply from the owner, some tweaks like WPFTweaksTele doing some tweaks without no explanation of what they are doing, example:
Lines 1840 to 1846 in 2354645
(this specific one is to show the balloon tips on mouse hover)
which of course I can google each on and get an answer but inside winutil they are not exactly documented,
some of the tweaks are not suitable for Windows 10 LTSC, the version without so much bloat,
gamedvr tweaks causes some issues for users (see the opened issue),
winutil itself is not designed for tweaks only, but has applications to install and other functions, but as a user who is not using winget, chocolatey, microwin, and only using the tweaks, this is not the right tool for me, the tool for me is Sophia Script, but to each their own,
Regarding your reply on TweaksServices issue (don't know why I rather answer it here tho)
winutil would be able to reset
That's the point, you should not reset what the script has changed, it's supposed to be a script you trust blindly, especially when the owner takes proud of the "test branches" he does, that's just not how scripts supposed to run, you suppose to run one script one time and forget about it (again - that's just my view).
I guess I can close this issue and the rest I opened?
Regarding the Off-Topic bit.
I'm completely on your side here, I think in a perfect world, chocolatey could be completely removed from winutil, but because we live in a Microsoft Hell, sadly winget is pretty much broken on a new install, and installation/upgrade problems exist waaaay to often to be like "let's remove chocolatey and let the end user figure out how to get winget working", but IMHO it could be definitely an option to modify the loading to work like:
- Check if Winget is installed and working
- Try to Update/install Winget if not
- If Install fails, install Chocolatey
- Retry the winget install using Chocolatey
This way Chocolatey wouldn't need to be installed at all if a working winget install exists. (It could still be installed and used as a fallback obviously)
You are welcome to propose this as an idea/issue if you like it :)
Regarding the undocumented/miscategorized changes, those are definitely a worthy candidate for a new issue because this helps no one and is only annoying for anyone who has to debug a change they didn't intend to make.
In the end, it's up to you if you see the issues you created as answered or if you want to continue the discussion ;) In the grand scheme, I'm only a small fish contributor with my own opinion and I like it to be challenged if someone thinks otherwise.
And Chris has the last say anyway because he is the only one accepting and merging PRs
To add to your first idea, I think it could be very well possible to modify the compile script to load the config from the file into the winutil script so that there would still be the PRO of having the separate file for simplicity while developing, but no need to download anything afterward. I've actually not considered the approach of utilizing the compile for this :D
You are welcome to propose this as an idea/issue if you like it :)
I'll give you a better idea, why not ditch winget and chocolatey?
Use PowerShell script to install what you need, for example:
Invoke-WebRequest -Uri https://dl.google.com/chrome/install/latest/chrome_installer.exe -OutFile $env:TEMP\chrome_installer.exe
Start-Process $env:TEMP\chrome_installer.exeRegarding the undocumented/miscategorized changes, those are definitely a worthy candidate for a new issue because this helps no one and is only annoying for anyone who has to debug a change they didn't intend to make.
I don't think I will, but I'm not saying it out of malice or anything, I'm saying this from 2 reasons, 1. the github-actionsbot will auto-close this issue in 2 weeks and this issue won't get re-opened so why bother? (taking this stance since the issue with chocolatey installing was super frustrating for me to see get closed automatically and get no reply when users complained), 2. the owner (probably) won't care/reply.
I've actually not considered the approach of utilizing the compile for this :D
lol, but that sounds a bit complicated to be honest, but I guess it could be done
I'll give you a better idea, why not ditch winget and chocolatey?
The simple reason is, with winget/chocolatey someone else does the heavy lifting in case of Version Updates, Changing URLs, Installer Arguments for Silent install, Installer Arguments for User/Computer wide installations and so on.
Sadly on windows there are pretty much no standardization or conventions when it comes to packaging installers so this is an endless fight against the windmills