Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code base: Rewriting/improving the FullTrustProcess #2794

Closed
yaira2 opened this issue Dec 31, 2020 · 6 comments
Closed

Code base: Rewriting/improving the FullTrustProcess #2794

yaira2 opened this issue Dec 31, 2020 · 6 comments
Labels
codebase quality Issues that are not bugs, but still might be worth improving (eg, code hygiene or maintainability)

Comments

@yaira2
Copy link
Member

yaira2 commented Dec 31, 2020

Is your feature request related to a problem? Please describe.
The current FullTrustProcess does what it's meant to do, but the code base is kind of messy and hard to work with, additionally, it uses more system resources than a project of this size should.

Describe the solution you'd like
Rewriting the FullTrustProcess seems likely to happen at this point, while it doesn't need to be done in c++, once the effort is being made, using c++ might be a good choice in order to squeeze the maximum performance that we can while using as little system resources as possible.

Describe alternatives you've considered
Improving the current code for this process to use better practices and to try to reduce the memory usage.

@yaira2 yaira2 added discussion codebase quality Issues that are not bugs, but still might be worth improving (eg, code hygiene or maintainability) labels Dec 31, 2020
@yaira2 yaira2 pinned this issue Dec 31, 2020
@gave92
Copy link
Member

gave92 commented Dec 31, 2020

@yaichenbaum @duke7553 correct if I'm wrong: I understood that the plan is to switch sometimes in the future to using net5 + winui desktop.
This would make unnecessary to have a fulltrust process separated from the main app
Depending on if and when the above is going to happen it may or may not make sense to rewrite the Fulltrust process to C++.

We could anyway check if there is any performance gain in loading the context menu (this is the most noticeably slow part of the Fulltrust process) by switching to c++

@yaira2
Copy link
Member Author

yaira2 commented Dec 31, 2020

@gave92 We haven't made any decision around that yet, it's going to be quite a while before WinUI Desktop is going to be ready for us to use and even then, we don't know what the full story will be. Taking that into account, if we were to make the switch, it won't be for a while and I wouldn't like that to hold us back on improving what we have now. That being said, if sticking with c# will make it easier to move over to WinUI Desktop in the future, then we should instead work on reducing the memory usage of the current code.

@yaira2 yaira2 changed the title Code base: Rewriting the FullTrustProcess in c++ Code base: Rewriting/improving the FullTrustProcess Dec 31, 2020
@gave92
Copy link
Member

gave92 commented Jan 1, 2021

Not for the faint of hearts:
you can find here a branch with a skeleton for the rewritten fulltrust process in C++.

In case someone else wants to get his/her hands dirty.. contributions are welcome :)

What works @10/01/2021:

  • AppService connection
  • Context menu
  • Loading icons and overlays
  • Recycle bin
  • Shortcuts .lnk parsing

@d2dyno1
Copy link
Member

d2dyno1 commented Jan 1, 2021

Wooow @gave92!!
Amazing work! Didn't know you you can code in c++ too!

@yaira2 yaira2 unpinned this issue Jan 14, 2021
@d2dyno1
Copy link
Member

d2dyno1 commented Mar 22, 2021

For #4180

@yaira2
Copy link
Member Author

yaira2 commented Mar 22, 2021

@gave92 Did we want to continue this or was the plan to wait for WinUI Desktop?

@yaira2 yaira2 closed this as completed Apr 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
codebase quality Issues that are not bugs, but still might be worth improving (eg, code hygiene or maintainability)
Projects
None yet
Development

No branches or pull requests

3 participants