Week 4 of Gateware: End of the First Month

     Well, here we are at the end of the month. Much learned, but still far more to learn. The problem we were having with the MacOS crashing last week was that the CMake code we were using to link the Vulkan SDK was outdated and since then, CMake has built-in support for linking with newer Vulkan SDK's, so we just needed to update that bit of code to get it working. So after that was done, it was finally compiling, but it was now crashing on the VulkanSurface tests.

    So in the newer Vukan SDK's for MacOS, they force the extension "VK_KHR_PORTABIITY_subset" to be enabled. This extension allows for applications to exist on non-conformant platforms and since MoltenVK isn't fully conformant, this extension needs to be enabled. And just for those who don't know (like me up until two weeks ago), MoltenVK is needed so that Vulkan can can map to Apple's Metal graphics framework. To opt-in to this extension, you need to modify the VkInstanceCreateInfo by adding the VK_INSTANCE_CREATE_ENUMERATE_PROTABILITY_BIT_KHR bit to the flag parameters and add the VK_KHR_PORTABILITY_ENUMERATE_EXTENSION_NAME extension to the ppEnabledExtensionNames array along with incrementing the enabledExtensionCount variable. Links and a screenshot of this information will be posted below.
Link: https://vulkan.lunarg.com/doc/sdk/1.3.243.0/mac/getting_started.html

While this is a very simple thing to implement in an ordinary application, Gateware is no ordinary application and took a bit more finessing. 

    GVulkanSurface uses a file called GVulkanSurface_core to implement the majority of the VulkanSurface implementation and thus makes the OS-specific files much smaller. But since our VkInstanceCreateInfo is in the core file, we can't just make all those changes there since Linux and Windows are comformant platforms and would cause another crashing error. So instead, after the original VkInstanceCreateInfo is created and setup, we have a new function called "PlatformOverrideInstanceCreate," which allows us to pass in the VkInstanceCreateInfo, along with some of its original variables to be cleaned up later, and then modify them all in the function to opt-in to the extension. We then of course had to include dummy versions of this function into the Linux and Windows version of VulkanSurface so that the function can still be called on other Operating Sytems.

    Since this extension only exists on newer versions of Vulkan, we aren't able to get Gateware to compile on older SDK's with the new Mac implementation. With this said, we will be dropping support for Vulkan SDK's on MacOS older than 1.3.216.

    Since we have been doing a lot of updating on the Mac side of things, we are also trying to update our Mac testing machines to the latest MacOS that they can support, which is Monterey. However, this has caused a previously discovered bug to pop up again. GWindow causes crashing on Monterey (and likely other newer MacOS's as well). While we aren't entirely certain what the problem is, we believe it has something to do with multi-threading. I wasn't really able to discover anything new with this issue, just tried to understand what was already found and made. I would like to return and try to fix this problem later on before I graduate, but we'll see when we get there. For now, this is the link to the issue in GitLab. https://gitlab.com/gateware-development/gsource/-/issues/229.

Week 3 of Gateware: MacOS

     For the past 5 days, I have been dealing with the donor MacBook. Originally, I was using it to fix a compiler issue involving GController unit tests, but in the process of doing so, I found another issue where GSource doesn't seem to compile using the latest Vulkan SDK version. After some research, we believe that the issue is that the OS on the donor MacBook is simply too outdated and we are hoping that updating the OS will solve the issue. So I just had to update the OS and the problem should be fixed. Simple, right? Of course not. Since the MacBook also had Linux and Windows operating systems on it, there wasn't enough space to install the update. So I had to factory reset the Mac and re-install the OS, but for whatever reason, it couldn't download the installer and install the OS. So I had to get access to the second donor MacBook, download a new MacOS (Monterey), transfer it to a USB drive, convert that USB drive to a bootable installer, plug it into the original MacBook, and then I can finally install a newer OS. And I am happy to say that it did successfully install. ☺

    Now with the new OS installed, I can start re-installing all the necessary software to compile and run GSource and everything was moving smoothly until I got to XCode. To use XCode, you need to sign into your Apple ID account, which we have. However, two-factor authentication has been set up for the account and we currently have no way around it. I'm hoping to soon find who set up the two-factor authentication so we can get rid of it, but if we can't find that person, things might get a little more complicated.

    It might be asking too much, but I'm hoping that once we've got this Vulkan compiler issues sorted out, I'll be able to figure out the other bug fixes fairly quickly so that I can get started on the UWP tasks and just have to worry about the Windows development environment. But as everything in the development world, that probably won't be the case.

Week 2 of Gateware: Research

    My big plan for Gateware or the next several months that I was going to be working on was sort of a two-parter. Firstly, I was going to complete the work of previous developers to get Gateware running as a UWP application so that it could run on additional Microsoft devices such as the Xbox, Windows Mixed Reality Headset, Hololens, and so on. Secondly, I wanted to convert the UWP code over to WinUI 3 to future-proof Gateware, as it seemed that Microsoft was dropping support for UWP and replacing it with WinUI 3. The problems arose with this second part, as the previous statement only seems to be partly true.

     From what I can tell, when people are talking about "UWP" in various articles and websites, they seem to be talking about two different things. The first thing they could be talking about is the UWP application framework. This is the overall structure of a project that makes a UWP app a UWP app. The second thing they could be talking about is UWP/XAML. This is a library/language used to create UI elements inside of a UWP application. Up until WinUI 3 came out, UWP/XAML was the only way to create UI elements in UWP apps, and that was really the only use that UWP/XAML had. 

    But now, with the introduction of WinUI 3, Microsoft seems to be trying to replace UWP/XAML (not the UWP application framework) with WinUI 3. But since people have always just used "UWP" to refer to both parts of the UWP ecosystem, this now seems to have created some confusion. Or at least it has really confused me. 

    The main thing to be learned from this is that WinUI 3 only brings about new libraries and API's for creating UI elements, which is something that Gateware does not have/need any time soon. Since Gateware uses graphics API's to draw to the screen, Gateware users can just create UI elements using those API's. Because of this, WinUI 3 has to use being in the current Gateware. I can see it possibly having some use cases in the future, as Gateware has more features added, but until then, there is not really anything to be done.

    Next Wednesday (April 19, 2023), Microsoft will be holding their monthly WinUI 3 Community Call where they has a QnA towards the end. I plan on attending this Community call to try and learn more about WinUI 3 and UWP, just to confirm that WinUI 3 holds no prospects for Gateware in present time.

    In the meantime, I will be working on various fixes that involves Linux and MacOS to not just get more Gateware experience, but to also get some experience in working with those other OS's. I do still plan on completing the UWP work to get Gateware running on Xbox, but that will be after I have confirmed that there is nothing to be done concerning WinUI 3.