Author Topic: OS/2 application developers  (Read 22086 times)

A. Demetrious Sharpe, Sr.

  • Newbie
  • *
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: OS/2 application developers
« Reply #15 on: December 08, 2017, 09:34:38 pm »
To answer the original poster's question, I want 64-bit OS/2 API to permit the implementation of libc and the rest of the netlabs RPM repository that would permit 64-bit compilation of newly ported open-source programs from other 64-bit platforms. Browsers, Office Suites, e-mail clients, image and movie editors all use too much 32-bit resources and need to be extended.

For most of the OS/2 32-bit API, I'd just want it to still work or be accessible through a 64-32 bit translation layer so existing code would recompile more easily.

Fair enough.

This is the type of feedback that I'm looking for!

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: OS/2 application developers
« Reply #16 on: December 08, 2017, 10:09:54 pm »
Related to Neils post, it would be nice to have an up to date Posix layer including working full mmap, copy on write etc and better shared library support, no 8.3 limit, the capability of symlinking shared libraries and even versioned symbols. Using ELF would probably supply all this.

A. Demetrious Sharpe, Sr.

  • Newbie
  • *
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: OS/2 application developers
« Reply #17 on: December 08, 2017, 11:02:12 pm »
Related to Neils post, it would be nice to have an up to date Posix layer including working full mmap, copy on write etc and better shared library support, no 8.3 limit, the capability of symlinking shared libraries and even versioned symbols. Using ELF would probably supply all this.

Thank you.

Alfredo Fernández Díaz

  • Jr. Member
  • **
  • Posts: 55
  • Karma: +0/-0
    • View Profile
Re: OS/2 application developers
« Reply #18 on: December 16, 2017, 03:43:15 pm »
Not a "serious" application developer in OS/2 land, I've coded some here and there.

The OS/2 API seems more than capable for everything I have wanted to do, I missed nothing -- I don't do 3D multimedia animation, or anything that flourished after the API was fleshed out, where I suspects most real lacks (if any) must lie. Sometimes the API forces doing things in a way that seems strange to me, but that may be because I'm not familiar enough with it. However, as the large file API has been mentioned, I'll say I'd like to see a 'clean' approach in some areas, *if* it's possible, and I'll use that as an example:

When file sizes were limited to 2GB, file position pointers, etc. could be expressed by a four-byte natural number (2^32 = 4GB), and that's the size of most file handling API arguments at the time. Support for anything beyond that "naturally" required new functions with would allow wider arguments, hence we have a parallel file API for large files.

From my point of view as a non-specialist in low-level implementation of such APIs, I'd like to have one working set of file APIs that would do its thing according to argument size (> vs <= 32 bits for starters), and any necessary redirecting APIs to address legacy applications. All APIs should be 'open' regarding that (argument size, or even number) if I am getting the point across (am I?). The FTP protocol comes to mind to further illustrate the point: at some point we needed newer clients and servers that could do 'huge' files; no protocol changes were necessary because that was handled in a more future-proof way (IIRC file size is transmitted as a decimal string, so any limitations of that are WAY into the future).

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: OS/2 application developers
« Reply #19 on: December 18, 2017, 02:13:24 pm »
Today, every application should use the "L" type of functions: DosOpenL, DosSetFileSizeL, DosSetFilePtrL, etc.
DosOpenL has a special parameter "OPEN_SHARE_DENYLEGACY" that will allow application A to open a file > 2 GB (if the filesystem supports that) while preventing application B to open shared that very same file via DosOpen (and therefore restricting itself right from the outset). Of course, the intention is to assure that BOTH applications can access the whole file.
Of course, the "L" variants will ensure that the underlying filesystems' capabilities (to support files > 2 GB) are completely transparent to the application. If the underlying filesystem does not support files > 2GB you will get an error if you attempt to create a file > 2 GB or try to access a fileoffset > 2 GB.

That's about as good as it gets. I was talking about the native OS/2 API. If you need proper RTL support (fstat, fstat64 etc.) then you would need to invest more effort.

In the year 2017, applications should be able to assume they are running on a kernel supporting the large file API and they should never ask for less.

1) Use "L" APIs, in particular DosOpenL
2) use "OPEN_SHARE_DENYLEGACY" on the DosOpenL call
« Last Edit: December 18, 2017, 02:16:33 pm by Lars »

Alfredo Fernández Díaz

  • Jr. Member
  • **
  • Posts: 55
  • Karma: +0/-0
    • View Profile
Re: OS/2 application developers
« Reply #20 on: December 18, 2017, 02:54:14 pm »
What Lars said, 'only' everywhere.

In the year 2017, this being a mostly theoretical question anyway, applications should expect APIs with no duplicate functions except maybe for legacy application support, and that will hit no practical limits in the foreseeable future in a stupid way: if sizes of anything being handled (memory size? file name length? what have you) would overflow this and that, then do it some intelligent way: assume it can be presented as a series of chunks, or however, to applications that are not too stupid (or old). At a minimum, any such things we have seen in the past, we shouldn't see in the future.

Arithmetic precision in REXX is arbitrary at the expense of lengthier/slower operation. I know there is a difference between interpreted languages and implementing a (presumably) low-level API, yadda yadda,  but the basic principle I allude to is the same one again: handle things (especially things that are likely to change in predictable ways, like continually skyrocketing sizes of everything) intelligently.

Over and out :)

xynixme

  • Guest
Re: OS/2 application developers
« Reply #21 on: December 18, 2017, 03:41:33 pm »
Today, every application should use the "L" type of functions: DosOpenL, DosSetFileSizeL, DosSetFilePtrL, etc.

</silence>
Should. Not every development environment of every application is aware of a LONGLONG, and implementing your own LONGLONG variable is slightly harder than appending a reasonable L. If a development environment supports LONGLONG by default, then it resulted in a broken app (VAC3.08 -> VAC4FP2, IIRC).

I wish it was as easy as appending an L, and implementing my own LONGLONG is a bit over the top for an app which typically won't be used with huge files. Nevertheless I've looked at appending it, but it resulted in VAC4's fatal new errors.
<silence>

RickCHodgin

  • Guest
Re: OS/2 application developers
« Reply #22 on: December 18, 2017, 05:27:32 pm »
FWIW, ES/2 goals are to use:

#include <os2.h> for all legacy apps as they were with IBM's OS/2 Warp 4.x.
#include <os2_32.h> for any newly added 16-bit and 32-bit app extensions.
#include <os2_64.h> for all new apps (be they 16-bit, 32-bit, or 64-bit).

    UPDATE:
    I have also considered adding direct support for ES/2 using new programming extensions:
    #include <es2.h> for all new apps.
    Note:  This add-on extension will likely only appear in ES/2's own custom compilers.


os2_32.h will auto-include all new functionality added to 16-bit and 32-bit code, including any extensions added to existing functions.  These will be exposed under new names where appropriate, or extended from existing names where appropriate.

os2_64.h will auto-migrate each function to its 32-bit or 64-bit counterpart by default, while allowing legacy functions to be accessed under a different name.  It will also introduce any new functionality that will be exposed through extensions to the 16-bit and 32-bit areas, as with os2_32.h.

-----
I think the goal has to be to maintain full backward compatibility so that everything which previously worked still works as it did with zero changes in the new kernel.  And any new development can work with new features using familiar function names without special prefixes, but just adjusted up to their 64-bit counterparts where appropriate.

That's the goal of ES/2 at least.
« Last Edit: December 19, 2017, 11:04:31 pm by Rick C. Hodgin »

Andi B.

  • Hero Member
  • *****
  • Posts: 811
  • Karma: +11/-2
    • View Profile
Re: OS/2 application developers
« Reply #23 on: December 18, 2017, 05:40:47 pm »
Quote
</silence>
Should. Not every development environment of every application is aware of a LONGLONG, and implementing your own LONGLONG variable is slightly harder than appending a reasonable L. If a development environment supports LONGLONG by default, then it resulted in a broken app (VAC3.08 -> VAC4FP2, IIRC).

I wish it was as easy as appending an L, and implementing my own LONGLONG is a bit over the top for an app which typically won't be used with huge files. Nevertheless I've looked at appending it, but it resulted in VAC4's fatal new errors.
<silence>
Your a masochist if you're still developing new >2GB aware applications with VAC3.08. No serious application developer will do this. Did you forget the thread is about dreaming of an 64 bit OS/2? And you're talking about problems with a compiler from the last century.

Even for current OS/2 application development use VAC3.65 or VAC4 or even better OpenWatcom and gcc with os2tk45. And simply do -
Code: [Select]
#define INCL_LONGLONG

xynixme

  • Guest
Re: OS/2 application developers
« Reply #24 on: December 21, 2017, 02:50:22 pm »
</silence>

Phase -1: implement your own LONGLONG
Phase 0: add a wrapper, DosOpenL isn't always available

Easy phases 1 and beyond: append a L to DosOpen or replace DosOpen()

VAC4's fatal new errors

FWIW: calculated output was different, compared to C and REXX. It may be a VAC3.65/VAC4 bug, it may be some change of the C programming language. Since I'm not being paid by the hour I stopped trying to append the L, mainly because of phase -1 and the errors.

<silence>

xynixme

  • Guest
Re: OS/2 application developers
« Reply #25 on: December 21, 2017, 03:18:55 pm »
At a minimum, any such things we have seen in the past, we shouldn't see in the future.

Arithmetic precision in REXX is arbitrary at the expense of lengthier/slower operation.

</silence>

If one wants to promote DosOpenL as some new default, why not, then one has to make it easier to replace DosOpen/fopen/... by DosOpenL, regardless of the development environment (Cs, Pascals, BASICs, ...). Unfortunately it's harder than just appending the L.

I'm not sure there's such a thing as arithmetic precision in REXX, even if we ignore rounding due to NUMERIC DIGITS settings. No numbers, no arithmetic precision. With any programming language with 8-bit numbers you can compile a string which represents a result and stop when the length of the compiled string is N characters.

As such a proper design of DosOpenL isn't required. It's possible to use the best available API, which is e.g. DosOpen XOR DosOpenL. A wrapper takes care of that.

<silence>