 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 Kacper 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 also contributed code to 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. The 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 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 on 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 HIKO 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 GoProductive, 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 HIKO 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 doesn't have as many features as LibreOffice has. 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 the 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, but 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 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 render after two weeks, continued the work until the end of January, 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 project just all the time, so a lot of work done there, and just three days. I have implemented window positioning so that the Haiku layer would 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 implement its 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 in a week it could be done. It crashes a lot, and 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. Saving a file works, actually it should be worked because I checked it today and it actually crashes, and trying to open one that looks this way. Okay, so challenges. Turn around 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, two minutes, so anytime I run it, it takes a long time to track some problems. Some feature switches on the browser are unfinished, so it's documented, but for example there are situations like when you disable scripting, some modules just won't build. The API is thread nature, so here Haiku 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 Haiku ports, which is a port system like Brew or PKGS or C, and a lot of work was related to Document Liberation Project libraries, because obviously we have ported free type for Haiku itself, and as says other more popular libraries were already there, but Document Liberation Project libraries are really used only by LibreOffice, so they needed to be ported, but this process was pretty easy because Haiku 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 Exat, it used in Haiku in another library, so it just needed to be linked in, and then it built as well. Back in the system, so unit tests can't be run because CPP unit tester 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 a sale 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. 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 future 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 SAL and OSL layers. It was just adding FDFs in proper places. Some code could be used more, I think at least, because for example, SAL Bitmap is just a code from Windows layer copied almost verbatim with only the system functions changed, 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. Any questions? No, no, no. The layer is native BAPI. It's a completely new layer. As we have some time, I can do a live demo, although it's not really impressive because it doesn't go very far. The first time it will crash, probably because something isn't implemented, and the second one works, and I can even add an image. That's all I have for today.