C++ proposition

[Slice]

33 minutes ago, Jief_Machak said:

How broken. Looks like it's working here (in QEMU, of course)

Only 5 lines. Others empty.

[Jief_Machak]

I have that. But it's not the same theme. What's yours ?

[Jief_Machak]

You sent me your QEMU clover folder. We are supposed to have the same ?

I can even change the theme with the option menu.

[Slice]

Not same because I made some modification for tests. Your theme is "embedded", I switch to "cesium".

Look also my latest commit.

[Jief_Machak]

Just compile what is in the repo and I got the about menu.

But it's not exactly the same theme. So send me your theme folder...

Found why Duet wasn't starting Clover automatically. My efi was generated with GenFw -e UEFI_DRIVER instead of UEFI_APPLICATION.

 

I guess that DUET is more strict than the EFI bios in VMWare and also the one in my laptop !

[Slice]

6 hours ago, Jief_Machak said:

Just compile what is in the repo and I got the about menu.

But it's not exactly the same theme. So send me your theme folder...

Found why Duet wasn't starting Clover automatically. My efi was generated with GenFw -e UEFI_DRIVER instead of UEFI_APPLICATION.

 

I guess that DUET is more strict than the EFI bios in VMWare and also the one in my laptop !

I see Clover version 2 on you screen while I set version 5.

See my picture

It is not theme difference. It is Clover difference as you take no my last commit.

Looks like unicode bugs.

[Jief_Machak]

I took the latest commit. Just didn't regenerate Version.h.

[Jief_Machak]

9 hours ago, Slice said:

Only 5 lines. Others empty.

And the icon on this picture is different. Isn't that a theme difference ?

[Slice]

15 minutes ago, Jief_Machak said:

And the icon on this picture is different. Isn't that a theme difference ?

The icon depends on time of day. There are daylight icon and night icon  

[Slice]

As I see the same Clover works on real hardware with good about menu. Such bug is hard catchable.

And I see some graphics artefacts absent in previous version.

[Jief_Machak]

Ok, sorry, don't have have time anymore until Monday

 

@Matgen84 It works if you change theme. I don't understand what's going on here. Sorry.

 

For the black square, looks like 

    EFI_STATUS st = GraphicsOutput->Blt(GraphicsOutput,
      &PixelData[0],
      EfiBltVideoToBltBuffer,
      x, y, 0, 0, AreaWidth, AreaHeight, LineBytes);

XImage line 359, returns 0, but all image memory is 0.

 

Good luck

Edited March 6, 2020 by Jief_Machak

[Jief_Machak]

I think I caught a very nasty bug in GenFW that was invisible before I created the .ctorss section. I didn't have time to fully diagnose, but I think GenFW is mapping the .ctorss section at the beginning of .data section. Which means it overwrite the beginning of the .data section.

I happened to have LinuxEntryDataCount = 22391, which seems impossible.

 

For me, line 542 of Elf64Convert.c is

mCoffOffset = (UINT32) ((mCoffOffset + shdr->sh_addralign - 1) & ~(shdr->sh_addralign - 1));

and should be

mCoffOffset = (UINT32) ((shdr->sh_addr + shdr->sh_addralign - 1) & ~(shdr->sh_addralign - 1));

Also, with our current version, first section '.text' is always mapped at 0x240, even if you change "--defsym=PECOFF_HEADER_SIZE=0x240" in linker command (ok, that's not currently a problem because 0x240 fits us).

 

So, either :

  - don't compile with GCC until this is fixed

  - import that modification and confirm it's working.

 

Cheers.

 

 

 

Edited March 6, 2020 by Jief_Machak

[Jief_Machak]

5 hours ago, Slice said:

As I see the same Clover works on real hardware with good about menu. Such bug is hard catchable.

And I see some graphics artefacts absent in previous version.

I'm pretty sure there is still some memory used before allocation. Where we have to be very careful, is when we use like &PixelData[0] to give to an UEFI service. Because then, the object cannot control and check anything anymore (allocated size). What am I thinking, is to create a method getDataSized(UINTN size) in XArray. It'll return a pointer to the first byte, but make sure that the size is right.

I'm currently doing that by calling setLength before, but that's not intuitive and we'll forget it some time.

We can also have getDataFromElementSized(UINTN index, UINTN size).

 

That way, we can take the habit to never write "&anArray[x]" to get a buffer, and because we'll be obliged to supply an argument, it'll make us think what size we need !.

 

We can do the same in XStringW, as its correct for a lowlevel function to directly write in XStringW memory. The only thing is to set the length after. Or, remove the "m_len" member from XStringW. After all, it use 8 bytes of memory, just to avoid recalculating the length each time we need it...

 

Food for thought for the weekend...

 

[Slice]

I tested the follow

#if 1 //test XImage
      XImage NewX(NewImage);
      NewX.Draw((UGAWidth - Width) / 2,
        (UGAHeight - Height) / 2, 1.f);
#else
      BltImageAlpha(NewImage,
                    (UGAWidth - Width) / 2,
                    (UGAHeight - Height) / 2,
                    &MenuBackgroundPixel,
                    16);
#endif //test XImage

#else is working method thus I know .Draw() is not working even if I simplify it to just BltImageAlpha.

 

 

[Slice]

OK, now XImage.Draw() works. Testing pointer...

[apianti]

I may point out that you guys are doing all this effort to update a GUI that is objectively terrible and effectively broken. I am unsure why you wouldn't be trying to rewrite the GUI at this point as it would make the most sense. The GUI should only ever run in one loop, not many nested inside each other, and each screen should be pushed onto a stack to be drawn. Then you even have the history of screens you've visited in order, and can draw them backwards to have them have transparency over previous screens (like a popup for say about or adding menus).

Edited March 6, 2020 by apianti

[apianti]

GenFw is doing what it's supposed to it's stripping the extra sections that the specification does not use for PE image and putting them into .data, it does not expect .ctors to exist. You probably have to modify GenFw.

 

EDIT: Actually, I think it's actually one of the other tools that does this, and it's being used by GenFw because all the images need fixed like this.

Edited March 6, 2020 by apianti

[Slice]

1 hour ago, apianti said:

I may point out that you guys are doing all this effort to update a GUI that is objectively terrible and effectively broken. I am unsure why you wouldn't be trying to rewrite the GUI at this point as it would make the most sense. The GUI should only ever run in one loop, not many nested inside each other, and each screen should be pushed onto a stack to be drawn. Then you even have the history of screens you've visited in order, and can draw them backwards to have them have transparency over previous screens (like a popup for say about or adding menus).

You say about development from scratch but it is hard work. We are going in simple way rewriting existing algorithms into the new framework. Eliminating existing bugs at the same time.

Menu is very large containing thousands lines. In the new framework we have to write them anew.

[apianti]

But you are already doing this massive amount of effort and it is filled with many bugs, obviously. Eliminating bugs and putting effort into a flawed design, and that is proven to be flawed makes no sense. Another point you make is that it contains a large amount of information, yeah, because it's badly designed. It has a bunch of insane cr ap. Much of the interface could be specified much easier, especially if you allowed the theme to do this. Then all of the information would be in the theme and could be simple plist dictionary information that generates the UI. Language strings would not need to be hardcoded and could be added much more easily with an additional file to use for the language.

 

EDIT: Because of SVG theme, scalar fonts can just be included.

Edited March 6, 2020 by apianti

[Slice]

An example of menu.plist? Or menu.svg?

[Slice]

I resolved a problem with mouse drawing as well as XImage drawing. It was my confuse with blt function.

Now there is a strange bug with blurring of background by mouse pointer.

 

There is also a bug with update mainmenu. Press ESC -> hang.

[Jief_Machak]

These bugs are just small things in the code. Small doesn’t mean that easy to catch but we will. We may have still memory problems. Remember : when ximage was writing on non allocated memory, the symptom was no keyboard and mouse !

so let’s continue to debug “core” objects that we can use easily. Have a good, perfectly working XImage will make everything much easier. Having a plist object would probably be a nice addition too. I think it’s too soon to change the design. Let’s use the current design to debug our newly created object.

Then, if we want to change the design and write some code from scratch for a new menu system, it’ll be easier.

The operator message means that an index > size was used in an XArray leading to using unallocated memory. That has to be debugged before anything else, as it can create any sort of bugs.

[Jief_Machak]

By the way : when you see the message about index out of bounds in operator[], the whole system freeze intentionally (CpuDeadLooo). That’s why you can’t use your keyboard or mouse.

Removing the CpuDeadLoop won’t work because it would allow using unallocated memory.

Writing the “getDataSized” method I talked about in an earlier post would help avoid that.

[Slice]

2 hours ago, Matgen84 said:

 

 

Now, there is another issue: When I use spacebar or arrow key to access to Menu: there is new message: a code line message about 'operator' or something like that, at left top corner. F10 don't work because keyboard don't work, so I can't post the screenshot.

I know. Just not found a reason of the mistake.

@Jief_Machak The message says " ... index > m_len". Somewhere SetLength missing.

[Jief_Machak]

Do the “getDataSized” methods (it just have to call SetLength and return the data pointer. SetLength is suppose to call checkSize.

Check the code for every call to &array[0].

You can also catch it with gdb. Put a breakpoint on the message and ask for backtrace