Linux GUI support for OpenWatcom programs (viw, wdw, setup, ...)

[winspool]

An idea from the old mailing list was to use GTK, but this will not work:

• linking to shared libraries not possible for the Linux target
• Compilation of a common used GTK will need needs too much things,
  which are not implemented in OW (atomics, threads, ...)

Even using other lightweight GUI toolkits (FLTK, wxWidgets)
will fail for the same reasons (both are C++)

*a) Lowest level would be using sockets.
The Internet has some sourcecode,
but building every requests manually and parsing the answers
is a lot of work.

*b) A level below the fancy GUI toolkits: Using X11 directly

Using xlib.h (with -lX11) has lots of tutorials and examples,
but i do not expect, that OW can compile X11 in the near future.

*c) Next lower level: xcb.

I was able to compile a static libxcb.a (1.16) with OpenWatcom
but i didn't tested the xcb tutorial examples yet.

(I was using my system X11 headers with the system xcb-macro package,
but the source still needed a workaround for AF_INET6 )

My idea is, that libxcb (License: MIT) can be imported to contrib,
but where to put the glue code?

• bld/gui/xcb
• bld/wpi/
• somewhere else?

@jmalak What do you think about this idea?

I know, that newer Linux distros use wayland.
Wayland can look like an X11 server for non ported X11 programs,
but i didn't checked yet, if this layer works for xcb or only for X11.

And for wayland, the program has to render the whole page,
while X11 (and xcb) supports multiple windows,
graphics primitives (line, circle, poly...)
and also font/text related features.

[winspool]

There is also the microwindows/nanox project
which is much smaller as the big X11 project.
(But OW can't build it)

This project can partialy emulate the X11 (xlib) API (Nano-X) and
has even a minimal emulation for the win32 UI API (microwindows).

This can help as hints, how to construct the glue code in OW.
(But no code reuse, as the license is MPL or alternatively GPL 2 ).

---

Microwindows/Nano-X has even a DOS port (with DJGPP) 🙂

[jmalak]

First, your approach is useless.
If you want to implement some framework it means to port it to OW first.
Your assumption that it will be compilable by OW is naive, none of this code is portable due to it is not 100% C standard or POSIX standard compliant.
Other problem is that it is mostly mono-OS or a few-OS solution and we need some framework working on DOS, OS/2, 16/32/64-bit Windows, Linux.
That your selection is chaotic only rule if compilable by OW or not, it is wrong, it is absolutely minor rule.
Selection must be done by various factors not by single one, and must be done by efort estimation for such work and what modules and how much need to change for such solution.
The main issue with OW GUI is orientation on Windows Windowing model, which cannot be used with X11.
The potentialy usable solution is

• get some framework which emulate Windows Windowing system on X11
• change OW framework at all to other one and rework affected OW code
• add our own code for X11 into OW GUI framework for non-Windows platform (Linux)

Of cause it always requires to port X11 to OW.

Some of your statement are wrong, by example OW support POSIX threads on Linux and it is possible to implement it on another OS-es.
It is only about somebody do it, but we have thread support on all target platforms which can use it that it can have sense only for portability of POSIX application.
Anyway that something is missing in OW is not reason to abandone some selution.
Missing things can be implemented but all this must be included into estimation and decision.
If you want to discuse such thing you need study all such solution and understend how it is going in OW.

You simple criteria that somethin compile and something doesn't compile with OW is useless it is rather information how such software is portable.

I don't like similar project for project, first you need resources and second knowledge. If you have it then you can start such project but without such resource it is only paper work nothing more.
But priority for such GUI solution is low because we not need it urgently, we have character mode solution for all platforms.
Try to answer simple questions what we gain by porting GUI to new framework, is value as high then time needed for this project is usefull and don't have some much simpler solution which cover such functionality?

If you want to improve OW try to start on much simple project as enhancement of C run-time library to implement more POSIX functionality or you can implement changes for IP V6 etc. I think it is much usefull for OW users than get GUI on Linux with OW.
I work way if I want to compile something by OW I first implement missing functionality into C run-time library and next continue.
Looks on change for C run-time library and you will see that most of enhancements are adding POSIX functionality. But this functionality is mostly Linux specific but it should be implement for all supported targets.

[pchapin]

Open Watcom used to be able to compile wxWidgets, although there might have been restrictions. I did it personally, but it was long ago, and I don't recall the details. It would not surprise me if wxWidgets now requires a more modern flavor of C++ than Open Watcom can handle.

In general, I agree with Jiri's point: instead of trying to shoehorn some existing library into what Open Watcom can currently handle, why not improve the scope of Open Watcom's abilities? For example, what is it about wxWidgets that prevents Open Watcom from compiling it now? Perhaps we should address those deficiencies. It seems like that would give us more benefits in the long term.

[winspool]

OpenWatcom is too weak for wxWidget, see below.

trying to shoehorn some existing library into what Open Watcom can currently handle

What do you mean here?

why not improve the scope of Open Watcom's abilities?

• Do you mean to port all OpenWatcom GUI programs to use a different GUI Framework?
  (For example, FLTK ?)
  The latest stable FLTK release (1.4) for Linux/*BSD uses Cairo for graphics, pango for text,
  and the lowest level is either xlib (X11) or wayland. (FLTK_1.5 will need C++11)

  FLTK would still need some glue code on Linux, so that FLTK can find and use
  functions usually provided by X11.

  I never tried to compile X11 with OpenWatcom,
  but the lower level "libxcb" sounds possible.

• My intentinon was to:
  1: use "libxcb" for the lowest gui level on unix hosts,
  (similar how OpenWatcom uses "ncurses" for the lowest console level on unix hosts)
  2: add the glue code which uses calls to "libxcb" at the low level
  and provides an API that looks like the Windows API at the topmost level
  3: reuse the existing, tested Windows GUI code.

Since the Windows GUI code (Level 3) works
and OpenWatcom can compile libxcb (Level 1)(limitations: untested, no IPv6 support)
only the glue code (Level 2) with lots of tests/examples is needed.

This is doable, as "microwindows/nano-x" already did it:
The "microwindows/nano-x" Project provides multiple top level GUI APIs:

• X11 or Nano-X (own API) or MWin (Windows API subset)
  (even FLTK_1.3.4 is usable with the X11 compatibility library)

The "microwindows/nano-x" Project supports many Platforms.
Related to OpenWatcom are Linux, Windows and DOS (Even BIOS / VESA is supported)

The example configuration in the "microwindows/nano-x" source tree is for macOS running X11.
Many other combinations are possible.

Full architecture of Nano-X / Microwindows:
https://github.com/ghaerr/microwindows/blob/master/screenshots/Architecture-Microwindows.png

For example, what is it about wxWidgets that prevents Open Watcom from compiling it now?

Current wxWidgets needs a C++11 compiler
While OpenWatcom might be able to compile an old wxWidgets
(wxWidgets 3.2 needs C++98) this will be Windows only.

On Linux, wxWidgets needs GTK and GTK needs X11 (or wayland).
(wxWidget on macOS (10.10 or above) needs Cocoa)

Regards ... Detlef

[pchapin]

I think I misunderstood the problem you are trying to solve. You are looking for a way to build the Open Watcom GUI applications on Linux. I thought you were looking for a GUI library that Open Watcom users could use to develop their applications. I realize that a solution to the first problem could also serve as a solution to the second one. However, I imagine some users would be reluctant to build applications against an Open Watcom-specific solution.

In any case, my comment about shoehorning an existing library was intended to suggest that if the existing well-established libraries require features Open Watcom doesn't support, the best solution might be to extend Open Watcom so that it does support those features (e.g., by adding C++ 11 support if that's what's required).

However, in light of what I now understand you to be saying, I see that you are seeking a way to integrate Open Watcom's existing GUI calls with an underlying Linux library, allowing the Open Watcom tools to be built with a minimum of changes. I can't comment on the specifics of your proposal since I'm unfamiliar with the technology, but it sounds reasonable!

[winspool]

about libX11:
I have xlib examle programs working
(hellox11 and a modified program from the xlib tutorial)
to better understand, how X11 works and how X11 uses libxcb and libXau.

OW can build most parts of libX11 but the resulting "libX11.a" is >825k.
That looks like a possible roadmap (for later) to build existing GUI toolkits with OW,
since Linux GUI toolkits are usually build on top of libX11.

about libxcb:
The xcb example on the wikipedia page works
For improving my knowledge about libxcb,
I wrote a test program for some basic features of libxcb.

about libX11 or libxcb glue code in bld/gui:
I would like to avoid >825k of libX11 for the OW tools and for that reason,
my preferd roadmap to implement the glue code is on top of the lower level "libxcb".

about lib/gui:
For future training with bld/gui, i implemented a "Mines" programm
with a minimal UI (key + mouse input, text output) on top of the linux console.

$ ls -al mi* -rw-rw-r-- 1 detlef detlef 32334 Jun 3 22:41 mines.c -rwxrwxr-x 1 detlef detlef 22336 Jun 3 22:43 mines_gcc -rwxrwxr-x 1 detlef detlef 21288 Jun 3 22:43 mines_gcc32 -rwxrwxr-x 1 detlef detlef 70099 Jun 3 22:42 mines_owcc -rwxrwxr-x 1 detlef detlef 20626 Jun 3 22:41 mines_tcc -rwxrwxr-x 1 detlef detlef 14652 Jun 3 22:41 mines_tcc32 

After the UI part and the game logic of "Mines" works correctly now,
my roadmap is to port the UI part of "Mines" to use the bld/gui ('gui.lib') API,
before touching any GUI tool in OW.

[st-hansdraugen]

My two cents:

The internal OW GUI API is not general at all, and has little/no documentation. It gives a very minimal/primitive level of GUI portability in Windows and OS/2 (because they are similar), limited to (less than) exactly what the OW GUI tools needs. I find the goals in this thread very commendable, but fear that an X11 based "solution" will result in less than hoped for, especially for the long term. It could end with something working, but it will be "ugly" and hard to maintain no matter what. X11 is (like it or not) being shunned by the big players, Wayland is their preference for the future.

The base challenge is that OW does not use Linux (gcc produced) shared runtime libraries. So no matter how a bridge is made (sockets based bridge is a possibility), it could still lead to problems for libraries making assumptions in API of shared file handles from the same C runtime as an example. Any bridging effort should take such dependencies into account before starting. The full GTK API may have such assumptions baked in (may be wrong, based on my bug prone memory).

I have looked at a LOT of possibilities, both with OW tools and OW user API usage potential in mind. One (maybe not so obvious) way is to go all text based UI, based off a combination of something like PDCursesMod + something like Turbo Vision 2.0 or a better menu / windowing alternative based on C rather than C++. Another is to focus a bridge construction for a C based GUI API that already covers most platforms OW cares about, but is designed to not depend on a common C runtime or C++ based API.

The (to my estimations) best and most future proof is to base any effort on a library with a C based API, with premade support for what is needed for the OW GUI tools, and potentially useful to other OW users, find a way to bridge the OW compiler to it on Linux/unix, and port the OW GUI tools to support it. The most likely candidate I have found for such an effort is IUP. It supported the Watcom compiler in earlier versions. It currently supports GTK and WIN32, but used to support Motif too. It has unmaintained/unfinished implementations for other platforms (quite similar to OW in that regard ;-) ). It is MIT licensed, and team seems to be welcoming outside interest.
https://www.tecgraf.puc-rio.br/iup/

[winspool]

My two cents:

The internal OW GUI API is not general at all, and has little/no documentation.

Yes, the gui documentation is sparse. Working with it takes longer as expected.

It gives a very minimal/primitive level of GUI portability in Windows and OS/2
because they are similar), limited to (less than) exactly what the OW GUI tools needs.

Exactly. That's why it's in the tree and not a huge standalone framework.

The base challenge is that OW does not use Linux (gcc produced) shared runtime libraries.

Not really, I see that an advantage of OpenWatcom.
(As long as OpenWatcom can compile the source)

I have looked at a LOT of possibilities,

/me too

based off a combination of something like PDCursesMod + something like
Turbo Vision 2.0 or a better menu / windowing alternative based on C rather than C++.

I do not see a need to replace the character mode TUI.
Only fixing the reported issues is needed.

The most likely candidate I have found for such an effort is IUP.
It supported the Watcom compiler in earlier versions.
It currently supports GTK and WIN32, but used to support Motif too.
tecgraf.puc-rio.br/iup

I looked at it: Far too high level and far too big.
It depends on GTK and GTK depends on xlib, which is also big.

Connecting bld/gui to a graphical unix backend has to be very slim.

[NishiOwO]

I've been developing my own GUI toolkit that compiles on Watcom (at least for GDI backend), might be able to help GUI thingies.

[jmalak]

I think that some low level interface to X11 or similar low-level API should be enough, because GUI API is based on events and it needs to implement handling of following GUI Events

GUI_INIT_WINDOW, GUI_INIT_DIALOG, GUI_NOT_ACTIVE, GUI_NOW_ACTIVE, GUI_MOVE, GUI_RESIZE, GUI_ICONIFIED, GUI_FONT_CHANGED, GUI_PAINT, GUI_KEYDOWN, /* keystroke messages */ GUI_KEYUP, GUI_KEY_CONTROL, GUI_SCROLL_UP, /* scrolling messages */ GUI_SCROLL_PAGE_UP, GUI_SCROLL_TOP, GUI_SCROLL_DOWN, GUI_SCROLL_PAGE_DOWN, GUI_SCROLL_BOTTOM, GUI_SCROLL_VERTICAL, GUI_SCROLL_LEFT, GUI_SCROLL_PAGE_LEFT, GUI_SCROLL_FULL_LEFT, GUI_SCROLL_RIGHT, GUI_SCROLL_PAGE_RIGHT, GUI_SCROLL_FULL_RIGHT, GUI_SCROLL_HORIZONTAL, GUI_CLICKED, /* menu or control clicked */ GUI_CONTROL_DCLICKED, /* control double clicked */ GUI_LBUTTONDOWN, /* mouse messages */ GUI_LBUTTONUP, GUI_LBUTTONDBLCLK, GUI_RBUTTONDOWN, GUI_RBUTTONUP, GUI_RBUTTONDBLCLK, GUI_MOUSEMOVE, GUI_TOOLBAR_DESTROYED, /* toolbar messages */ GUI_TOOLBAR_FIXED, GUI_TOOLBAR_FLOATING, GUI_CLOSE, GUI_DESTROY, GUI_HSCROLL_NOTIFY, GUI_VSCROLL_NOTIFY, GUI_CONTROL_NOT_ACTIVE, GUI_CONTROL_CLICKED, /* control clicked */ GUI_INITMENUPOPUP, /* popup menu about to open */ GUI_CONTROL_RCLICKED, /* control right clicked */ GUI_DIALOG_ESCAPE, /* escape was pressed in a dialog */ GUI_STATUS_CLEARED, /* the text in the status line was cleared */ GUI_QUERYENDSESSION, /* the windowing system is asking if we can close */ /* if you return false your session indicating that it is OK by it to shutdown the windowing subsystem */ GUI_ENDSESSION, /* the windowing system is telling us we must close */ GUI_KEYTOITEM, GUI_ACTIVATEAPP, GUI_CONTEXTHELP, /* the F1 key has been pressed */ GUI_TIMER_EVENT 

Probably some of these events has trivial solution.
But it needs somebody with good knowledge of X11 or other API to implement it.
My knowledge about it is zero.