Following the documentation (which is not being updated for this type)
on using `hex::type::Instruction` fails to produce any patterns
regardless of how you format the string that is passed to capstone to
select architecture and options.
The error is traced back to mishandling the input string so that the
correct parts are not selected properly. Rather than manually selecting
the parts of the input string from the result of find it is much simpler
to use splitString() (which uses find internally) and does all the work
for us with fewer chances for errors.
There are still problems. The resulting string for the formatter doesn't
return the disassembled instruction and prints the variable name with
the @ used to place it. To view the instruction you need to unseal the
pattern and open the child which then shows the instruction. That only
happens after this fix has been applied.
Feature description
This pull request introduces full Polish language support to ImHex.
It is a new feature that allows users to switch the UI to Polish,
improving accessibility for Polish-speaking users.
Implementation description
-Translated a total of 10 JSON language files into Polish (pl_PL.json)
-All translations were done manually, with the help of tools such as
DeepL, large language models (LLMs), and technical dictionaries
-Validated the JSON files using [jsonlint.com](https://jsonlint.com/)
-Performed initial UI testing — all translated strings appear and render
correctly
Screenshots
Below is an example of the UI in Polish:
Additional things
-I'm a beginner with both ImHex and English, so I may have missed some
things
-I'm fully open to any suggestions or corrections — whether related to
translation accuracy or JSON formatting/style
-I would greatly appreciate it if the reviewer could:
-Confirm that the project still compiles correctly (it built fine on my
side using ninja)
-Check that the pl_PL.json files are properly formatted and follow the
project's standards
If there are preferred tools or workflows for validating and formatting
JSON in this repository, I’d be happy to adopt them in the future.
---------
Co-authored-by: paxcut <53811119+paxcut@users.noreply.github.com>
<!--
Please provide as much information as possible about what your PR aims
to do.
PRs with no description will most likely be closed until more
information is provided.
If you're planing on changing fundamental behaviour or add big new
features, please open a GitHub Issue first before starting to work on
it.
If it's not something big and you still want to contact us about it,
feel free to do so !
-->
### Problem description
<!-- Describe the bug that you fixed/feature request that you
implemented, or link to an existing issue describing it -->
Updated
[plugins/builtin/romfs/lang/zh_CN.json](https://github.com/only9464/ImHex/blob/master/plugins/builtin/romfs/lang/zh_CN.json)
file to add support for Chinese language
### Implementation description
<!-- Explain what you did to correct the problem -->
Updated
[plugins/builtin/romfs/lang/zh_CN.json](https://github.com/only9464/ImHex/blob/master/plugins/builtin/romfs/lang/zh_CN.json)
<br/>The original
file:[plugins/builtin/romfs/lang/zh_CN.json](https://github.com/WerWolv/ImHex/blob/master/plugins/builtin/romfs/lang/zh_CN.json)
### Screenshots
<!-- If your change is visual, take a screenshot showing it. Ideally,
make before/after sceenshots -->
### Additional things
<!-- Anything else you would like to say -->
Nothing
### Problem description
While working with the section view, I noticed the window wasn't
resizable.
### Implementation description
This simply removes the `ImGuiWindowFlags_NoResize` flag, and then when
drawing the section window sets the hex editor to 70% of the available
window, leaving 30% to the pattern data. This is not ideal, but I think
before a full rewrite of the section window system this would probably
be a simple change to make it a lot more usable.
### Screenshots
Co-authored-by: paxcut <53811119+paxcut@users.noreply.github.com>
A while back there were some changes to the pattern language library
that changed the way shared_pointers are created using
shared_from_this(). Unfortunatelly the changes were not complete and
various bugs were created among them 2234, json type not working, unable
to export files, static arrays of bitfields,... The cause of the errors
was that in class Pattern the member m_parent was left as a raw pointer
and it needs to be handled by shared pointers. Also there were some
cases in which share pointers were needed but unique pointers were used
instead. Both cause crashes when shared_from_this is used on pointers
that are not managed by shared_ptr. Another source of errors were
infinite loops of clone and reference that caused stack overflow. The
fixes include making m_parent a weak pointer, turning unique pointers
into shared pointers and moving codefrom the copy constructors into
clone to break the infinite loops.These changes are the bare minimum
needed to bring the pattern language back to the full functionality that
it had before shared_from_this was introduced or at least thats the
hope.
This pr aims at fixing for negative values in advanced search for
numerical values. For a simple example try searching for -1 for int32_t
which is 0xFFFFFFFF. With the changes you can now find -1 for 1,2,4 or 8
byte integers.
Internal types are bigger than or equal to the types selected in the
options. Search keys are converted to the bigger type, but the values
read from the input file are not. This works ok for positive numbers,
but for negatives it needs some casting.
The casting is performed inside a newly added function that takes the
value returned by read, the size in bytes of the selected type in the
options and a template argument for the 64 bit type the value is stored
into.
I have tested positive and negative values for several different sizes
of signed integers. Also tested unsigned integers both in the low range
(near lowest limit) and in the high range (near largest possible value
for that type)
The bitmap visualizer has been simplified considerably. The previous version was designed to work with the TIM format which has some peculiarities that are not general enough. The current implementation has the following specifications.
. Whether colors are in a lookup table or part of the image itself they are always 32 bit R8G8B8A8.
. If using a color LUT the image then has indices as its element. Indices can have 16(32000 colors), 8 (256 colors) or 4(16 colors) bits each.
.For the cases 0f 16 and 8 bits, the data should be an array of N*M elements of the given size where N is the number of rows and M is the number of columns of the image.
. For the 4 bit case use an array of N*M/2 bytes so that each column contains two indices.
ToDo: Documentation, sample patterns and unit tests.
The 3-d visualizer can now handle textures from both the command line or the user interface and things should work as expected. A command line entry will be automatically displayed in the user interface, but changes will be applied immediately as you type or use the file picker. If the user interface text is deleted, then the command line texture will be used again. If a texture is invalid for any reason, then the previous one, if any, will be still in use and an error message will be displayed until the problem is cleared. Valid textures are image files that the stb library can open.
<!--
Please provide as much information as possible about what your PR aims
to do.
PRs with no description will most likely be closed until more
information is provided.
If you're planing on changing fundamental behaviour or add big new
features, please open a GitHub Issue first before starting to work on
it.
If it's not something big and you still want to contact us about it,
feel free to do so !
-->
### Problem description
This is a fix for the ImHex bug "ImHex crashes when analysing any PE
file #2221"
### Implementation description
This is a fix for the ImHex bug "ImHex crashes when analysing any PE
file #2221". The fix requires changes to the Pattern Language and the
ImHex UI. Revision would be wise. We want to avoid collateral damage.
It's a big code base and I'm new to it and the compilers/build-systems
used. And the bug is complex and low-level. I suspect this will fix
other random crashes. The problem is caused by two issues:
- The std::sort algorithm conjuring up garbage due to the sorting
criteria not being a strict weak ordering. See
[this](https://github.com/Voultapher/sort-research-rs/blob/main/writeup/sort_safety/text.md)
link.
- We sort shared_ptr<ptrn::Pattern> by pointer value, and the
object is a clone. In essence we're changing the values as we're
sorting.
Fixes#2221
### IMPORTANT
I'm not sure how "plugins/builtin/source/content/data_formatters.cpp"
got into the PR. Been trying for an hour to rectify. I'm not a Git
expert (the last time I used source control seriously SourceSafe was a
thing) please ignore that file. It's a fix for another PR I submitted. I
suspect I stuffed up the branching and merging.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
