OS/2, eCS & ArcaOS - General > Polls

Compatibility with OS/2

(1/9) > >>

RickCHodgin:
I'm mapping out the features that will be supported with ES/2.  I would like community feedback on how important some features of OS/2 are, such as 16-bit support?  16-bit and 32-bit Win-OS/2 support?  16-bit and 32-bit DOS support?

In addition, what are some must-have's in moving forward?  64-bit is a given.  But what else?  What is OS/2 lacking that would be needed in moving forward?

ivan:
Rick, I don't think there is a definitive answer because any answer depends on usage.

For example, the manufacturing plants that my old company looks after are using OS/2 to run the machine tool controllers, all of which are 32bit programs and physical PCI cards.  Almost all of the computers now use 64bit processors (the remaining few should be upgraded by the end of the year).

In that instance, as long as a 64bit OS/2 clone will still run 32bit OS/2 programs and act in the same way as OS/2 does at the moment (high stability, up running for several months at a time and operators don't need retraining) I think the company could sell them on the upgrade with little or no certification problems.

RickCHodgin:

--- Quote from: ivan on November 06, 2017, 10:08:57 pm ---Rick, I don't think there is a definitive answer because any answer depends on usage.
--- End quote ---

My thinking is this:  For full compatibility we have avenues like ArcaOS or eCM which are moving forward to support modern hardware with full binary compatibility on all DOS + OS/2 + Win-OS/2 code.  But in moving forward with a fully open source kernel, drivers, and app stack, I am wondering if we need full compatibility on the new product?

Would it be enough to allow existing OS/2 code to recompile from source code in ES/2 and then run in that environment the same way?  In that way OS/2 apps can be recompiled and run natively in ES/2 as they have, but will not be binary compatible.

My personal goal is to allow most all existing OS/2 code to recompile with no to very little refactoring.  I want to keep everything pretty much standard with the existing OS/2 design, but there will be changes here and there.  The extent to which I change things will be influenced by this poll.

Doug Bissett:
You know that there is another approach to this.

If you look at the whole situation, the only reason why we think we need a 64 bit OS, is to run the bloated crap that is ported from other platforms (Mozilla, Office clones etc.). We have lost the ability to create compact, efficient, software for OS/2.. We are also very close to losing the ability to create drivers for modern hardware. Unfortunately, part of that is that the manufacturers won't reveal their secrets, but Linux seems to be able to get the required information, so it isn't impossible.

The OS/2 kernel is still very powerful, even without 64 bit. All it needs are some new programs to replace the crap that comes from elsewhere, and new drivers to run new hardware. A new, 64 bit, clone of OS/2 sounds impressive (and it would be very impressive, IF it can be done), but the software to run is old, and it is that old software that actually keeps OS/2 going, so complete compatibility is required, or there is no point in doing it.

Currently, there has been a break though, by using the technique to use memory above 4 GB, as pioneered by the QSINIT package. That is only the beginning of what could be done to use the expanded memory space. An API to be able to use that would solve a lot of the memory constraints, and the kernel doesn't need to get involved. Many more things can be done.

RickCHodgin:

--- Quote from: Doug Bissett on November 07, 2017, 12:11:53 am ---You know that there is another approach to this.

If you look at the whole situation, the only reason why we think we need a 64 bit OS, is to run the bloated crap that is ported from other platforms (Mozilla, Office clones etc.). We have lost the ability to create compact, efficient, software for OS/2.. We are also very close to losing the ability to create drivers for modern hardware. Unfortunately, part of that is that the manufacturers won't reveal their secrets, but Linux seems to be able to get the required information, so it isn't impossible.

The OS/2 kernel is still very powerful, even without 64 bit. All it needs are some new programs to replace the crap that comes from elsewhere, and new drivers to run new hardware. A new, 64 bit, clone of OS/2 sounds impressive (and it would be very impressive, IF it can be done), but the software to run is old, and it is that old software that actually keeps OS/2 going, so complete compatibility is required, or there is no point in doing it.

Currently, there has been a break though, by using the technique to use memory above 4 GB, as pioneered by the QSINIT package. That is only the beginning of what could be done to use the expanded memory space. An API to be able to use that would solve a lot of the memory constraints, and the kernel doesn't need to get involved. Many more things can be done.

--- End quote ---

As I understand it, there is a legal barrier in what we're able to do with the existing OS/2 kernel and drivers.  We are not allowed legally to reverse engineer anything, or to perform binary patches.  Arca Noae was able to get a license to do that for their new release of OS/2, but for the rest of us it's out of bounds.

Can we move forward legally extending the OS/2 kernel?

I've been looking at the OS/2 API and there are parts of it that are daunting, but I know if I can get the base framework developed and begin coding the functions, then other low-level OS/2 developers will come on board and help with completing all of the functions.  I'm also hoping that many original OS/2 developers from IBM will see this project and, in their retirement, come forward and offer their assistance, knowledge, and insight.

I really want to move us forward with a new kernel.  And if full compatibility is a must, then that will be my target ... but I honestly don't know if I can do that because of the legal barrier.  I would have to have intimate knowledge of how things work, and without reverse engineering, decompiling, and examining how the binaries work, I don't think it's attainable legally.  It's why my goal has been to reproduce the entire environment, allowing for recompiles of existing source code with little or no change, but that the OS/2 binaries would not work on ES/2 systems, or vice-versa, except in simple app cases where everything is runtime linked.  But for drivers, and more complex apps it would require the recompile.

Navigation

[0] Message Index

[#] Next page

Go to full version