CppCast - Modernizing DOSBox

Episode Date: June 18, 2021

Rob and Jason are joined by Patryk Obara. They first talk about in Visual Studio 2019 and a Trip Report from Herb Sutter on the Summer ISO meeting. Then they talk to Patryk Obara about the dosbox project itself and the dosbox staging repository where he's been working to modernize dosbox. News <format> in Visual Studio 2019 v16.10 Trip report: Summer 2021 ISO C++ Standards meeting (virtual) Painless coroutines part 4 Links DOSBox Staging DOSBox Staging on GitHub DOSBOX Sponsors Incredibuild

Episode 304 of CppCast with guest Patrick Obara recorded June 16th, 2021. wait. In this episode, we talk about the summer ISO meeting. Then we talk to Patrick Albara. Patrick talks to us about DOSBox and his efforts to modernize the project. Welcome to episode 304 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? All right, Rob, how are you doing? Doing okay. Don't think I have any complaints. How about you?

Any news going on? Oh, I thought you were asking me if I had any complaints. I mean, do you? I mean, I'm sure there's things I could complain about. But it has been officially announced that I am scheduled to do a workshop at IndyC TechTown. So that's official now. And just as an aside, because we don't have it in our show notes to discuss, I just saw yesterday that CPPCon has announced their call for papers.

Oh, very good. So talking about conferences and starting to return to normal in some ways. Yeah. And on that note of CPPCon, do we yet know if it's going to be a virtual in-person or some kind of hybrid? They've been mentioning hybrid for a while now. Hybrid is the plan.

Cool. Okay, well, at the top of every episode, let's read a piece of feedback. We saw this tweet from Sean Parent saying he's excited to announce that Dave Abrams is joining Adobe and we are restarting Adobe's Software Technology Lab. And someone then tweeted at us, Christoph Havasi, saying, CPCast want to invite Sean for an update. And it certainly has been a very long time since we had Sean Parent on the show. I don't recall if this is something we talked about with him,

the Software Technology Lab. Is that something he used to be a part of and they're now restarting? Yes, it definitely would have come up because his alternate futures implementation, I think, is on the ST Lab GitHub. And there's a few other projects on there. So I'm sure it came up in some regard, but I don't know if we talked about it specifically on the show. Okay. Well, yeah, we should definitely reach out to Sean and Dave, maybe both of them, or at least one of them to come on and talk about the type of stuff they're working on there. Yeah, that'd be cool. Yeah. Well, we'd love to hear your thoughts about the show. You can always reach out to

us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Patrick Obara. Patrick is a Poland-based polyglot programmer. During his 13 years of professional experience, he worked on various C++-based projects like Opera Browser, middleware software for Nokia networking products, and recently on VoIP software products

for Metaswitch slash Microsoft. He's also a maintainer of several open source projects and drive-by contributor to many more. Aside from C++, he enjoys programming in C, Rust, Python, OCaml, and even weird languages like Prolog. Patrick, welcome to the show. Hi. Hey.

Nice to meet you. That's interesting. I like the categorization of yourself here as a drive-by contributor to many open source projects. What does that look like? Well, basically, whenever I have some kind of gripe with any project, if the gripe is big enough that I actually want to use that project and not switch to any other one, I try to compile it and try to see, hey and not switch to any other one, I try to compile it and try to see, hey, maybe it is easy to fix, maybe it's not fixed. So through this

process, I actually contributed to quite many projects and learned the way to... Usually the hardest part is actually to go through the process of learning how to contribute to a given project. For a GitHub-based project, it's usually the same, but when it comes to when you have made English or some other system or SVN or something, it might be more difficult. So for many projects, you've just submitted one or two patches to fix some issue and then moved on with your life, basically. Yeah, yeah, basically. Sometimes five, sometimes 10, sometimes 15.

That's usually what I want. You know, that's better than what I do because I feel like I often just patch around it locally or look to see if I can find a branch that has my solution or something, and I don't actually go the next step of trying to help contribute back to the project when I see something like that. I guess it depends on the situation I've done both but more often I just hack around it locally. Yeah, I'm having

quite standardized process of publishing patches and submitting changes. Like GitHub helps, but it's a little bit of double-edged sword when it comes to various, for example, maintenance time. Right. Okay, well, Patrick, we got a couple of news articles to discuss. Feel free to comment on any of these,

and we'll start talking more about the work you've done on DOSBox, okay? All right, so this first one is from the Visual C++ blog, and it is Format in Visual Studio 2019, version 16.10. And if you have not used Format before, this is a really good post just going over how to use std format as it exists in C++20, which is now fully into Visual Studio 2019, the latest

version, which I did update to the other day. I haven't had a chance to try to use format yet. I haven't tried any of the vendor-provided ones yet. I've only used libformat standalone. But nice to see that even more of C++20 is making it into the different compilers already. I just commented, Rob, that you said std format. I just had someone comment on YouTube. What's that? Should I be saying std fmt? No, no, no, no.

It's okay. I just had someone comment on my YouTube channel. They said, in 20 years of development, I've never heard anyone say std. And I did that in my YouTube channel recently. I don't tend to. I tend to to only use stood if i'm at a conference and there's a bunch of other people around me also saying that instead of saying std anyhow just a random aside yeah i think i i guess sometimes switch between the two and i hadn't thought about it that much in a while yeah okay uh next thing we have is a post from herb sutter's blog and this is a another uh virtual uh standards meeting trip report uh for summer

2021 and they did vote in a few more uh c++ 23 features he's got a short list of what's gone in and he also did put in an update that they do have planned what might be the first uh tentative face-to-face meeting since the pandemic started which is uh currently scheduled for february 2022 which still seems so far off but we're moving through 2021 pretty fast 2021 is moving way too fast. Yeah. Yeah. Is there any other any of the papers that went in you wanted to highlight Jason or Patrick? I just think it's worth maybe commenting that if you you look over the last several of these standards meeting trip reports from Herb, it seems to be increasingly clear that we're not going to get any very large features in c++ 23 at this rate it it seems that way i mean there's always

the chance that they approve a lot in february 2022 but that is the like feature freeze of c++ 23 right if they don't get a lot in then, then you're absolutely right. C++ 23 is probably going to be fairly small, more of a bug fix. Yeah, and maybe we'll get concurrency, it looks like. Possibly there's some progress on that. But none of the other features that I was hoping for, like pattern matching, we haven't seen anything about that. Maybe someone will comment after they listen to this episode and

say that pattern matching is actually moving along quite well but i would be surprised from what we've seen yeah i feel like it's been a while since we've kind of talked to anyone working on standard proposals in a while so i have don't have as much tracking on like what's been going on there maybe we should uh you know do another update on the type of progress they've been making right yeah okay and then the last thing uh we have is a fourth of four part series on painless c++ coroutines and this is all on medium and it looks like i don't think i've read through the first three parts, but this fourth part is pretty long, but it looks like it really gets into how to make coroutines a little bit easier to work with.

I really just wanted to highlight the series of articles because I had someone else point them out to me that it's part four of painless coroutines when each one is like a novella. Yeah. coroutines when each one is like a novella yeah it's so um i mean i i appreciate what the author is doing but clearly it seems that coroutines out of the box are not so painless to use it certainly seems that way patrick have you had a chance to uh try our coroutines out not yet and i think it will be still a little bit of time. Right now I'm more concerned with having C++ 17 and 20 widely available. And only after data is switched to using those standards. And yeah, C++ 20 is still a thing of the future. Okay, well, I think we've talked about DOSBox a couple times before on the show,

but could you start off, Patrick, with telling our listeners a little bit more about what DOSBox is, if they haven't heard of it before or aren't too familiar with it? Yeah, so DOSBox is a low-level emulator of x86-based machines. So that is a great description. And so let's explain step by step. So what does low-level mean? Low-level emulator. It means that CPU is emulated completely in software

as opposed to using some virtual special instructions provided by Intel architectures to make it faster. Now it's completely in software, which makes it more portable, easier to code to different operating systems and between architectures and that's good enough. There are of course some features to make emulation faster on popular architectures, but even if there is some very weird platform that has very weird requirements, you can always fall back to slower paths and it will work. That's how many pods have started. So that's the most

precise So that's the most precise description. However, there are some high-level emulation features in the RLA, emulating some parts of graphics tag and some etc. But that's a safety point for now. But what's important about Dosbox, because it's a quite unique project compared to other x86 emulators others because there are plenty of such projects out there. It has a set of unique features,

it has a very unique combination of features that make it very attractive for certain use cases. That is, first of all, it has built-in DOS-like shell which makes it easy to actually run the programs.

So when a user wants to start some program, run something, they don't need to install MS-DOS 6.22 in some image somewhere. Just starting DOSBox is enough. There's a DOS-like environment in there with plenty of DOS commands, not all of them, but very usable subset. Another unique feature is ability to mount directories from native file system as a virtual DOS drive. That means that no images are required. Most emulators have some kind of ROMs or emulators for NES or other consoles have games distributed as ROM images nowadays, right? So those games were never installed. For those, for all the PC games, the situation is different. CDs and floppies were only used as medium for installation. So when a user has old floppy images or old CD images, they need to be installed.

And because we have DOS shell out of the box, and we can install directly on 222.5 system, it looks like installation 222.5 system. It's a little bit similar to Wine's prefixes. Another feature is the possibility of scripting emulator startup. So in the very beginning, the user can write a configuration file where a specific set of DOS commands are being evaluated on start. Every DOS game is different. Every DOS game has its own quirks, its own special toggles and bugs and other things that need to be checked and switched and toggled. So using DOSBox this can be completely scripted.

Oh, and another, it's completely free. And it's completely free Libre Software, which means there is no requirement for obtaining some ROMs from old hardware, some firmware images and dumping them with the game. No, it works out of the box just like that. Yeah, it can emulate plenty of old hardware like old PGA cards or old graphic cards, old sound cards, different types, including some weird ones. Yeah, so that's important. And because of this combination of features, it basically can be treated as a runtime

for modern operating systems for running all the DOS software. So it behaves basically as runtime. Thus, it is a very attractive project for companies that try to release their old games nowadays on Steam or on GOG or somewhere else, because they don't need to do that much. They only need to prepare the configuration file, start up the configuration file, dump the installed files somewhere and distribute them however they like.

And there are no ROMs, everything is GPL-free, so they can distribute it. Another big group of users is game... of course gamers, especially older gamers who have memories of playing games in the 80s and 90s and want to relive those memories. Because there are a lot of those games, lots and lots, thousands and thousands of those games. And many popular ones were ported to modern operating systems or are supported by projects like ScamVM, which is an excellent project. But it's only a tiny, tiny portion of available software that was written for us. So gamers who want to believe in the past

and somewhat similar group, game archivists, game historians, people who are actively... Their hobby is to preserve those games. So they sometimes go to very great lengths to obtain some old legal copy of some game from mid-80s and then preserve it properly and make sure that all the instructions are there in digital form, etc. So for them, it is very important to have ability to quickly switch different features, hardware features, emulate maybe this card, maybe different graphics card, maybe trim the size of emulated hard drive,

because if it's too big, some cases are going to fail. This era software is not very good compared to modern times. So yeah, that's very important for them to have this ability to test good. And there are also other use cases like people who want to run some old non-gaming software to dump old projects or recover data from old databases or connect to some old physical big hardware, for example. There is a group of users who are using Dosbox to connect to the CNC machines from the 80s because this is the only way to run drivers for those CNC machines. How do they tie the...

Do they use like a USB parallel port or something? There's a serial port emulation in those blocks and it can go to a cost-operating system and they are probably using some kind of exact USB device to

can write serial outputs for the emotions I had no idea I could do that that's cool yeah or there are people who run all the BBS is for example because there is all the networking features in relation like IPX network and various others. Even some some users who were asking a little bit more questions, for example, I hope it's not true that Dosbox is running in any hospitals or something like that. There were, I heard questions about this kind of scenarios, I hope they are not true. Oil rigs as well. Oh, wow.

So that's a little bit of a spoiler about how worried we are about not introducing any regressions. So does Dasbox emulate any particular PC or is it just like a generic PC from the 90s? It's not like trying to be a Tandy or trying to be a whatever, Dell or something. It tries to emulate generic PC, but it's kind of switchable.

Those PCs, those PC clones were quite similar to each other, so it is possible to switch. So, for example, it is possible to switch from a generic 286 or 386-based machine to TEN-T or PCjr. There is an ability to load cartridges for PCjr. Oh, okay. It has the ability to distribute games on cartridges. It is possible to configure the runtime for using Sound Blaster, which is the default,

different types of Sound Blaster. Also, this grab is ultrasound, which is very important for some use cases and for some people, for demo scene, for example. Demo scene is another group of users, which itemoscene, for example. Demoscene is another group of users which it's important to actually run them.

Demoscene production somehow. And those were more likely than the usual to use Gravis Ultrasound cards, which are not very popular. So what is your relationship with how you've been contributing to the Dustbox project? Do you want to tell us with how you've been contributing to the DOSBox project? Do you want to tell us about how you got involved? Okay, so I'm not a maintainer of the DOSBox project itself.

I'm a maintainer of the fork called DOSBoxState. And this project, let's roll back historically. Before actually starting my work with DOSBox, I was working on a different project called Boxtron. This Boxtron is a tool for running Dos games that are distributed via Steam in a native new version of Dosbox on Linux. Okay. So, some game distributors who are dumping their archives on Steam, they usually bundle it on some very old and very deprecated version of Dosbox. And, for example, a version from 15 years ago. And it is something problematic to run those versions on modern

machines. And Boxtron was a project to make it easy. So, okay, I want to run this old game. It is officially distributed on Steam, but I want to run them in a new version of those books. Okay, so after installing and configuring the only box strong inside Steam, the only thing the user needs to do is just hit play and box strong takes over running the game, reconfigures it for modern version of DOSBox, runs it in native Linux version of DOSBox instead of some wine or other compatibility tools. Oh my goodness. version of DOSBox instead of some Wine or other compatibility tools. And the results were pretty

good, pretty fine. A lot of users enjoyed that version because configuring DOSBox can be a chore. It can be quite difficult. I did just a quick step back. You said, if I heard right, that some of the old DOS games distributed on Steam, if you

run them on Linux, is going to run DOSBox through Wine on Linux to play the game. Okay, that does not sound ideal. Not at all. Those are mostly games that were never distributed on Linux in the first place. Right, sure. Steam has the feature called Proton for running not every Windows game

on Linux via Wine. So that's Steam doing its automated compatibility layer. But that happens only because the original distributor did not care to actually release a version of DOS game using

native Linux version DOS books on skin. So yeah, that's the workaround for this problem. And when working on Boxtron I was learning about all the quirks, all the problems that are usually happening when what needs to be done to actually properly configure some old game for a given situation, how to solve this problem. Maybe there are two displays and it doesn't work correctly, so how do I solve them? And Boxron was implementing workaround after workaround after workaround for some features, for some problems that I was experiencing. And at some point I ran out of workarounds. It was no longer possible to fix certain things just by changing the configuration, because there was literally a bug inside the

box. So I switched to looking inside and learning how can I fix that, deploy my one or two fixes, and go on my merry way and continue working on boxing. And the big problem in there was switch from SDL1 to SDL2. Because SDL1 is very old library and it is still being used by upstream DOSBox. And it is causing a lot of issues, at least on Linux. On other operating systems as well, but on Linux it was especially bad. Issues like input, literally not working

keyboard, for example. Or issues with output when there are two displays attached to PC. Starting DOSBox took over both displays at the same time and stretched the image some. And all of those problems could be simply fixed

by moving to SDL2. So I would be surprised why SDL2 was not used after 10 years or something. Yeah, it's been a long time since SDL1 was maintained, I feel like. Yes, SDL1 was maintained, I feel like. Yes, SDL1 is not maintained at all anymore. That's great. All the development moved to SDL2.

But it is still a big problem. There are a lot of games, older games and older software, which only used SDL1 and never moved to SDL2 because migration was not trivial. Right. Migration was not trivial because SDL2 is a much better project. It has a much better API and it improved on many issues in the original library. But that required breaking a lot of things.

Well, anyway, quite a bit. So I tried to fix the issues that I was experiencing and I noticed that I'm not, of course, not the only one. The problem with DOSBox was that the last major version was released 10 years ago. And the development didn't stop completely it's still ongoing on very slow pace but community contributions moved much faster so there's an extremely long backlog of items that some people started developing and tried to push it upstream

but maintainers of thoseBox did not have enough time and enough, basically, time to budget in. And this backup was really very, very long. And what was not helping was that the project is in SVM still, which is rather an exception nowadays. The community wanted to move to Git, but upstream prefers to stay in SVN for pay reasons. So I said, instead of complaining on the forums or something like that, I will actually try to solve the problem. Therefore, I migrated very carefully. I migrated all the history, preserving all the changes, not dump the history, but preserve all the history

that was in SVN, the correctness, the nice syntax. That can take a while. Preserving the history and your move from SVN to Gibson. I did the same thing many times earlier at work and for other projects.

I had already scripts prepared exactly for the thing that needs to be done. It was quite quick. Good. And after some deliberation, named the repository Dosbox staging to suggest that, okay, I am not trying to fork Dosbox. I am not.

I am trying to be a staging area for people who are waiting to help with resolving this backlog of items. Right. Because there are hundreds and hundreds of patches and features that are developed, and some are forgotten already. Some are quite good, but were never finished because nobody reviewed them.

And therefore, they cannot be measured as is, but someone needs to do a review. And resolving this requires, of course, having a CI, having some tests, having ability to easily build on all operating systems. And unfortunately, the DosBot project was lacking all of those. So initially, and other developers from Vulkan's forum, Vulkan's forum is a place where.NET was developed, joined me, which is particularly very enthusiastic about move to Git, because someone actually did it instead of complaining and asking again and again.

And for some time we tried to go with this process when new patches were staging in my repository, and after they were good enough and upstream maintenance decided okay that's fine, they were trying to merge them into upstream, into sv repository. After a little bit, after some time, it didn't work so well. Mostly because for our Git repository, for staging repository, it was quite easy to learn new changes because of CI, a little bit of tests because we are still adding tests, a written build system, some bugs fixed and other areas addressed. So for us it was quite easy to learn new changes. But for upstream it's not so easy. So the backlog, instead of going smaller, it actually started to grow

because more people were interested in presenting their purchases. So after some time, we decided that now we can follow this way. And Dosbox staging turned from

staging repository, which had no readme back then, even into soft fork of the project. So we are regularly still syncing up with upstream, because there are some regular important changes, especially for various game queues and specific programs. There are important changes still landing in there, so we are gradually merging those changes back into the speed station. But otherwise, we are much more liberal about adding new features, completely re-roll the build system, for example, adding tests,

moving from old C++ to newer version, etc. And also breaking some features. We also broke or removed some features that we thought were not important anymore. So, for example, we removed

support for OS2 operating system. So, for being able to run OS2 in DOSBox, or from being able to run DOSBox on OS2? The second one. From DOSBox on OS2, which is, nobody runs OS2 really anymore. Just Tobias and, yeah, a few people, yeah. Yeah, I mean, it was dropped in 2006 or 2008, something like that.

Yeah. But OS 2 or, for example, Windows 98, because there are people who like to run Windows 98, those bugs inside, and then disk image, and then Windows 98 inside, and then those bugs inside. Oh, that's right. So there are people who enjoy these kinds of things, but I don't think it's really

necessary for us to keep the projects back and not have, for example, C++14. Right. So I guess that answers a question that I just had. Is C++14 what you're moving to? We already moved to

C++14. And I hope in a few months we're going to move to C++17. The only thing holding us back is that one of the platforms that we want to support does not have C++17

standard library because it was based on Ubuntu 12.04 very much correctly. But I think the problem is already resolved and we probably can safely move to CPU 17.

Was that like a version of Raspbian or something that's holding you back? I'm just guessing here. Steam Runtime. Since then, there was a new version of Steam Runtime released Old Steam Runtime. Oh, okay. Since then, Steam Runtime, there was a new version of Steam Runtime, released literally several months ago. Actually, I'm not sure if it was released or if it's still in beta, but it's there and it's much newer and much better, much improved.

But the old, original version of Steam Runtime is not able to reliably run C++17 projects. Reliably. I like that. Okay. So... I wanted to have the discussion for just a moment to bring you a word from our sponsor. As C++ coders, I think you can say we've gotten

used to waiting. Waiting for code to be compiled, tested, and even analyzed. My friends at Incredibuild have been working decades to help developers like you and I code more and wait less. Because expert developers don't wait. With Incredibuild's acceleration platform, I've easily gotten up to 10x speedup on real-world projects right out of the box. What I like most is how easy it is to use. Their virtualized distributed processing technology turbocharges product development with just a lightweight Incredibuild agent.

No need to install any build tools or source code, turning every host in your network into Thank you. or HPCs or developers. Go to incredibuild.com slash cppcast to start your free trial today. That's incredibuild.com slash cppcast to start your free trial today. So in addition to upgrading to C++14, have you made other changes to modernize DeskBox? Are you using static analysis against the code base? Anything like that? Plenty.

So first of all, we started fixing warnings. That's like the most basic thing that developers can do to significantly improve the developer experience, which is developer experience is important for open source projects. Right. And to make it easier to review the code. So if there are no warnings, it's much easier. The reviewer doesn't need to remember about, oh, do I need to check about this and this and this.

If there are no warnings, then that's it. The host of potential issues is already addressed. So we implemented gating. First of all we created CI based on GitHub actions, because it just happened that GitHub actions arrived in... was released as beta at roughly the same time, so we started using it. And put in place gating so that we can change things. But not a single change that we introduce cannot raise the limit of warnings. It can only go down. This hard gating simply does not allow any pull requests that make the added new warnings. And gradually we started adding a new category of warnings to the skating. So the number of warnings went down and down and down.

And several thousand warnings later, we are not there. And it is really an improvement to see the clean build from the beginning to the end. And it's also an incremental build. That's important. I just had a curiosity. As you've been reducing the warning load, have real bugs been fixed? Okay. Yes, yes, yes. Sometimes those bugs were not really that big.

Those were potential bugs talking into code, but even simple warning fixes can not maybe indicate exactly the line of code where the bug is present, but when developer starts looking at why someone wrote this like that, or maybe this warning is like this, but maybe this is something different, or maybe this is code copied from some other place and this does not look right. And we actually had quite weird emulation issues fixed only by looking at warnings that were indicated by console. And we of course run it through GCC, CLang and MSPC. Running MSPC on CI was a little bit problematic, but it works and it's very beneficial. So after that we also added static analysis, because the same, just like warnings, static analysis is great. Maybe not all, but the vast majority of static analyzers are very high quality products

and every single one of them indicates a little bit different issues. Some have high false-positive radiators, some have lower false-positive radiators. It's important to at least look at those issues, because if the automatic system is confused about the code and the person looking at the code later on is probably going to be confused as well. I like that attitude.

Yeah, and with the same gating, we are not allowing any new static analysis issues to show up, which means that some feature, maybe longer in-review or will be developed later, but hey, we are open source, we don't have deadlines, we don't care more about quality than about delivering quality data.

And out of static analysis tools, we definitely use C-Lang static analyzer, which doesn't report so many issues for us, but it has very low performance-positive ratio. And indicated actual problematic code areas and actual buffer overflows and bugs. Honestly, it is so easy to run C-Line Static Analyzer on CI that I don't really want to work on C++ projects that don't have it integrated into the CI.

You're distinguishing that from Clang Tidy, right? You're talking about now Clang Dash Analyze or something like that? Are you talking about Clang Tidy or are we talking about... see like now clang what dash analyze or something like that or are you talking about clang tidy or are we talking about uh no i think tidy is to automatically fix some issues but okay i don't remember because even that's fine as i did we also use Coverti static analyzer, which was a little bit painful for some time, at times to use, and detects completely different host of issues than the static analyzer. But it's also very good. It's also very good.

And also detects a number of specifically buffer overflow issues. Wow. detected a number of specific buffer overflow issues in the network. Or indicated code that was smelly, a little bit. And because we after looking into context, okay, maybe right now there was no actual

bug was not present at the moment. But if some other prerequisite changed line earlier earlier or later, then yeah, that would be a bug. That's interesting. Also PVS. We used PVS for a year and it was another completely different set of issues were detected. What is very nice about PVS is it also suggests certain improvements. So for example, in here you can speed up this thing by using pre-incrementation instead of post-incrementation. In here and here and here. Or in here you can

simply compare to null instead of invoking some method which will be slower because it's not a virtual method and so on and so on. PVS is good at this kind of things. So the quality is by using PVS, quality got improved but by maybe micro optimization here, micro optimization there, some actual code quality issues here and there. It's very interesting. And we are using that for a year and successfully we got renewal of our license, free license from PBS, so that's great. And some time ago we started using LGTM.com. Oh no!

This is a project which has a very different approach to static analysis and it is very interesting I'm not sure how it works in detail but I think after doing static analysis they are filtering it by

some machine learning to decide if this is false positive or not and the result is that it detects much fewer issues, but the issues that are detected have very low false positive ratio. Very, very low. And it also has the ability to compare projects, and score the project. Okay, the code quality for C++ code in this project

is B or C or A. And this is some kind of incentive to actually improve and compare. And, yeah, I understand this as well. Wow. So you're using basically every tool you can get your hands on. And finding different issues with each one,

which is something everyone should keep in mind. I think that in the past, especially for programmers who started in the 90s on Windows, they do not believe their tools, but tools for all the languages, not only for C++, but for all the languages. Tools and quite a few compilers

in the last few years, and the cost of issues that are being detected. It makes sense to actually look at those issues and do not decide, okay, I'm not going to... Compiler is definitely wrong, because this is not a bug, because line error happens there, and later something different happens, so this is not a problem right now, so compiler is wrong. Okay, maybe we can fix this line so compiler does not complain anymore, and maybe it will actually improve the code quality in here, because next person looking at this code, it might be more available for the next person after it's going to be coming here and trying to maintain this solution. I just want to comment on that real quick.

And when you said before, when you're looking at the static analysis of the warnings and you say, well, this definitely is not a bug right now, but if anyone modifies code around this, it could become a bug. That's just such a different attitude than I'm used to hearing. Most people will say, oh, you know, stupid static saying, well, wait a minute, what about the future viewer of this code? Is there some way we can make this better and improve the overall state? It sounds awesome to me, so I just wanted to comment on that. I think

that's a benefit of working on Microsoft's code where there are no set deadlines and it's more important to preserve the head quality of the code than actually deliver some time. Because for in cloud software

there might be other factors like some business timeline which is important to deliver by that time. For computer games there are deadlines that cannot be crossed, for example. But for open source software, usually it is much more beneficial to preserve high quality, mostly for the sake of maintainers, because contributors are coming and going hard, but maintainers should be interested about keeping quality as high as

possible. And sometimes it might be even mean changing the code. This is a lesson that I learned from Git project, I submitted and some of my patches were accepted to the git. And the lesson from there was that my initial version of the code was already okay and it was already acceptable, but the maintainer asked me to actually rewrite it a little bit to make it a little bit less optimal, but there was fewer repetition and if anyone changed that line of code again, it was most likely, the compiler would be more likely to complain. Therefore, less workload for the maintainer

for the future parties, for the next person. Interesting. It does seem like the kind of lesson that would largely be learned from large-scale source projects that most people don't have access to. Or in some of the very large open source projects that we might have discussed on this show previously, they tend to be largely maintained by one company with its own goals and ideals and whatever internally. So we talked a lot about, you know, modernizations you've made and some of the things you took out of DOSBox, old features that weren't relevant anymore. Is there anything you've added on this version of DOSBox? Oh, yeah.

So first of all, I already talked about the changes that were focused more about making the project easy to maintain. Sure. Introduced CI. Introduced testing infrastructure, which we are still working on. That sounds difficult. Before we actually start writing the proper set of tests, because previously there were no tests at all. And if you have

9,000 PC games from the 80s and 90s and you don't have tests at all, then every change is very scary. There are plenty of people actually. The community is great and plenty of people are doing manual testing and manual verification before each release, but it is much better because it's automated. Which is having automated tests running on three operating systems at the same time, which are easy to deploy and easy to run, is actually not so trivial in the modern environment, right? Because, for example, Gtest, we are using Gtest. When the project is used via Visual Studio,

Visual Studio has its own preferred way of running Gtest. And when we want to have code deployable by different distributions, they have their own preferred way of running Gtest. And the same with Mac OS, where Gtest is not available via any repository. So those kinds of... I will talk about this later, but we solved those kinds of issues by introducing, by using Meson. And Meson is such a great system. I will talk about that. Back to the features. We started introducing changes that make the project easier to use. Earlier I said that Tazerbox is not so easy to configure. You need to have some experience to actually know how to tweak certain things and why.

You might have performance issues right now, but after switching one magical option, those issues for this specific game might actually disappear. So we redesigned the defaults because defaults that were there, default settings, were designed in early 2003. Dustbox is a 20-year-old project. So some defaults, for example, about how the full screen should behave, were completely different in times where everyone had CRT and resolutions were fixed and there was a set of expectations about full screen works on PC. And now, when almost every gamer prefers to have some kind of borderless full screen window, which will not trigger mode change on their LCD display.

So we started redesigning the defaults, improving documentation, started work on improving existing translations, because right now there is some way to translate messages inside the emulator, but it doesn't work so well. So we started to work on making translations and replacing old translation system with newer one, which will serve so many issues once it will finally run. And that was also great, because the moment we started talking about translations, people, new potential contributors started coming in, oh, I want to do French translation, oh, I want to do Russian translation, oh, I want to do Italian translation. So the more people are coming in, the more contributors, the easier it is to actually move forward. Every contributor is a test-resolver. The features from the ones that I would do for... Ah, and we started adding also

non-standard DOS shell commands. For example, in Windows and in Intel there is a command that everyone uses on those systems, dir, to display directories. And people who dread command line on Windows, old command line, are used to this way of displaying files in the current working directory. But nowadays people are used to typing ls, right? Because ls used to work. I mean, from Unix times, it works everywhere. Even in PowerShell nowadays, people just type ls. It's very muscle memory.

So yeah, we implemented LS. Nice colored syntax to distinguish between files and directories, which is very important because we are emulating a terminal when you start DOSBox. The default Windows

looks like DOS terminal from 80s, which has 80 columns and 25 rows, right? So it's very limited space. So using that space to carefully display files and directories and using colors to signify it is such a small thing. And after that, person after person was contacting me through various forums, thanking me about implementing this feature. I don't know how many times I've accidentally typed LS into DOSBox. So in DOSBox staging, it will just display.

Now I have to install it. Nice. Okay, so those are small changes about improving usability and bigger changes about implementing features that were usually someone already implemented that like seven years ago and patch is in there somewhere half finished, half working or for example working on Windows and never tested Linux. So we started looking at those patches and cleaning them up, fixing them on a lot of other things. So they work cross-platform properly. And step by step merging. Sometimes those switches are really big, so splitting them into smaller, more maintainable pull requests and merging them one by one.

And those are usually the selling point with each release. When we want to brag about, oh, we have a new feature, because when we are going to do a release and we are going to fix this bug and this bug and this bug, people are not going to care. But, ha, we have this new feature. It's a visible spike in downloads. Okay. Out of those features, which is also connected to the method,

which I will talk about later, we implemented one of those patches was built in MIDI synthesizer. Of course, not our implementation, because MIDI synthesizer is completely other class of software. But there is one very, very good implementation, SynthetizerCard FluidSynth, which also had a revival several years ago. It used to be almost abandoned project, but Meguro took over and started implementing and improving it, and now it is really, really good. So yeah, previously, I mean in 90s, specifically 90s, there were many games that used MIDI music and those games sometimes sounded so beautiful and there were so great technical achievements for some of those games using MIDI music. For example, LucasArt games had their own system where music changed dynamically

based on the situation of the screen. So this is a feature that we have even in modern games right now. But their implementation is based on MIDI and this music was automatically generated during the gameplay. And it works so much better than what we have in modern games right now. Authentically, it is something so much fun to run some old game that you remember from childhood and to turn on MIDI music for this game. And this completely can change the experience. So, earlier, before we

integrated FluidSend, setting up MIDI music was quite painful, because synthesizers need to be... Some people used, still, even now, physical synthesizers, like keyboards or stuff like that, and we're connecting those bugs to those,

but majority of people just tried to use software synthesizers like FluidSynth or T-MIDI-T or some other ones. I think there is official, but all on software synthesizing. How good is it? It is, but we have great open-source alternatives. But it was a little bit painful to set it up. Every operating system exposes MIDI devices in a different way completely, different APIs are used, different configurations are required. It was a pain. Right now it is integrated into the emulator itself, to DOSBox, it's much easier.

I think we're starting to maybe run a little bit low on time. Is there anything else you wanted to share before we start to close it out? Meson. When we started, in the very beginning, the project was quite old. 20 years of maintaining the same two build systems. There is one build system for Windows, which is all Visual Studio-based. Not new one, does not work in new Visual Studio, but it was there. And auto-tools-based build system, which works everywhere else, but it was there. And autotools-based build system which works everywhere else, but it was painful to use. Painful to integrate

every new tool, very painful to integrate the GTS, to add compilation flags, to integrate our own tools or scripts inside. It was very... I did some prodding here and there, checked several different build systems,

and in the end I decided, okay, I will compare CMake and Meson and decide on one of the two. I had some experience with CMake already from the previous job, so I kind of knew what to expect from CMake. And Meson I was learning from scratch. And I must say, Meson exceeded all my expectations.

I was completely prepared that building, setting up another build system for another project is going to be painful again, and there will be a lot of razor blades hiding somewhere, and a lot of pain points. And it turns out the Maison is such well-crafted and carefully designed system

that it was a pleasure to use. And I'm honestly a little bit surprised that modern CMake is fine, and there are a lot of projects which prefer to use modern CMakes. And honestly, I'm a little bit surprised that modern CMake is fine. And there are a lot of projects which refer to as modern CMakes. And honestly, I don't understand why. Not only is Maison great as a tool, it's also very reliable and well-maintained. It is improving very fast. And the community is great. It's well maintained, it is improving very fast, and the community is great, it's extreme. So we had questions towards the community about certain features or certain edge cases that we

were experiencing, and they were always helpful and into pointing us to correct technical decisions. And yeah, I think I landed one or two patches in Meson in return, of course. And Meson also has a feature called Meson Wraps, which is about integrating external dependencies, which can be configured per build, per operating system that you want to use. It's up to the developer. And yeah, it turns out that there were some projects missing in RAUV, so I started packaging

them, which helped us. In turn, it gave us the connection to other related open source projects. So it's easier for us to cooperate right now with FluidSend and the MT32AMU project, which is a little bit related to DOSBox. I recommend Amazon wholeheartedly. It's great. Okay. Well, it's been great

having you on the show today, Patrick. Thank you for telling us all about the work you've done to kind of modernize DOSBox. And where can

listeners go and check out the project? Maybe if they're interested in contributing? DOSBoxstaging.github.io with dash DOSBox dash

staging.github.io with dash dosbox dash staging.github.io or there are links there for GitHub and for Discord, we have quite active Discord community and any questions can be asked in there. Also on Reddit, subreddit, air dosbox,

people are... Oh, nice. Okay, thanks for coming on, Patrick. Thanks a lot, that was great. Thanks for listening. Thanks so much for coming on, Patrick. Thanks a lot. That was great. Thanks. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion

for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast.

And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.