It's now been a week since my last blog post and I would say my understanding of the structure of Gateware has grown immensely. I focused on the structure and flow of GWindow as that is going to be my initial target for the port. Since last week I have put together an outline for my research document that will detail the research I have done. I will transcribe that outline in this blog post and detail anymore research that still needs to be done.
Purpose of Research
- To port Gateware to UWP
- The challenge
- UWP is commonly written in C#
- Need access to modern Windows Runtime APIs
- Gateware is written in C++11
- The solution
- Use C++/WinRT
Research on C++/WinRT
- What is this?
- "C++/WinRT is an entirely standard modern C++17 language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library, and designed to provide you with first-class access to the modern Windows API. With C++/WinRT, you can author and consume Windows Runtime APIs using any standards-compliant C++17 compiler."[1]
- Why is it a solution?
- This will allow us to port Gateware to UWP without having to switch programming languages.
- What problems could arise?
- It needs C++17, will this be an issue?
- To be answered
- Will this not work with the single header file structure of Gateware?
- To be answered
- Will the end user need to know C++/WinRT API calls?
- Could we abstract this so the user wouldn't know that it is present?
- To be answered
- As of right now, my understanding of C++/WinRT is that you must start a project with one of their templates if you wish to use it. Another option that Microsoft suggests is to add the functionality to an already existing project(there are tutorials to do so), but I have yet to get this to work the way I would like.
Research on UWP(Universal Windows Platform)
- What is this?
- "Windows 10 introduces the Universal Windows Platform (UWP), which provides a common app platform on every device that runs Windows 10. The UWP core APIs are the same on all Windows devices. If your app only uses the core APIs, it will run on any Windows 10 device no matter whether you are targeting a desktop PC, Xbox, Mixed-reality headset, and so on."[2]
- Why are we porting to this?
- Microsoft Store
- Xbox
- Will need need to use XAML?
- Microsoft's XML
- Used to build GUI in UWP
- UWP can be built without it and as we are going to be rendering with a graphics API, it does make sense that we would not need it.
Research on Gateware
- What libraries will need the most work?
- GWindow seems to be the likely candidate.
- Because of the modular structure of Gateware, most libraries seem as though they will work regardless of what implementation of GWindow is being used.
- I believe I can get a window handle in UWP, this will allow things like GInput to work as normal(hopefully).
How I could apply this to the port
- Create another implementation of GWindow for Windows that the user will select when they download Gateware, similar to how they already do when choosing a graphics API.
- This implementation will use C++/WinRT to get the window handle
- winrt::handle struct could be used
To be done
There are still some unanswered questions and a lot more research to be done. Over the next week, I hope to have some sort of a prototype to see how this stuff will mesh together and answer most of the questions I still have. I believe doing so will be really helpful for writing my research document.
Resources
*bullet points that have the sub-bullet "To be answered" need more research
No comments:
Post a Comment