Re: [Libcdio-devel] [PATCH] Remove unnecessary high-memory safe wrapper for DosDevIOCtl() on OS/2

[Rocky Bernstein]

> Unfortunately, kLIBC v0.6.6 uses the same name as my wrapper.

I see that SafeDosDevIOCtl went in libcdio August 2014 and was in the 0.93
release in September.  kLIBC 0.6.6 was released the next month in October
2014. How is it that they happened to use exactly that same very specific
name?  Given this has been this way for two years already, it doesn't feel
like this is a pressing issue that has been bothering a lot of people. And
why didn't you mention this earlier?


Let's go back to our correspondence two years ago:

You:

Hi/2.
> Rocky Bernstein wrote:
> > Ok, then you can be responsible for OS/2 . That means that you will be
> > *expected to test, in advance, releases*. [emphasis added] Note that
> this is a change from the
> > laxness we've had in the past with respect to releases.
> >
> No problem.
> > If you disappear and there is no one else to take responsibility, the
> > ability to test OS/2 disappears, then OS/2 support in libcdio may
> disappear
> > as well.
> >
> Ooops... I feel the very much responsibility. ^^
>
>
Ok. There was a release this year and that would have been an ideal time to
get this change in. You blew it.



So what I wrote in over two years ago is still true:

About a month and a half ago we were discussing dropping libcdio's OS/2
> driver altogether.  See http://lists.gnu.org/archive/html/libcdio-devel/
> 2014-06/msg00004.html
> What motivated this was the desire to change the API to add get_track_isrc
> and Robert Kausch mentioned he had no way to test OS/2. In that, we
> realized that basically no one *is* actively testing OS/2.


And that is still feels like the situation now.  There have been API
changes and there are ones that may come up.

In the past, I suggested setting up libcdio developer access to OS/2. That
hasn't happened.

So given the history, your lack of involvement and commitment, the
smallness of the OS/2 libcdio community, the lack of libcdio developer
access, and the general lack of libcdio resources,  I feel like you and/or
Portia should be the maintainers of OS2 libcdio. I'll be happy to
contribute to that.

That said, I welcome comments from you and other people on the libcdio
developers mailing list.


On Tue, Nov 29, 2016 at 6:55 AM, KO Myung-Hun <address@hidden> wrote:

> Hi/2.
>
> Rocky Bernstein wrote:
> > At the risk of going down a rabbit hole of OS2 stuff which I doubt many
> > people use, (you are the only one I am aware of that has *ever* used
> > libcdio), I wonder about this. Is there harm in having the wrapper there?
> >
> > The last OS2 release was in 2000 with and end release date of 2006, a
> > decade ago.
> >
> > Removing the code above would force people to use
> > <https://trac.netlabs.org/libc>kLIBC v0.6.6 <
> https://trac.netlabs.org/libc>,
> > which I guess is an add-on.
> >
> > I'd be grateful if you'd explain the harm of keeping the old code.
> >
>
> Unfortunately, kLIBC v0.6.6 uses the same name as my wrapper. So call to
> the wrapper leads into 'not enough memory' due to a recursive call.
>
> kLIBC v0.6.6 has backward compatibility. As well as kLIBC v0.6.6
> provides older versions of DLLs forwarding to v0.6.6. So even if people
> upgrade their kLIBC to v0.6.6, they will not encounter any problem at
> all. And most of all OS/2 users are already using kLIBC v0.6.6.
>
> Not enough ?
>
> --
> KO Myung-Hun
>
> Using Mozilla SeaMonkey 2.7.2
> Under OS/2 Warp 4 for Korean with FixPak #15
> In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
>
> Korean OS/2 User Community : http://www.ecomstation.co.kr
>
>
>