RicaNeaga

Can confirm that now everything is ok in test 4. Thanks.

Test 4? Or maybe should I wait for test 5? BTW, I opened many threads and I don't want to open another for an oprional very small ''issue''. I just installed the resulted image in a VM, and saw that RunOnce Installer had a 1.4.1.13 name - maybe it better be named as the actual version, 1.4.1.15.

AIO - integrate updates, LDR mode.

Wasn't it deleted by default after everything was done? Not anymore... this happens in test 1, but very likely also in test 3...

Attached - latest WinToolkit141-15_Test1.7z used. It's the windows update cabs. one of them going red.

Don't believe it 'till I see it in a test build.

I've asked you here to sort the updates in Microsoft's way, with KB9xxxxxxx first, and only then KB2xxxxxxx. I've repeated this obsessively in various threads because I didn't wanted you to implement the alphabetical sorting, that wrongfully puts KB2xxxxxxx before KB9xxxxxxxx. And just what I feared has happened. If you cannot make the sorting by name to put KB9xxxxx first, then please remove the sorting by name ''feature''. It was better before without this sorting, when I could integrate the KBs directly from explorer in the right order.

Ok, then I also think a not-so-common name to that folder is preferable. I only hope the changes involved won't generate issues and / or waste too much of Lego's time. BTW, please Lego separate this thread and move parts of it as a request thread, for further consideration, as it's clearly not an urgent request.

+1 Sorry it's not in the Requests sub-forum, but maybe you'll see it Lego as right now you're into solving requests, and it's probably simple to implement. Or maybe we shouldn't worry, and Win Toolkit only searches the root of the DVD and not in other folders / sub-folders.

First of all, I can confirm it works great installed on a live win 7 x86 system via .inf - right click - install. Both install / uninstall don't generate any more issues. I'll edit this post after testing it as an addon.

Hope you haven't missed this, Lego. Or maybe you're waiting to refactor the code for Addon Maker first...

Tested myselfidem's installer in vm 7 x64, and everything is ok also on the x64 front, both regardin install and also uninstall. I'm going to test yours as an addon once you'll update it, both in x86 and x64 environments. Thanks. LE: Maybe you'll find usefull the .reg entries left by the (new - 1.3.0.632b) original installer, for both x64 and x86. Below... For x64: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Everything] "DisplayName"="Everything 1.3.0.632" "UninstallString"="C:\\Program Files (x86)\\Everything\\Uninstall.exe" [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run] "Everything"="\"C:\\Program Files (x86)\\Everything\\Everything.exe\" -startup" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\Search Everything...\command] ""="\"C:\\Program Files (x86)\\Everything\\Everything.exe\" -path \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.efu] ""="Everything.FileList" "Content Type"="text/plain" "PerceivedType"="text" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Everything.FileList] ""="Everything File List" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Everything.FileList\DefaultIcon] ""="C:\\Program Files (x86)\\Everything\\Everything.exe, 1" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Everything.FileList\shell\open\command] ""="\"C:\\Program Files (x86)\\Everything\\Everything.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Everything.FileList\shell\edit\command] ""="\"C:\\Program Files (x86)\\Everything\\Everything.exe\" -edit \"%1\"" For x86: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Everything] "DisplayName"="Everything 1.3.0.632" "UninstallString"="C:\\Program Files\\Everything\\Uninstall.exe" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run] "Everything"="\"C:\\Program Files\\Everything\\Everything.exe\" -startup" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\Search Everything...\command] ""="\"C:\\Program Files\\Everything\\Everything.exe\" -path \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.efu] ""="Everything.FileList" "Content Type"="text/plain" "PerceivedType"="text" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Everything.FileList] ""="Everything File List" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Everything.FileList\DefaultIcon] ""="C:\\Program Files\\Everything\\Everything.exe, 1" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Everything.FileList\shell\open\command] ""="\"C:\\Program Files\\Everything\\Everything.exe\" \"%1\"" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Everything.FileList\shell\edit\command] ""="\"C:\\Program Files\\Everything\\Everything.exe\" -edit \"%1\"" There is a new insteresting association with .efu files - don't see why not associate it with this rare extension. Or am I wrong?

Seek and you will find! Now I'm quoting the Bible... You want the short version probably... attached. In this way you'll find absoluti... errr... the isos, by following one of those paths. And three Hail Marys! Sorry Lego for the little offtopic, couldn't help myself.

Oh, but you'll be amazed. All you have to to is contribute in some way to this great app. Or I can say... It's all written in the app! I mean you can find all the info in that screen of Exclusive ISO on how to contribute. Hey, Lego, how about a new Win Toolkit cult? It's going to be the new scientology, let me just convince Tom Cruise to join.

I'll be back on this topic once IE10 is out, and its final .msu / .cab will be available. However: 1. If IE-related updates are the only reason, then last year I remember there was only one out-of-band update for IE9 that didn't came out on Patch Tuesday. All other updates that came out on Patch Tuesday were pre-integrated by Microsoft in the updated .msu from that month. Also, if my sorting request would be fulfilled, right now all other updates are going to be integrated after the IE9 msu for ''Microsoft alphabetical'' reasons, as requested here. Going to reply again after IE10 out. But if this is still the case then also, I don't see any reason for you to keep installing IE at the top and keep making code rules for pre-requisites. IE will install just fine if it was supposed to be installed last, with other updates with IE in the title and IE language packs also in that last category, these also installing just fine with the ''Microsoft alphabetical scheme'' applied (KB9xxxxx first then KB2xxxxxxx, and also for IE the updates had a higher KB number than IE, or if the msu was integrated - named simply IE9-win7 - was sorted by Explorer and also hopefully by Win Toolkit afterwards for alphabetical reasons). 2. You say that IE integrates just fine only with only one KB as prerequisite. But this isn't a safe approach at all. If Microsoft says that four updates are prerequisites, then please make sure all these updates are integrated (a pop-up screen or smth if those updates aren't detected). Once again, I'll be back after IE10 final is out.

The question in the title, if it has the answer I believe to have, I think will help Lego alot in its further development of its app. First - the ''old problem'', hadn't had the time to make a thread for it earlier - as you can see from the screenshots posted here and here, Win Toolkit will not only pre-integrate a certain update before IE10, but also before IE9 (without any reason). Also, as other have posted elsewhere, there are four updates (KB2786081, KB2670838, KB2726535 and KB2729094-v2) needed for IE10 right now as prerequisites. But I never understood why there is a need to install IE before the ''normal'' updates in the first place. IE can be a prerequisite only for IE-related updates (that have IE in the title) and IE language packs. IE 9 or 10 isn't needed to be installed first (to my knowledge) before any KB9xxxxx or KB2xxxxxx windows-related update. So, unless someone else says otherwise, why not let Lego simplify Win Toolkit's code by letting IE9 or IE10 install lastly (before IE language packs and IE-related updates)? Otherwise, Lego, you'll have to add rules to install 4 updates before it (ok for IE10, redundant for IE9, as is the case now, as shown in the linked screenshots), or maybe even more - we'll know soon when IE10 will be released as a final stable build. Also, as I've requested here, Win Toolkit would better install the updates in Microsoft's order, as for example Windows Update sorts them on a live system and installs them in that order - the current states of affairs, installing first for example KB2786081, KB2670838, KB2726535 and KB2729094-v2, after that IE10 and language packs, then the other KB9xxxxx and KB2xxxxxx (and only if the user already has them sorted, Win Toolkit doesn't sort them further) - this way it's just weird. In my vision, a ''perfect'' way (after my request regarding sorting is done) is that no-matter-how the user loads the updates, first KB9xxxxx and then KB2xxxxxx are installed, and only after IE9 / or IE10 and it's language packs and/or updates. Much simpler and more Microsoft-like, or am I missing something?

Yes!!!!! This is it!!!! Both installing and unistalling without issue!!!! Great!!! Thank you! @Geej Please update your addon with myselfidem changes regarding taskkill, both for installing and also uninstalling Everything. His latest .inf inside the 1.3 .7z installer solves both problems I've had with yours.

He probably means to add it. There is however already a tweak in WinToolkit that adds it to the desktop right-click.

I think it's perfect from my perspective the new screen with the exclusive ISO's. Actually also a little touched by the text (not joking). I for one will definitely contribute also with money for this great tool and only in this way unlock that area. However, besides the spelling error in the name of the tab (Exclusive not Exl...), are you sure Lego about the term ''Updated'' there? I was reading the last phrase in bphlpt's previous intervention.... How about ''Community ISOs'' or ''Exclusive ISOs''?

I was kidding with the language. Thanks however for the screen, tskill.exe is really where it's supposed to be, I don't think this is the issue. I'll try again on a fresh install. Thanks again.

I'll try again tommorow on a clean virtualbox install and report back. Thanks again.

This one installs just fine, however gives the same tskill error when trying to uninstall. Oh, and it's also in french (just kidding). Thank you for trying. Maybe some .reg entries were changed in the new version regarding uninstalling process of Everything? Or maybe smth is wrong only with my pc...

@myselfidem Much obliged if you could share the generated .sfx file via mediafire or smth. I'm only a semi-advanced user when it comes to silent installer making, so as the right-click install option is out of the question for what you've attached, and I'm lazy enough to generate a config file for the way I know to generate .7z installers... Thanks.

1. The first bug is related to some inconsistencies regarding displaying the correct settings in an Addon when opened. For example, as you can see here, after opened in Addon Maker, Reaper's x64 NFOPad addon from here is diplayed as having the shortcut point to Program Files (NOT OK!) folder instead of Program Files (x86) (OK!). This is not the case, everything is ok with the addon, the shortcut really points to Program Files (x86) as it should. To make this one even weirder, I changed a little this addon, didn't even check that tab (left it as Reaper made it), and afterwards the newly made addon pointed to Program Files (x86) also when opened with Addon Maker. However, for another user, as you can see here, it's the other way around, my addon points to Program Files (NOT OK!) while Reaper's to Program Files (x86) (OK!). :doh: 2. Probably this one is also related to the first, but it's worth mentioning. When opening an addon with Addon Maker, for example the same x64 addon made by Reaper, one file (contained in the temp C:\Users\Administrator\AppData\Local\Temp\WinToolkit\AddonC folder) appears as lastly modified at the same moment as opening them. But this is not all! When saving again the same files as a new addon (open the addon then save again with a new name), even without modifying anything, most importantly the .reg file is modified by default when saving through Addon Maker (not the same MD5 and also all the spaces between the entries in the .reg are gone!!!). Other files are also modified - the .lnk, and the .txt files - but these aren't so important.

Just seen it. Are you sure this is the best idea? Why not showing that tab only for donators? It's your app, your way, I just hope you won't have trouble with you-know-who...