 Okay, so I wanted to tell you about this LibreOffice port I've been working on for the past three years, on and off, not continuous time frame. I'm Katsper Kasper and I write software for a living and as a hobby. I'm a high-co-developer. I mostly write applications. I sometimes contribute something to the system itself. I've also contributed quotes KDE and some other small open source projects. So what is high-co? High-co is an open source MIT licensed operating system. It is a BOS array implementation. BOS was an operating system that died in 2001 because the company behind it bankrupted. But it had really a lot of really nice technical solutions. So our goals are to be desktop oriented. We are not aiming for tablets or anything like that. We are focused to make sure that working on a desktop is comfortable. We maintain binary compatibility with BOS so you can run your old applications without recompiling them. And we want to deliver consistent user experience and we can do that by controlling the whole stack. We have our custom kernel. Our windowing system is also custom. And there are two official flavors. There is GCC2-based 32-bit and GCC5-based 62-bit. And before you run away screaming that it's GCC2, you don't actually have to comply with the C++ flavor that GCC2 understands. That's only a requirement for kernel code. You can actually write applications in GCC5 and run them on the GCC2 compiled system because we ship GCC5-compiled user space. So you don't really have to do anything with GCC2. This is the user interface. It's pretty old-fashioned but some users love it. Some users hate it. There is really not much more to say here. It's a matter of taste. Okay, but there is one question. Can you try LibreOffice? And well, as we're going to see, yes, it can, kind of, almost. So what is already out there? And the problem is that Haiku prouds itself to be desktop oriented, but there is not really an office to it. So that's a problem. And until very recently, you couldn't really... We didn't really have any office to it. There is Go Productive, but the problem is that it was commercial. It was proprietary and it was closed source. And we don't have the source code. It runs on Haiku only thanks to the binary compatibility. And it's really old. The last release was around 18 years ago and so it doesn't support any of the modern formats. Caligaro supported recently along with KDE frameworks, but this is very recent. It was supported in November 2017. And it's good enough for most these cases, but it's not as... It doesn't have as many features as LibreOffice has and... Yeah, so that's... Okay, so another office to it is ThinkFreeOffice and it was running thanks to OpenJDK. It was swing based, but they no longer sell licenses for that, so that's not really an option anymore. Some individual apps that were there, there was a Borg port, but it was actually in a state as my LibreOffice port is. It wasn't really usable. There is Summit. It's a spreadsheet application that was written for BOS. And there is Scribus, which is a cute application, because we have also a cute toolkit ported so any cute application can work on Haiku as well. Okay, so the timeline. I have started working on it in 2014 and to be honest, I didn't really know what I was doing. And I got sidetracked with our projects until the beginning of 2017 because that's the kind of a problem with Haiku that there is a lot of things to do and there are not a lot of people doing them. So when I came back to it, I've updated the base to 5.3 because previously I was working on master, but then I decided that it would be better to have a fixed reference to work on. And when I restarted the work, I got a first window rendered after two weeks, continued the work until the end of January and did some work in April. And that's the result. So later that year, we had the kernel debugging camp. It was Haiku coding sprint in November 2017. And it was really great because we could work on any Haiku related projects just all the time. So a lot of work done there. And just three days, I have implemented window positioning so that the code would reach the Haiku layer with respect where the window should be positioned. I rewrote the rendering back end to be more stable because lots of crashes were related to this threading model BAPI uses, which I'm going to talk about later, and implemented SAL virtual device, which got me this. So there are a few problems. Keyword input doesn't work yet, but that's really a matter of sitting down, I think like in a week it could be done. It crashes a lot. Yeah, it deadlocks sometimes. Windows updates, for some reason, start from the coordinates 8 and 8, which is really weird. I couldn't track it down yet. And saving a file works. Actually, it should be worked because I checked it today and it actually crashes. And trying to open one deadlocks this week. Okay, so challenges. Turnaround times are really long because compiling is pretty long, but then when I want to debug something, the debugger has to load a lot of symbols and it can take like one to minute. So anytime I run it, it takes a long time to track some problems. Some feature switches on the browser are unfinished, although it's documented. But for example, there are situations like when you disable scripting, some modules just won't build. The API's thread nature. So here, Hiker uses for each window a new thread is created. So that creates problems with VCL because it tries to render from the main thread and the window has its own thread. So every drawing operation needs to have locks around it. And that was the reason why it crashed a lot because sometimes command can be issued to the window that is already destroyed. So it's no longer there and then it crashes. There are bugs in the system, which I'm going to talk more about later. And there are lots of dependencies, which is also substantial amount, which amounts to a lot of work. Okay, so porting libraries is time consuming, but it's not that hard. Work is happening at Hiker ports, which is a port system like Brew or PKGSRC. And a lot of work was related to Document Liberation Project libraries because obviously we have ported free type for Hiker itself. And as says other more popular libraries were already there. But Document Liberation Project libraries are really used only by LibreOffice, so they need to be ported. But this process was pretty easy because Hiker has POSIX compatibility, even though we don't claim that we are Unix. So it compiles mostly out of the box. One exception was MWADW. And the issue was that Exeter, it used in Hiker, it's in another library, so it just needed to be linked in and then it built as well. Bugs in the system. So CPP unit tests can't be run because CPP unit tests to crashes on exit and it appears to be a random loader issue. It doesn't run pthread destructors when unloading the library. It tries to do that on application exit, but the library is unloaded so the code is not there and there is a crash. And I think that TLS is broken, but it's over my head. So the issue was that I was working on SAIL frame. I added another member and then it started randomly crashing. And I've worked around the issue by moving members to another structure and it works, but I have no idea what is happening there. Memory dumps are just garbage. They're, it just needs some debugging to be done. Okay, so closing thoughts. Nothing is upstream yet. My main fear is that we are going to upstream it and then nobody will work on it, so it will be pulled because currently I'm just one person working on it and it's quite a huge undertaking. It was actually easier to do than expected. There is not a lot of code that needed to be touched. It's just VCL, other SAIL and OSL layers. It was just adding FDFs in proper places. Some code could be used more, I think at least because, for example, SAIL bitmap is just a code from Windows layer copied almost verbatim with only the system functions changed. And there is a link to, oh, there is, there is, and I think the easiest part is done. It just needs to be stabilized, but that will obviously take much more work. Here is a link to the repo where you can find all the code. I will try to upstream some of it, but that might happen a bit later. So any questions? No, no, no. It's, I've done, the layer is native BAPI. Yeah, it's a new, completely new layer. So as we have some time, I can do a live demo, although it's not really impressive because it doesn't go very far. Okay, so the first time it will crash, probably because something isn't implemented. And the second one works. And I can leave it out an image. Yeah, so that's all I have for today.