OS/2, eCS & ArcaOS - General > Polls

Compatibility with OS/2

<< < (2/9) > >>

Dave Yeo:

--- Quote from: Rick C. Hodgin on November 06, 2017, 08:51:09 pm ---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?

--- End quote ---

With a 64bit kernel, 16 bit code simply will not run, the CPU design is such that in 64 bit mode, we lose access to 16 bit code running directly on the CPU. It would be possible to use DOSBOX or even VirtualBox to run 16 bit code in a virtualized environment, but it's not the same and if people want to do that, they may as well run OS/2 in one virtual machine as well.
Also our device drivers are mostly 16 bit, so there is no way to migrate to your new operating system and the truth is, without device drivers of some type to interface with computers, it wouldn't be possible to use it.

Valery Sedletski:
2dryeo:

This is not true. This is a common misunderstanding. 16-bit code works in 64-bit mode. Dixie, the author of QSINIT (aka Tetris) said that he safely uses 16-bit IDT/GDT entries together with 64-bit and 32-bit ones. This is EFI version of QSINIT. EFI is 64-bit here, and QSINIT uses some 16-bit routines. So, 16-bit code can coexist with 32-bit and 64-bit ones. Indeed, under "16-bit", many people mean 16-bit real mode code, not 16-bit protected mode code, as 16-bit OS/2 and Win16 are. So, VM86 processor mode won't work in 64-bit "long" mode indeed, but 16-bit protected mode code will work.

RickCHodgin:

--- Quote from: Dave Yeo on November 07, 2017, 01:47:05 am ---With a 64bit kernel, 16 bit code simply will not run, the CPU design is such that in 64 bit mode, we lose access to 16 bit code running directly on the CPU...
--- End quote ---

ES/2 won't only be a 64-bit kernel.  It will be able to boot into both 32-bit mode and 64-bit mode depending on settings, or boot-time overrides.


--- Quote ---Also our device drivers are mostly 16 bit, so there is no way to migrate to your new operating system and the truth is, without device drivers of some type to interface with computers, it wouldn't be possible to use it.
--- End quote ---

I intend to write a full driver suite, and to create tools to help others port drivers to support as much hardware as is possible from published sources.

My goals for ES/2 are comprehensive.  I'm not trying to hack together something, but to build a base that will be our operating system from here on out.  It is a real effort with real purpose and focus.

Doug Bissett:

--- Quote ---ES/2 won't only be a 64-bit kernel.  It will be able to boot into both 32-bit mode and 64-bit mode depending on settings, or boot-time overrides.
--- End quote ---

That really doesn't make sense. If a user needs to reboot to use older software, why would you need a new kernel? There are many options to do that already, and there are probably very few OS/2 programs that could be converted to 64 bit programs. In a lot of cases, the source is not available, so it would require a complete rewrite to make those programs work. Programs like OpenOffice, and Firefox, already run better in other operating systems.


--- Quote ---I intend to write a full driver suite, and to create tools to help others port drivers to support as much hardware as is possible from published sources.
--- End quote ---

Why don't you start with drivers, and make it possible to convert to 64 bit, when/if that feature becomes available. Today, we need a lot of new drivers. If we don't get those drivers, there won't be any need for a new kernel because the platform will be long dead (unusable), before the kernel becomes available. There are very few people, spending long hours, trying to keep OS/2 viable, and that doesn't include even dreaming about a new kernel. Today, we desperately need USB 3. eMMC,  GPT, WiFi, (although this one is under way), and more.


--- 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.
--- End quote ---

It is true, that you cannot reverse engineer the kernel (legally), however OS/2 is designed to be enhanced by simply replacing parts with new parts (Object oriented). Doing so is not going to cause legal problems, as long as you don't copy what somebody else did. Patches are a gray area. From what I understand, you are not allowed to patch something, then distribute the patched file (Arca Noae has an exemption, for OS/2 itself, but not for other things). It seems to be okay, if you distribute a patch that a user can apply to the original file.

As i understand it, one of the biggest problems with drivers, is that they need the device driver development package, from IBM (the DDK), and that is no longer available. Some people do have that package, and they can develop drivers, using it. If that package could be replaced, drivers would be easier to develop. In addition, I expect that there are more than a few DDK licenses, sitting idle, and those could be put to good use, if those who have them would donate them to somebody who can/will use them.

There isn't any point in putting a modern gas/electric hybrid engine in a model T Ford, if the tires are going to wear out next month, and they cannot be replaced. Better to find a way to reliably replace the tires, then worry about replacing the engine.

RickCHodgin:

--- Quote from: Doug Bissett on November 07, 2017, 04:21:21 am ---Why don't you start with drivers...
--- End quote ---

GNU did that back in the mid-80s.  They wrote replacement after replacement for Unix-based drivers + programs.  Fast forward to 2017 and they still don't have their own kernel ready for a production environment.  The GNU HURD is unstable, buggy, and not recommended for any type of use.

ES/2 will start with the kernel, then drivers, then apps.  It's a purposeful goal based off the truly excellent core design of OS/2.  It is something I believe in and have wanted for over 20 years.  The time is now.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version