Image Writer won't start - nothing happens at all!

Not sure which zip you downloaded based on your question. Each binary release has been tested before uploading. Also, it is not advisable to have multiple binaries extracted to the same directory, as each zip has libraries specificly tested with that release.

One thing you can try is to run it from the commandline. See if it produces an error.

If you can hold on, I am feverishly working on v0.7 for release today (hopefully before the Superbowl).

Hello!

In my case, after the program started, the process keeps a cpu usage at 25% around for a while, then the window shows up. The function is OK.

I tried v0.6 and it is fine. The window shows up immediately when I double-click the program in explorer.

v0.7 CRC32:
3AAB65F1

v0.6 CRC32:
6AA3BFE6

qaqz: Do you reboot in between tests? Try starting 0.6 first, and then 0.7. Your computer could be caching things from the first run which allow the 2nd run to start much quicker.

Penn: no idea. I use 0.7, 0.6 and 0.5 on win7, and they all start up. Are you using an admin acct to run it?

Thanks all - I downloaded v0.7 and it works fine. I haven't experimented with v 0.6 in a different location, but I guess it could be to do with running the file from the Downloads directory.

(BTW I wasn't running multiple versions from the same directory, I deleted 0.5 before downloading and unsuccessfully trying 0.6).

Jeff: Well, I've tried as your say, nothing changed. I started v0.6 first, and then v0.7. No matter v0.6 is closed or not, v0.7 keeps a conspicuous cpu usage for about 20 seconds and then the window shows up. During the high cpu usage the process owns just 1 thread, and the became multiplethreads after the window shows up.

v0.6 shows up immediately whether v0.7 is up or not.

I was very sure that my computer was not doing caching or other things.

And of course I put v0.6 and v0.7 in their own directroies with all files extracted from their own zips.

I'm sorry - I didn't mean to run them simultaneously - I just thought that QT might be doing something with loading/caching display elements on the first run, which subsequent runs can benefit from...

AFAIK, 0.7 doesn't do anything (during startup at least) radically different from 0.6. Not sure why their startup "process" would vary. If I get some time, I'll take a look and see if I see anything.

Thanks for the info.

It's OK, thanks for work!

Actually, v0.7 does do a little bit of work when first started. To figure out where the Downloads directory is, it scans all subdirectories below %USERPROFILE%. Since each version of Windows is different, this can be a bit slow. I haven't had a chance to test this feature extensively yet on a system that has been in operation for a while, but it shouldn't be too hard on a system. On my work system (Lenovo T61 Celeron w/ 2G memory running Windows 7 Enterprise), the first time I launched it took 4 seconds and 48% cpu (in task manager). The second time took 2 seconds with the same load spike. Note that on my work system, I have lots of files and subfolders under my %USERPROFILE% directory. Our IT department thinks that is a good location for pushing updates and IT spamware (and they wonder why the user profile backups are slow).

This was added to work around a new issue that came up when fixing LP:1100228. The fix involved changing the file dialog from a Save to an Open function, but that in turn created an issue where the user wants to save a new image file (file doesn't exist in the Open dialog caused it to generate an error). To get around the whole mess and to make the program a little cleaner, I decided to make it default to the user's Download directory, but there again, Windows has no clear solution how to derive this path (it has changed with every Windows release from what I can tell).

I'll look into a more optimized solution for setting the default directory before the next release. Maybe tweak the filters or something.

Thanks Tobin, this should be the point.

On some very old machine, the 4 seconds work on newer machine will be increased by multiple times due to the OS or hardware mechanism here. This tool is not just for new machines I think, actually it usually was used with some *nix stuff which works more fluent than windows stuff on the old machines. Thus the 20 seconds waiting will defeat lots of users - I'm still using v0.6.

The save posiotion question is quite simple, to avoid the long-time scan action, there are a few suggestions from me:

1. Just use the folder where the .exe resides - there're so many tool applications do this way. And the last used folder was remembered in a .ini file(or in windows' registry) which placed at the .exe folder. If the remembered position does not exist, the .exe folder would be the start point.

2. Lead the user to a non-writeable position - like 'my computer' - for the first time the user want to save and disable the 'Save' button. OK this is just a trick to have the user deciding the save place rather than let the program to searching for a proper position. And after the user pick a position for the first time the app can remember this.

3. Use the folder which the user choose to open an .img file last time.If this position is not specified, refer to above.

4. The worse method, hit the scan action while the save as box is about to show.

Wish these suggestions to be of help.

And thanks for the work again!

One reason against using the current working directory (CWD) is that when we launch the installer later this spring, the default location will be somewhere in the "Program Files" directory. Also, most users will be downloading images for their devices, and 99% of the time, those downloads will default to the "Downloads" directory for that user. Hence the reason I chose that directory.

One solution to this could be to create default settings during installation that can be read on program start much quicker than the current implementation (i.e read a registry key). Another way to improve this would be to move the directory initialization code to run just before a Read or File Select operation instead of on startup.

As to older hardware, I can try testing on really old systems to see just how bad it is. But you also have to consider that Microsoft has all but dropped XP support now, and supporting Intel hardware older than 5 years is very difficult (I do have some, but it may take a bit to get them online). The oldest system I have online now is a Core2Duo T2700 laptop (6 years old). The oldest system I have available is a Pentium III 700mhz, but I'm not sure what state it is in or if XP will run on it. Beyond that, I really don't see much benefit to supporting things that are older. We can't test on older OSs (I just don't have any).

You mention "*nix stuff". Can you clarify? If you are using this in a non-windows environment, I don't know how to support that (or why I would try, given there are far better tools for this in Linux/Unix), although a Linux version has been considered and could be a possibility in the future.

Well, I use this program to write image to usb/flash keys, NAS4free or FreeNAS or maybe other things.
What I was fighting against recently is NAS4free and FreeNAS. There seems to be a bug with the samba in them, so I have to test them alternately over and over on different machines with a few recent releases. I don't think that use windows to hold a nas file server is a good idea than a FreeBSD based speciallized system.

About the older hardware, I'm sorry that I haven't actually tested for that inference. Actually my notebook is not as old as a P3 level, it's i3-2310M and 2G RAM inside, but it still stucks me for about 20 seconds to finish the scan action. That is what I was confused since I haven't read the code. So, that the older machine will take more time to do the scaning is just a deduction that infered from the high cpu usage and long-time action on my i3.

To locate the 'Downloads' directory for current user, the best way is surely to read a registry or call the system APIs to get the path. But there's still a problem that older version of windows do not have a system defined 'Downloads' folder.

May this be of help:
http://stackoverflow.com/questions/7672774/how-do-i-determine-the-windows-download-folder-path

So, according to above information, the process maybe should look like in this way:

1. Get and verify the current system version.

2. If it is Vista and above, go the SHGetKnownFolderPath way; if xp/2003/2000, the SHGetFolderPath + '\\Downloads' way; if me/9x/nt4, the user system should have IE4 installed that this API can be obtained through SHFolder.dll which was coming with IE4.

Some helpful links here:
http://msdn.microsoft.com/en-us/library/bb762188.aspx -- SHGetKnownFolderPath
http://msdn.microsoft.com/en-us/library/bb762181.aspx -- SHGetFolderPath <-- note the Remarks section

Oh, and this link is about OS version geting and verifying dropped above:
http://msdn.microsoft.com/en-us/library/ms724832.aspx

Yea, I had already tried those. Even in Windows 7, using the prescribed methods from MSDN for Windows 7, it failed on my test system.

Part of the problem here is that we use mingw as our build environment, not Visual C++, due to licensing and costs (I really do not want to spend money only to support a free app). And since Microsoft keeps changing their functions for finding this with every release, it is near impossible to keep up, especially when the underlying tools are still based XP api's.

I'll continue to profile this and look for improvements. Like I said, maybe the key is to just look during install and create a registry key (or create a registry key on first run). For now, unless it is completely unusable, I would rather focus on other high need tasks (like getting a proper forum for discussions like this onto sourceforge). I also want to let this version float around for a little while to get more feedback (this is very helpful btw).

Created lp:1117840 to track this (mainly so I don't forget).

It's OK and again, thanks Tobin and the developers!

Good for this and damn for M$ ;)