# CDbg Build 0.0.0.7

Hello guys! A new build is here and lets see what is new.

- Added Unicode support to the rendering system.

- Fileviewer will open files that are encoded as UTF-8.

- Fileviewer now has indentation lines that can be toggled from
the config file through the "fileviewer_show_indent_lines" value modifier.

- Added a config value modifier "fileviewer_tooltip_timer_ms" that
changes delay of the value tooltip in the Fileviewer widget.

- Added a config value modifier "maximize_window_on_start" that
maximizes debugger's window on startup on startup if set to "true".

- Added a config value modifier "tab_width" that changes default tab width.

- Added a new config event "clear_all_expr" that clears all the expressions
in the inspector. Currently bound to CTRL + l.

- Added a new config event "clear_all_data_bp" that clears all the data breakpoints.
Currently bound to CTRL + g.

- C/C++ Lexer now can parse integer suffixes like 0x123ull.

- String viewer tool from the inspector now will pick up size parameter
from the expression and when you are going to click on the magnifying
glass, the tool will read amount of bytes that was specified.

- Inspector will display each array element address along with an index.

- Inspector now can handle UTF-16 strings.

- And a bunch of bug fixes.

Download Link
Edited by seventh-chord on Reason: Clarified last sentence
Im very excited about this. It seems like at least two of the common crashes I was experiencing are fixed now. Again, thank you for making this project!

One thing I was wondering about: Are you planning on supporting debugging of executables without debug information, i.e. stepping through machinecode directly?

Non-ascii characters seem to work, and alt-gr also works as a third level modifier now. However, I think there is still a bug somewhere in the way you handle input. I have remapped keys by editing the registry in windows (I use capslock as altgr, though the specifics shouldn't matter), but this remapping is not respected in cdbg. I am fairly certain that winapi should handle this internally, and that the WM_CHAR message gives characters based on my remapping without you having to look at the registry. Let me know if you need any more info on this.
Nikita Smith,
seventh-chord
Im very excited about this. It seems like at least two of the common crashes I was experiencing are fixed now. Again, thank you for making this project!

One thing I was wondering about: Are you planning on supporting debugging of executables without debug information, i.e. stepping through machinecode directly?

Non-ascii characters seem to work, and alt-gr also works as a third level modifier now. However, I think there is still a bug somewhere in the way you handle input. I have remapped keys by editing the registry in windows (I use capslock as altgr, though the specifics shouldn't matter), but this remapping is not respected in cdbg. I am fairly certain that winapi should handle this internally, and that the WM_CHAR message gives characters based on my remapping without you having to look at the registry. Let me know if you need any more info on this.

You are welcome!

Yes, there will be support for stepping through the machine code directly, in the next build.

About the AltGr. I actually use WM_CHAR event to get the character, but debugger also needs to know which modifiers are pressed like Ctrl, Alt, AltGr, or Shift and for this debugger uses WM_INPUT. And the issue is that the AltGr key is not properly detected when remapped. I will try to fix this soon, thanks for letting me know.
Ameen Sayegh,
This is awesome work!!
I just watched handmade hero trying it out and immediately came here to check it out.

I think it is already at a place where it can replace visual studio. It has the essential features of a debugger. Also, it is relatively stable. I will start using it and see how it goes.

What caught my eye is the font rendering. At first, I assumed you are using GDI or DirectWrite (because of the ClearType). But reading your older blog posts, you mentioned that it is actually FreeType+OpenGL with your own implementation of ClearType! I must say the end results are amazing.
You also mentioned you will be writing an article about that. I wonder if this is actually out somewhere or not yet because I would love to know more about that.

Thank you for the amazing work you are doing.
Nikita Smith,
aameen951
This is awesome work!!
I just watched handmade hero trying it out and immediately came here to check it out.

I think it is already at a place where it can replace visual studio. It has the essential features of a debugger. Also, it is relatively stable. I will start using it and see how it goes.

What caught my eye is the font rendering. At first, I assumed you are using GDI or DirectWrite (because of the ClearType). But reading your older blog posts, you mentioned that it is actually FreeType+OpenGL with your own implementation of ClearType! I must say the end results are amazing.
You also mentioned you will be writing an article about that. I wonder if this is actually out somewhere or not yet because I would love to know more about that.

Thank you for the amazing work you are doing.

I wanted to write one, but in the end did not have enough time. However, I put up a demo some time ago that you can check out here: link
I also use FreeType for font rendering, but I added this extra code to reduce the colour fringes:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 for (int y = 0; y < height; y++) { for (int x = 0; x < width; x++) { int32_t r = (int32_t) ((uint8_t *) bitmap->buffer)[x * 3 + y * bitmap->pitch + 0]; int32_t g = (int32_t) ((uint8_t *) bitmap->buffer)[x * 3 + y * bitmap->pitch + 1]; int32_t b = (int32_t) ((uint8_t *) bitmap->buffer)[x * 3 + y * bitmap->pitch + 2]; // Reduce how noticeable the colour fringes are. int32_t average = (r + g + b) / 3; r -= (r - average) / 3; g -= (g - average) / 3; b -= (b - average) / 3; output[(x + y * width) * 4 + 0] = (uint8_t) r; output[(x + y * width) * 4 + 1] = (uint8_t) g; output[(x + y * width) * 4 + 2] = (uint8_t) b; output[(x + y * width) * 4 + 3] = 0xFF; // OSPrint("\tPixel %d, %d: red %X, green %X, blue %X\n", x, y, r, g, b); } }