allows the ability to assign colors to global placed and non-placed
variables, pattern, local and calculated pointer variables, template
arguments, function variables and arguments, etc etc etc. It
accomplishes this using the parser and the token sequence generated by
the lexer. It still uses the original colorizing code but the underlying
data holding the pattern has been updated to be easier to use and to
debug. The changes are too numerous to cite here.It is a big but
necessary step to bring the pattern editor to a somewhat useful state.
There may be one commit in the pattern language repo needed to be able
to run this code
This pr updates the pattern language library to include two fixes.
The first fix deal with local variables that are children of a
structure, a union, a bitfield or an array losing their offsets when the
parent's `setOffset()` is called.
The second fix is that local variables of unions were being used as size
contributors of the patterns place with said unions.
Further details may be found in the pattern language pull requests for
the files listed as changed in the PL submodule in this pr.
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)
