Closed mzomparelli closed 1 year ago
ok but 2134 will use 22000. I will prove it just give me a bit. Do you have 2134 installed and ready?
No that's the point I don't have a machine running it anymore.
Well go get an iso for it and setup a VM. You are assuming stuff and creating code we don't need
Do you think I could just uninstall KB5029351 which is 22621.2215?
possibly, but it's safer to just get the iso and setup a VM. I'll do it. Will you be able to attend a screenshare when I have it ready?
You are assuming stuff and creating code we don't need
Not assuming 😁 I saw it before my own eyes. VirtualDesktop worked, do windows update reboot, VirtualDesktop don't work…
Ok, I trust that something happened for you, but based on the code I'm certain it will work without the minor. I will set it up and prove it.
possibly, but it's safer to just get the iso and setup a VM. I'll do it. Will you be able to attend a screenshare when I have it ready?
Depends when that would be. I'm GMT+1 don't have anything planned tonight though, other than getting a good night rest.
It won't have to be today. Your code works and can stay for now, but I will prove this and we will do away with minor version. When I prove it you will take my commit that does away with minor, right?
Of course if we can prove there is not need for the minor version check I would gladly do without it.
As for the app.config
and settings issue there must be a way to use the settings wizard so that it generates a cleaner config.
Here is what it looks like on my machine:
but why is the app.config so important to you? It looks fine to me and users should not change it. It's created when we build and the only reason for a change to it is when we build. There is no reason to modify app.config after compile.
To me, easy to read diffs is important to keep track of those changes. If every contributor comes along with a different version of Visual Studio and keep pushing unneeded changes just because on that day with that version of Visual Studio the code generator decided to do something different we keep on polluting the file history which would make it hard to track regressions down the road. Hope that makes sense.
We don't modify app.config. It's created from Settings.setitngs at compile time
https://files.rg-adguard.net/version/f0bd8307-d897-ef77-dbd6-216fefbe94c5
I have undone your changes and have it working on 22621.2215. I am now getting the iso for 2134
https://files.rg-adguard.net/version/f0bd8307-d897-ef77-dbd6-216fefbe94c5
Thanks for that link, that could be useful.
well getting that specific version is not easy, but I will keep trying
well if it's not easy then why are we supporting it?
even though I'm sure my code will in fact support it
well if it's not easy then why are we supporting it?
For smooth transitions while users are upgrading. You could try any 22621 build before 2215 and it should not work with the new UIDs.
ok' I'll try one that is earlier than 2215 if I can find.
if you find a link then post it. I have some downloading that I hink will work. I have a feeling that Microsoft will perform the update during installation though
You could install offline.
You could install offline.
Are you sure? I'll try but I though MS makes you be connected.
Please no more commits until I am done. I will be done today. I just don't our repos to be out of sync.
I have this - I think it'll do. Installing now en-us_windows_11_consumer_editions_version_22h2_updated_sep_2022_x64_dvd_f408dad5
Do you know how to get around this?
I think I got it
I'm booting up a laptop that could have a version we could use for testing.
Nevermind that's Windows 10 laptop…
I have 22621.525 and I'm testing it now
Let me guess, it's not working the way you thought it would? 😁 You know using both OS Build major and minor version really is not much more complex than just checking the major version. Also the current implementation is rather clumsy. I don't think we should assume major is 5 digits and minor is 4 digits. So there is a lot to improve on there. However checking the whole OS Build makes this solution future proof and I think that's what we should be aiming for.
ok ok you win, but you don't need the Settings.settings for 22621_0000 because it's the same as 22000 and it falls back fine. I just tested.
So I am keeping your changes, but I am removing 22621_0000 and I am also adding support for Server 2019 and 2022
I would like to point out that we should not even support 22621 < 2215 as Microsoft will quickly update you past that now. Shame on them for keeping the major build number while having interface changes.
ok ok you win, but you don't need the Settings.settings for 22621_0000 because it's the same as 22000 and it falls back fine. I just tested.
That is correct. I believe 22621_0000 is just a left over of my implementation process. It does no harm but is also not needed and can thus be discarded. Also it's not about winning or loosing it is about getting it right.
My first commit is just removing that 22621_0000. the next commit after that will be for support for server 2019 and 2022
Win server 2022 is build 20348, so we will need the 22621_0000 back in in order to support server. Ugh!
oh nevermind, I got confused. We don't need it back in
I would like to point out that we should not even support 22621 < 2215 as Microsoft will quickly update you past that now. Shame on them for keeping the major build number while having interface changes.
If I had to take a guess I think there is a lot more < 2215 than >= 2215 today and for weeks or maybe even months to come. The amazing flexibility this library offers thanks to @Grabacr07 and other contributors allows us to support all those versions and I am of the opinion we should try to keep it that way. Though I have to admit we could greatly reduce the complexity and just decide to support the latest and greatest at some point. Let's hope it does have to come to that.
And yes it did look like until recently only major updates would come with interface changes. Though I can't say I'm surprised they did that.
This works, test it. The GUIDs should be ordered.