Jump to content

Windows 7 Toolkit v1.4.0.x Feedback / Issues / Bugs


Recommended Posts

That addon works just fine in v.*67. Ask me how I know :D

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 OS

THX

ps : sorry for my bad english :shy:

Edited by geromichi
Link to post
Share on other sites
  • Replies 62
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

WOW thats really well kinda rude and unnecesarily put out there. Why are you being confrontive about it? Better put: "Hey Lego, what would be the reason for the txt file the toolkit leaves? Can that b

I have already posted this in other thread:

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

Posted Images

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 post
Share on other sites

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.

Link to post
Share on other sites

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 post
Share on other sites

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 place

temp- and mount-folder: this path will be written in the setting txt and used on all the next runs.

Regards, Thiersee

Link to post
Share on other sites

this path will be written in the setting txt and used on all the next runs

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.

Link to post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites
Guest
This topic is now closed to further replies.



×
×
  • Create New...