Skip to content

Conversation

@dongle-the-gadget
Copy link
Member

I copied code over the K7Modern wrappers, not sure whether I should do it like that or make the underlying methods public. Could probably be utilized for future modernization.

Signed-off-by: Dongle <29563098+dongle-the-gadget@users.noreply.github.com>
Signed-off-by: Dongle <29563098+dongle-the-gadget@users.noreply.github.com>
Signed-off-by: Dongle <29563098+dongle-the-gadget@users.noreply.github.com>
Signed-off-by: Dongle <29563098+dongle-the-gadget@users.noreply.github.com>
@MouriNaruto
Copy link
Member

I copied code over the K7Modern wrappers, not sure whether I should do it like that or make the underlying methods public.

We should make all NanaZip.Modern things exported only by K7Modern C wrappers. It's necessary for modernization work like NanaZip.Universal.

Kenji Mouri

@MouriNaruto
Copy link
Member

MouriNaruto commented Sep 18, 2025

Note: The one of goals for NanaZip modernization is keeping the usage of Windows Runtime interfaces only in NanaZip.Modern module.

Kenji Mouri

@dongle-the-gadget
Copy link
Member Author

I don't believe that exposing a lot of K7Modern getter and setter properties for all WinRT properties is the best API choice.

@MouriNaruto
Copy link
Member

MouriNaruto commented Sep 18, 2025

We should only expose necessary properties which actually used. Also, I suggest that wrapping XAML Islands based UI more to Win32 HWND controls will make easier to integrate with inherited 7-Zip mainline historic things, which the modification marks will be more compact.

Some interesting notes: If you have read https://x.com/driver1998/status/1968255362647417251, you will know that I had an idea about a homemade ComCtl v10 where every control is an XAML island hosted by Mile.Xaml. This is actual the plan B of NanaZip modernization work, if I have not met your previous contributions before, the plan B may be started, lol.

Kenji Mouri

@dongle-the-gadget
Copy link
Member Author

Can't we make shim classes in that case? Since with mainline all controls are behind wrapper classes anyway, we can replace them with our own classes and still get to use WinRT that way.

@MouriNaruto
Copy link
Member

For Windows, the only ABI can cross compiler/language is C style. COM is actually C style, only coincidencely uses the same structure of vtable.

Note: I need to make a similar wrapper for implementing the NanaZip Classic flavor UI. Ideally, I even hope we can use the same C interface (function prototype definition hope to be same, function name can be different because it's OK for LoadLibrary dynamically) between NanaZip.Modern.dll and NanaZip.Classic.dll. It can much simplify the NanaZip.Universal's implementation. It can help simplify the future maintenance work. K7Modern interface is the beginning of that work. (Although it's not the final definition.) I also hope that work can help me to split non UX but cross-platform part from inherited 7-Zip source code. That not only helpful to make a much modernized UX part implementation, but also helpful for making cross-platform implementations. (Although NanaZip only supports Windows in the foreseeable future. But I don't know whether something like Windows 10X would come out.)

Kenji Mouri

@dongle-the-gadget
Copy link
Member Author

I thought the non-UX parts are generally in Core already except the CLI, but that's not as big of a hassle to port.

I think the converging to flat-C only makes sense if we were to completely rewrite the entire UI stack instead of a gradual port, since that would need an insane amount of internal details being interop-ed. In addition, are we actually having the two UIs in one executable?

@MouriNaruto
Copy link
Member

I thought the non-UX parts are generally in Core already except the CLI, but that's not as big of a hassle to port.

The non-SFX CLI has moved to NanaZip.Universal because it's important to make CLI and GUI use the same codebase version to reduce some differences.

I think the converging to flat-C only makes sense if we were to completely rewrite the entire UI stack instead of a gradual port.

In the current stage, I hope we can rewrite the UI stack gradually.

In addition, are we actually having the two UIs in one executable?

This is one of the goals because it's important to reduce multiple inherited 7-Zip source code instances. (Currently we have NanaZip.Core NanaZip.Universal NanaZip.UI.Modern NanaZip.UI.Classic)

Kenji Mouri

@dongle-the-gadget
Copy link
Member Author

Couldn’t we have the projects reference a shared folder for the common ones and then split as needed? I don’t think we can get much code shared either way.

@MouriNaruto
Copy link
Member

We should also reduce the compile time, at least by using the static library. But for multiple UX modules, they should be dynamic library.

Kenji Mouri

@dongle-the-gadget dongle-the-gadget changed the title Modernize XAML dialog Modernize copy/move XAML dialog Sep 18, 2025
@dongle-the-gadget
Copy link
Member Author

(unrelated) Could we have this PR merged for now since it's going to Modern?

@MouriNaruto
Copy link
Member

I hope we can use the C-style K7Modern prefix API to wrap.

Kenji Mouri

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants