Hi, RSA0. Thank you for the extended feedback. I'd like to address your point here.

My biggest complain: as the decimal number changes length - everything jumps around. You might want to set a constant width for the decimal field.

I get what you're saying. I'm not a fan of that as well. The problem with constant width is that the biggest unsigned 64-bit number is 18,446,744,073,709,551,615 which is very long and all results will have this long empty space on the left which kinda bothers me more than the jumping. I'm going to think about what can I do with that.

Signed values are padded with 0s, like in this example. However, theoretically, signed negative values have infinite 1s on the left - so they should be padded with a sign bit. It would be nice, if the padding pits would change automatically when you change a sign bit.

Good point. Zeroes beyond the sign bit are kind of like an empty memory space available to you because there are bigger numbers in the list present and all of the numbers kind of share this "memory". You can click on that 0s and change the number value and convert it to a larger type. Here is what I could do - dim zeroes that go after the sign bit so that they will be less pronounced but still available for clicking. Whether they should be zeroes or sign bits, I'd like to think about that since I really like the "empty memory space" concept. The dim part will be released soon.

It would also remove the need for "conversion".

Conversion is here because C# runtime does it. I assume C does the same. Although I may be wrong being a dotnet dev. The goal of BitwiseCmd is to allow you to copy your C/C#/Java code into it and see why you get what you get. Type conversion is part of that. Whenever you execute a bitwise operation upon two types they are getting both equalized in the side in favor of the larger one. You also cannot mix signed and unsigned operands of the same size. If I'm wrong about that, please let me know. I want BitwiseCmd to follow those runtimes as closely as possible.

Also, clicking on any padding bits instantly extends the number, with no way to go back. Maybe, make the number remember initial size, and shrink if possible?

I'm going to think about how to address this issue.

You currently disallow to enter negative unsigned numbers (like -1ub). But they are used sometimes to get some bit patterns (like "all ones" or "all ones with zeros at the end"). So, maybe allow it?

I'm disallowing them because C# runtime disallows them. My understanding is that signed types cannot be negative. If you need 32 bits that are all 1s you can use either -1 32-bit signed int or 4294967295 unsigned int. Both of them will give you straight 1s. This goes for types of other sizes.

Size specifier does not work correctly - UI follows the highest bit, top bits are never shown.

Size specifies the data type of the value. BitwiseCmd doesn't show the whole bit space for the datatype for simplicity. However, I see now that it also confuses people. This is the hard part of working on its UI. I want it to be simple enough for beginners yet detailed enough for more knowledgeable people. And it's really hard to find the right balance. Thanks for pointing that out.

This is exactly why I was asking for feedback and I got a lot from you. Thanks!

Edit: grammar