geromichi Posted September 8, 2012 Share Posted September 8, 2012 (edited) That addon works just fine in v.*67. Ask me how I know I think you're using a x86 OS..I've found the problem : .exe based addons don't work when x86 arc is wroten in tasks.txt when integrating in a x64 os based.The same addon with x64 in tasks.txt works fine in v.*67 in a x64 os based...So installer both architectur compatible included in addon with x86 line in tasks.txt appears to not work with x64 OSTHXps : sorry for my bad english :shy: Edited September 8, 2012 by geromichi Link to comment Share on other sites More sharing options...
Legolash2o Posted September 8, 2012 Share Posted September 8, 2012 I'm guessing its the registry entry which adds the RunOnce not getting added to the correct place. Link to comment Share on other sites More sharing options...
Legolash2o Posted September 8, 2012 Share Posted September 8, 2012 Found the issue and it's now been fixed. Link to comment Share on other sites More sharing options...
RicaNeaga Posted September 8, 2012 Author Share Posted September 8, 2012 Great! Also, I think you forgot about this cosmetic issue two pages back...the ENE USB Mass Storage 5.89.0.71 (that you can find here as an individual driver, and also you can see it's for windows 7), comes up yellow. This is only valid for the x86 version in an x86 environment, everything is fine in a x64 environment with the x64 driver.This is also present in v68. Once again, only a cosmetic issue, but maybe you can add an exception so it won't come up yellow.Also, in v68 now I consider there is a new problem by design. I've tried in this thread to confirm that even in LDR mode the KB2685811 and KB2685813 generated explorer issues are still present, but you chose to ignore this. So please at least add a warning so users can be informed about the matter (a warning like ''even in LDR mode these two update can generate explorer issues for some hardware & software configurations"), so users may remove them from the integrating list manually. Link to comment Share on other sites More sharing options...
dareckibmw Posted September 8, 2012 Share Posted September 8, 2012 new v.*68 is really slow, in my case it took 38min., when it usually takes under 20min. and i tested it twice, just to make sure it isn't "operator error". Link to comment Share on other sites More sharing options...
geromichi Posted September 8, 2012 Share Posted September 8, 2012 No more addon problem for me with v.*68 : great work :dancing: Link to comment Share on other sites More sharing options...
RicaNeaga Posted September 8, 2012 Author Share Posted September 8, 2012 About the slowness issues, I think it's related to the new temp folder location via options.I tried to change the location from D:/WinToolkit (the partition that was auto-detected as having the most free space) to C:/WinToolkit, but the app has the usual behaviour to erase the folder after unmounting. So guess what: after I've run for the first time AIO, on C:, mount-integrate-unmount, and opening the app again and not detecting any temp folder on C: (the app erased it on the previous run), so the app once again had the temp folder set on D: by default.At least this behaviour is weird so the current implementation is faulty. Maybe smth like a single choice in the options to change only the partition you want for Win Toolkit to ''operate'' on, that also remains unchanged, no matter how many times you run the app.Suggestion for users with ''slowness'' issues - If you have an SSD, make (sure) the app has its folders (via options) on the SSD partition EVERY time you open the app. If you have a HDD, make sure you have those folders on the first partition - C:, the same as the original copied windows files. dareckibmw 1 Link to comment Share on other sites More sharing options...
dareckibmw Posted September 8, 2012 Share Posted September 8, 2012 Thanks for the tip RicaNeagaI unplugged external HD in my laptop and now it uses my SSD. All done in 18m56s Link to comment Share on other sites More sharing options...
RicaNeaga Posted September 8, 2012 Author Share Posted September 8, 2012 You're welcome. Another thought for this default option - maybe if the C: partition has at least 25 GB free, then choose C: for the temp folder. And if it has less, then scan for another partition... This would also pre-solve the potential slowness problems.I don't know what the reason in the first place to make this option, Lego, but please reconsider it. Link to comment Share on other sites More sharing options...
Thiersee Posted September 9, 2012 Share Posted September 9, 2012 I can't understand this complain about temp-folder-placing!If you don' want that WinToolkit search for you the biggest free partition, you can set, where WT has to placetemp- and mount-folder: this path will be written in the setting txt and used on all the next runs.Regards, Thiersee Link to comment Share on other sites More sharing options...
RicaNeaga Posted September 9, 2012 Author Share Posted September 9, 2012 this path will be written in the setting txt and used on all the next runsIf you would have read what I've said you would have understood that this is not the case. So to understand you really need to read. Not reading equals not understanding. Also, if a user has an external HDD attached, or a very fragmented (but with ''tons of free'' space) partition, then Win Toolkit processes will become very slow. Link to comment Share on other sites More sharing options...
Thiersee Posted September 9, 2012 Share Posted September 9, 2012 If you would have read what I've said you would have understood that this is not the case. So to understand you really need to read. Not reading equals not understanding. Also, if a user has an external HDD attached, or a very fragmented (but with ''tons of free'' space) partition, then Win Toolkit processes will become very slow.I have read, what you wrote and I'm still not understanding, because on my installation WT writes the chnages in the setting.txt.BTW, I have 2 HDDs attached and I DON'T use the auto-feature. Link to comment Share on other sites More sharing options...
Legolash2o Posted September 9, 2012 Share Posted September 9, 2012 Great! Also, I think you forgot about this cosmetic issue two pages back...This is also present in v68. Once again, only a cosmetic issue, but maybe you can add an exception so it won't come up yellow.Also, in v68 now I consider there is a new problem by design. I've tried in this thread to confirm that even in LDR mode the KB2685811 and KB2685813 generated explorer issues are still present, but you chose to ignore this. So please at least add a warning so users can be informed about the matter (a warning like ''even in LDR mode these two update can generate explorer issues for some hardware & software configurations"), so users may remove them from the integrating list manually.It doesn't appear yellow to me, works completely fine.Also Win Toolkit will only selected from 'Fixed' drives so external HDDs should not be selected.P.S. Since everyone is dumping there issues into this one thread and making everything complicated, i'm going to lose this thread. If have used the latest version and still have issues then please make a new thread which should have happened in the first place... Link to comment Share on other sites More sharing options...
Recommended Posts