New GUI code to replace current Configuration GUI (and other possible uses)

[joncampbell123]

While the current Configuration GUI codebase has functioned well enough, I really don't like how it's designed.

It has have C++ style "new Button or whatever" code which allocates objects that you hope attach to the Window or whatever and never get lost. There was also a long ago hard to fix use-after-free issue with the system menu and the window (when you select Close). Finally, it requires DOSBox-X to stop and switch the SDL video mode to 32bpp.

I'd like to write a new GUI toolkit for DOSBox-X. I know enough how to code one, and any help is appreciated.

• Can be used whether DOSBox-X GFX code is in 8bpp, 16bpp, or 32bpp
• Can be used while the emulator is running (doesn't have to pause emulation)
• Could be used to provide informational windows atop or to the side of the emulated VGA display. Perhaps even provide a mode where the DOS screen is shrunk down into a window of it's own if the UI calls for it.
• Can draw pixels, lines (horizontal, vertical, and arbitrary), circles, filled circles, rectangles, filled rects. Draw bitmaps, too.
• Efficient rendering code. None of the generic and slow calling setPixel() to draw things as the current Configuration GUI does.
• Can draw text. Text will either be monochrome 1bpp bitmaps or something rendered by FreeType. More than one font supported, UI will no longer be one big uniform grid of Terminal font. FreeType anti-aliased rendering for 16bpp and 32bpp should be allowed.
• Can we "borrow" and use the System font from a real Windows 3.1 installation as part of DOSBox-X (built in)? It would make the title bars more realistic, but the System font is copyright 1988 or so by Microsoft. Is the copyright old enough we can just go ahead and use it anyway?
• Full emulation of Windows 3.1 behavior and common controls, window styles. Windows with a resize border, or 1-pixel non-resizeable, or thicker dialog border. Menus and menu bar behavior, system menu behavior.
• Eventually, the configuration GUI will be themeable in that if you want it to look like Windows 1.0, 2.0, 3.0, 3.1, 95, 98, ME, 2000, or even XP, you can do that.
• Two Windows 3.1 themes: Windows 3.1, and Windows 3.1 3D common controls, as separate options.
• Unlike real Windows, each window will be an SDL surface that is composited as needed (in the same way that the Configuration GUI does now). Dirty rects will be used though to only redraw what needs to be redrawn. This version will have much better performance, especially if you drag the window on the screen, than the Configuration GUI.
• Future GUI rendering: polygon outline, filled polygon, arc, filled arc (for informative elements).
• If the new GUI toolkit is good enough, it may replace the current menu bar (on Linux builds) and allow emulation to continue running while navigating the menus.
• GUI resources are accessed through handles, not direct pointers. Allocation returns a handle, free with a handle. This prevents memory leaks and bad pointers especially if objects refer to other objects i.e. menu bars linked to menus and submenus.

[Torinde]

Great! I like all of the ideas mentioned. It would also make possible:

• Soft keyboard, mouse(s), joystick(s); emulate LED indicators #3636

Coincidentally, at Staging the GUI/OSD discussion was just re-activated with the idea to use Blend2D

Thinking out loud about potential synergies/collaboration:

• single GUI "inside" which the user can run either X or Staging - best outcome in my mind, if goals on both sides can be aligned. 🤞 Some features may be enabled/exclusive only when running with X others only with Staging, but the bulk will be for both.
• cross-compatibility, so that either DOSbox variant (and other SDL forks, if another project wants to adopt it) can use a GUI from another one
• just sharing bits and pieces as already happens for other parts of the codebase

[johnnovak]

Coincidentally, at Staging the GUI/OSD discussion was just re-activated with the idea to use Blend2D

Thinking out loud about potential synergies/collaboration:

• single GUI "inside" which the user can run either X or Staging - best outcome in my mind, if goals on both sides can be aligned. 🤞 Some features may be enabled/exclusive only when running with X others only with Staging, but the bulk will be for both.

• cross-compatibility, so that either DOSbox variant (and other SDL forks, if another project wants to adopt it) can use a GUI from another one

• just sharing bits and pieces as already happens for other parts of the codebase

These points are absolutely unfeasible, in my view. Besides, I have pretty strong views about how I wanna do things, so I'll do it my way in Staging 😎 Will most likely use my own immediate mode toolkit with C bindings (once it's backend agnostic).

However, anybody will be free and welcome to copy/adapt/etc my approach; I just don't see the collaboration happening during the dev phase from my end.

[joncampbell123]

Whatever Staging is going to do is probably very different from how I imagine coding this GUI toolkit, however I have no problem if ideas are borrowed between the two projects. I'm pretty sure I understand Bresenham well enough to code a line draw routine and circles should be doable.

I intend this toolkit to be usable even during emulation, not just during the Configuration GUI, which means it needs to have code for 8bpp, 15/16bpp, and 32bpp SDL surfaces. Maybe 24bpp too, but SVGA cards really haven't supported 24bpp since the late 1990s because it's not a power of 2. I think Windows XP was the last version of Windows to still support setting the display to 24bpp (3 bytes per pixel), at least within VirtualBox.

[joncampbell123]

Blend2D looks amazing. The problem is that I would be using all that amazing rendering code to recreate the aliased pixelated look of Windows 3.1 :) It's like when I watch these game jams and someone is using the Unity engine to make a game render at 320x240 at 15fps and look like a mid 1990s Playstation game, even going as far as to write a vertex shader to make the polygons jiggle a bit when you move around, it's too much! 😆

[joncampbell123]

However I've also considered UI elements that might show the state and activity of various hardware and the vector graphics offered by Blend2D might be good for that. So perhaps, Windows 3.1 style UI with anti-aliased renditions of keyboard LEDs, CD-ROM drives, hard drives, etc. for debugging purposes or whatever.

It's interesting Blend2D comes up because I was considering using the Cairo graphics library for that for some time. I wrote a proof of concept in the source code repository that shows how easy it is to direct Cairo to draw onto an SDL surface. Can you direct Blend2D to draw onto an arbitrary SDL surface as well?

[johnnovak]

Can you direct Blend2D to draw onto an arbitrary SDL surface as well?

Absolutely; it will work the exact same way with Blend2D conceptually.

[Torinde]

Can we "borrow" and use the System font from a real Windows 3.1 installation as part of DOSBox-X (built in)?

Good idea, as that will avoid problems with copyright period, etc. - in the same way for some OS/2 variants IBM didn't pay for Windows license (thus those OS/2 variants were cheaper than normal?), but was using user-supplied Windows installation, where the user takes care of the licensing costs, Windows installation media, etc.

[rderooy]

Can we "borrow" and use the System font from a real Windows 3.1 installation as part of DOSBox-X (built in)?

Good idea, as that will avoid problems with copyright period, etc. - in the same way for some OS/2 variants IBM didn't pay for Windows license (thus those OS/2 variants were cheaper than normal?), but was using user-supplied Windows installation, where the user takes care of the licensing costs, Windows installation media, etc.

@Torinde I think you are confused. What you are referring to was IBM using the pre-installed (independently licensed) Windows 3.1x for use under OS/2. That is not what @joncampbell123 was referring to. Nobody has Windows 3.1x installed these days (other then possibly in a virtual environment), so you cannot just "borrow" part from it. Instead he seems to refer to shipping the Windows 3.1x system font with DOSBox-X, and that would be an issue.

In my view, it would be a "Bad idea". The copyrights on this are still valid. MS may not take action, but it will prevent many Linux distros from even considering packaging it.

[Torinde]

I'm thinking in the lines of OS/2 'Red spine', yes. People have Win3.x installed these days - inside the DOSbox virtual environment, yes.

That's exactly the point as I understood it - Jon's idea is that DOSbox itself can, optionally, utilize for the GUI a font present in the "guest" environment, specifically original Windows fonts part of whatever version of Windows the user has installed themselves.

[joncampbell123]

I thought about that, and the "Sans Serif" font too. If not available, the TTF files from the Google Font library were added to the repo as substitutes for Sans Serif at least.

I was considering code that would extract the System font from VGASYS.FON and Sans Serif from SSERIFE.FON, compile it into a bitmap strip with width info, and then build it into a char[] array within DOSBox-X.

There is proof of concept code I wrote about a year go (in Python 3) on how to dig into the FON file (which is really an NE executable with resources), pick out a bitmap font resource, render it, and present it as a PNG.
See: https://github.com/joncampbell123/a-pile-of-documentation/blob/main/images/encodings/gen.py#L143
And: https://github.com/joncampbell123/a-pile-of-documentation/blob/main/apodlib/windowsNEres.py
And: https://github.com/joncampbell123/a-pile-of-documentation/blob/main/apodlib/windowsFNT.py

It can only do bitmap fonts, not vector or TTF, and it's been tested against the FON files in Windows 1.0, 2.0, 3.0, and 3.1. Bitmap fonts in Windows 95 and higher are basically the same format as 3,1.

If I can't legally include them in the emulator, then, yes, I'll use them if available, and fall back on the Google Fonts I recently added as substitutes for those fonts (Open Sans and Anton).

Perhaps Windows builds could try to use the font files already on the Windows system itself. Win32 APIs since Windows 95/NT do allow a way to set up a DIB section where GDI allocates memory that you also have access to, and both you and the GDI can draw on it, as a way to gather font bitmaps to draw with, especially when FreeType isn't available. From what I learned writing a Win32 API interception project in 2005, the Adobe Flash player uses just that to efficiently draw on the screen and combine it with "dynamic text" rendered by the Windows GDI text functions. The project in question was designed as a way to record Flash animation to an AVI file (KKapture style), but was quickly extended to detect those "scare flash" animations that was the fad at the time and attenuate the audio whenever loud distorted audio was detected. It was actually quite reliable except for false positives whenever someone used NES chiptune music.

[joncampbell123]

By the way the only documentation on Microsoft's font format, written by Microsoft, is terrible. They don't even list the offsets of fields, and sometimes not even how large the field is. I had to do guesswork and some playing around with the "Font Editor" shipped with Visual C++ 1.5 to figure it out. Blah.

[joncampbell123]

And of course, Windows 1.0/2.0 have a vector font format of some kind which they don't even bother to document at all (not TTF, just vector), so, I guess those aren't going to be rendered.

[joncampbell123]

On a related note, the Unifont TTF file used by the TTF output might be useful as well because it has the full range of Unicode in it.

Perhaps the GUI toolkit could support using the message translation system in place, such that it can use your language setting. Unifont could be used for, say, the Chinese characters that the other fonts don't have.

[joncampbell123]

Huh, how about unifont.pcf in X11.

It looks similar to Sans Serif.

https://fontforge.org/docs/techref/pcf-format.html

[joncampbell123]

The copy on my system is 5MB large with some things in it that are probably not necessary for DOSBox-X, like the massive "glyph name string table" that's mostly strings like "U+3543", and the font bitmaps are uint32_t aligned, so it would be converted to something more compact within DOSBox-X obviously. However unifont.pcf also has the full Unicode range, which means the UI could support more than just English and European languages with this one.