RicaNeaga

Ok, great! Also, more of a question: if I remember correctly, wasn't supposed Driver Installer Tool to detect the x86/x64 architecture of the system, and then hide the inadequate drivers (for example hide the x64 drivers on a x86 system) aka stopping them from beeing installed? Now x64 drivers are added to the list (haven't tried to install them), with no warnings (red bar or smth) on a x86 system...

Two small issues in test 10 beta of Win Toolkit 1.5.0: 1. Still the Ene cardreader x86 driver shows up yellow in Driver Installer Tool. You can see a screenshot here, and you can get the x86 5.89.0.71 driver from here. 2. I think the new transparency ''feature'' is quite transparent in certain cases. For example see here - the on-top Apply Unattended window is more transparent than probably intended.

Why is Apply Unattended missing from both AIO and WIM Manager? Beta 5 here...

If this is bugged, then I also vote for a fix ASAP. A very good registry tool - jv16 PowerTools - has a ''block malicious websites'' tool, that you can read about here, that adds to the hosts file such links from a known public database. So it's really important.

Test 5 soon? I'll test the latest beta build in a couple of hours...

Very likely it's something you've removed from windows causing this. It may be anything from this short list below... ... but most likely IE. Make another image, and make sure you keep the things I've mentioned here, and I'm pretty sure you won't have problems no more. Once again, make sure you DO NOT remove the stuff I've mentioned.

In test 3 of 1.5.0, when I click on Downloads / gadgets, it redirects me to this page. Wasn't that link supposed to redirect to the msdn page / Why not also change that link?

I don't think many would mind if you remove any gadgets related capabilities / mentions from your app, since Microsoft is abandoning them and consideres them a vulnerability they can't ''patch'' anymore. And that link to the msdn link is very useful.

Great! I was a little annoyed that in the latest builds I had to wait more than usual for the app to check for updates. Hell yeah! Bring them on! Stuff like that makes me forget I also wish for some requests to be implemented sooner than later; when multitasking comes to be discussed, later is ok. However, from a hardware point of view, please also make sure to test those stuff on a hdd - laptop low rpm to be preffered (~5400 rpm), or new ''green'' desktop hdds, that have also around 5400 rpm. If you have a SSD, it's very likely that this feature will be a killer, everything will be probably ~ twice as fast when it comes to integration (I mean a future multitasking app compared to the available 1.4.0 app, that does the stuff you mentioned in steps). But for HDDs, with poor I/O (besides poor writing / reading) performance, compared of course with SSDs, such a feature may bring very small performance gains (the time spent to integrate stuff may be virtually the same with or without multitasking). It may even be slower for the multitasking version when beeing run on an HDD. Already your app is fast, and already the differences of using it on a SSD vs. a HDD are huge. It's not exactly a warning, just wanted to bring this to discussion, and for you to strongly consider from the beginning that this kind of feature is VERY hardware bound. But since SSDs price are dropping, and already your app is adressing the needs of a niche (enthusiasts), who have purchasing power and spend alot on hardware, then maybe it's just talk. PS: As I was writing, I had an idea - how about Win Toolkit to check for the Windows Experience Index grade, the same as the windows os does, that stopps some services when the grade for the storage is high enough? I mean to bring on the big guns aka multitasking only on SSDs (that have a grade greater than 6.5 - 7 on windows 7), and keep it simple on a HDD. Just a thought really, if it's too complex (I really have no idea) programming-wise, then sorry for mentioning it.

It's fantastic that you're working on this, but I have a question. Can't you keep a working 1.4.0 version with the ''stable'' mark, and your code reworking in a new-app-name 1.5.0 beta? I'm asking because I really needed a working build the other day, and started with build .76, and it never occured to me that bugs can reappear. I thought that the code changes were coming in build 1.5.0; and with your code changing, it's very likely some things will not work again, and maybe some users don't want to be beta-testers. Also, it may have a huge impact on newcommers, that may think your app is buggy. So a ''stable'' 1.4.0 and ''beta'' 1.5.0 tags I think it's the way to go. I will help as usual with testing the new 1.5.0, and I'll always use it, unless I have an urgency, when a stable release will be very useful.

Yep, everything is fine in v77. Thanks.

Vote for sticky!!! I'm going to try this on my usual 4 addons in the weekend, and come back with feedback. Thank you very much, myselfidem!

Yep, v76 is yet again defective regarding silent installers. NONE of them work after integration - NONE are installed during first boot. You can try it Lego for yourself with ANY silent installer, I don't think further details are needed.

That time is now and this addon has just become xp exclusive (Vista and 7 users will use 4.5). So please Rick, with your next update, reconsider my request. Thanks.

Oh, great, thanks for the clarification. I'm not very into windows 8 right now, but it's nice to know for the future. So this installer is only for windows 7 & vista - maybe it's a good idea to bold that text in the first post, so some users with windows 8 won't use this.

Thank you again Rick for an amazing installer. However, I do have a question: I see that Microsoft is looking at .net 4.5 from two perspectives - the same problem generates two very different hotfixes, one for vista and 7, and one for 8 and 8 RT. So in this case wouldn't it be recommended to make two separate installers, one for pre-windows 8 OSes, and one for 8? For example, what versions of clrjit.dll and peverify.dll does your installer contain?

@mooms Your latest .exes from your previous post in this thread - are they still in frech by default? If yes, how can I modify them to be english by default? Thanks. And sorry Geej for this a little offtopic discussion, hope you don't mind.

Great! Can you also make an x64 addon of Everything?

Good to see you back, Lego, and glad you're feeling better. Not even a powerful flu can stand in the way of Win Toolkit dev! About those unsolved bugs... you need further info to figure them out? The first one with the collection is read only in AIO may be related to a peculiar location of the temp mount folder and some administrator options of that partition / location. Maybe it's related to the new option of Win Toolkit to have that temp folder on the largest partition available, that may also be a network drive. The second one - only one idea - maybe it's only user-related, some clumsy user renamed the windows image folder after it was loaded in Win Toolkit, with Win Toolkit running. For the last three I have no clue, sounds more like a c++ programming error than an windows error. Also, a suggestion - I remeber seeing ALOT of AIO errors reported here beeing caused by already processed windows images (either updates post-sp1 already integrated, or stuff already removed). So maybe a warning when scanning for the windows image folder (a warning that can be disabled from the app options), to preferably use an untouched msdn image when using AIO (you links for them in your app already) would be a good idea.

It's a Toshiba driver. Remove it from the integration and you won't have this issues anymore. Probably you are using driverpacks...

No no, I'm not reffering to that thread. It's ok, I don't have a big ego like other people from IT-related forums. But you were saying yesterday something ... I'd better quote you: So I remembered the no. 1, and thought that maybe you should state it more ofted.

Sorry to be a little offtopic, and also to contradict you, but I think you're more like Jean-Luc Picard. You're asking stuff Picard also spoke of. BTW - you said somewhere people who discuss more than one bug (as I do often) in one post annoy you. Maybe you should repeat this more, last thing I want is for Picard to get angry!

I was a happy user of WinCDEmu for a very long time, but lately it made me very itchy - way too many issues, so I went back to Virtual Clonedrive, which I ''left'' because it didn't have .nrg cd-audio support. However, with other complementary tools like ImgBurn, this is really a non-issue. So, if you could make a custom installer out of this, I would be very grateful. Please remove the default desktop icon, also associate with all supported extensions (.ccd, .dvd, .iso, .img, .udf, .bin, and also .nrg - it's ok with video or data .nrg files, only audio .nrg audio cd's are the problem), and also make sure the unneeded options ''keep history of recently mounted images'' and ''show icon tray'' options aren't selected/pre-ticked by default. I know it's my second request after Quicktime, but both aren't apps that receive alot of updates, so hopefully if you'll have the time to make these you won't spend much more updating them.

Maybe with the next update, when something new comes up, of course, that needs updating, you'll also make this ''useless'' updater issue go away. Thanks again!

Thank you very much but the latest version keeps bugging me about an update. Anyone else experiencing this?