bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Thu Feb 27, 2020 5:05 am

CaptainMidnight wrote:
Wed Feb 26, 2020 8:14 pm
Well here we are bzt, a completely successful test write of the raw(dd) image
YES :-) Thanks! I was hoping that build 2 is now finally works on all platforms perfectly.
Image
CaptainMidnight wrote:Well what can I say, your program can write a raw(dd) image to a 32GB uSD card in less that 1min more than the established competition and with a program size of just 239KB :o
About one second per minute is below the measurement's error margin because you were running them in a multitasking environment. It could be easily the other way around depending how many other tasks are running and how the scheduler picks them. But if it turns out to be presistent, even then the guarantee that the data is physically written to the disk worth that extra half seconds per Gigabytes IMHO :-)

My understanding is, that with compressed images USBImager is about twice as fast as etcher? Is that correct?
CaptainMidnight wrote:Just download a new version again from GitLab - how do I know it's the new version 2 (presume it would be) - it still displays 0.0.1 in the program window?
If there are no more bugs, then I'm hoping I can close the Release Candidate phase and go to the Stable Release. For stable I could finally bump the version to 1.0.0 which you'll see in window.
CaptainMidnight wrote:Well done ;)
Thanks! Thank you for your through testing, that was very very helpful! I'm sure I could not done without! I put your name in the README :-)

So the conclusion:
  • For raw images all programs performed equally, the difference being about 1 sec / 1 minute (within error margin of multitasking)
  • Win32 Disk Imager does not support compressed images
  • balenaEtcher does, but it takes about twice the time
  • Of the three USBImager is the smallest, by a lot
  • Only USBImager is dependency-free
  • Win32 Disk Imager requires Qt
  • balenaEtcher has hundreds of megabytes (!) of dependency
  • balenaEtcher and USBImager are available on all desktop platforms, Win32 Disk Imager is Windows only
  • Of the three only USBImager is available for ARM and Raspbian :-)
Cheers,
bzt

User avatar
CaptainMidnight
Posts: 76
Joined: Sun Nov 03, 2019 4:32 pm
Location: UK

Re: USB image writer

Thu Feb 27, 2020 8:29 am

bzt wrote:
Thu Feb 27, 2020 5:05 am
So the conclusion:
  • Win32 Disk Imager does not support compressed images
  • balenaEtcher does, but it takes about twice the time
Just to clarify, the timing results were produced with use of USBimager created raw(dd) and compressed (bz2) image files only.

* Win32 Disk Imager can work with compressed images as far as I'm aware - just not with the bz2 compressed image created by your program.
* balenaEtcher works with your bz2 compressed image but took over an hour to complete - but again only tested with the compressed file created by you program.

So in summary, if you create a compressed image with your program, it would be daft to write it back to the uSD card with anything other than your program ;)

Thanks for the mention in your credits, was just helping someone out that was creating something I've always been waiting for - thank you!

Through my experience with your program and your timely updates to discovered issues, I have no hesitation to recommend your program. As ever and to be expected from user land - a function creep request to add a 'dropdown block size selector' in the gui of all builds, with a predefined default, would round it off from my perspective. ;) :D
"Never get out of the boat." Absolutely goddamn right!
Unless you were goin' all the way...

bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Thu Feb 27, 2020 10:38 am

CaptainMidnight wrote:
Thu Feb 27, 2020 8:29 am
Just to clarify, the timing results were produced with use of USBimager created raw(dd) and compressed (bz2) image files only.
That's okay, I've used the vanilla libbz2 library, no modifications were made. If you use the "bzip2 -z9" command under Linux, it would use exactly the same code to compress, and it would create exactly the same output, bit-by-bit.
CaptainMidnight wrote:* Win32 Disk Imager can work with compressed images as far as I'm aware - just not with the bz2 compressed image created by your program.
I don't think so. I'm looking at its source right now:
mainwindow.cpp:381 in the method MainWindow::on_bWrite_clicked() passes the input file name to getHandleOnFile(). And that is defined in
disk.cpp:33, where it simply calls CreateFileW(), I see no signs of format detection, and in readSectorDataFromHandle (same file line 166) I do not see calls to decompressors or anything. So I think it's just a GUI version of "dd" for Windows (but for that a good one, may I add).
CaptainMidnight wrote:* balenaEtcher works with your bz2 compressed image but took over an hour to complete - but again only tested with the compressed file created by you program.
Thanks for the confirmation. As I've said, that's okay, USBImager uses the vanilla bzip2 library. But it made me curious, if you don't mind, would you be kind to create a measurement with the original raspbian.zip image too? That uses the deflate algorithm instead of bzip2, it would be interesting to see if there's a difference.
CaptainMidnight wrote:So in summary, if you create a compressed image with your program, it would be daft to write it back to the uSD card with anything other than your program ;)
Nope, you could create a compressed image with USBImager, then decompress it using "bzip2 -d"; or you could just as easily compress any existing disk image with "bzip2 -z" and use that with USBImager. There's absolutely nothing specific. USBImager just uses libbz2's low-level API in an on-the-fly streaming fashion, that's all. I don't believe in proprietary formats which tie the user to one particular application. The data is yours, you should be able to use it with whatever program you like.
CaptainMidnight wrote:Thanks for the mention in your credits, was just helping someone out that was creating something I've always been waiting for - thank you!
You are most welcome! You did a really great job, you reported problems accurately (even if you weren't sure about the why behind the problem) and provided detailed feedback. I wish all tester were just as through and informative as you were.
CaptainMidnight wrote:Through my experience with your program and your timely updates to discovered issues, I have no hesitation to recommend your program. As ever and to be expected from user land - a function creep request to add a 'dropdown block size selector' in the gui of all builds, with a predefined default, would round it off from my perspective. ;) :D
Thanks! I was thinking adding another combobox for block size, but I'm bit hesitant about adding more elements to the GUI, as I'm afraid it would scare off average users. Hence the command line flag. I think it is unlikely that an average user knows what block size is for, and they probably don't want to use different block sizes on the same computer with a given set of USB sticks / SD cards anyway. Advanced users can always create more shortcuts (".lnk" startup icons) if they want. TBH the reason why I haven't tried Rufus (besides it's Win only) is because it had way TOO MANY options on the screenshot that I knew I'd never ever need nor use.

That being said if there's a demand from more users to put a block size option on the GUI, I'll add it; I'm not against it, just a bit hesitant.

Cheers,
bzt

bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Thu Feb 27, 2020 12:07 pm

Confirmed by a tester: USBImager works on Windows XP!

There was a small issue with the displaying of the rounded disk capacity under XP. It should have worked, but it didn't. Fixed.
(For the curious, I've calculated the size in gigabytes as explicitly casted long long values multiplied by ten, then stored the result in an int, and printed as int. Now I store the result as long long, and only cast it in printf's argument. This did not influence the disk operations, just the combobox's strings on the ui.)

Cheers,
bzt

DarkElvenAngel
Posts: 730
Joined: Tue Mar 20, 2018 9:53 pm

Re: USB image writer

Thu Feb 27, 2020 1:28 pm

bzt wrote: I was thinking adding another combobox for block size, but I'm bit hesitant about adding more elements to the GUI, as I'm afraid it would scare off average users. Hence the command line flag. I think it is unlikely that an average user knows what block size is for, and they probably don't want to use different block sizes on the same computer with a given set of USB sticks / SD cards anyway. Advanced users can always create more shortcuts (".lnk" startup icons) if they want.
Something I've seen in some programs is an advanced options button that expands the GUI to show the things you want to hide from the average user, I have no idea how easy that is to implement on all your supported platforms. Or if it is easier have an advanced mode accessed by command line argument. Just throwing you some ideas.

User avatar
Greg Erskine
Posts: 140
Joined: Sat Sep 15, 2012 4:20 am

Re: USB image writer

Thu Feb 27, 2020 10:21 pm

FYI: AVG anti-virus warning
avg1.png
avg1.png (13.57 KiB) Viewed 1626 times
avg2.png
avg2.png (11.99 KiB) Viewed 1626 times
It looks like I was the first to use your utility with AVG and it has now been added to their database, so maybe others won't get the warning message.
* Raspberry Pi is a trademark of the Raspberry Pi Foundation

User avatar
Greg Erskine
Posts: 140
Joined: Sat Sep 15, 2012 4:20 am

Re: USB image writer

Thu Feb 27, 2020 11:02 pm

hi bzt,

I really like your design philosophy.

Works great on my Windows 10 PC. Thank you.

One thing I miss is USB image writer doesn't display the partition label of the partition it is about to clobber. I really like this sanity check before I overwrite something.

Feature request: On the Done message can you display the time taken.

regards
Greg
* Raspberry Pi is a trademark of the Raspberry Pi Foundation

DarkElvenAngel
Posts: 730
Joined: Tue Mar 20, 2018 9:53 pm

Re: USB image writer

Fri Feb 28, 2020 2:04 am

Greg Erskine wrote:
Thu Feb 27, 2020 10:21 pm
FYI: AVG anti-virus warning

avg1.png

avg2.png

It looks like I was the first to use your utility with AVG and it has now been added to their database, so maybe others won't get the warning message.
These are similar to what I got as well

bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Fri Feb 28, 2020 9:51 am

DarkElvenAngel wrote:
Thu Feb 27, 2020 1:28 pm
Something I've seen in some programs is an advanced options button that expands the GUI to show the things you want to hide from the average user
This is not a bad idea at all! If I decide to put on the block size combobox, I'll most definitely introduce advanced options checkbox as well!
DarkElvenAngel wrote:I have no idea how easy that is to implement on all your supported platforms. Or if it is easier have an advanced mode accessed by command line argument. Just throwing you some ideas.
Well, not too difficult with Win32 and libui, but a bit more work with the low-level X11. Using advanced mode command line flags is definitely easier by a magnitude. Thanks for the idea btw!
Greg Erskine wrote:It looks like I was the first to use your utility with AVG and it has now been added to their database, so maybe others won't get the warning message.
Thanks!
Greg Erskine wrote:One thing I miss is USB image writer doesn't display the partition label of the partition it is about to clobber.
Yes, that's because it is not using partitions at all. It writes to the physical disk, but unfortunately under Windows it is the drive letter that users expect (I'm pretty sure you'd be surprised to see the real device name like \\.\PhysicalDrive\2 in the combobox, and you wouldn't know which one is which). I know this is not an issue most of the time because there's only one partition and therefore one letter per disk, so showing drive letters works fine. But for example, there could be a disk with two partitions, D: and E:, then if you choose either of them, both D: and E: will be dismounted, \\.\PhysicalDrive\2 will be locked and written into. After that you might have one drive letter, or maybe more, depending on the new partitioning table written into \\.\PhysicalDrive\2.

This is not an issue with MacOSX and Linux as there I can show physical device, there is a one-to-one relation and users are familiar with /dev/disk2 and /dev/sdb for example (just a quick note, on MacOSX it is not the physical device either, it would umount /dev/disk2 but would open with exclusive access and write to /dev/rdisk2, there's an additional "r"). This also implies there could be no partition label on these platforms, and I want to keep the UI consistent. Hope this makes sense to you.
Greg Erskine wrote:Feature request: On the Done message can you display the time taken.
That's a good idea and easy to implement. I'll look into it.

EDIT: just an idea. How about '-a' flag for advanced interface? That would list physical drives under Windows as well (no need to format the disk prior to imaging) and would add block size to the GUI on all platforms? What do you think? Or what if I show the block size combobox only when block size is set on the command line? (Then the block size given on the command line would be selected as default).

Cheers,
bzt

bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Fri Feb 28, 2020 3:38 pm

Hi Everybody,

I've tried advanced options checkbox, but I found it pretty annoying to use. I couldn't simply check verify, I felt it's way too hidden and that I had to click too much to enable it. So advanced options checkbox finally didn't make it. Instead I made a little poll among my non-IT friends. They all agree that three options is not that much to be scary. I hope they are right, because they are all pretty smart (most of them have university degree, I wouldn't call them an average user, but at least they are not IT guys). Anyway, long story short, I decided to simply add the buffer size.

Here's the changelog for the next release candidate (build number 3) with minor, only UI-related updates:
  • Buffer size added to the GUI
  • On X11, checked checkbox got more contrast
  • The total elapsed time is shown when finished. The status bar looks like "Done. Image written successfully in HH:MM:SS."
  • Documentation updated
Under MacOSX it is a bit funny, because "Compress" sometimes sticks to Verify, other times to the buffer size when you resize the window. The combobox seems to have the top and bottom cut off, but everything is fully functional. There's no such problem under GTK (which uses the same libui), it centers "Compress" between Verify and the buffer size, and we have the whole combobox.

The UI now looks like this:
Image

Cheers,
bzt

jahboater
Posts: 5646
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: USB image writer

Fri Feb 28, 2020 5:09 pm

Hi @bzt,

I just built and tried usbimager for the first time (in fact the first GUI based imager - I have always been happy with dd/cp/unzip)!
Worked perfectly for Raspbian Lite using my Linux Mint 18.3 PC. The image file was in /tmp - a tmpfs disk.
It correctly offered only the USB mounted disks as destinations.
Nice little program!

Some trivial comments:

1) does it sync to the physical disk at the end (like conv=fsync for dd, or just typing "cp ....; sync") ? What I mean is, can I immediately pull the SD card out of the reader when the progress bar finishes? (I would call fsync() at the end, then close()).

2) The block size option perhaps needs a label.

3) The range of block sizes seems to go too large. As we discussed some time ago I think the "cp" command (and others like cat etc) use 128KB for good reasons. I am happy with the default 1M though. I think 512M would be slow - because it cant start the writing until the first block is read, and 512M is a big block. Perhaps offer a range from 128KB to 128M say.

4) Consider -Os instead of -O3 as speed is probably limited by disk I/O.
Pi4 8GB running PIOS64

bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Fri Feb 28, 2020 6:29 pm

jahboater wrote:
Fri Feb 28, 2020 5:09 pm
Hi @bzt,

I just built and tried usbimager for the first time (in fact the first GUI based imager - I have always been happy with dd/cp/unzip)!
Worked perfectly for Raspbian Lite using my Linux Mint 18.3 PC. The image file was in /tmp - a tmpfs disk.
It correctly offered only the USB mounted disks as destinations.
Nice little program!
Thank you! For the records, I use zcat|dd on command line too, but many users prefer a GUI. You could also try "usbimager -S", that will offer serial devices too, and USBImager will send your image over serial to raspbootin running on your Pi.
jahboater wrote:1) does it sync to the physical disk at the end (like conv=fsync for dd, or just typing "cp ....; sync") ? What I mean is, can I immediately pull the SD card out of the reader when the progress bar finishes? (I would call fsync() at the end, then close()).
Of course. It was a very important design goal that you can remove the USB as soon as USBImager says "Done.". This is also guaranteed on Windows and MacOSX.

Btw, "conv=fsync" not the best, you should use "conv=dsync" with dd. Likewise, in a code on an opened device file you should use fdatasync() instead of fsync(), because primarily you want to flush the actual data and not the meta-data on devfs.
jahboater wrote:2) The block size option perhaps needs a label.
Thought about that, not enough place unfortunately. The interface is multilingual, in my native language "Compress" is quite long actually.
jahboater wrote:3) The range of block sizes seems to go too large. As we discussed some time ago I think the "cp" command (and others like cat etc) use 128KB for good reasons. I am happy with the default 1M though. I think 512M would be slow - because it cant start the writing until the first block is read, and 512M is a big block. Perhaps offer a range from 128KB to 128M say.
Most modern devices use 1M internally. I don't want to put an upper limit, who knows what tomorrow brings? For now I do agree that using buffer sizes above 2M or maybe 4M is futile and probably slower than 1M. But maybe tomorrow on an USB5/6/7 stick 32M would be the best, who knows?
jahboater wrote:4) Consider -Os instead of -O3 as speed is probably limited by disk I/O.
No. I need specific linking optimizations with statically linking some of the libraries. Besides, compression and decompression is computation heavy and needs to be fast. Furthermore, the application is a single executable, which is less than 256K on all platforms (!), I wouldn't worry about code size if I were you :-)

Cheers,
bzt

jahboater
Posts: 5646
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: USB image writer

Fri Feb 28, 2020 6:41 pm

bzt wrote:
Fri Feb 28, 2020 6:29 pm
Besides, compression and decompression is computation heavy and needs to be fast.
Aha, yes of course. (I had assumed it would have called library functions or even a separate program for the decompression, in which case your optimization choice would not matter).
bzt wrote:
Fri Feb 28, 2020 6:29 pm
Furthermore, the application is a single executable, which is less than 256K on all platforms (!), I wouldn't worry about code size if I were you :-)
I'm not worried, it loads instantly on my PC!
I am very pleased to see there isn't hundreds of MB of bloat like etcher.
But a 40% (or so) reduction in executable size never does any harm :)
Pi4 8GB running PIOS64

jahboater
Posts: 5646
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: USB image writer

Fri Feb 28, 2020 6:58 pm

bzt wrote:
Fri Feb 28, 2020 6:29 pm
Most modern devices use 1M internally.
Yes, 1M is good as the default, so I will likely never alter the block size option.

By the way, the fact that USBImager is "dependency free" and trivial to build is a really important feature in my opinion.
Much less work for the RPF if it ever gets adopted as the "official" imager.
Pi4 8GB running PIOS64

bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Fri Feb 28, 2020 7:21 pm

jahboater wrote:
Fri Feb 28, 2020 6:58 pm
Yes, 1M is good as the default, so I will likely never alter the block size option.
I agree. That's why I was hesitating to add that option to the GUI, first it was only a command line flag (which still works).
jahboater wrote:By the way, the fact that USBImager is "dependency free" and trivial to build is a really important feature in my opinion.
Much less work for the RPF if it ever gets adopted as the "official" imager.
Yes, I have great experience in porting programs, I know exactly how much it means to have as few dependency as possible :-)

Btw, USBImager needs only
kernel32.dll, user32.dll, shell32.dll on Windows (all installed by default, libc statically linked)
CoreFundation, IOKit, DiskArbitration, Cocoa frameworks on MacOSX (all installed by default)
libc and libX11 under Linux (very likely installed on all distros, and installed on Rasbian by default for sure)
everything else (gzip, bzip2, xz, zip, libui etc.) linked into that 256K statically, so no shared objects needed for them.

There's a concern about X11 with distros switching to Wayland, but I'd say there's an XWayland module for Wayland just to solve that. But should a real need raise, and I'll implement main_wayland.c too.

I don't know about being adopted as the "official" imager, I'd be happy if the Raspberry Pi website wouldn't recommend a bloated spyware to newcomers (and I honestly wouldn't mind if it were not USBImager but another simple to use, Open Source multi-platform solution). USBImager just provides an option for that, a viable alternative.

Cheers,
bzt

User avatar
Greg Erskine
Posts: 140
Joined: Sat Sep 15, 2012 4:20 am

Re: USB image writer

Fri Feb 28, 2020 8:39 pm

bzt wrote:
Fri Feb 28, 2020 9:51 am
Greg Erskine wrote:One thing I miss is USB image writer doesn't display the partition label of the partition it is about to clobber.
Yes, that's because it is not using partitions at all. It writes to the physical disk, but unfortunately under Windows it is the drive letter that users expect (I'm pretty sure you'd be surprised to see the real device name like \\.\PhysicalDrive\2 in the combobox, and you wouldn't know which one is which). I know this is not an issue most of the time because there's only one partition and therefore one letter per disk, so showing drive letters works fine. But for example, there could be a disk with two partitions, D: and E:, then if you choose either of them, both D: and E: will be dismounted, \\.\PhysicalDrive\2 will be locked and written into. After that you might have one drive letter, or maybe more, depending on the new partitioning table written into \\.\PhysicalDrive\2.

This is not an issue with MacOSX and Linux as there I can show physical device, there is a one-to-one relation and users are familiar with /dev/disk2 and /dev/sdb for example (just a quick note, on MacOSX it is not the physical device either, it would umount /dev/disk2 but would open with exclusive access and write to /dev/rdisk2, there's an additional "r"). This also implies there could be no partition label on these platforms, and I want to keep the UI consistent. Hope this makes sense to you.
Hi bzt,

Yes I understand that it is not using partitions, simply writing a complete imagine over the top of the existing structure. I would still like to see the partition label of the (first) partition that is about to be destroyed. This is because when there are 2 USB drives mounted, I want to be very sure I have the correct one selected.

On Windows 10, as the first partition is often formatted DOS its label is recognised and used. The second partition is usually not in a format recognised by Windows 10 so the label is not used.

I would have thought the Linux type systems would handle partition labels better than Windows 10!

Here are a couple of Windows 10 examples where partition 1 label is "PCP_BOOT":
PCP_BOOT3.PNG
When SD card is inserted
PCP_BOOT3.PNG (23.14 KiB) Viewed 1434 times
PCP_BOOT2.PNG
Windows File Explorer
PCP_BOOT2.PNG (8.26 KiB) Viewed 1434 times
Here's how Win32 Disk Imager displays partition labels.
PCP_BOOT4.PNG
Win32 Disk Imager
PCP_BOOT4.PNG (8.09 KiB) Viewed 1434 times
I create hundreds of SD cards and always use partition labels. I think Raspbian is also created with partition labels.

regards
Greg
* Raspberry Pi is a trademark of the Raspberry Pi Foundation

User avatar
CaptainMidnight
Posts: 76
Joined: Sun Nov 03, 2019 4:32 pm
Location: UK

Re: USB image writer

Sat Feb 29, 2020 7:00 am

bzt, thanks for the block size selection box I know many may think it a frivolous gui feature - just completes your utility from my perspective. :D
"Never get out of the boat." Absolutely goddamn right!
Unless you were goin' all the way...

bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Sat Feb 29, 2020 8:56 am

Hi,
CaptainMidnight wrote:bzt, thanks for the block size selection box I know many may think it a frivolous gui feature - just completes your utility from my perspective.
You are welcome! Others have asked for it too, so here you go.

TLDR;
I have added the output of GetVolumeInformationW (requires Win XP / Win Server 2003) under Windows as an extra information in a parenthesis. Just don't rely on it too much!
Greg Erskine wrote:
Fri Feb 28, 2020 8:39 pm
Yes I understand that it is not using partitions
That's the problem, on Windows out of necessity it does list partitions instead of real disks. But the write operation must be done using a real disk device, not a partition.
Greg Erskine wrote:I would still like to see the partition label of the (first) partition that is about to be destroyed. This is because when there are 2 USB drives mounted, I want to be very sure I have the correct one selected.
I can't show the first partition's label as all the options are partitions. Besides, partition labels are inadequate to identify a disk, because:
- more entries in the combobox may refer to the same physical device (it lists partitions, not disks!)
- more partitions may have the same label
- when FAT used with GPT, partition label is ambiguous

I think the root of the problem here is that Microsoft calls the designation "X:" a drive letter, however it is nothing like that, it should be called partition letter instead. This misleads most Windows users.
Greg Erskine wrote:I would have thought the Linux type systems would handle partition labels better than Windows 10!
Oh, they do! It is absolutely clear that physical devices, such as "/dev/sdb" do not have partition labels, only partition devices like "/dev/sdb1" or "/dev/sdb2" do :-) But on Linux USBImager can list the disks, no need for messing with partitions, users recognize the physical device name "sda" or "sdb".
Greg Erskine wrote:I think Raspbian is also created with partition labels.
Well, Raspbian images do not use GPT, and there are no labels in MBR. So strictly speaking it does not use partition labels. But the FAT BPB has a short label in it, which says "boot". If you have a Raspbian disk in both of your USB drives, then you'll see two "boot" labels in the list, not really helpful.

Cheers,
bzt

User avatar
CaptainMidnight
Posts: 76
Joined: Sun Nov 03, 2019 4:32 pm
Location: UK

Re: USB image writer

Sat Feb 29, 2020 10:39 am

bzt, I've got an interesting issue - reported via the gitlab tracking system :!:
Last edited by CaptainMidnight on Sat Feb 29, 2020 1:26 pm, edited 2 times in total.
"Never get out of the boat." Absolutely goddamn right!
Unless you were goin' all the way...

User avatar
Greg Erskine
Posts: 140
Joined: Sat Sep 15, 2012 4:20 am

Re: USB image writer

Sat Feb 29, 2020 10:46 am

Thanks bzt,

Sounds like I haven't convinced you of my use case. lol.

regards
Greg
* Raspberry Pi is a trademark of the Raspberry Pi Foundation

bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Sat Feb 29, 2020 11:44 am

Greg Erskine wrote:
Sat Feb 29, 2020 10:46 am
Sounds like I haven't convinced you of my use case. lol.
No, but I've added the label regardless. Just remember you should not trust it, check the size, manufacturer's name and model strings too, that's my advice.

@CaptainMidnight: thanks! I'm looking at it.

Cheers,
bzt

Ernst
Posts: 1331
Joined: Sat Feb 04, 2017 9:39 am
Location: Germany

Re: USB image writer

Sat Feb 29, 2020 12:26 pm

I found one small "inconvenience" when used under English Windows 7:

https://gitlab.com/bztsrc/usbimager
You can use the executable in the archive as-is, the other files only provide integration with your desktop (icons and such). It will autodetect your operating system's language, and if dictionary found, it will greet you in your language.
My operating system language is English, my location is Germany, my keyboard/input language is German, every application uses English, except ...
Untitled.png
Untitled.png (43.59 KiB) Viewed 1324 times
The road to insanity is paved with static ip addresses

bzt
Posts: 558
Joined: Sat Oct 14, 2017 9:57 pm

Re: USB image writer

Sat Feb 29, 2020 1:44 pm

Hi,

@Ernst: yes, USBImager uses the LANG environment variable on all OSes, except Windows where it uses GetUserDefaultLangID(). Originally it used GetSystemDefaultLangID(), but some testers were complaining that it did not follow the Localization setting's change on the Control Panel, so I decided to use the user's language instead. Hope it is not a big prob for you that USBImager speaks your own language :-) I've fixed the documentation. BTW, is the German translation correct?

For everyone, I've found the issue @CaptanMidnight was referring to. Fixed, build number 4 is out. There was a problem with the backup buffer's size, so this fix affects all platforms. Unfortunately this was a bug indeed, so the number of days to the first stable release had to be reset :-(

Changelog:
  • Fixed backup buffer, now it works and you can modify it just as the write buffer's size
  • The backup file name changed a little bit, date and time is separated by a "T" to be RFC compliant
  • Really minor thing, I've standardized the verbose output on all platforms and added a few more details to it
  • Correction in the doc, USBImager uses the language that you've configured.
Cheers,
bzt
Last edited by bzt on Sat Feb 29, 2020 2:06 pm, edited 1 time in total.

User avatar
CaptainMidnight
Posts: 76
Joined: Sun Nov 03, 2019 4:32 pm
Location: UK

Re: USB image writer

Sat Feb 29, 2020 1:51 pm

Yes!

Timely updates and bug support, much appreciated my friend - hopefully stable release within touching distance now. :)
"Never get out of the boat." Absolutely goddamn right!
Unless you were goin' all the way...

Ernst
Posts: 1331
Joined: Sat Feb 04, 2017 9:39 am
Location: Germany

Re: USB image writer

Sat Feb 29, 2020 2:43 pm

bzt wrote:
Sat Feb 29, 2020 1:44 pm
Hi,

@Ernst: yes, USBImager uses the LANG environment variable on all OSes, except Windows where it uses GetUserDefaultLangID(). Originally it used GetSystemDefaultLangID(), but some testers were complaining that it did not follow the Localization setting's change on the Control Panel, so I decided to use the user's language instead. Hope it is not a big prob for you that USBImager speaks your own language :-) I've fixed the documentation.
That is a very big misunderstanding, I have had many "discussions" with some software companies (including Microsoft) because "Location" does not imply "Language", and there is no "User" language (at least under Win7)
Untitled1.png
Untitled1.png (34.55 KiB) Viewed 1264 times
Untitled2.png
Untitled2.png (34.25 KiB) Viewed 1264 times



see https://docs.microsoft.com/en-gb/window ... ge-support

The interpretation of the information in the above URL is not that easy if you have not been involved in this area of internationalization:
The National Language Support (NLS) functions permit applications to:

Set the locale for the user
Identify the language in which the user works
Retrieve strings representing times, dates, and other information formatted correctly for the specified language and locale
NLS also includes support for keyboard layouts and language-specific fonts.
NSL is about using a language for input and presentation, it does not apply to the display of application resources as these are dependent of the OS language. NLS is about information entered by the user and how to format certain language specific items. (time, date, etc). Translation is not part of NLS.

This is a relatively difficult problem if you have to support a large number of users from different countries (as I have done for many years) because normally the hardware will be a different language version from the operating system and applications. In the past I have been "forced" to work with Windows 7 English on a computer with a French keyboard located in France, that is the worst combination I have used. Using your logic I would have seen your interface in French.
Hope it is not a big prob for you that USBImager speaks your own language :-)
Unfortunately German is not my language ;-) For historic reasons my IT operating language is English, I do understand/speak German quite well but I do not want to use this in a my English environment.

The proper strategy is to use the system language (because that is what is used to present the OS resources) with a user selectable language option, no problem to use German language if the OS is a German version, mixing languages is bad.

Just my opinion based on 40 years experience working for a large german company in an international environment.
The road to insanity is paved with static ip addresses

Return to “General discussion”