OSDev.org

Hi All,

Let's say you have reached to the point when you can present a downloadable live image of your hobby OS. You tell your testers to download it, and they ask back: and now what should I do with this file to boot it on real hardware? Or maybe you just want a quick and easy way to create bootable media from live images because you like trying out OSes. What options do you have? Not much currently. R***s is only available on Windows. E***r is several hundreds of megabytes and known to be spying on you. The dd tool is cool, but average testers can't use it, specially not with compressed images.

So I put together a neat little application: USBImager. It comes without warranty, but if you find it useful then I'm happy for you

Features:

• No installation required, portable executable.
• Extremely small (about 128K on each platform)
• Available for all mainstream operating systems (Windows, MacOSX, Linux)
• Uses a native, very minimalistic GUI
• Can verify writes by reading data back and comparing to the original buffer
• Supports raw images: .raw, .bin, .iso, .dd etc.
• Supports compressed images: .gz, .bz2, .xz, .zip (both PKWARE and ZIP64)
• Estimates remaining time
• Has multilanguage support (currently 16 languages supported) by detecting the OS' locale
• Free and Open Source Software, licensed under MIT

Screenshots:


The Windows version uses GDI and requires MinGW to compile. On MacOSX it's shipped with libui (statically linked) that uses Cocoa and can be compiled by CLI tools (no need to install XCode). Under Linux, you have two options: there's an X11 version that's totally dependency free (save libX11.so), and there's the statically linked libui version which uses GTK (and has tons of dependencies, X11, Wayland, harfbuzz, freetype2, cairo etc., but looks cool).

There's no reasonable upper limit on the disk image size, it can write easily a 2^63 bytes image, as it uses streaming only (for compressed images too).

Cheers,
bzt

That's a cool one! Thanks.

Some side-question: I never heard of libui before. Can you tell me a link to it?

Regards
Peter

PeterX wrote:That's a cool one! Thanks.

You're welcome! I wanted to show the world that having a 400 MB application that has to connect to facebook and google in order to write local files to local USB drives is NOT the only way... Actually I can't believe how doesn't people realize that's just insane.

PeterX wrote:Some side-question: I never heard of libui before. Can you tell me a link to it?

Yeah, sure. I've included its license as well as the repo url in the README. You can find its source repo here.

Libui is a small, MIT licensed, Open Source C library that provides native GUI. Or more precisely it provides the same API on all platforms. I really liked the idea how it was done: instead of a single bloated software, the same C API implemented on all platforms separately and independently, using the native toolchain (C under Linux, C++ for Windows, and Objective-C on MacOSX). These compile to the appropriate libraries (.so, .dll, .dynlib) to provide exactly the same C interface. Its API is really clean, plain simple and straightforward to use. Just as it should be.

Unfortunately it's in alpha stage, and I had many issues with it. I was able to compile it under Windows, but I couldn't link it with its examples. So I started with a native Win32 app for USBImager. Then I realized that under Linux it uses GTK, and that GTK forbids setgid (running with effective gid of the "disk" group is essential to access raw disks). I was pretty annoyed to find out that GTK checks for setgid, and calls it a "WARNING", while it actually refuses to run, and there's no workaround. Blocking the app is not exactly a warning, isn't it? Anyway, this is not libui's fault. But I had to implement a purely X11 interface for USBImager. Finally, I've experienced problems with the combination of pthread and libui under MacOSX. As a result, I had to use one thread only, so the progress bar is pretty laggy under Cocoa. So although libui looked great, but I ended up coding a native GUI on all platforms, something that I wanted to avoid in the first place.

So in short, great idea, poor implementation. Despite all of these issues (which are not uncommon for a software in alpha stage) I honestly believe this is a great project and has a great potential. I do hope the author will solve these issues, and it gets a stable release. I think I'll port its API to my OS too, just to support portable windowed apps.

Cheers,
bzt

New features

• It can also read devices and save into raw or bzip2 compressed image files
• It is now able to send images over serial line (useful for boot-time imaging microcomputers like the RaspberryPi)
• All known bugs fixed.

EDIT: since USBImager is able to send images over serial line, just for fun I've quickly put together a multi-platform boot loader that can receive those images: Image Receiver.

For x86, it uses BIOS and loads kernels at 1M. It accepts raw images and ELF kernels, and sets up protected mode for them, unless there's an ELF64 header in which case it initializes long mode before it jumps to the ELF's entry point (and identity maps the first 1G RAM).

For the Raspberry Pi, the loader is implemented as a chain loader, it preserves the environment and loads the kernel exactly where start.elf would, so it is capable of loading unmodified ARM kernels. ELF kernels are also supported, although either ELF32 or ELF64 depending on the platform, no dynamic detection unlike for x86.

Cheers,
bzt

Dear Forum Members,

I'm looking for a little help from you. I've translated USBImager to several languages, however I do not speak all of these. So I'd like to ask a native speaker to verify the translations. Only a handful of sentences and phrases, nothing big, shouldn't take longer than a couple of minutes (the dictionary literally fits on one screen).

The translation file is here.

Already verified by a native speaker: English, German, French, Hungarian, Dutch, Russian, Turkish (nothing to do with these).
I'm particularly looking for a Spanish or Chinese speaker, and it is not as important, but would be really nice to have someone to verify Italian, Polish, Portuguese or Japanese dictionaries too.

Thank you,
bzt

ps: I named Spanish and Chinese languages only because of the big number of native speakers, nothing else. I do not want to suggest that other languages are inferior in any way; and new languages are also welcome any time.

and new languages are also welcome any time.

if interested, I translated in Ukrainian. here is its structure element (I don't use gitlab, sorry): The only note is about this string:

"Done. Image written successfully in %02d:%02d:%02d."

if it means duration, in form of hh:mm:ss, in which the image has been written, which looks logical for me, and not the date of the write, then nothing to change. If it is the latter, then you need to change:

"Зроблено. Образ записано вдало за %02d:%02d:%02d.",

to

"Зроблено. Образ записано вдало о(б) %02d:%02d:%02d.",

Thanks zaval!

zaval wrote:if it means duration, in form of hh:mm:ss, in which the image has been written

Yes, that's the duration that writing took to complete in hh:mm:ss.

All looks good, but I have a few questions too. Just to be clear.

zaval wrote:Очікування клієнта

GT translates this as "Customer expectations" (but GT can be wrong). This is supposed to be "Waiting for client" (client as in server-client protocol not as in customer), or maybe "Waiting for device". This message is shown when the image is sent over serial line, and USBImager is awaiting the initial message from the Raspberry Pi to start the transmission. Can you confirm this translation is good for this?

zaval wrote:покищо

Translated as "yet", not sure if this is correct (but could be). To give you a context, this is supposed to be "so far" or "thus far", and shown when the image is written from a compressed file which does not store the uncompressed length therefore the total size is not known. For example: "1 MiB so far" instead of "1 MiB / 128 MiB".

The translation of these two phrases were problematic for other dictionaries as well. The rest all looks good to me.

Thanks,
bzt

GT translates this as "Customer expectations" (but GT can be wrong).

in the context of businesses and their clients, "очікування клієнта" would mean "client/customer expectations", but in the context of an image flasher, this is certainly "waiting for client", exactly in the sense you described. less formal, there is also this wording for the same:

"Чекання на клієнта."

But it's the same, in this context.

as of "so far", "покищо" in the meaning you clarified, is perfectly fine as well, but I'll provide you yet more variants every of which fit well into that meaning, feel free to choose any:

"назараз"
"натепер"
"поки"
"на цей час"

note, GT is pretty dumb and with the ukrainian translations esp., and especially with such frequently used words having tons of meanings. you can be sure, "128 MB покищо" will be understood exactly as currently processed size of unknown total with the progress going on.

Thank you very much for your help! It's appreciated!

zaval wrote:in the context of an image flasher, this is certainly "waiting for client", exactly in the sense you described.

Ok, thanks!

zaval wrote:note, GT is pretty dumb and with the ukrainian translations esp., and especially with such frequently used words having tons of meanings.

Yes, I've noticed, and it's a problem with other languages too. That's why I asked for a forum member's help

zaval wrote:you can be sure, "128 MB покищо" will be understood exactly as currently processed size of unknown total with the progress going on.

Ok, thanks!

The Ukrainian language has been added to USBImager. I've mentioned you in the README as a contributor.

Cheers,
bzt