ELKS port

[rafael2k]

First of all - thanks @jhhoward for the wonderful browser you develop!

We are discussing in ELKS (Linux-8086) forum ghaerr/elks#2185 about a graphical browser for the system. Do you see any problems we might have porting to ELKS?

We'll use the watcom compiler and the large memory model, the direct hardware graphics access is fine on ELKS, but DOS calls we'll need to substitute by ELKS counter parts, and also the network code, to use the Linux-like ELKS api.

[jhhoward]

Thanks for taking an interest in MicroWeb!

I've actually been keeping a close eye on the ELKS project and I've been considering porting MicroWeb to ELKS, but I haven't looked too deeply into how to set up a development environment for ELKS on Windows.

If there is already a supported way of using the OpenWatcom compiler, I believe it should be relatively straightforward to port. The video, networking and input systems are abstracted through driver classes, so you would need to implement ELKS API versions of these. For direct hardware access, you can probably use the same video driver as DOS.

The other part of the codebase to be aware of is the EMS and disk swapping memory management system inside MemBlock.cpp. All of the EMS stuff is inside #ifdef DOS blocks already but if ELKS provides an API for accessing EMS you'll need to update that too. EMS and disk swapping is all optional though so you don't need it enabled to get a port up and running.

There is a Win32 version build that compiles in MSVC which is useful for debugging the HTML parsing / rendering. I haven't looked into the networking API for ELKS but if it is similar to BSD sockets, there is a Winsock implementation for the Win32 build that would be a helpful reference.

[rafael2k]

Thanks for the message @jhhoward ! This is very valuable information.

Indeed, ELKS was adapted to support OpenWatcom: https://github.com/ghaerr/elks/wiki/Using-OpenWatcom-C-with-ELKS.

Winsock is indeed very similar to BSD sockets, and that is what ELKS use - wonderful!

Next week I'll try to put up a build system for MicroWeb targeting ELKS as a starting point (dunno if using watcom make or gnu make).

ps: I can make a copy of ELKS watcom-compiled libc and the headers, and as so I think it would be enough for your watcom build setup to build for ELKS. I'll do some tests here.

[toncho11]

I use WSL2 on Windows and it provides a perfect build setup for ELKS.

[ghaerr]

If there is already a supported way of using the OpenWatcom compiler, I believe it should be relatively straightforward to port.

ELKS fully supports the OpenWatcom C compiler, but currently has no support for the OW C++ compiler. @rafael2k is working on that, and I imagine the success of that will depend on how deeply MicroWeb uses specialized C++ features or class libraries. ELKS doesn't use any of the OpenWatcom C library, the entire C library comes from ELKS and is thus completely compatible with our other supported compiler(s). This all means that all/any C++ library code will have to get pulled out of OW's C++/C library, which could be in conflict with ELKS libc, especially in the areas of memory management, exception handling, and RTTI.

The video, networking and input systems are abstracted through driver classes, so you would need to implement ELKS API versions of these.

In general, ELKS is Linux, and supports the same general APIs as Linux/UNIX, and no DOS APIs. All input has to come from opening regular or special files (mouse/keyboard etc), and interrupt trapping by user programs is not allowed.

if ELKS provides an API for accessing EMS

There is no ELKS support for EMS. This has been a long discussion, and it has been determined that each and every EMS card would have to have a special driver written for it. We can't easily run any DOS EMS drivers since there is no DOS system call support, and ELKS is multitasking whereas DOS doesn't do task switching.

EMS and disk swapping is all optional though

That's nice. The disk swapping sounds interesting, does that just automatically handle writing data to/from disk when memory runs out? We suffer the same limitations as DOS (or worse) given that everything's got to fit in 640K + UMB memory. There are some options for ELKS running in "unreal mode" to support access to XMS memory of any amount - but currently this implementation is exclusively for kernel data buffers, as they don't have to be directly accessible and are copied in/out of main memory as the system needs them.

I haven't looked into the networking API for ELKS but if it is similar to BSD sockets,

Yes, ELKS supports BSD sockets, which should be pretty compatible with old Winsock.

[jhhoward]

Ok it sounds like the lack of C++ support is going to be the biggest challenge. Fortunately, MicroWeb is mostly written more like a 'C with classes' style and doesn't rely on features such as exceptions or RTTI. Standard C library functions are used instead of C++ ones too. Placement new is used so support for that will be required.

The disk swapping is more experimental but just uses standard C file I/O calls. Currently the page 'tree' has to exist in conventional memory but the text / image data can be stored in EMS / swap.

One other thing to consider is how mouse cursor rendering is supported. In DOS, the mouse driver can do this for you when an interrupt fires on the mouse moving. Depending on how it works in ELKS, maybe MicroWeb would need to do its own rendering.

[toncho11]

Is the UI only VGA programming? If yes, then it should not be a problem - ELKS just need the base of the video memory to manipulate it and draw whatever needed.

[jhhoward]

There are a number of supported video modes, would ELKS automatically handle mouse cursor rendering for non VGA modes such as CGA or Hercules too?

[toncho11]

The cursor should be rendered by the application itself. I think VGA support should be the first step as we do not know how many other port difficulties there will be.

[ghaerr]

One other thing to consider is how mouse cursor rendering is supported. In DOS, the mouse driver can do this for you when an interrupt fires on the mouse moving.

Yes, this would be another issue, thanks for bringing that up, . Currently, the ELKS kernel doesn't know anything about mice or graphics cursors. The Nano-X server is just another application, and it contains its own mouse and screen drivers, and handles all cursor hide/show etc relieving any responsibility for the client applications to do so. Centralized cursor (and graphics) management is required because of overlapping windows and multiple applications, etc.

For standalone applications, there's a tiny library available that switches to a few VGA/EGA/CGA modes, contains very basic line and point drawing, and also contains linked-in mouse drivers, but no cursor drawing. As you know, cursor management can get complicated when mixed with drawing routines. I kind of like the idea of having a cursor drawn for the application like the DOS mouse driver does, so that applications don't have to worry about it.

Overall, ELKS has just gotten to the point where issues like this are being discussed. A month ago, ELKS only had an ancient version of Nano-X that was quite small, but didn't support multiple applications connecting, so it wasn't really a window manager but more of a graphics library. Now, we've got the modern Nano-X running, but have also produced some tiny graphics libraries that are mostly being used for image output, not interactive application building. So it remains to be seen what approach should be taken to bring forward more complex graphical applications. I had originally envisioned using Nano-X, but I think that will likely be too complicated for something like MicroWeb.

I agree that C++ support is the main issue at this point, so we'll see what's entailed to getting that working.