nanogui: Thread: support for 16bit / minix2 ?

Hello,

Background:

I am looking for an environment compatible with the legacy 16-bits
*nix-like OSes, because of the efficiency of smaller platforms,
as long as the task fits the limitations.

Many of those OSes are free now (e.g. Venix) but unfortunately the
support for 16-bit Intel apparently has been lost forever (?).
(Venix/[2]86 and its clones like a Venix-ABI-compatible BSD2.9 port to x86
made by some guy in Russia in early 1990-s are not available anywhere).

I used to use multiuser Venix/86, even occasionally ran a spreadsheet
with graphic output (no, not with Nano-X). Swapping and transparent code
segment overlays made the OS quite capable for those days's applications.

Minix2 does not exactly work like that but anyway it comes quite close.

My questions are:

Is there any working support for Nano-X under Minix2?
Just in case, support for any other 16-bit *nix?

What I found is http://minix1.woodhull.com/microwin.html
which states that there was an unfinished effort
dated 2002-10-23.

Was there any Minix-related work done after that?

How much did Nano-X change since then to make the old effort relevant
regarding the current code?

Best regards and thanks for keeping the small and nice tools
like Nano-X alive.

Rl

> 
> Is there any working support for Nano-X under Minix2?
> Just in case, support for any other 16-bit *nix?

It's been a long time, I think someone did a Minix port though.

I added support for a bare-bones hardware version that ran
on 80x86 processors in real mode.



> 
> What I found is http://minix1.woodhull.com/microwin.html
> which states that there was an unfinished effort
> dated 2002-10-23.
> 
> Was there any Minix-related work done after that?

Probably not, but you should check the release notes to make
sure. I think they're up on the ftp site outside the tarball.


> 
> How much did Nano-X change since then to make the old effort relevant
> regarding the current code?

The biggest issue was that the code segment was limited to 64k, 
(and data to another 64k), and there were lots of optimizations
as well as features not added in order to stay within that.

Somewhere along the line I indicated that support would be ended
for these systems (v0.86 or so?). After that, the architecture itself
didn't really change, except that we never measured the size of the
segments nor maintained backwards compatibility with those compilers.
At some point we started taking advantage of the gcc compiler extensions
and optimizations.



> 
> Best regards and thanks for keeping the small and nice tools
> like Nano-X alive.
> 

Let me know if I can help.

Regards,

Greg

Thanks Greg for your reply,

On Tue, Jun 25, 2013 at 04:34:25PM -0600, Greg Haerr wrote:
> > How much did Nano-X change since then to make the old effort relevant
> > regarding the current code?
> 
> The biggest issue was that the code segment was limited to 64k, 
> (and data to another 64k), and there were lots of optimizations
> as well as features not added in order to stay within that.
> 
> Somewhere along the line I indicated that support would be ended
> for these systems (v0.86 or so?). After that, the architecture itself
> didn't really change, except that we never measured the size of the
> segments nor maintained backwards compatibility with those compilers.
> At some point we started taking advantage of the gcc compiler extensions
> and optimizations.

I see.

> > Best regards and thanks for keeping the small and nice tools
> > like Nano-X alive.
> Let me know if I can help.

Regretfully, I probably will not undertake reviving the development for
16 bits-systems.

(For better or worse, nowadays it would hardly have any practical value)

Otherwise, as I see it, platforms' limitations do not necessarily lead to
limitations in fuctionality, but possibly to a more resource-efficient
design. Having done a lot of production work on 16-bit systems before
the 32-bit era I know they are quite capable.

Thanks for your work on Nano-X.
Rl