Computers
Finally wrapped up the peer review draft of my first-ever Theology paper! It explores the relationship between the Christologies of Nestorius and Cyril-- how they disagreed and, more importantly, what common ground they had.
Long-time readers will know I've always been a sucker for mobile apps. At work I took over a barcode scanning application which is written in an ancient version of Xamarin Forms. It builds both UWP and Android versions, and uses MSAL for authentication.
One of the first bugs I was handed involved the UWP version "freezing" on login-- not every time, but most of the time. I thought it would be a trivial fix of maybe a few hours, but it turned into two full days of worm can opening.
As I learned, there are two main ways of brokering authentication via MSAL: using what's called the "Web Application Broker", or "WAB"-- or the "Web Account Manager"; the "WAM".
The "WAB" is this old .exe called "AuthHost" which has shipped with every version of Windows for a gazillion years. At some point, a Windows 10 update rolled which broke the "WAB", causing login freezes. Another Windows update fixed it-- but then another broke it. So "AuthHost.exe" has been in varying states of brokeness for several years, across both Windows 10 and 11.
Of course, this is the form of authentication the UWP app uses. So the "freeze" isn't due to the application code-- it's due to "AuthHost.exe" not working correctly.
Around the time this initially broke, Microsoft had moved on from Xamarin and forward with MAUI. They also deprecated the "WAB" and not only refused to support it, but removed it from their internal test labs entirely! "Migrate to WAM", was their instruction.
I started on that migration process on Friday morning. I found out after hours of hacking and researching, with Copilot's full inspection of the codebase as well, that WAM will not work with this ancient version of Xamarin, because there is no way to obtain a low-level, IntPtr handle to the parent window.
WAM supports opening a browser to facilitate authentication, but that won't work either because, being sandboxed, Xamarin UWP apps are not permitted to run other applications. Indeed, I get an exception from the app when it tries to launch "msedge.exe".
I thought, "No problem, I'll just spawn a timer thread, and if it looks like AuthHost.exe is going to lock up, I'll pre-emptively kill the process, from code, without the user even knowing it." Yeah, UWP apps aren't allowed to kill processes either. "Ok, I'll spawn a PowerShell script to kill the process." No dice: the PowerShell script would just be running in the sandbox.
I considered, "What if I had a .bat file run a 'cleanup' script invisibly, and then launch the application?" Trouble is, what would the cleanup script do? I carefully monitored "AuthHost.exe", and it doesn't start until the moment before it dies: whereas, I was hoping it was a long-running process, pre-dating the application, which I could kill so as to get a fresh, working one.
We are planning to re-write this mobile application completely in the coming months or maybe year. I'm tempted to just throw a message on the login screen for now, instructing users to just click "End Process" if they get such a message.
Long-time readers will know I've always been a sucker for mobile apps. At work I took over a barcode scanning application which is written in an ancient version of Xamarin Forms. It builds both UWP and Android versions, and uses MSAL for authentication.
One of the first bugs I was handed involved the UWP version "freezing" on login-- not every time, but most of the time. I thought it would be a trivial fix of maybe a few hours, but it turned into two full days of worm can opening.
As I learned, there are two main ways of brokering authentication via MSAL: using what's called the "Web Application Broker", or "WAB"-- or the "Web Account Manager"; the "WAM".
The "WAB" is this old .exe called "AuthHost" which has shipped with every version of Windows for a gazillion years. At some point, a Windows 10 update rolled which broke the "WAB", causing login freezes. Another Windows update fixed it-- but then another broke it. So "AuthHost.exe" has been in varying states of brokeness for several years, across both Windows 10 and 11.
Of course, this is the form of authentication the UWP app uses. So the "freeze" isn't due to the application code-- it's due to "AuthHost.exe" not working correctly.
Around the time this initially broke, Microsoft had moved on from Xamarin and forward with MAUI. They also deprecated the "WAB" and not only refused to support it, but removed it from their internal test labs entirely! "Migrate to WAM", was their instruction.
I started on that migration process on Friday morning. I found out after hours of hacking and researching, with Copilot's full inspection of the codebase as well, that WAM will not work with this ancient version of Xamarin, because there is no way to obtain a low-level, IntPtr handle to the parent window.
WAM supports opening a browser to facilitate authentication, but that won't work either because, being sandboxed, Xamarin UWP apps are not permitted to run other applications. Indeed, I get an exception from the app when it tries to launch "msedge.exe".
I thought, "No problem, I'll just spawn a timer thread, and if it looks like AuthHost.exe is going to lock up, I'll pre-emptively kill the process, from code, without the user even knowing it." Yeah, UWP apps aren't allowed to kill processes either. "Ok, I'll spawn a PowerShell script to kill the process." No dice: the PowerShell script would just be running in the sandbox.
I considered, "What if I had a .bat file run a 'cleanup' script invisibly, and then launch the application?" Trouble is, what would the cleanup script do? I carefully monitored "AuthHost.exe", and it doesn't start until the moment before it dies: whereas, I was hoping it was a long-running process, pre-dating the application, which I could kill so as to get a fresh, working one.
We are planning to re-write this mobile application completely in the coming months or maybe year. I'm tempted to just throw a message on the login screen for now, instructing users to just click "End Process" if they get such a message.